[libvirt] [PATCH] qemu: fix migration with local and VIR_STORAGE_TYPE_NETWORK disks

Daniel P. Berrangé berrange at redhat.com
Thu Feb 8 09:07:05 UTC 2018


On Wed, Feb 07, 2018 at 01:11:33PM -0600, Chris Friesen wrote:
> On 02/07/2018 12:05 PM, Daniel P. Berrangé wrote:
> > On Wed, Feb 07, 2018 at 11:57:19AM -0600, Chris Friesen wrote:
> > > In the current implementation of qemuMigrateDisk() the value of the
> > > "nmigrate_disks" parameter wrongly impacts the decision whether or not
> > > to migrate a disk that is not a member of "migrate_disks":
> > > 
> > > 1) If "nmigrate_disks" is zero, "disk" is migrated if it's non-shared
> > > non-readonly with source.
> > > 
> > > 2) If "nmigrate_disks" is non-zero and "disk" is not a member of
> > > "migrate_disks" then "disk" is not migrated.  This should instead proceed
> > > with checking conditions as per 1) and allow migration of non-shared
> > > non-readonly disks with source.
> > 
> > Huh, this doesn't make sense. If an app has passed a list of disks
> > in migrate_disks, we must *never* touch any disk that is not present
> > in this list. If the app wanted the other disk(s) migrated, it would
> > have included it in the list of disks it passed in.
> 
> Okay, that makes sense.  I can restore the "return false" here.
> 
> Are you okay with the other change?

That part of the code was intended to be funtionally identical to what
QEMU's previous built-in storage migration code would do. I don't want
to see the semantics of that change, because it makes libvirt behaviour
vary depending on which QEMU version you are using.

If that logic is not right for a particular usage scenario, applications
are expected to provide the "migrate_disks" parameter.

> Our original problem scenario was where the root disk is rbd and there is a
> read-only ISO config-drive, and "nmigrate_disks" is zero.  What we see in
> this case is that qemuMigrateDisk() returns "true" for the rbd disk, which
> then causes qemuMigrationPrecreateStorage() to fail with "pre-creation of
> storage targets for incremental storage migration is not supported".

So you want zero disks migrated. Simply don't ask for storage migration in
the first place if you don't have any disks to migrate.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list