Sizing encrypted volumes¶
If you have an unencrypted volume and migrate to an encrypted type, it fails because there isn’t enough space on the target to fit the entire source volume. This happens because an encrypted volume must have a header, which takes up some space.
In fact, the exact amount of space lost isn’t clear, it may vary by LUKSv1/LUKSv2 and PLAIN dm-crypt formats. It’s probably on the order of 1-2 MB, but we allocate space in GB. Whether you can do really fine-grained space allocation or not probably depends on the backend containing the volume. However, we also need to keep the gigabyte boundaries for accounting purposes (usage, quotas, charges, etc.) because that’s what everyone’s tooling expects.
In addition, drivers optimize migration in different ways, and since we previously didn’t have a new size parameter, there’s no easy way to get this info into the drivers.
Taking everything into consideration, we could have a flag indicating that it’s OK for the volume to be increased in size if it’s required for the retype to succeed. This way we don’t go behind the user’s back – we fail if the volume won’t fit, and allow them to retype to a new size if they want the retype to succeed.
The main use-case here is when upgrading an old deployment and would like to encrypt old volumes after that.
The manager.py will create a destination volume bigger <source-volume-size+1> GB size if the flag ‘allow-resize==on_demand’ and the destination volume-type is encrypted.
Driver-specific method ‘_copy_volume_data’ for copy volume data when using block devices (i.e LVM will still use the actual _migrate_volume_generic). This method will be called after _before_volume_copy during volume migration.
RPC minor version for a new param 3.x - Add allow_resize to retype method and increase_size to migrate method.
Add a new optional field, “allow_resize”, to the os-retype action. Possible values will be “on-demand” or “never” (which are the same as the current “migration_policy” field). If not specified, the default is “never”.
Add a new optional field, “increase_size”, to the os-migrate action. The operator specifies how many GB to grow the volume (so the final size is current size + increase_size).
Add the next parameters to Python-cinderclient for retype and migrate commands:
Retype: New flag
--allow-resizeindicating that it’s OK for the volume to be increased in size if it’s required for the retype to succeed.
Optional Arguments: --allow-resize <never|on-demand> Allow the volume to be increased in size during the retype if the system decides it is necessary. This argument is recommended when retyping to an encryption type. ...
Migration: allow a new size to be specified during a volume migration. New optional argument added
Optional Arguments: --increase-size [<size>] Number of GiBs to grow the volume during migration. This is recommended when migrating to an encrypted host. ...
The displayed size of the volume will be the actual size of the volume.
Leave everything as it is and don’t allow this kind of migration. To help users add some workaround to the documentation (i.e. backup the volume and then restore the volume to a bigger one). <1GB size increases won’t be allowed, as explained in the problem description above.
Data model impact¶
REST API impact¶
New parameters should be passed to retype and migrate commands as explained in the ‘proposed change’ section.
None. If you’re allowed to migrate at all, you should be able to increase the size, and if you’re allowed to retype, you should be able to allow-resize.
Other end user impact¶
Other deployer impact¶
- Primary assignee:
Sofia Enriquez <email@example.com>
Implement new logic in cinder
Implement new logic in python-cinderclient
Unit tests and current devstack-based jobs won’t be enough to test these changes. At least two tests should be added to cinder_tempest_plugin/api/volume/admin/test_volume_retype.py
retype unencrypted volume to LUKS type.
retype encrypted LUKS volume to regular type.
Currently I’ve added some documentation notes warning about retyping an unencrypted/encrypted volume. However, these notes should be replaced with proper documentation.