From a78478443806e6afc5ecbb99aeb4cb33677f97ff Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Fri, 2 Oct 2009 17:53:51 +0100 Subject: [PATCH] Add documentation about migration. This adds a page documenting many aspects of migration: - The types of migration (managed direct, p2p, unmanaged direct) - Data transports (native, tunnelled) - Migration URIs - Config file handling - Example scenarios * libvirt.css: Rules for data tables and diagrams * Makefile.am: Include extra png/fig files * migration-managed-direct.fig, migration-managed-direct.png, migration-managed-direct.png, migration-managed-p2p.png, migration-native.fig, migration-native.png, migration-tunnel.fig, migration-tunnel.png, migration-unmanaged-direct.fig, migration-unmanaged-direct.png: Diagrams of migration * migration.html.in, sitemap.html.in: New migration doc --- docs/Makefile.am | 14 +- docs/libvirt.css | 48 +++ docs/migration-managed-direct.fig | 58 +++ docs/migration-managed-direct.png | Bin 0 -> 3901 bytes docs/migration-managed-p2p.fig | 58 +++ docs/migration-managed-p2p.png | Bin 0 -> 4004 bytes docs/migration-native.fig | 43 ++ docs/migration-native.png | Bin 0 -> 2173 bytes docs/migration-tunnel.fig | 49 +++ docs/migration-tunnel.png | Bin 0 -> 2237 bytes docs/migration-unmanaged-direct.fig | 58 +++ docs/migration-unmanaged-direct.png | Bin 0 -> 3951 bytes docs/migration.html.in | 601 ++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 + 14 files changed, 931 insertions(+), 2 deletions(-) create mode 100644 docs/migration-managed-direct.fig create mode 100644 docs/migration-managed-direct.png create mode 100644 docs/migration-managed-p2p.fig create mode 100644 docs/migration-managed-p2p.png create mode 100644 docs/migration-native.fig create mode 100644 docs/migration-native.png create mode 100644 docs/migration-tunnel.fig create mode 100644 docs/migration-tunnel.png create mode 100644 docs/migration-unmanaged-direct.fig create mode 100644 docs/migration-unmanaged-direct.png create mode 100644 docs/migration.html.in diff --git a/docs/Makefile.am b/docs/Makefile.am index 0b8f2269dc..5644fe2804 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -60,7 +60,12 @@ png = \ libvirt-driver-arch.png \ libvirt-object-model.png \ madeWith.png \ - et.png + et.png \ + migration-managed-direct.png \ + migration-managed-p2p.png \ + migration-native.png \ + migration-tunnel.png \ + migration-unmanaged-direct.png gif = \ architecture.gif \ @@ -85,7 +90,12 @@ fig = \ libvirt-net-physical.fig \ libvirt-daemon-arch.fig \ libvirt-driver-arch.fig \ - libvirt-object-model.fig + libvirt-object-model.fig \ + migration-managed-direct.fig \ + migration-managed-p2p.fig \ + migration-native.fig \ + migration-tunnel.fig \ + migration-unmanaged-direct.fig EXTRA_DIST= \ apibuild.py \ diff --git a/docs/libvirt.css b/docs/libvirt.css index 6e54b73163..5123ed68d7 100644 --- a/docs/libvirt.css +++ b/docs/libvirt.css @@ -364,3 +364,51 @@ span.since { font-style: italic; font-weight: bold; } + +img.diagram { + background: rgb(230,230,230); + border: 2px dotted rgb(178,178,178); + padding: 1em; + display: block; + margin-left: auto; + margin-right: auto; +} + +table.data th, table.data td { + padding: 0.3em; +} + +table.data { + border-spacing: 0px; +} + +table.data thead th { + background: rgb(178,178,178); + text-align: center; +} + +table.data { + border: 1px solid black; + border-collapse: collapse; +} + +table.data thead tr th { + border: 1px solid black; +} + +table.data tr.head th { + border-left: 1px solid black; + border-right: 1px solid black; +} + +table.data tbody td { + background: rgb(240,240,240); +} +table.data tbody td.y { + background: rgb(220,255,220); + text-align: center; +} +table.data tbody td.n { + background: rgb(255,220,220); + text-align: center; +} diff --git a/docs/migration-managed-direct.fig b/docs/migration-managed-direct.fig new file mode 100644 index 0000000000..59ae9969a1 --- /dev/null +++ b/docs/migration-managed-direct.fig @@ -0,0 +1,58 @@ +#FIG 3.2 Produced by xfig version 3.2.5b +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2775 2400 3675 2850 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 2775 2400 3675 2400 3675 2850 2775 2850 2775 2400 +4 0 0 50 -1 16 12 0.0000 4 150 570 2925 2700 libvirtd\001 +-6 +6 5400 2400 6300 2850 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 5400 2400 6300 2400 6300 2850 5400 2850 5400 2400 +4 0 0 50 -1 16 12 0.0000 4 150 570 5550 2700 libvirtd\001 +-6 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 3825 1200 3825 3000 1200 3000 1200 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5250 1200 7875 1200 7875 3000 5250 3000 5250 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5400 1350 6075 1350 6075 1950 5400 1950 5400 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 6225 1350 6900 1350 6900 1950 6225 1950 6225 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1350 3675 1350 3675 1950 3000 1950 3000 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2175 1350 2850 1350 2850 1950 2175 1950 2175 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 1350 2025 1350 2025 1950 1350 1950 1350 1350 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 4 + 1 1 1.00 135.00 180.00 + 4350 4275 4350 3600 3300 3600 3300 2850 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 4 + 1 1 1.00 135.00 180.00 + 4800 4275 4800 3600 5775 3600 5775 2850 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3225 4125 5850 4125 5850 6000 3225 6000 3225 4125 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 3375 5100 5700 5100 5700 5550 3375 5550 3375 5100 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 135.00 180.00 + 3750 5100 3750 4500 4050 4500 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 4050 4275 5100 4275 5100 4725 4050 4725 4050 4275 +4 0 0 50 -1 16 12 0.0000 4 150 870 6825 2850 Dest Host\001 +4 0 0 50 -1 16 12 0.0000 4 150 1080 1350 2850 Source Host\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 1425 1725 VM-A\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 2250 1725 VM-B\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 3075 1725 VM-C\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 5475 1725 VM-C\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 6300 1725 VM-D\001 +4 0 0 50 -1 16 12 0.0000 4 150 960 4725 5850 Client Host\001 +4 0 0 50 -1 16 12 0.0000 4 180 1500 3525 5400 management app\001 +4 0 0 50 -1 16 12 0.0000 4 150 735 4200 4575 libvirt.so\001 diff --git a/docs/migration-managed-direct.png b/docs/migration-managed-direct.png new file mode 100644 index 0000000000000000000000000000000000000000..f8fbb3aabfb710a343c49cce55316e0ad57834be GIT binary patch literal 3901 zc-pmB4K&kz-=FH1N?v-=Tp^{NUL+)WyHHC+hP;MmW@RBRjg{F@h`O&`cI9RAo=YZV z6vnVE6lJu+%-hgarWu>Idls{~*E#p|oacG2>pstYo^$SV{=d)f{C?+re{cWq_w)IF zA9#7VY~T9BRsaC7-SvW#Hvphgp=>AARFyME?MWhKrxNGw0s@fU>G70cmgSMd4G6I+4mHV3`xo@WC98cbKGv%U%Ai=3$Jnzjw9UdS4kj~&@( zyE-1JN_#0^pA6kOVt7Bw54FfS7Mk$cX#e|ip-dH!wX2Y*`%LxS6QL~BWMS@ByA9Wd zW4=Cg3T&ai4E8|Y+V%Opoi*2H!h9X?r}FYcx;CIo4e;MFnUK7cBUn#}*LiUczPGOq* z?MrX8KRF(pcQ}1%Zf;BxOODQ|I?5PAl^89Ak(!`X@uL*>&Gly3FnRGeefYeEc~4dT z7z(lzK8ZCtVZ!jA)y?>*$jPT(o0Y$d&S^OxNTi^}l<$_ZN6a!)yzE8s^oh0hx_r4x z%X8-J?t*|D@-eNhq%>BUE+*;iyFh{aMf#l1wXvEX;SA;w(?s@cB0Oe=NjRMT{%=V_ z&3%hsZnbZpZiVWj`#tqPLD-f@E1`VBgrYUXfonwx_bs)2lB*~-8K&ctxCItJ+XwBq z$asN5_wn*GL_oo3$7 zy;dvAmG@v!2x`>C667COx5Uzk_lBP>5NnIt;NVFZ(Am+4cA7mHF>xy%j)GW?b0m>D z@=JjP0^-DxDsKCe_8Htnc%)q}0>AQ@1-`8j)y{K3(QQSKm||VNN_D$6YN+l;B$vjl zZoId)T01aNy`74x4RZ}7A7QpHP@}nR?&_hfB;&;Z7XxwD!}YZr&F1-7qC-XXbXlS2 zRH#IwFcTf4t9o(HGN6?5Lhn+<0wubS$5`|!HAfDZwe=;VhRvbSL@npNWsrVLb1|Zn z3b1MET()k!>`kzoeG48+48cH_rsF0)=cHqq=f@y0K=UU%{H6?s@(bKI1}qB-|}FUX;AzjJ5ybwdrA8mWt`lZjJisl0a7jiA&agr0**0T z>}U7L@(T7@(rN+DE+hlwqB z5#Lce#g{oGL`v_y0v?9q&8L_K?IamWD^32eVoQbT0;r(o;7i4Qv#^}Bc7B_z6H${i&=I2(Bpt}q!i97x-aLm5D}x^NO%gX! z5<0Ki+HBQBMH)>Th{moeTB0Y2(G%gojQ{8vRqtM^+UJlGe!~Hdcq$Rju8G$>6|FQ< zO$xaNLF6_D$Xkh7*vL~5wepCG<$y-J%D?fOEuv?hBkT0fHqNOP*Wv}{g#x{0Aow;* z{uMH9v^kO#Aa+%Z-_>W1qy<0A32?Tgohl^7gtLun-Cv8SdO>jdTzQG)X(0vu3zc^I zH3OYz=Opkr@>7S!>gLgNBsgEE#{%WIvSKM=+2yY=8;z@JMQv*bP&*(@K62EC-5(rB_%#4)e?ROQ%a1g?if|px`epd0>87O^{5;hX#TuLMeGNOceBs-n zjeE$XSK>FtA_RkPwIUm-hAQ zG)Mz^d3+MvgsT5b@q76!xea~Z~aqK0Op&QZ{WfD1AEXQPg-FbL45 z~ecM5JM`NrE6z~61kOwM;}WzdL93I1KtpKVG@eW^Fa2-RW+d ztczo86`Sya9Sc#{bybuxtt6s<6V7mwpKXX#9;891kf_xCq%?vyAjtXpmg~Af>yNK( zQt}@F_HV(L`D#hi!P}toO0^u>fEbh}HR#ZW@P132jI#!En{(Sf*73ON&W=ai z_-DK>>)6$Wy{5DQZ_e0G+oHl-R zL?B2_%H*!kojEf1FwL-M^hvHjSeaW0gztpwm9R&VJsXs~1iedGAE;*zz+J~2zHX`z zVmuRBCsUbCezSYw#aR2Egr8R8AyzA6hmfP`T7v!7R*rQ>w7ZV`JCAmMzEsP*-?%=B z4BY92GPG|aH?c%#7;2|ANYvD)G_DW%@;I4Fhu*3%@eA2=Z1dqb_Q5};N$q=Q&+HIA~GNhC+$-T1GFxc94*X?3p_i=?&WHK7c$K%<7vhaTMT*8Q7v3sz>1{r$~=$C z3)sHsK6al_^2PrB$<*JF10Nrjxe|a=b)XI6XDIdRP+>AX^>gUF* zK5T1Ra-zkfkKm-H%y*$Fm8_Oq4i_0d1Q-b$yPKr@)t|!34&JqbOQ`1|XQ}6FVYMsI zOf;|ScB*0upJaS9RC$ zP>h7b_OS3TMZUSknXlgLhXtwWDxK)}CRkJD>MCQ*CEq0aJop~FDh~{Np01*f?f9|b zaR)*4)++S}*Gz(Tkn_ILlOV=@CIYbWe-t8_7EMKg-DU~lKN#YyT?|zgT&?u~cct>5 zsCTe(SQ$l*${an#jfxe$*759olX8fB+EQqrzokpfV}}!1EF3Zsc@CYTcRg)-?PEsd zQmc#z56m`{K7GP>{KY|9HOSX-cH=30=u;?;oT{g~5*HP8%!i>DJmt@D0;<@x{I$pZ zFN2p4IWA+^D6sOw-5fG}+P)yd#%Zx&YMw&)e=(s!YN9(31(7!JP10l6-4!VsMJJm; zYTyYn826QZ%14~A>r^ESD1iBx#w}3woNUyq2sVCGG@<>05QdudMKADMn6C!*X|PBA zk$OlTyTKrdtp}O~;Pjl7B=?F-+HSHX5BRBU=26jH2=Yr)w9L5UiV+CdnR(ybBScmZ z75ECczG-ACWvwA3d~A1s#&zohTH4MpRqHAysk=cyeVCPw`pURhsh~hBp_1io+PF~4 zIO~^1tnK!_xCOT9u;vpOFd5aJw;Mes@l((jbc%|?V+?%C3KFRb61rekD8a;uGYUV% zL;J7Wdid$;f~&6mSya2MKHo~4n8IhPT>d@fT&(`py+*=4%4!$jdfvl{1PV?4J3Rb%YA zA0tdLt?fklrs+CGm`|rrdNiBrc72ZKx+1K?&$dTx7Xk1S@ZaDpKiF311TZalP68Bu z0b}LU9atiiSL2&q-EY>qRGDQb{Qrm)MXFr}jx~aOyDbos>l> zEoJx+#GjuT!(3pt0x=F%pv#jIh$b=#Tz!FU*?*~0nvnjq+G=*bcG<0 zIH8;MvsI!$?hBdXz+y$|Fu|(>vFBGriBhs)H22&}buch3P_SLbC`(Hi&3kJMxz#ZB zOe&)aYjwv=#d#%|n4~H_R%EGga;s?7qWT0<8V&4I4>1SA-54?_+Sah8-nr7!<&2n5 zVK{EAusOGWr~&gL%f{&ZjH8I6D`@Y{Y`N2M73UN8>hi}>SM8&59e2G&wO>u%Z7i) zr-Qp-zlbixE5fC*5w4gEl|R>8A*wo?zBFU9a@_}CM}CXm(FC@GEB*)6pn+BDS-9KY z5?hA=qkSTOH}m^U&-eD8Y~|4E^8nSgA=_h?=U?R*94eVdy)+(x9%~GY8xc;1h>{&5 z5H(U^Egy>Pe$GZm2YDFnk;luysJPL=$RwkO*r{iIveZrZm_?6kMbmlsRhdm{q(ktH zE_>$024W>KUxMmfu}JUQ$02MSP{ilN*mGr6Xb$};#^2`f5~S$hks1#yn=+Ss54^?2 zbr9Ne3TQ7nxZPz4rumw+-t=1vYyCAIo$fSMXT`5Bp07!GA7nme(LWZxqQUAjYhNdN zce-UF9P`_e9+|(`l3`a<)wz77R9%(6zk=8NNANW$Z`kf4p)8OEzilLrzv{S~KsMBd z8WJ;D!Y+4B)gnOf+W&_0C6nq&QW023m2zceHe*Bcj6!a_gWR<1xe}7k4hb+G(nh z8M~VJtd!IO)@j5u!KozpDRcQlq?2-C=5RGx;?>UE;gXzQ4@&5KW$YN^DmW z+&(XeReJ)N&E3;(Obp`YHIe7X?&0Pqv(qtl#`YV7ubN0lDHeOqsz<8=GcY=8%$kdh zZWP#I*^L+);%|=JiFKL6dzLT%G2$GCSOx2tw8o=0hORitEUB10qBSk)^d@`bPg5`a z%|!mkwVY^Vto`Gc(!^hIWyPeSS09MnXo`FFOnpyaJzkl%o+hU?uyTZRxJy0)v=93O z3|aeiF6YN*1rj|zY)6QWy$IAd9Sp=L$Nmi)*G5m&>?nvECd;P_AX6fZw8k&#J|eox zyZs)V*0;b#a08p`gk8~*chFx)FWe;xV4U;yD|h>bRs;)`g%D|6b3;9&@^Yx37sV+g z!cVMrE^jMWb7oMk{-uxpDH}%2@)6J0lFrYNMJdFHVnyg=>@gYQShlfS(_$oVkeU_y z(PsToNVT63<;2;iOLxc|Z+jU>@}cYpfg<$W&E;XdDoSUA(}KizlH+M1@`t-MQsh@l zxdf)OL%4X_a;A56%CRLw{9$AldVu237|!kbT%(VZ%q`W7J*2VWPJurxX0<&@;-oF? z2T?xNNXaQn5vmZrvrmV&RfnQ0V!yg|lwdYiLCO^kd$ARc*xf_bSswffp|933fBHdE zEy>5#0(3sTtJh+LGx*|Zj7b4p)}Yo%$9rWrYD{MpYCm;Ru1l&IOhWoLAeUbpCU8>= z5bqR+Kl%gts6cYqK{O`%=P*w4FGXxii~&8u8!%+#j7Eo44Du?gWZuh5y;v71?Hn(5 z0Kc7vvTw+*YaXZew%S3fOA;ItLGnTBWa9I7Zh#GU%D3pz-64o6hhUY^v41duJ(2Tl za!6W!q>Y7ad-u^XfVzA=94jwKutP_XE!BfV6Ut;_eHY|RYFFHiu0A5GD90jcyzPl) zTcv9|%T=UbkTCH8%lmpExc0#H^nf@)D?4GM&ol}CIIc%+HcC}7gMW{D(&oib|IRa< z%54=!YTvAD0hC#@wXh%EvHk;%v(H1inV9T@r0seDy+>_`2>DcY= z3UbUH2SENEh5bK~&I9HB8bGKU&^A#Wpc)Y70w~un-1q3RR=NKFsF?rXFmiJp>7s>y zjEHqbg#E5e{CiY%_|=SYch;d8ou?NOS999N=)X!46@o;4W26k)C==nbgz-%z_gKm3@|Mdu5DiO zJ`~o0{2?fs?X;#^QAIfj3+bTYggXfE+tB7G`fuX6PiA4}9rywjpCq?Nk&R;S?mT4O ziqNuxd5UjZ%pTlh_sheU|c$z=hbo{-&a)P7ecOt|5yi&?Y5j}3^4@liad_#(ZhjOuKY5}dVY{E*O zjNQAti;!XLg4of54fa;Akbjyy@e2&tH^LL3-ccpt*PmQSJEU{t-t>oj1EAHH{ZMdt zoem=4MT#`{Y)W%kvq>!lJyFT}h)iCv#vnW68R1d!2iqnjr z?Xc~s%kg{BKU+Str}D;C1h{kCtlXB1KO=;xav>g-z5HM-KzpWwF-0xy53T?uH^6UC zKjsVgjPMSy7qgV)<`(*OWiN;SlKum{f4h8BmXFnR`b284O%+Rpit?^T`@fz1KT&)LEETc|6rQ##E z*XYkJl+qLB#h9JE5V~JHChEea%FlG#(MXpt7y1!`EN@GIQEjdHyj+&x=rw_X@AS;gik-5uh@4ziC2heL0w0w z&StrTJ^1=*pRNvZ0%KPWUE^pI;Gh`PUFQYW39tK7n_<&%RDO3W7HUz&zZ?`$y5_U7iYUvmJkZ)0Go$R)=&H-bm*>S0 z(_X?7J|YP4MHK-lXd=H(ew&MgY@zPMSIX=u;+js1Rhpxvyx}bZJYL#d=J{c3@LI>Srxukvai0TA z79oUSV8jLGvRy_a9-=cDS=;M9K5h?TRFB^RuZgYM2Fuw{TyY#fITK~b{NCn-ZkmV1 z#?T-)W#H6wqV>Ty^jS8sZa_&{Ule6HbEsKGam-!;YJgg}?VDK1gv+eigSOM_V3nlk z4SDziFL~IeJ}@~?)FMkfNzdIJNqUs)#Vl{0E3CCYQq&yV7r>-7RzXs^2H>zw{{UZ8 zN6-#Y_j#-OlWQTNxk(j;_pyr20X3UV2*YQJNtbKo2l@`EKCVH{q~HfS>(RGSm@7-p zyP|h{^~+3aBN9dQ$XwtrSg3NfR?cO~cD3-A*K@ znUuuam}Lrz5k`rkt(KJLCGP@WPKex8QnVBl*LMHeKhDg~&g>u0XP)mn^S<*u^Uimk z=Z-(p(@=kpJ^%oQ-d-L70H9N`k(2a(*x*N#_HRN57vSj*FuM22HpG@Bud_G+*m~z% z=s3Rbtlc=&#e4gn(iP~N7&zOyBn77ffZjH5kCQ=H`Lkn}l8Yd~5B>x1Et;(By+(Em zCbiOF+L4^}y&_!facqLYE-&@(21qG~u_-51jouA>j*m>$3EWTiylnmK7DI8Jn{(e7 zKp>pxZ>4)kBw#xNIQYNwRgHBcFw!rYmr7vcDX3>JZH{j;vNgZ3+4zZnaPVcv&xs|b zJW|ADFjh;a(P+xS(}?bn)`@T@dfwyND+${{nXspM722ESoM@`iNXhG{zeR1%vDxH` z!C!bowApmRL}x=GDSn-WkKiUcNpa0adQMpU=At%fNg{#}vZ4$sV0EyD!FV4fylD40 z1!T%?LsG+Jb3p~r0$orAc>OFP_S=g<)PLdYYqx$SF@Li~y6$&3LB-BAU<9yFMOev$ zn7Rex_N+C_v2CGHu*@MnozEU@O`Jw9$v=RzLmJmdY~rc0A#Y8>DjABmf&>AZrpWl3 z>-5s{TK-d|Mp;%r>jG8Uk$oY%(hDnxx-^_XE~K&RsaTa-Mp5_Q#CUVQ_(8T^avNFu7~s3#GuE=%0d;Y&!sw&R<6|jRz^SowFy&HqVU$rVT6=Mu-+aobs#Y%Xmr8CPZ`mpUrQ55s+HKBiV zAF~ibhdzRZx0T2TkMdUwM#~%d`w-R9KHtMp!!4ze8QTMv9}gSWsz}dgf=dbG%T=-( zR-R#*_+O2;fC+A~#2{>O<21D6R(hAfY5m@y%of6db0HO7Pqh}8HJ)ru8mkk7pjh;_ zuZYr)b`EyfrF@#StGF~Gva3j|2~CSvz0@yX7c|-Yh@e2htzIT^sQWiLfWj;Fn}{>y5;b%+PI4>8BH2LY{m0MYpW z!{(Xm3cW+ZW>V$^v{zoCzHQUzgiov@%SB5ME5G}<_5O@ZB}m2&aMfAmOtWG4Oxj1i>L zW792?{#`4gnB4Alx4|l2gs$8y>_&?jI@mcT5mpCI$lAw{7Foaqw^j@9yx9~}dRm!zT; zRCbvQ8>^`>&Q-soZ>iW;>~5+!d?M4sgn3$&DEQKNMS>~z?I-k%Ds3I2^7b#?cWKD^ z1JM^wATjk15&UjV^;o-XJtmok>oFqSGpAle4Y090-IwQagTL6MekUB-D;g5MOC#dJ zg<34NGM-u~*EDYwD%WU-VT5zB7hT|(DzS1!-M@Y^Q#c-)?{;m;4y|yeWefW}tvFOG zqQ8T$3Oxcsug;I;8-4a~U`L$9P3?3_YvJ$)@xw`P2JvaNWDJ-5Q&n}OulY)t^~@Rm zwmGKXQ25|0c|0fiA!@D$wo@euxM;XmYBg(FM=Lxx+$#zTghhr%9O}cnXNgMa**Rv9 zUD^AhEM@cs@yo?fOrol%uOw*Px1{BM@@>bIKt8KT&_3jlk~4I8xtG&-+d5lVY@d{R z@ZJ&*vlxu|O1^tJqie$76_Syff)+$60xxX^ig3{uOINE~Hr1)-8~ zu?1vO+p%M&I!pPXS^iFYCDlZ{#pTOiJA3}#-YOkk{nSf{%evnt{9~GhC2=QUS5Z|! zG00=(BAPY#=cw+UIBP=<2=c8xQv)#5T`_2&yBhk;NOo z?7HS;Z{V`<0WB@fZCw4FHNaDCs%qjLQIgx$TukO5UmJgV{Z(oaz2(KV_|l}A1_#_- zbls?GL0n(oi^rl#Ov2fq$QU?yI;dJ^e1bgK5Qje>F0HjL^N({>e3`a zfC!|C&c=j2@gJO|(=5_>ZMrg!6>+=p;+rR{y175Ge3@laA2zlH!21-^gW-Pu`ac1? CJTQ0w literal 0 Hc-jL100001 diff --git a/docs/migration-tunnel.fig b/docs/migration-tunnel.fig new file mode 100644 index 0000000000..00f1f58251 --- /dev/null +++ b/docs/migration-tunnel.fig @@ -0,0 +1,49 @@ +#FIG 3.2 Produced by xfig version 3.2.5b +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 2775 2400 3675 2850 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 2775 2400 3675 2400 3675 2850 2775 2850 2775 2400 +4 0 0 50 -1 16 12 0.0000 4 150 570 2925 2700 libvirtd\001 +-6 +6 5400 2400 6300 2850 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 5400 2400 6300 2400 6300 2850 5400 2850 5400 2400 +4 0 0 50 -1 16 12 0.0000 4 150 570 5550 2700 libvirtd\001 +-6 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 135.00 180.00 + 3375 1950 3375 2400 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 7 1 0 4 + 1 1 1.00 135.00 180.00 + 3375 2850 3375 3375 5700 3375 5700 2850 +2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 135.00 180.00 + 5700 2400 5700 1950 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1200 1200 3825 1200 3825 3000 1200 3000 1200 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5250 1200 7875 1200 7875 3000 5250 3000 5250 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5400 1350 6075 1350 6075 1950 5400 1950 5400 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 6225 1350 6900 1350 6900 1950 6225 1950 6225 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3000 1350 3675 1350 3675 1950 3000 1950 3000 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 2175 1350 2850 1350 2850 1950 2175 1950 2175 1350 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 1350 1350 2025 1350 2025 1950 1350 1950 1350 1350 +4 0 0 50 -1 16 12 0.0000 4 150 870 6825 2850 Dest Host\001 +4 0 0 50 -1 16 12 0.0000 4 150 1080 1350 2850 Source Host\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 1425 1725 VM-A\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 2250 1725 VM-B\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 3075 1725 VM-C\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 5475 1725 VM-C\001 +4 0 0 50 -1 16 12 0.0000 4 150 495 6300 1725 VM-D\001 diff --git a/docs/migration-tunnel.png b/docs/migration-tunnel.png new file mode 100644 index 0000000000000000000000000000000000000000..0f186d3e9f487ee73c09d09c03ed9e0a7402751d GIT binary patch literal 2237 zc-oa#dr;Eb8pX9f3Q1<)@k?|NYoNe1|@+&TW+oorKA7m zRs%(qWN+USDnfN#4MzhJx3mTXQiXVX9uNFuXl^9-pOyPTo6kI$KK#)nv7i&L=l^2P zDF*j2;9eth`{J)xA!qImq`*Mg5V_hOtS-^>qfI02c7H4V1)A0`$_mGob!+dOHmk;N zzjm@j9D`ajuH29f+3p2WH3e<^Z%iNN@s-)1!{0P)kJc&J`9AAtQL8W0)FRHYno7$ncuP(#6NOtQn_IMN88dC&svQ z*5yf-Y_^#(q1J?ZYtGUDk&b${ zX5%5Vq?V>c1j`*|`?;Z$dKksGA5>Y(G=qRq)J-mD>A9sRUn1h^X;Ccs`4Z#U36$^# zIXbhtsbaN0G$gLP>;uwLz=b)n z^#LroXGs?F_bJ+_7SZ3Dd~FX&BK}%u@CXY*k9NgA{H=)99>6m&wku2NXN(8U2iA1P zEnavnvo?M5MPv)hqBz;UnQOe9K#;dk3;a6K35YtBlfy_|$~#wR5owa3-cA?5Y+wm* zQAZd?(<}}@%C`p=8T{l==9V=_Y&Y`DKic}rL}#AA&&ZoQT)4v2is#r%Mv1q8qbE8e z9Wlbwz66J><1N7Eu7kiOe`wq*D%!Fq*_>oSvXwX2p6+az0Vpi*aTLFjm8Y>;+*&Al z=@7Sq*)dRSPI4=ceale0%o*7gQsde$ni2P}1}m0*m>p%k&y$)0-#rkh9pvSH;lP#QMN-U8UW)Y$X2HjkT?R z^>KLH^`ew|466;qe=Jc{vD&*SfLwriK6lb_c~dKN^=ua@TcuNG5PoS>w$%n;*-L1` z`&@XN)**qcWJLvs1N1d49Hww6sz2q1%L8Gx-PM0~u~OfF)oxY$b$#bQL{aZ3st(09 z8yoX0*V?$D(DYHKl&KZVO_ZY3x$Q194_0p2TP8& zXLsf|2$GbYrcGOOx3#Xo1vb(j3{>^SUNBaBQJ!`iC0rXkh$Cd29BD;!x2^A&&|}vEi-40`gxXj z>_|I`$!M2;Ti=uB*9-YIvRQW4YAU+Abdk(!N?umnw_eVQbGgtf>I3`D${v^J*B2D> zr&i5Lf>DH!!Pd8?;M0q(Fk?H~&+k)OXA9F$6*6ktU<-+&Qh3r*+G*bhL~zC>h~LHf z0-K#5Y<+XBTgV>M9KrncC9w#B>kM_z__S@r-%)IV{W4ROG*64F3W;rZG9x9+k)g3X zluh7hbq)JTy25h%a9-2lYUK0;I^(Q@0d+gFbPO!TUy#4!i=bt`I}sX=V)*NMK>j1C zItXNYbK2&P0_526>g+BgAT_7iO#2bo%tTPRDM_L~*H`g^ofgg+%1pqg)PAjMlOlVh zIfJYB&X%vh-OjnkPAy!CK`N?>sRI4RtlMO6ts3zTz^4dYdn@xNMMCP1Ss{_f<}4CGPw5N{9DGqzeDMTdEgadUGvN zntt)rXWnpRLsr}xUEvylm%)|vH-llHy9mc<*Fl~3f(2F&6jq%TV(8@oS7U#AbDib%wUA$~ zQ!oBn@(t}XHm~;-WGi$7(zlGSa{Pxi@Uv8E|MR(X8 zOqpHme>LN&JT|-gDcAs@_FG0@g`DFn(7QL`B^?gSfKM55%@=V}>k6u48(mP0!Pkkq z@vL*^$km`3gcleVyW@SgQ{<-y-KKcG>x3B`Lvl8WL(H2pW=aYkH8w}dwhXrI5?)Ch z8c15wz*2cml7WJ-WLb%ooMwf=WHcAkTaZ;XLqvA4(2bVCdp7wP`Vh%m*m^;pX@PM` zH!2?z@n|0DaO0j7m}DdwlwNAJLCaX@s?~-~+X3IeY9|m1^1HSFv=Bt5Mp=-%5#6P4 zuU7R=3r_@jV*mZwnd9eS@of}{gh1Ztr)jdy>*Y8OGw_jf0FX;_l!zsJcM!v)2fX{=oG&_C10(##dn%EI#Gl1rXOfygn&1@{dQEi<(dm&r9# z$t=tz4K-X*lNn7gX>vg&TvFUnF;Nj0{L{J4i*v4-xz2geZN&JtzcUxfuok zC_VhT_Lz0EUdaykhhKHLyq~M6u56(uuN6TB095x}y>!7XdSsF3|ESzhPTu+KK*cQa z!R1H9M$mLup}7$VDECXSqdSNG3ap$SbNrZQV7=#F0QuW|%G@jYw5iDEZ~W0VZEbC7 zIF+cL-E$6ot8`-K{Q}KzELK(0aA}b}yItjg@xBB#KnD=;-x)jYxZyCi8@;aii}3)T zv^JrxAxitzHt~=8%IA$x-sAbu&dsOj@E%kO+VX1&5c0pU6-pYRVMl0%F|Y(f%lAVB zc1~kgCU&OZr(!b!EZzPAp=!r9#TC_9>;1!SsJp+(D7_ zF84z??(+0^o=!(EHUz!K=NEHk77F;i=fq)w*K=RZ8`o`H?e^ECH(@C`ZFSZ<3Dc3y z5{4agb7yCrlkcc_?Gc@EaA3lR|aZw_xvWk@RC~21A!^<~9wT zuW=_bLni5owWDva4LQb(9zv^W6ljdKnvtK)2#@fHdYQr%?~I@0`@6yls|509H|%|b z8w3NVw`!YuUa{Sr)3TwMhVf+Xod9SSCSCH>|uzuek2LUO5uIz!W&IaBY1>wIUynEhdEpfpXg`SHHt$i~9$ z@|4G=H}QKy{q8S@+%YOW?LVK{Oo_NjKrD}iai=m9whL228#+MBoLS96bQ`|Qh|H~6 z85$Ec?3&7M*3#|4jWq2zPej@ca@oQC98wxO#UDP_fGV8JvvCLR2=l&&cgzNJ;pz&I zuI;ssceQhX4RiFqyM}Urzh`@w!REmOYh;-DGYi$j3tQ4t^Px2C{hj&D#dzaz3{`JwlQOrvpeafB^MM{@mK z)6zsc@r3peacnFupMpE-eHEv%`_pt`>YE)kbU50m(*~2S_ktp5vguQyBc(+wJr)a7 z&hB-#h&@S%jTFf1bVl23xZ0<%qea7lkxuWW!%@KEMqXf* zmGD+zx^Ym+i+ii7Tad1a{6D(+_hSRDObrh|FHRQ}3}u-q4r!~w17erig;iP=>^7*< zcjwpb64ag)raBgeOp8~<7Ar%suykm4@4-v!cCDr)7kkzE_-W0llM?o(vZE3*4Vf>jHYP4OH52tpQLkgU7E;K z)pTgEFSOxz%bP#Kt*5^qbMQ!XY?MoKp-LZ(3<)K-@9;omegE0DH+sk%_a(4oscIPsS3-Vqsw_6gO>$xWG|~bAEAX%xERnTdWf^GIK3+B3 zJuam=_QaufsGM(QA;HdbZD~E^4@1PxJ?7~3So$?aP4kT?9%ZzG#YCI*6UviRx^Dbb zCfw>~L+iG^JQ(3ygKR^dRJl*HB6dwyw&~XFp*oX|9dOeW`)Q+YR!j0wF=hx(gzEQ) z$S@_p6r~WHE#JAETxycT2hWJQ^^iz)5Nw{|O>JlZ3E2$r+RK}HFwnNn^d(W$fd_rFD+a`pQOuktd)jCWmQPH&xyIb_9{QcK* z)L@kuWUw5B0lw{ZZr}yJ{Sg3z08W4I(my8HLOPvSRa+%}^{He3KWw0U5YyiT52R|x zr?QJb1=im(@aju<55_ve{yo1)UjkEQ!ICM%%4kpXk=>C`L-r8 z$M{=A1P8Y7N2ytxwR>kl6LC_Zb1_o%+ye&LaP%~3HR}9><4qD5IobP$k645bC4iT7 z%-xGd)jYz$5~h;Fu^^X;uXxvYVCVPYIu0i(qX#G;0;-DJN$f-)R|*^D6~3O9tKHJ>zF-` zUgdM$)W2kZa@hY@VT+U7TT10-nryz0CXjl>5JOyi5O{3RI}iXyohM%O%l?wX5#kT0W}B*f^C?&Lc%^zMZGA}R&~NJGUXRw?nQB&HZ3~s% zQdh9uC|Z@NN6){~n(xn_!LMt@7&F2HPMB3$Sgja$he8mhJ>H-g1Y9!OA7ks&^EhY; zgA_HEb`WO8UW3k>l+pXuOBasDH!gRMMdwu&n3`osD(TzwrGI3J23Qp=jr?ll4V7P8 zg+fpi48@6XAcd@BkS@Komf1RIZ;-P-GOQw&LG-A8tw(6fRg(F0tC#`W;xk=KcHtSZ zBeUoda6+1iihIGSrxi4==?M(oZOoN8r09xI{@t)&V&E;Dn8q)o&p5B$E&K(0@$lCd zAYNlxuOnNVN}bz0&P-;*<0?X@tCBXGoN+L}c^DY}`ssBx!?p1`@sPc%C>xftLbpP- zQZkbm$T?o6L1}CE_%Qxu(lT>AAFtY)eN?@w<%`V*tYqagaTw5c7R75<s)OMgrX-phD$Zh)=MzS_?me-FjW`JJnUI%nMYd9(w&bk5 zN9~Ky)x^VR4-?UBAPmw8=ZS{4VV9SKHkqQ{|r+ujEP8=(<5T<7_jXK2xiaOo-P8)}W%>jV&Deg$muzOB@AicIm<>UdfAyQ^U*bF@!4 z=b@q8p>rSC$Z+ze>s*9t36{I%w1c;wlOk2_Tk-OXm_uiia_R@ps=?cP>Cbe$@15&^ zr@B+*;^$&7`-FYRUM4MsHd-Xl8z%g|m6vo289kZwfh#2|lw^JEE3OB35c9WpHB5be zegMv|637M~hLyLEl~TToY~XoamTR$!RC%V6=*`lo5Xu}RIT{8TKY79AMACKKq%AKD ze;Kz}-jcYsP&*CQ4{CpRVP6MOC18H!LxJ-{BdJ1K*;(-;+fqSO(sF1j5WNreZ=L4& zMNBzH&3pUce-L)RFz}E0&R#fMhOV3%dSAc?D3jr-lkgV0kQlFnI?5CoDBSbF8?2pW zO*Cq_@p<79dGmTYr19~4{o)mxZR5;V4Y?CwCUsHfyJSa@sgThis5Z zR38F2+59BUdog{9(r5e^9)6cCp(<8kg?8P5o-Zh5@^=pKXIe(G`518Zvg4(yi?`zc E2};;tzyJUM literal 0 Hc-jL100001 diff --git a/docs/migration.html.in b/docs/migration.html.in new file mode 100644 index 0000000000..3676f0b1f4 --- /dev/null +++ b/docs/migration.html.in @@ -0,0 +1,601 @@ + + +

