Hi Michal, I think issuing a libvirt migrate to a host where the network disks don't already exist would be a prequisite failure. Libvirt can never copy a network disk, but it shouldn't fail trying to migrate an existing domain that contains a network disk. If a libvirt user wishes to migrate a domain that contains a network disk, it's their responsibility to ensure the disk exists before calling migrate.
Could you propose this patch to libvirt? -- Noel On Thu, Mar 19, 2015 at 3:45 AM, Michal Privoznik <[email protected]> wrote: > On 18.03.2015 22:00, Nick Bartos wrote: > > Actually I messed that up slightly on the case. My C is a bit rusty: > > > > diff -U3 -r libvirt-1.2.13.orig/src/qemu/qemu_migration.c > > libvirt-1.2.13/src/qemu/qemu_migration.c > > --- libvirt-1.2.13.orig/src/qemu/qemu_migration.c2015-02-23 > > 22:04:12.000000000 -0800 > > +++ libvirt-1.2.13/src/qemu/qemu_migration.c2015-03-18 > > 13:55:45.873322477 -0700 > > @@ -1507,9 +1507,12 @@ > > flags |= VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA; > > break; > > > > + case VIR_STORAGE_TYPE_NETWORK: > > + ret = 0; > > + goto cleanup; > > + break; > > case VIR_STORAGE_TYPE_BLOCK: > > case VIR_STORAGE_TYPE_DIR: > > - case VIR_STORAGE_TYPE_NETWORK: > > case VIR_STORAGE_TYPE_NONE: > > case VIR_STORAGE_TYPE_LAST: > > virReportError(VIR_ERR_INTERNAL_ERROR, > > Sounds reasonable to me. Although I'm worried that there might be users > using network disk, supplying different XML on migration, where the disk > is switched to yet non-existent network disk, expecting libvirt/qemu to > copy the data. > > The other option is: libvirt won't copy shared or read only disks. So > OpenStack would mark network disks as shared. > > One way or another - do you want to propose a patch or should I do that? > > Michal >
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
