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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list