Guest migration

+ +
    + +

    + Migration of guests between hosts is a complicated problem with many possible + solutions, each with their own positive and negative points. For maximum + flexibility of both hypervisor integration, and adminsitrator deployment, + libvirt implements several options for migration. +

    + +

    Network data transports

    + +

    + There are two options for the data transport used during migration, either + the hypervisor's own native transport, or tunnelled + over a libvirtd connection. +

    + +

    Hypervisor native transport

    +

    + Native data transports may or may not support encryption, depending + on the hypervisor in question, but will typically have the lowest computational costs + by minimising the number of data copies involved. The native data transports will also + require extra hypervisor-specific network configuration steps by the administrator when + deploying a host. For some hypervisors, it might be neccessary to open up a large range + of ports on the firewall to allow multiple concurrent migration operations. +

    + +

    + Migration native path +

    + +

    libvirt tunnelled transport

    +

    + Tunnelled data transports will always be capable of strong encryption + since they are able to leverage the capabilities built in to the libvirt RPC protocol. + The downside of a tunnelled transport, however, is that there will be extra data copies + involved on both the source and destinations hosts as the data is moved between libvirtd + and the hypervisor. This is likely to be a more significant problem for guests with + very large RAM sizes, which dirty memory pages quickly. On the deployment side, tunnelled + transports do not require any extra network configuration over and above what's already + required for general libvirtd remote access, and there is only + need for a single port to be open on the firewall to support multiple concurrent + migration operations. +

    + +

    + Migration tunnel path +

    + +

    Communication control paths/flows

    + +

    + Migration of virtual machines requires close co-ordination of the two + hosts involved, as well as the application invoking the migration, + which may be on the source, the destination, or a third host. +

    + +

    Managed direct migration

    + +

    + With managed direct migration, the libvirt client process + controls the various phases of migration. The client application must + be able to connect and authenticate with the libvirtd daemons on both + the source and destination hosts. There is no need for the two libvirtd + daemons to communicate with each other. If the client application + crashes, or otherwise loses its connection to libvirtd during the + migration process, an attempt will be made to abort the migration and + restart the guest CPUs on the source host. There may be scenarios + where this cannot be safely done, in which cases the guest will be + left paused on one or both of the hosts. +

    + +

    + Migration direct, managed +

    + + +

    Managed peer to peer migration

    + +

    + With peer to peer migration, the libvirt client process only + talks to the libvirtd daemon on the source host. The source libvirtd + daemon controls the entire migration process itself, by directly + connecting the destination host libvirtd. If the client application crashes, + or otherwise loses its connection to libvirtd, the migration process + will continue uninterrupted until completion. +

    + +

    + Migration peer-to-peer +

    + + +

    Unmanaged direct migration

    + +

    + With unmanaged direct migration, neither the libvirt client + or libvirtd daemon control the migration process. Control is instead + delegated to the hypervisor's over management services (if any). The + libvirt client merely initiates the migration via the hypervisor's + management layer. If the libvirt client or libvirtd crash, the + migration process will continue uninterrupted until completion. +

    + +

    + Migration direct, unmanaged +

    + + +

    Data security

    + +

    + Since the migration data stream includes a complete copy of the guest + OS RAM, snooping of the migration data stream may allow compromise + of sensitive guest information. If the virtualization hosts have + multiple network interfaces, or if the network switches support + tagged VLANs, then it is very desirable to separate guest network + traffic from migration or management traffic. +

    + +

    + In some scenarios, even a separate network for migration data may + not offer sufficient security. In this case it is possible to apply + encryption to the migration data stream. If the hypervisor does not + itself offer encryption, then the libvirt tunnelled migration + facility should be used. +

    + +

    Migration URIs

    + +

    + Initiating a guest migration requires the client application to + specify up to three URIs, depending on the choice of control + flow and/or APIs used. The first URI is that of the libvirt + connection to the source host, where the virtual guest is + currently running. The second URI is that of the libvirt + connection to the destination host, where the virtual guest + will be moved to. The third URI is a hypervisor specific + URI used to control how the guest will be migrated. With + any managed migration flow, the first and second URIs are + compulsory, while the third URI is optional. With the + unmanaged direct migration mode, the first and third URIs are + compulsory and the second URI is not used. +

    + +

    + Ordinarily management applications only need to care about the + first and second URIs, which are both in the normal libvirt + connection URI format. Libvirt will then automatically determine + the hypervisor specific URI, by looking up the target host's + configured hostname. There are a few scenarios where the management + application may wish to have direct control over the third URI. +

    + +
      +
    1. The configured hostname is incorrect, or DNS is broken. If a + host has a hostname which will not resolve to match one of its + public IP addresses, then libvirt will generate an incorrect + URI. In this case the management application should specify the + hypervisor specific URI explicitly, using an IP address, or a + correct hostname.
      2. +
    2. The host has multiple network interaces. If a host has multiple + network interfaces, it might be desirable for the migration data + stream to be sent over a specific interface for either security + or performance reasons. In this case the management application + should specify the hypervisor specific URI, using an IP address + associated with the network to be used.
      3. +
    3. The firewall restricts what ports are available. When libvirt + generates a migration URI will pick a port number using hypervisor + specific rules. Some hypervisors only require a single port to be + open in the firewalls, while others require a whole range of port + numbers. In the latter case the management application may wish + to choose a specific port number outside the default range in order + to comply with local firewall policies
      4. +
    + +

    Configuration file handling

    + +

    + There are two types of virtual machine known to libvirt. A transient + guest only exists while it is running, and has no configuration file stored + on disk. A persistent guest maintains a configuration file on disk + even when it is not running. +

    + +

    + By default, a migration operation will not attempt to change any configuration + files that may be stored on either the source or destination host. It is the + administrator, or management application's, responsibility to manage distribution + of configuration files (if desired). It is important to note that the /etc/libvirt + directory MUST NEVER BE SHARED BETWEEN HOSTS. There are some + typical scenarios that might be applicable: +

    + +
      +
    • Centralized configuration files outside libvirt, in shared storage. A cluster + aware management application may maintain all the master guest configuration + files in a cluster filesystem. When attempting to start a guest, the config + will be read from the cluster FS and used to deploy a persistent guest. + For migration the configuration will need to be copied to the destination + host and removed on the original. +
      • +
    • Centralized configuration files outside libvirt, in a database. A data center + management application may not storage configuration files at all. Instead it + may generate libvirt XML on the fly when a guest is booted. It will typically + use transient guests, and thus not have to consider configuration files during + migration. +
      • +
    • Distributed configuration inside libvirt. The configuration file for each + guest is copied to every host where the guest is able to run. Upon migration + the existing config merely needs to be updated with any changes +
      • +
    • Ad-hoc configuration management inside libvirt. Each guest is tied to a + specific host and rarely migrated. When migration is required, the config + is moved from one host to the other. +
      • +
    + +

    + As mentioned above, libvirt will not touch configuration files during + migration by default. The virsh command has two flags to + influence this behaviour. The --undefine-source flag + will cause the configuration file to be removed on the source host + after a successful migration. The --persist flag will + cause a configuration file to be created on the destination host + after a successful migration. The following table summarizes the + configuration file handling in all possible state and flag + combinations. +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Before migrationFlagsAfter migration
    Guest typeSource configDest config--undefine-source--persistGuest typeSource configDest config
    TransientNNNNTransientNN
    TransientNNYNTransientNN
    TransientNNNYPersistentNY
    TransientNNYYPersistentNY
    TransientNYNNTransientNN
    TransientNYYNTransientNN
    TransientNYNYPersistentNY
    TransientNYYYPersistentNY
    PersistentYNNNTransientYN
    PersistentYNYNTransientNN
    PersistentYNNYPersistentYY
    PersistentYNYYPersistentNY
    PersistentYYNNPersistentYY
    PersistentYYYNPersistentNY
    PersistentYYNYPersistentYY
    PersistentYYYYPersistentNY
    + +

    Migration scenarios

    + + +

    Native migration, client to two libvirtd servers

    + +

    + At an API level this requires use of virDomainMigrate, without the + VIR_MIGRATE_PEER2PEER flag set. The destination libvirtd server + will automatically determine the native hypervisor URI for migration + based off the primary hostname. To force migration over an alternate + network interface the optional hypervisor specific URI must be provided +

    + + 
    +      syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [HV-URI]
