On 09/03/2014 04:10 PM, Gary Hook wrote: > On Wed, Sep 3, 2014 at 2:12 PM, Brian Rak <brak@xxxxxxxxxxxxxxx> wrote: > >> Try creating a blank file on the target system at >> /mnt/store01/virt/e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f.qcow2 on 'dewey'. >> > > Yes, tried that before posting. At least, with a simple "touch" command. > > >> Migrations really don't go well when the target disk doesn't exist. I'm >> not certain why this is, I think the migration feature was mainly built >> with shared storage in mind. >> > > I appreciate that, but unless it's a documented and designed restriction, > it seems it oughta work. And I know for a fact that it does (details which > I will not include here). > > Thank you for your time; much appreciated. Shared storage migration was implemented first. Non-shared migration was added after the fact, so you have to explicitly request it; and the fact that libvirt still can't create the destination file itself is an annoying limitation that we'd like to lift someday. It would also be nice if libvirt could detect at least obvious cases of the destination being incorrect (such as different file sizes) - except that in SOME cases, you CAN migrate to different sizes (if the source is a single raw file, but the destination is a brand-new qcow2 file with the original as its backing, then the guest contents will be identical from either source or destination perspective up until the point the destination starts writing into the qcow2 wrapper file). So I'm not sure if any heuristics can be added to help diagnose obvious problems. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
