On Wed, Feb 07, 2018 at 13:11:33 -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?
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 why do you use storage migration if your storage is shared or would
not be migrated as in the case of the config cdrom?
Said this, by default the storage migration probably should not try to
migrate network disks unless explicitly asked to do so. The check should
use virStorageSourceIsLocalStorage though, since blindly checking
NETWORK is not okay as you need to check the actual storage type.