Differences

This shows you the differences between two versions of the page.

--- unix:virtualization:virtlib:migrate [2022/05/19 01:40] – rodolico
+++ unix:virtualization:virtlib:migrate [2022/05/22 21:22] (current) – rodolico
@@ Line 82: / Line 82: @@
 <code bash>ssh hostname 'ls'</code>
 If something breaks, fix this before you go further.
+Finally, test the virsh connection between machines. Assuming virtlib running on both machines and ssh access, this should work: <code bash>virsh -c qemu+ssh://hostname/system list</code>. This should return a list of all virtuals running on the TARGET machine.
+===== Notes =====
+  * Make sure you have the same bridges defined on all hypervisors, with the same names: <code bash> virsh net-list</code>
+  * Make sure your paths are all the same on all hypervisors: <code bash>ls /dev/disk/by-path</code>
+  * There are several GUI and WebUI tools to do the migration, but the only one I've used (virt-manager) has some serious issues.
+    * It assumes you want to copy your block devices to the target, and fails when it tries to do it. However, I was able to shut down on one machine and start up on the second, once I had used --persistent one time to copy the config.
+    * I have some machines with the disks encrypted. The message to enter my passphrase doesn't show up on the virt-manager console screen
+===== Test the migration =====
+Ok, you know ssh works, and you have the correct version of cpu definition on all machines, and you have checked the configuration. Now it is time to test. On the source machine:
+<code bash>virsh migrate --live --persistent --verbose  runningVirt qemu+ssh://target/system</code>
+Replace //runningVirt// with the name of a test virtual you want to migrage, and //target// with the same name you used for your ssh tests. You should see a notification that the virtual is being moved, with a progress. On a very small (4G RAM) under no load, it took about a second.
+  * **--live** simply says "do this without shutting the virtual down
+  * **--persistent** copies the virtual's definition to **target** so it can be shut down/started there.
+  * **--verbose** lets you see what is going on, which I like
+  * **qemu+ssh:** says to make the move over ssh
+  * **system** gives you access to the system on the target, allowing migrate to start the machine
+There are a lot of additional things you can do with migrate. From the command prompt, <code bash>man virsh</code> and search for migrate.
+===== Links =====
+  * https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-managing_guest_virtual_machines_with_virsh-guest_virtual_machine_cpu_model_configuration
+  * https://www.geekpills.com/virtulization/kvm-guest-cpu-doesnt-match-specification-missing-features-hlertm