From: Daniel P. Berrange Date: Fri, 2 Oct 2009 16:53:51 +0000 (+0100) Subject: Add documentation about migration. X-Git-Tag: v0.9.7-rc1~22 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a78478443806e6afc5ecbb99aeb4cb33677f97ff;p=thirdparty%2Flibvirt.git 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 --- 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 0000000000..f8fbb3aabf Binary files /dev/null and b/docs/migration-managed-direct.png differ diff --git a/docs/migration-managed-p2p.fig b/docs/migration-managed-p2p.fig new file mode 100644 index 0000000000..42875481b1 --- /dev/null +++ b/docs/migration-managed-p2p.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 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-managed-p2p.png b/docs/migration-managed-p2p.png new file mode 100644 index 0000000000..eb9355866b Binary files /dev/null and b/docs/migration-managed-p2p.png differ diff --git a/docs/migration-native.fig b/docs/migration-native.fig new file mode 100644 index 0000000000..0b4ac686e3 --- /dev/null +++ b/docs/migration-native.fig @@ -0,0 +1,43 @@ +#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 7 1 0 4 + 1 1 1.00 135.00 180.00 + 3375 1350 3375 825 5700 825 5700 1350 +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 + 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 + 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 + 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 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 1080 1350 2850 Source Host\001 +4 0 0 50 -1 16 12 0.0000 4 150 870 6825 2850 Dest Host\001 diff --git a/docs/migration-native.png b/docs/migration-native.png new file mode 100644 index 0000000000..bf35cf185b Binary files /dev/null and b/docs/migration-native.png differ 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 0000000000..0f186d3e9f Binary files /dev/null and b/docs/migration-tunnel.png differ 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 0000000000..d49cd0d0b1 Binary files /dev/null and b/docs/migration-unmanaged-direct.png differ 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: +

+ + + +

+ 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