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 zcmcIn4K&kj|DWoSN?v-=+##j@y+}y%cB7Vv40#RB%*sOC8Y{D*5cS-X z@^IO{^@pth0ARc81t)I+K&3)iPN=CWdyLwXM9NAf&f5h9AidM$DH~g2F9gN`0NWmX zFDh1V8Fk9e&GD|_^P4BO0@ZB}deuG81^_geu1;rt6UG-gQQ0+Z8&tiJH7*}Jvd?yP zJW`eRQocSJx^u+vev}_-k#j6G;j_{H_vJ#FDj;iDAyN04>boaGS*Xdv+^u#St_{b0 zedrX}LVX$RfxNZr^LsmMuFZt`I^Iv^<%e`_K$jZekC;qIUdj=yC&X*M&g(4eS=NEYa%vj37>7n)>Za zZ?r!-9-MbLeQ9oPOcG0u&Z#=e7($g8ErgMppj7dr6!y*aX4o)!@i%?=yoGsBRsI+X zvJ*auH9BF!@SoMq_^8Oqr(TVJZ;Ess`0`GN^WYls8aiW2TyYWXBrQEW0y$0u9^IeV7a$(l+gR;3iSHeFTZvl_Ov?9yq$Zk zR+KC6!JrV-sEH-WKdx?xr4#QBKU*Ny7PY~_lQ5vOqYv#gdoW_+Ry-U9u^Q({B6H-I z0tp1fi6d3q_9yK#xQXycyIcf*Kr958F^OGXWwL!pUU&U?!s{g&opL@5FRa!79_B_(OK4x<>bs_BF~lxicAcl{y2YTmV8AU0(zoW474O z?vdq*uHgSe)BaD)UpZ#&@?Yk(L9JNbOjtwtB7WH={bAa<*$nvyMS?>c51{1?FvR^C z9eimp)Ab_nNN+b&CZfM$g%Y79GwQlej2M~T?`W08M){j5m(s?w5I;lMavNjtQMt{p zVi~;5xXN_eblS%}G{p&MjwWALgxm_wt!HnJUs&(2BUapb2Ci`C7e=SXnAPLBo3Z)L?&!m`U>VKy39(~8>G4xo1aBp^1qShau$ zqGC2uvuEJqJ`xYt_e2fNMxCRe2>};k_RmHgTVW8O zO~+pin$;BDm7GMTwwKlYYE%q0QQAM!VD9 zHdzwDO={4g4dMNkI2mUR%JrgUi_`rV z<@#Z+B^%;qK6f@{HhV@tDx&di_iCnV2VKOo>hei^MN_u7TT1F7y5lkhxmrDPX@&9} zO&|B(2-~y|=#J9LrRR%JKuyp6hNbe`&exUeIl*B8`7VZEEqmjqr6XPWZJe0yhnjmh zZT#qnK#-c0$z7j2b7byenqklAlU#wYGPe*2-wD?%VUHqvHYj-sdY7<1P|qBIyN)@0 z-BcmOcqXz=rZSuSX7|F2vGzR)Kdr<=tX9SjAxG1-1pBS69P5l|cOCb49_{{osg`%Y zaeWdQxYG$`Xx~O|Vu{W$)J|)VsHsnBTp#k~aWa(-y;Wi27qaKr=EJ$-zPft*F3l!f zXeMFEK-65Wx0Qm40dG508L#=`M|?-I-UXYPKEBtAUB?dW(gXF-Z(#`CmkqCPkBYkF z<53_u>{N4c^{*I-9q{EHGY}AR5a+OZN5>g^g#9m6Nh!96&0=*iautU&z|I3P3HO-9 zA`PW|eUBsm-{|PC5(iStzpUE(Lq@0D8DRN=kK>0=VI4T}-{VWAK>i6E8gsMrlzV2e zP$hW)%>+HIA~GNhC+$-T1GFxc94*X?3p_i=?&WHK7c$K%<7vhaTMT*8Q7v3sz>1{r z$~=$C3)sHsK6al_^2PrB$<*JF10Nrjxe|a=b)XI6XDIdRP+>AX^ z>gUF*K5T1Ra-zkfkKm-HjCY|am8_Oq4i_0d1Q-b$yPKr@)t|!34&JqbOQ`1|XQ}6F zVYMsIOf;|ScB*0upJa zS9RC$P>h7b_OS3TMZUSknXlgLhXtwWDvjv(CRkJD>MCQ*CEq0aJop~FDh~{Np01*f z?f9|baR)*4)++S}*Gz(Tkn_ILlOV=@CIYbWpAwNwi>9K$ZnK2&9}IEUE`}-#u2%a0 zG~f?ei{8P?VWk&2Dr58%H!4>2TF0~VP0AtiX-lDf{+2E^j~z~6v2e&lhvBsd);{7*wjO8}fYWnQlH4mUX}igmJm9CYnMXx)A;>RH(K6$XD@Gt-XXbr# zj}TcwRNyP%`lgYol(mMC@Uh(i8rQ84XlXmYRIRI+r0xa*^z>MP@3rGf&jgi4mT zY2!jE*1%X3$D8Mul(O-_4!uX#1uYTT5#R32uZhc*9&_CL%RZPvRr(q{GdD;e=HYUHnlRN|f^!A)~KIR?ImGFI| ziw*wsQo3RD;A&Q zyIB)tQKV>?odXI# zgR%0d4lEJMtMSdQ?l)^)s!Y1-V2BpZt8NtS3w+`Gs2sDb)mEJPRgQ` zmNI+@;?K{FVJ(B;WFh$b=#Tz!FU*?*~0nvnrOSy_u=n6p~ zNkTX4XRAbi+-EYyfyIi_VS-l&V$ZLL5~XCpXzsa{>R@16pkTX1SA-54?_+Sah8-r3U9<&2n* zVK{EAusOGWr~&gL%f{&Zw4;ckD`@Y{Y`N2M73UN8iF==1hS*c8@(~^|9E?hx048XTG}SWy8PY z)4^S^Uqlz;72(p@2v^L7%Af145LKN`pPMmRx$c9nBfom@Xad{875@Wj(7-D7EZl8x ziLFC`(LRyCoB4gF=O6Z-Y~|4E^8i)YknJ(c^RIFY4wcNKUK$TTk2MCyjR+@0M9B^j zh#IM|mJdaCKWC$(gFKA($m8W;RNUxbWRlTCtoT`3G>85a<8O0#2~u?MNR0=UO_|NT2j1f1 zItXn!1+*6(-0m_2(|pZZZ~8TnwZ2b}PIa29v*K45&(|dU5oA7Q(LWZxqQUAjYhNdN zce-UF9P`_e9+|(yl3`a<)wz77R9%(azk=8NPv~n<-mu+8LRlaSe%nYAf7Nj}fo!M^ zH6&)RgkA2Ms^0*D*Zw~`UoxqlBo%>mR4G?hW-~T4?`XRe!*ai6y`5#+aZuhcLrYYR-&T}S%Ct#^x&nK-5iA%vq9J>=i#-}us6E@`eyXonUpQh zQySN~uOy@#Z)6}64dYYWpz{(NM;x73J&_3+< zFl6nQ*__woysbC;JIrcBuxHfvCW=BEXFj+oT01=Bc(i%Uf`-tc& z>GpeYTHgW}!3}J#6Lv*M-a&sEy>OQ(fN{>(uiWh$S`jQ%7DA+P%?yzONi$%nEZ1d7meHq|#Q;j}uZg#0=>>-T}cMAMrF{|xK5+`k8 zKZx?NMoLauicq=moqamItvVE45&OlhqXe_D3R13U*o&=j#O@xd&hp?_2z|AN`BM*) zYDqq>7NGO#UA-0~oWU1QV@wL*vIezAI^HY0QDZ8rQ2VKia$QozU=q@|0lEC*FoBy| zfOw}k{J|f{M+K6@4x%y9KZkLWe<@;HVhrdJ-hd$^XEZvbVvtu^CG%ch>czT9Y3F#c z1NiMUlzl^fUGq4#x77|>U6SCK2$By{CljBya|3L+V&9@icZVRR9D-Fs$Ns?t_C(IJ z$suX^kv0~x?cE2*0P6DfaICx_!44fkwp0%eO(>H|^j(nCsat$NCR6&O8t4W@54rlD6vs^d7C5ew4HEs~qYiDqSu9rDM0d zE66c-902(~c>Q~5`!9FtJW$@R0ff2%Z4;FN)qpS;K)HV5zDJj}%Ju(48UJre{rAp9 zZmuI;wD6A+v95@)-#Qcj9u*vZF=O1FaVSRT=|#lVoVGFg*H%Pj6i8%m>JdytdcTss z+|lW3LioufnRYfU?!$Kx^LLZCKn&lwXDS7hW}?HK>82)jy6dHGHgtTrFf)lT$Z7?# zy4dQ$soZWHPI5_wlMThHo4)Rh#0lc>pzxQJ8%2b1JNtWo0>0Uy;RRYN5lE=KPG05} zClD*j2VJhwaZ=@tdAg`&Nf7wAb(md|D@1O;>6|3R)BM4vE2WGS(c@5atC>M*w z3uuL96L#*&*uA^E2pPsMh#f81U~lyb`Nzo9d$1J`jZQ3hjeb-n|hyb z0JQqN9|{hy(?JBhNRj5AO=&J`HVH=83+mg4H8fs5ciiHlD$Ds{6m8R2zcqaVY;pmp z^5UQAlHGKv&~`zlnfxpGnvdg*wgC30!T*=eRFw|@hNBo*d*GIJ!A0ZbznZ^w`3YFK zYh*C+$`U^J&oua^O%Rd^9?*((oxdu-5r-#?4JnA$iRw%-Z@HTnDUm4+*y5d5ZQ@@C zs2Zvm3hmN19e-!9EZ;UtKA~ko5XKvn%9F!(nwMn4X$}Fr+6;kbT*vBo)^gXU-mw~{ z9&-lehZXnW`>i<5_?Zsdp1K^r7yUEk(|am!Tt$F8x6R0Hx%e|em?{_IQQ6B6#sajb zD;Q#GX@779D7gWCd+IS?z-NSafW4TdBsaIvFVhQicsd?0w=I)N=i2NAvN5t5tKHs- z`kv@68aiCC@;qB(V_(~d^Egt^d<5M+5<0*q>F z&FAH^1V^t43?#pSSIDsH4IuhWYPM(@@9#y;d0To<-{|g+M|V7yoM)Xe=gZy#DNp$H z!}*GR*OPdKm=@G^l*%^C9qhr^Py2Lrh!YsQa_AaIn*ayJpzb;^s7`p@=h_ULhNJSk zTd`1!D*ok&pbxkcqC(CFhxQY-a%r~ThUI<{CM!#6!09+qTQ#Dg;n6jpja5Whj^%;Y z#+VspuSQp0F1|c3ftdCZmhcflUq_Vx>*9umgWQhC@Y`{vYArWI)^2%S@cl97O}Y+q z(?vpK1Tc-~q^V=F8b9}TJLXNfa_@5}RB}YLzC~-}7H5-HT+>O3s^@4aZ+MFUkC!%= zdA{Eoyw>sTsYT^Z+^4{jMF=4n7;!t*aiv+1vI7-IIdGa2`5D^Mx_u8t& zvO=cpezxf(&q?N9j^*TvT2{$oD8}um>s>8Tm%7r@b7ji2}j2VZvloLFMY zCq+yIV>Jvqovs`>jpzz#84q`2#F-Oe5Y<9(FyqTOQ@ zkSVVfNez?F1(Bg-T~Gyh<18WeTSegay8nf*uig5Y#QMb+>AK(D1Qk0|j}gK?6=9_h zVrmzN+q2d!N4JGS!E%T6bOC3eC2{N3Dd60(Ar;^3gGRk7#jb?tv*ny9zwP+5FX| zvNN?2BU60ARUs#sG|z8R*SRq%f;Fo$Qwheh}_e}3fUSbtek6+Pg%^aA|! ztKzhy9RuxlDW4|nDlQF+?JCl$L(}3HU+R}{2pesFL{OmM7B7>y#j@RqrXr&p$_@me zXZFoyf66mUHKP(o-)1(nK$0gp$qU#OWiLZUj-|b{{>xgOb%+PA7cs}T2LUa50MYpW z!={<*3cW+3CQ{}&v}d|Pb=#)b37=S*KP_H-`y7NbWV*`d)N(G>I`}H#wpb z{VPwK{D@AUjT}0@tm0s2&-Z&0jk^mlcdw`)}#liRi7Hc-ir(4965yU}chj;zSKlWW{E6PH()pmHn$P1X9{d%;v#w5_a% zlUQ^Gm#$Fp!5y>G=BFtRzU=AsE|lvxOJEi@PUQ2^Aw{7FoEhT^uGPwp9~}dRmSy4; zRCbvQ2dl0y&Q-l*Y^m5*>~5+!d?M4sgmqe+DE!iJMT#l*?IU!LC~Y00^7b#^cd5_$ z4bdA;AhGlh5&UjVc3Zn_Jtm!k>oFtTGbdj}^>eU0-B;#u1OKo|{Z2HvS3D?smqx^c z3pH3OEuKo7RyS!IomOjxV1#qA7hT|(N{Mn+)wgjnQ#2M@;C5}<4y|yeXN!70t+-Sx zqQ8UhB6=8vUYj2-F#7CY&xtsRo80M?*39J(;D?gl4B*ph@-e*ppDL>&ea%b`@0# z6oWigFQVz=Prb)gv92V2tjp3HL&?( zmtEJL>f#xeaTdv-r14vIB5D28{ebUn(1X3abdz|WK0K0YD)(xd3f3Q1<)@k?|Fw_!G1|@+&TW+o|rKA7m zRs&9zWN+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(^ic 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{nW$}MY-*ly&Pf3)?LiOxKKpOH6rxNwE370<1IjP*FoTsKQ!(Y6>Zs*Y)-Nu*~*)1Pj@!V03|H%aTLFjm8Y>;+*&Al z=@7Sq*)dRSPI4=ceale0%o*7gQsde$ni2P}1}m0*m>p%k&y$)0-#9@EZE@y7gUZkJ6XKzaK)k*kAI#y2AB- zuc#fSJ5!+TCb-QbpSdgZODC}4q6*uwiVU>rkh9pvSH;lP#QMN-U8UW)Y$X2HjkT?R zMRs`G^`ew|466+c{2xmcRjl@I3P2s;oX?$fT;9|QT|L`H%2w%=8H8Wjlx?*EV8u&l z!uwo!o7N$LtYk$6hXc4aEF7kAD5^h6hsy(DwcXW!MzK=gfYokQ`*l6@AEKyt6jg`f znvIS5m1}L>&~hJ&OOtCTJ+ty|Yp#lYo-VPi#&u{Jkso~wh_FuL|AoTBN)DIp+k+)X z+p|0K8w5$pPSd8Xx!YP--~t=z4+g6GVlNo0y(mw+jS{X69z+$3ARZR@t%sp*?9ArO z)0}L1u2pz)JbkU{A%n88aCAzp2)KipMgPn78}0jtcLPVw;o*p?@8@P}`$YASRQ}F4<;cDdc1Uloaf&q0qvUChA#b1!W^bj$-)hd4T>S zsX7Q`dvn_6jsoP^@apU?BtSK%*-ZNp*vv#wxhYAaKi60Bf}Ix58Olt+r__F}YLg;+ zq&b7D_s*8Dz}?Qd$4)I=i9sr=im3wq#;n_P!PA4D1V4&pbJEh*gkDJ`J3d$l?c=h0 z;AP7X6;&|r)k^BjR=(mgg?gJWvbb!JR!!A>vG-L@XeI9Z^h$^KMx+Y=yj!XlTzYdY zQJQ}7)MwssWJ6Zm8eQQUfS1A#iib&sp^7CqGOE)-@cM zk)=aqaudSqLx?d?Zs@@YYF`al9SwxrrN&L=t|f9Yhf$f*!DL5qev%d-xa5Aa*S-Z@ zh`i@mg?`p6A0*x7b1yElVjpSuXhXxBlV_JRdg4-{6N6=LY+0as&xdUKuS^tF&* zu2V1mTJjC;Gd8dH6yzgGeO4i79a(v5y25!I7PwC`kTYwnqQ8aMu>AJXGGA_%Lq&Jk z9ZZ>B?0+@msXR8j`zhD}DDAh5z6v?VSD<%q!b>_FmI0qK;+ikwq}CNw$2Pj47=y19 zcjH;-%#o`>GYBs*EOy8HZl}mk54uh9de;dvIELhG5{H;KWz3WmJZfx?l5H7m+a=;ygUM(vrnexgYKDmHV4)i=gZFImG4vslx3KksJktW> zl5SK!B;wIL(&5HEDKN=MGAO;&YJ--s&Q+@oo3;bGfz?hR6y$en|0yAeOpUT2cO$w> z-(Iciofe)5^2Gl8vopuf!{Xa05D9_2(NEK4o7c;69A@An=Kv^A!z_TMs|V--=%*_D yA9zvC&8gF5vVy1tXimLYD_$@-t~~a9P5F7o2^}4R@^Rp|0rEcK=Sg$Fc0KrO literal 0 HcmV?d00001 diff --git a/docs/migration-unmanaged-direct.fig b/docs/migration-unmanaged-direct.fig new file mode 100644 index 0000000000..d4dee04333 --- /dev/null +++ b/docs/migration-unmanaged-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 630 2925 2700 HV Ctrl\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 630 5550 2700 HV Ctrl\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 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 +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 + 3675 2625 5400 2625 +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-unmanaged-direct.png b/docs/migration-unmanaged-direct.png new file mode 100644 index 0000000000000000000000000000000000000000..d49cd0d0b16957193504eb68b909da8688a9ad60 GIT binary patch literal 3951 zcmcInX;c%~l8$I2TOeq+jV+4|J`rpbMAi^c(V&b#WRbCf#7JYBCF}u`5Ku(GCM+$h z2t-7KECvG@)&P=jkOYY>OMn;_A#4GH1PEaXFV37f=goBYnIG@XkNe$w>zw*=Z&iI? z)dQHb15oKZB>(^bymI-XD*&*kRJKkj$jdBx&4d-%wkN{X;R1ltt2rmTD286X5di=w zKlrltSah>q%8dIXuQ*-W&sEY;u~L`U#!vwOwLMoZo_CKKS>y#itT2|7hn*RyoF&}9 z^pMa9obD>JGyy8e{T%A-!J)qdsbs_+JE|32@3j{|`nrHT_fkH6DysRbK%`w;TU$C- zHM(c_tW)1Aose~}Q0ptJRn>HCdQ{JDR|R0aFHs%Pp#b zo6yh{rT=1|^m~2PvqmuQ(R_I4<`ZOO4}=$U@M%FRTObo+ZBH3zOawz$UD;BO8?-G%;bxEYgO%A~Xg*^l8>Y54{fXiR?c zBWKID=_6smKC}v#F|nA`vS4&X7#;k$#fWL`l=Dt(-50mEL*TDNVp+h3E>geK><)!FJMPDeFM z7!Kggot?$%1_WUxUkBXj=IF$wsR@<>;=NDnh#q^J8nV9|q3uM_V7s3{rer2*4&sThCbWEeHuJp z<3V7CP12KUM_;2Ga!nUKg*MX&;23K)vml2NiSdknk;)bCjGyHPxe=rIbcuyw;oE|yYfXa+N<>s_#&Z><=!-){|+rAszH+%q28Sh!V@ z`l##%Zcli?y~VKGCS|7r=d+s0m>YPX<*^9vR9514QEGTY2T+AGt5t+-!*!XExRonI zW1@y#bJ@>YyWhW_t`qO&lYX64esDjBn2t;hgpM^Jistg|JQQ|>`QJi2W<$A94Mn}K z?X`}#wR3{WN$joh706%J7erN+#FNcF`{9?NT=`8;b?`DMqV(* zMtCzg!!)Gy`Q6pDExoRZg5SIO_u_&sPYn-0E6ETP4rN;?4e6*ugW{IiMHKByb{kmv zn{(?9iRzDw(wvLJro}5_tCgWRNCr5k_u$2KhgNf@N-;rE=;1Id>H03K zgwsrUJg_k}cZ(=ConHCA?$qS4P?NP7rHuEVBCRGZ&z$ z>nMUH@I~z{BLw(^yms@GrrY{H;N3E&?TUGMS=e4iYg~LhN=vlfB_^b6Owu`du1%z= zYC1U7AKdVp^^G5(w$tB^Ie8{IH_9cuQl$?^hJ=z^w|PL4Vc_iAYXf+$#}Y`gRJ4*B z6|DQ!dM0;>8hATmq#}INY;gdbCm}sQSss_`E;&Dc3U1{CDfF}(ER~gBRXK3gF+nZI zBR;h`?)ag0u$+HY5#GUTZD~F1cVnNOyUfvRarCQae-4$wi|sFvg-Vl8|)7`1N? zks!(esmftkdp@j!RA!dTnN3?CR6PvpYxqm zBbpzxb4}K-t4YqTE}v5KihEykAcFB? zNq&%}frEW|m;;eHPIQ$7zknZjg#iqVnHX|QsZqikUTXpP*JMI0=22?M%@dxZL!ggC z_-dk2`ny{G;(!||x~h!kkTIte|L6lyg;YN!pHwN#a4;QQznXUOCAvD7mhta-k1`~A zj1*CK8e3ny9~oI_oDi)oDt6l6-lh0O>bm9()pm6Lvt%3K)t7|||HTs?8bI-!?vyX!g~@sP!43)PZX_AcNW(xk41DC^EQNJ22eAdbd*%?h0I_MJ5 z>BTm|lA?{T?*9w2|5f)sXvq$r?X%m4=91A|55EDpfm))vrcM6(tMziAo2V>1$OZ(R zHG+7G;jWJHxGQL`R55p3`aY7s?Mp8WZz`!lESBFjPB^VXwpL({v1(WxR^|zWi^02j zAphuhO3h8Sat~OVecGq6bMo}vsr513EIQcdf`Zszv>S0W+i&VYxkWUdb;U{%2Y>4nXho@Eha_sSI#=N1>o2|4T^Hm{wmOrum)vQ!jGQCwZ z%pln`^ka%Z8|Q(wvPxuvdN?I3s1wyXcZ=0=(2%9Wbl1V_GU0am=>)Me*Yr?$b(}mz zFHyZ?_84-N&vn=Mob%D?Ph!#Dg_YY|M&;;??@d(i`J`OE%=^;_|Ap@TQ3=0T#=8t} zIx0+j%^I)WY^^^4g8p>bQmhCZV;gJz@Ba0_Yi6Me?R9cbu|lg){6w10h25a7WRT5W zXtcx46%9Yej& zpFirLJ(hQM4+{9)rLtTYeya2Dh#qYs!cWI&ML+vRN_h4%hQB z@9_o3`amV4{jv6bJ&!_`P;gOWSqFYr>^%t6B9GpyUOImyp>er$EGC~)Xl{`ysiJSw zm;RP58emnjGz+TX*HwRM6$*jT5CjL~L=0O;!CiZ6t#fqGTqk9JVAx=mf%NEp?T1L~ zRifoHo7e%`;!}NVcF}3EGqd=j!h|#n5&xW1Pb+L(GY}Yi*jXxbh%uEP1G^zV$3j~; zv5lWcpK@M#SOp69;-Ih2>v@l5zlv&YDucCoo}SEs##e?Hp4d6_w0fKzMDIif*n`E0iVDP8$Q z7zVVRLGaqucrX~dc>sj~vtb0L7fk?nA-Mf!k(hZz0|eDHC(_&z@m8BWzX<#_--$Ie z<{-3ZLSDWV-b#JalDqN_u@9rKg@eu>CLq}g5WQB?5sm*rSsRx1QKscWJo~CF@46I@ z-GLnbLc4opZ1D$7Q1j=~6m>twkI)DkZu9)C)3g{RsPrWDHMK_UeOy7$@-oQmU0a#g z6p8Gw-SMLCH#g%>=4hXO?gL}FLuWs%k)Whaw>gYjDVn?GvV(J+lfqT++3*UAnL}ri zbL$7rs6*R(=}&ci@1E^{tF}|@8sO?E3t`{U7s(6ZjaDi1#)-de@7W?t=;_0@=XBu<`Y?Q7&+m4Lq;P^Q>0ks!uhOd|8^6LK%ak z#6a}MPnrxen$Mz zzD&@Ryd0jUfZT`pw@ypkBB}zV?z?^PKk&Ps8MsG$m^ap*p)aS7+!yp7%w%}!CcXhL zBqit~jxa?=ig!J6Mr&tS6OEegd|o6bf8IcsI6i*2U%bP3|JZW~AFlmj%2?(@M;Ha|}HUCdY__nH1l!+wV?p(;_(LWgcZ&u0WY + +

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