← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1719362] Re: libvirt: Data corruptor live migrating BFV instance with config disk

 

** Also affects: nova/ocata
   Importance: Undecided
       Status: New

** Also affects: nova/pike
   Importance: Undecided
       Status: New

** Changed in: nova/ocata
       Status: New => In Progress

** Changed in: nova/pike
   Importance: Undecided => High

** Changed in: nova/pike
       Status: New => In Progress

** Changed in: nova/ocata
   Importance: Undecided => High

** Changed in: nova/ocata
     Assignee: (unassigned) => Matthew Booth (mbooth-9)

** Changed in: nova/pike
     Assignee: (unassigned) => Matthew Booth (mbooth-9)

-- 
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):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  In Progress

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


References