+
+
+      eg using default network interface
+
+      virsh migrate web1 qemu+ssh://desthost/system
+      virsh migrate web1 xen+tls://desthost/system
+
+
+      eg using secondary network interface
+
+      virsh migrate web1 qemu://desthost/system tcp://10.0.0.1/
+      virsh migrate web1 xen+tcp://desthost/system  xenmigr:10.0.0.1/
+
    + +

    + Supported by Xen, QEMU, VMWare and VirtualBox drivers +

    + +

    Native migration, client to and peer2peer between, two libvirtd servers

    + +

    + virDomainMigrate, with the VIR_MIGRATE_PEER2PEER flag set, + using the libvirt URI format for the 'uri' parameter. The + destination libvirtd server will automatically determine + the native hypervisor URI for migration, based off the + primary hostname. The optional uri parameter controls how + the source libvirtd connects to the destination libvirtd, + in case it is not accessible using the same address that + the client uses to connect to the destination, or a different + encryption/auth scheme is required. There is no + scope for forcing an alternative network interface for the + native migration data with this method. +

    + +

    + This mode cannot be invoked from virsh +

    + +

    + Supported by QEMU driver +

    + +

    Tunnelled migration, client and peer2peer between two libvirtd servers

    + +

    + virDomainMigrate, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED + flags set, using the libvirt URI format for the 'uri' parameter. The + destination libvirtd server will automatically determine + the native hypervisor URI for migration, based off the + primary hostname. The optional uri parameter controls how + the source libvirtd connects to the destination libvirtd, + in case it is not accessible using the same address that + the client uses to connect to the destination, or a different + encryption/auth scheme is required. The native hypervisor URI + format is not used at all. +

    + +

    + This mode cannot be invoked from virsh +

    + +

    + Supported by QEMU driver +

    + +

    Native migration, client to one libvirtd server

    + +

    + virDomainMigrateToURI, without the VIR_MIGRATE_PEER2PEER flag set, + using a hypervisor specific URI format for the 'uri' parameter. + There is no use or requirement for a destination libvirtd instance + at all. This is typically used when the hypervisor has its own + native management daemon available to handle incoming migration + attempts on the destination. +

    + + 
    +      syntax: virsh migrate GUESTNAME HV-URI
