Usually the source volume would be the same size or smaller
than the destination volume and they must share the same
volume-type. In particular, when the destination volume is
same size as the source volume, creating an encrypted volume
from a snapshot of an encrypted volume truncates the data in
the new volume.
In order to fix this the RBD workflow would be something
like this:
A source luks volume would be 1026M, we write some data
and create a snap from it. We like to create a new luks
volume from a snapshot so the create_volume_from_snapshot()
method performs a RBD clone first and then a resize if needed.
In addition the _clone() method creates a clone
(copy-on-write child) of the parent snapshot. Object size
will be identical to that of the parent image unless specified
(we don't in cinder) so size will be the same as the parent
snapshot.
If the desired size of the destination luks volume is 1G the
create_volume_from_snapshot() won't perform any resize and
will be 1026M as the parent. This solves bug #1922408 because
we don't force it to resize and because of that we don't
truncate the data anymore.
The second case scenario is when we would like to increase
the size of the destination volume. As far as I can tell this
won't face the encryption header problem but we still need to
calculate the difference size to provide the size that the
user is expecting.
That's why the fix proposed calculate the new_size based on:
size difference = desired size - size of source volume
new size = current size + size difference
Closes-Bug: #1922408
Co-Authored-By: Sofia Enriquez <email address hidden>
Change-Id: I220b5e3b01d115262a8b1dd45758f0531aea0edf
(cherry picked from commit cf1c5252965e731d77af503529ca42e269c305c6)
Reviewed: https:/ /review. opendev. org/c/openstack /cinder/ +/803181 /opendev. org/openstack/ cinder/ commit/ 165122557d4976a e902ac6156d1512 14fec037ae
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit 165122557d4976a e902ac6156d1512 14fec037ae
Author: haixin <email address hidden>
Date: Sat Apr 3 12:36:14 2021 +0800
[rbd] Fix create encrypted volume from snapshot
Usually the source volume would be the same size or smaller
than the destination volume and they must share the same
volume-type. In particular, when the destination volume is
same size as the source volume, creating an encrypted volume
from a snapshot of an encrypted volume truncates the data in
the new volume.
In order to fix this the RBD workflow would be something volume_ from_snapshot( )
like this:
A source luks volume would be 1026M, we write some data
and create a snap from it. We like to create a new luks
volume from a snapshot so the create_
method performs a RBD clone first and then a resize if needed.
In addition the _clone() method creates a clone
(copy-on-write child) of the parent snapshot. Object size
will be identical to that of the parent image unless specified
(we don't in cinder) so size will be the same as the parent
snapshot.
If the desired size of the destination luks volume is 1G the volume_ from_snapshot( ) won't perform any resize and
create_
will be 1026M as the parent. This solves bug #1922408 because
we don't force it to resize and because of that we don't
truncate the data anymore.
The second case scenario is when we would like to increase
the size of the destination volume. As far as I can tell this
won't face the encryption header problem but we still need to
calculate the difference size to provide the size that the
user is expecting.
That's why the fix proposed calculate the new_size based on:
size difference = desired size - size of source volume
new size = current size + size difference
Closes-Bug: #1922408 262a8b1dd45758f 0531aea0edf d77af503529ca42 e269c305c6)
Co-Authored-By: Sofia Enriquez <email address hidden>
Change-Id: I220b5e3b01d115
(cherry picked from commit cf1c5252965e731