yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

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

** Changed in: nova
   Importance: Undecided => Medium

** Changed in: nova/queens
   Importance: Undecided => Medium

** Changed in: nova/queens
       Status: New => Confirmed

** Tags added: libvirt volumes

-- 
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/1749418

Title:
  swap volume not blocked between an unencrypted and encrypted volume
  while using QEMU to natively decrypt

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) queens series:
  Confirmed

Bug description:
  Description
  ===========
  The original check [1] introduced in Queens only handles cases where we are swapping from an encrypted LUKS volume and does not handle swapping from an unencrypted volume into an encrypted LUKS volume. This still needs to be blocked pending additional QEMU/libvirt wiring to allow data to be rebased into an encrypted LUKS disk while using QEMU to natively read and write to the disk.

  [1]
  https://review.openstack.org/#/c/523958/18/nova/virt/libvirt/driver.py@1487

  Steps to reproduce
  ==================
  Swap between an unencrypted volume to a LUKS encrypted volume in >=Queens with the native QEMU decryption requirements met (QEMU >=2.6 and Libvirt >=2.2.0 ).

  Expected result
  ===============
  This is blocked by n-cpu with a NotImplementedError raised.

  Actual result
  =============
  This is allowed but ultimately fails due to Libvirt being unable to rebase into the encrypted disk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1749418/+subscriptions