yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #68086
[Bug 1719362] [NEW] libvirt: Data corruptor live migrating BFV instance with config disk
Public bug reported:
When live migrating a BFV instance with a config disk, the API currently
requires block migration to be specified due to the local storage
requirement. This doesn't make sense on a number of levels.
Before calling migrateToURI3() in this case, the libvirt driver filters
out all disks which it shouldn't migrate, which is both of them: the
config drive because it's read-only and we already copied it with scp,
and the root disk because it's a volume. It calls migrateToURI3() with
an empty migrate_disks in params, and VIR_MIGRATE_NON_SHARED_INC in
flags (because block-migration).
There's a quirk in the behaviour of the libvirt python bindings here: it
doesn't distinguish between an empty migrate_disks list, and no
migrate_disks list. Both use the default behaviour of "block migrate all
writable disks". This will include the attached root volume. As the root
volume is simultaneously attached to both ends of the migration, one of
which is running guest, this a data corruptor.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1719362
Title:
libvirt: Data corruptor live migrating BFV instance with config disk
Status in OpenStack Compute (nova):
New
Bug description:
When live migrating a BFV instance with a config disk, the API
currently requires block migration to be specified due to the local
storage requirement. This doesn't make sense on a number of levels.
Before calling migrateToURI3() in this case, the libvirt driver
filters out all disks which it shouldn't migrate, which is both of
them: the config drive because it's read-only and we already copied it
with scp, and the root disk because it's a volume. It calls
migrateToURI3() with an empty migrate_disks in params, and
VIR_MIGRATE_NON_SHARED_INC in flags (because block-migration).
There's a quirk in the behaviour of the libvirt python bindings here:
it doesn't distinguish between an empty migrate_disks list, and no
migrate_disks list. Both use the default behaviour of "block migrate
all writable disks". This will include the attached root volume. As
the root volume is simultaneously attached to both ends of the
migration, one of which is running guest, this a data corruptor.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1719362/+subscriptions
Follow ups