8fbaeba11f
Patch fixing bug #1861071 resolved the issue of extending LUKS v1 volumes when nova connects them via libvirt instead of through os-brick, but nova side still fails to extend in-use volumes when they don't go through libvirt (i.e., LUKS v2). The logs will show a very similar error, but the user won't know that this has happened and Cinder will show the new size: libvirt.libvirtError: internal error: unable to execute QEMU command 'block_resize': Cannot grow device files There are 2 parts to this problem: - The device mapper device is not automatically extended. - Nova tries to use the encrypted block device size as the size of the decrypted device. This patch leverages the "extend_volume" method in os-brick connectors to extend the device mapper device, after the encrypted device has been extended, and use the size of the decrypted volume for the block_resize operation. Related change: I351f1a7769c9f915e4cd280f05a8b8b87f40df84 Closes-Bug: #1967157 Change-Id: Ia1411f11ec4bf44af6a42d5f96c8a0903846ed66
10 lines
342 B
YAML
10 lines
342 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Extending attached encrypted volumes that failed before because they were
|
|
not being decrypted using libvirt (any other than LUKS) now work as
|
|
expected and the new size will be visible within the instance. See
|
|
`Bug 1967157`_ for more details.
|
|
|
|
.. _Bug 1967157: https://bugs.launchpad.net/nova/+bug/1967157
|