David Wilcox wrote:
On the other machine, the log file that gets created under
/var/log/libvirt/qemo/windowsxp.log
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc
-m 512 -smp 1 -name windowsxp -uuid 24d2fd62-ed4f-a321-e264-200b347cfa6c
-monitor pty -pidfile /var/run/libvirt/qemu//windowsxp.pid -localtime
-no-acpi -boot c -drive
file=/var/lib/libvirt/images/windowsxp.img,if=ide,index=0,boot=on -drive
file=/aml/iso/windows_xp_sp3.iso,if=ide,media=cdrom,index=2 -net
nic,macaddr=54:52:00:01:f1:06,vlan=0 -net tap,fd=19,vlan=0 -serial pty
-parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0
<
http://127.0.0.1:0> -soundhw es1370 -incoming tcp:0.0.0.0:49159
<
http://0.0.0.0:49159>
qemu: could not open disk image /var/lib/libvirt/images/windowsxp.img
I would think that the virtual machine should copy from the one machine
to the other. Isn't libvirt supposed to copy the image file?
No. The underlying storage needs to be shared at exactly the same location.
That is, if on the source machine your file is located at
/var/lib/libvirt/images/windowsxp.img, then you need to nfs share
/var/lib/libvirt/images, and mount it on the destination machine as
/var/lib/libvirt/images. Then the file windowsxp.img will be available on both
sides, and the migration should work.
What's even stranger, I've been trying this for awhile. It's failed
every time, except once when it succeded. I don't know what made it
succeed in that case and fail in all the other cases.
That makes no sense, unless you have been moving the location of your NFS mount
around. It can't work without the storage being in the same place on the source
and the destination.
Note that patches have been recently posted to qemu upstream that *does* do a
copy of the entire storage along with the memory. If and when those are applied
to qemu, it's something we could think about enabling in libvirt. Note,
however, that this will quite a long time to migrate, since you have to copy the
entire disk image as well as all of the memory.
--
Chris Lalancette