Differences

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

--- unix:virtualization:virtlib:migrate [2022/05/19 01:32] – rodolico
+++ unix:virtualization:virtlib:migrate [2022/05/22 21:22] (current) – rodolico
@@ Line 71: / Line 71: @@
 Failing that, you will get an error about an incompatible netcat (nc) which does not have the -U flag.
-====== Set up root access between hypervisors ======
+===== Set up root access between hypervisors =====
+I like to use ssh, and since I'm in a fairly secure environment, I don't mind giving root on all the machines access to each other without a password. It uses Public Key pairs to do this.
+On each machine, run the command <code bash>ssh-keygen -t rsa -b 4096</code>. Feel free to change the type (rsa) and key length (4096) for your purposes.
+Now, copy the contents of /root/.ssh/id_rsa.pub from **each** machine to /root/.ssh/authorized_keys on **all machines**. So, for example, if you have three machines, each will have two lines in their /root/.ssh/authorized_keys file, each line containing the contents of id_rsa.pub from the other two machines.
+Test this by logging into each machine as root, then issue the following command for each of the other machines. This simply give a directory listing of /root/, which is all we need for a test.
+<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