Живая миграция kVM


Живая миграция kVM

Живая миграция на kvm

The command I came up with is:

virsh migrate —live —persistent —undefinesource —copy-storage-all \
—verbose —desturi

Where is the receiving host and is the name of the virtual machine to be migrated. I entered this command on the current VM host – as I do not want dependency on any client machine.

First problem: copying the disks

After issuing the migrate command, I got the following error:

Strange, as I enabled –copy-storage-all , so I thought the help (saying “migration with non-shared storage with full disk copy”) did not lie. The log files did not say anything about this, so I started reading old and not useful comments, posts and mailing list archives. There was one useful hint I though I could try:

Create an empty disk with the same geometry before migrating

You can view the disk image information with qemu-img info:

Now I could have created two 10737418240 bytes large images, but I used the same sparse file method I used when I created the original images:

0+0 records in
0+0 records out
0 bytes (0 B) copied, 2,223e-05 s, 0,0 kB/s
# dd if=/dev/null of=/ssd/vmstorage/migratetest2.raw bs=1M seek=10240
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2,4834e-05 s, 0,0 kB/s

-rw-r—r— 1 root root 10G szept 13 22:07 /ssd/vmstorage/migratetest2.raw
-rw-r—r— 1 root root 10G szept 13 22:07 /ssd/vmstorage/migratetest2.swap

As you can see, I have ended up with two 0 byte large disk images, that are really 10GB long and qemu-img do recognise them as 10 GB disks. Let’s try the migration again:

After checking the running machines list, it did seem to be working.

How good is this libvirt + qemu + kvm migration?

Network configuration

The VM has two network interfaces:

eth0 is connected to a host internal network with DHCP and NAT, so the machines can access the internet without any special configuration. This network has the same name on all hosts and the same IP configuration, so a migration can only cause problems if two machines use the same DHCP address. I assign static addresses to “long life” machines for this reason.

eth1 is connected to a bridge interface on the host that in turn is connected to a switch with all the VM hosts plugged in. This network also has the same name and configuration on all hosts with strict static IP addresses. This way, all the VMs should see each other no matter on what host they are running.

Did anyone notice the migration?

I wanted to see two things:

How many pings do we lose while migrating?
What does the VM see while migrating?
Well, it turned out pretty good. Pinging the machine from a third computer (migration started at the 15th and ended at the 34th package):

Running a little script on the machine being migrated (migration started at the 44th and finished at the 2nd second):

Please note, that this is an “easy job” as the infrastructure is pretty fast and the test virtual machine was not doing any work at all (except running the above script). The hosts have professional SSDs in hardware RAID 0, direct Gigabit ethernet connection and not much load for the blazing fast processors.

Additional random error messages you may encounter

The receiving host can not satisfy your CPU configuration needs

Although the two VM hosts has the exact same hardware configuration, I got and error that stated that the receiving host did not have the capability to provide the exact same CPU configuration to the VM.

I could not reproduce the problem, but I did solve it when it came up. I just had to replace the exotic CPU configuration the VM had:

with plain kvm:


End of file from monitor and not processing incoming migration

These errors came up randomly, and I could not figure out anything about them. They both disappeared after I decided to set up the receiving VM host completely (networks, kvm kernel module, etc.) before playing around with migration like a child who can not wait till dessert.

Good luck with migration! :)

Об авторе

human administrator

    Оставить ответ

    Войти с помощью: