a107a5099e
When connecting an encrypted volume to a host the _attach_encryptor method will be called in order to either call a legacy os-brick encryptor *or* configure a libvirt secret used by libvirt and QEMU to natively decrypt LUKSv1 encrypted volumes. To create this libvirt secret the configured key manager will be queried to provide and then decode the associated secret before this is stashed within libvirt. This change simply skips the above when an existing libvirt secret associated with the target volume is found on the host already. While this obviously optimises basic instance lifecycle flows such as a simple power off and on it additionally resolves a more convoluted use case when the ``[DEFAULT]/resume_guests_state_on_host_boot`` configurable is enabled. In this case the compute service has no request context with which to query the key manager when attempting to restart instances with encrypted volumes attached. As a result any attempt by the compute service to restart an instance with an attached encrypted volume would previously fail. Closes-Bug: #1905701 Change-Id: Ia2007bc63ef09931ea0197cef29d6a5614ed821a
14 lines
557 B
YAML
14 lines
557 B
YAML
---
|
|
fixes:
|
|
- |
|
|
The libvirt virt driver will no longer attempt to fetch volume
|
|
encryption metadata or the associated secret key when attaching ``LUKSv1``
|
|
encrypted volumes if a libvirt secret already exists on the host.
|
|
|
|
This resolves `bug 1905701`_ where instances with ``LUKSv1`` encrypted
|
|
volumes could not be restarted automatically by the ``nova-compute``
|
|
service after a host reboot when the
|
|
``[DEFAULT]/resume_guests_state_on_host_boot`` configurable was enabled.
|
|
|
|
.. _bug 1905701: https://launchpad.net/bugs/1905701
|