[virt-tools-list] KVM Migration Using Virsh

Chris Lalancette clalance at redhat.com
Mon Oct 12 13:49:26 UTC 2009


Jeff Hardy wrote:
> I have been trying to get migration and/or live migration working on a 
> pair of KVM systems, using this syntax on host system named blade1:
> 
> virsh migrate sputnik qemu+ssh://blade2/system
> virsh migrate --live sputnik qemu+ssh://blade2/system
> 
> The VM makes it to the destination fine, but begins with a reboot in 
> both cases.  The libvirt logfile on the destination shows only:
> 
>   LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc 
> -m 512 -smp 1 -name sputnik -uuid c2bffc39-a9b5-29dc-1ca5-fb49ac664c1d 
> -monitor pty -pidfile /var/run/libvirt/qemu//sputnik.pid -boot c -drive 
> file=/mnt/os2/sputnik-disk0,if=virtio,index=0,boot=on -net 
> nic,macaddr=00:16:3e:10:13:e3,vlan=0,model=virtio -net tap,fd=17,vlan=0 
> -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 
> -incoming tcp:0.0.0.0:49154
> char device redirected to /dev/pts/2
> char device redirected to /dev/pts/3
> 
> Both machines are configured identically, with identically named bridges 
> to the same networks, and the raw VM image mounted at the same location 
> on a clustered filesystem.  Each host system is on kernel 
> 2.6.30.8-64.fc11.x86_64 and libvirt-0.6.2-17.fc11.x86_64.
> 
> Is this something I should expect to work?  This link still includes 

Yes, it's expected to work.  Typically something like this is due to bugs in
qemu (although bugs in the kernel and libvirt aren't inconceivable); what
version of qemu are you running?

-- 
Chris Lalancette




More information about the virt-tools-list mailing list