+
+
+      eg using same libvirt URI for all connections
+
+      virsh migrate --direct web1 xenmigr://desthost/
+
    + +

    + Supported by Xen driver +

    + +

    Native migration, peer2peer between two libvirtd servers

    + +

    + virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER flag set, + using the libvirt URI format for the 'uri' parameter. The + destination libvirtd server will automatically determine + the native hypervisor URI for migration, based off the + primary hostname. There is no scope for forcing an alternative + network interface for the native migration data with this method. +

    + + 
    +      syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI]
+
+
+      eg using same libvirt URI for all connections
+
+      virsh migrate --p2p web1 qemu+ssh://desthost/system
+
+
+      eg using different libvirt URI auth scheme for peer2peer connections
+
+      virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+tls:/desthost/system
+
+
+      eg using different libvirt URI hostname for peer2peer connections
+
+      virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+ssh://10.0.0.1/system
+
    + +

    + Supported by the QEMU driver +

    + +

    Tunnelled migration, peer2peer between two libvirtd servers

    + +

    + virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED + flags set, using the libvirt URI format for the 'uri' parameter. The + destination libvirtd server will automatically determine + the native hypervisor URI for migration, based off the + primary hostname. The optional uri parameter controls how + the source libvirtd connects to the destination libvirtd, + in case it is not accessible using the same address that + the client uses to connect to the destination, or a different + encryption/auth scheme is required. The native hypervisor URI + format is not used at all. +

    + + 
    +      syntax: virsh migrate GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI]
+
+
+      eg using same libvirt URI for all connections
+
+      virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system
+
+
+      eg using different libvirt URI auth scheme for peer2peer connections
+
+      virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+tls:/desthost/system
+
+
+      eg using different libvirt URI hostname for peer2peer connections
+
+      virsh migrate --p2p --tunnelled web1 qemu+ssh://desthost/system qemu+ssh://10.0.0.1/system
+
    + +

    + Supported by QEMU driver +

    + + + diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index 505b599a14..1de2b20c1b 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -60,6 +60,10 @@ Authentication Configure authentication for the libvirt daemon +
  • + Migration + Migrating guests between machines +
  • Windows port Access the libvirt daemon from a native Windows client -- 2.47.2