When rebuilding a volume backed instance, while copying the new
image to the existing volume, we preserve sparseness.
This could be problematic since we don't write the zero blocks of
the new image and the data in the old image can still persist
leading to a data leak scenario.
To prevent this, we are using `-S 0`[1][2] option with the `qemu-img convert`
command to write all the zero bytes into the volume.
In the testing done, this doesn't seem to be a problem with known 'raw'
images but good to handle the case anyway.
Following is the testing performed with 3 images:
1. CIRROS QCOW2 to RAW
======================
Volume size: 1 GiB
Image size (raw): 112 MiB
CREATE VOLUME FROM IMAGE (without -S 0)
LVS (10.94% allocated)
volume-91ea43ef-684c-402f-896e-63e45e5f4fff stack-volumes-lvmdriver-1 Vwi-a-tz-- 1.00g stack-volumes-lvmdriver-1-pool 10.94
REBUILD (with -S 0)
LVS (10.94% allocated)
volume-91ea43ef-684c-402f-896e-63e45e5f4fff stack-volumes-lvmdriver-1 Vwi-aotz-- 1.00g stack-volumes-lvmdriver-1-pool 10.94
Conclusion:
Same space is consumed on the disk with and without preserving sparseness.
2. DEBIAN QCOW2 to RAW
======================
Volume size: 3 GiB
Image size (raw): 2 GiB
CREATE VOLUME FROM IMAGE (without -S 0)
LVS (66.67% allocated)
volume-edc42b6a-df5d-420e-85d3-b3e52bcb735e stack-volumes-lvmdriver-1 Vwi-a-tz-- 3.00g stack-volumes-lvmdriver-1-pool 66.67
REBUILD (with -S 0)
LVS (66.67% allocated)
volume-edc42b6a-df5d-420e-85d3-b3e52bcb735e stack-volumes-lvmdriver-1 Vwi-aotz-- 3.00g stack-volumes-lvmdriver-1-pool 66.67
Conclusion:
Same space is consumed on the disk with and without preserving sparseness.
3. FEDORA QCOW2 TO RAW
======================
CREATE VOLUME FROM IMAGE (without -S 0)
Volume size: 6 GiB
Image size (raw): 5 GiB
LVS (83.33% allocated)
volume-efa1a227-a30d-4385-867a-db22a3e80ad7 stack-volumes-lvmdriver-1 Vwi-a-tz-- 6.00g stack-volumes-lvmdriver-1-pool 83.33
REBUILD (with -S 0)
LVS (83.33% allocated)
volume-efa1a227-a30d-4385-867a-db22a3e80ad7 stack-volumes-lvmdriver-1 Vwi-aotz-- 6.00g stack-volumes-lvmdriver-1-pool 83.33
Conclusion:
Same space is consumed on the disk with and without preserving sparseness.
Another testing was done to check if the `-S 0` option actually
works in OpenStack setup.
Note that we are converting qcow2 to qcow2 image which won't
happen in a real world deployment and only for test purposes.
DEBIAN QCOW2 TO QCOW2
=====================
CREATE VOLUME FROM IMAGE (without -S 0)
LVS (52.61% allocated)
volume-de581f84-e722-4f4a-94fb-10f767069f50 stack-volumes-lvmdriver-1 Vwi-a-tz-- 3.00g stack-volumes-lvmdriver-1-pool 52.61
REBUILD (with -S 0)
LVS (66.68% allocated)
volume-de581f84-e722-4f4a-94fb-10f767069f50 stack-volumes-lvmdriver-1 Vwi-aotz-- 3.00g stack-volumes-lvmdriver-1-pool 66.68
Conclusion:
We can see that the space allocation increased hence we are not preserving sparseness when using the -S 0 option.
[1] https://qemu-project.gitlab.io/qemu/tools/qemu-img.html#cmdoption-qemu-img-common-opts-S
[2] abf635ddfe/qemu-img.c (L182-L186)
Closes-Bug: #2045431
Change-Id: I5be7eaba68a5b8e1c43f0d95486b5c79c14e1b95
We decided that H301 makes no sense for the "typing"
module, just set that in tox.ini instead of every
time it is used.
Change-Id: Id983fb0a9feef2311bf4b2e6fd70386ab60e974a
While reverting to a snapshot with generic flow, we create a
temporary volume from snapshot and copy data from temporary to the
original volume.
While creating this temporary volume, the snapshot is in 'restoring'
state whereas the remotefs driver only accepts 'available' and
'backing-up' states for this operation.
This patch adds the 'restoring' state to the list of acceptable states.
Closes-Bug: 1946059
Change-Id: Id1e40fd42b88c63dbbba2aaae77c40660ddac4c7
Format info support was added to the nfs driver with change[1]
and due to a issue with groups, it was restricted for volumes
with groups with change[2].
This was a problem with OVO handling of consistency groups/volume
groups and is fixed in this patch thereby also removing the
limitation on nfs driver.
[1] https://review.opendev.org/c/openstack/cinder/+/761152
[2] https://review.opendev.org/c/openstack/cinder/+/780700
Co-Authored-By: Gorka Eguileor <geguileo@redhat.com>
Change-Id: I078a54a47e43b1cc83b4fb1a8063b41ab35358a1
The NFS snapshot creation for an attached volume requires interaction
between Nova and Cinder, and a new qcow2 file is used after the
attachment completes.
This means that the connection properties stored in the Attachment is no
longer valid, as it is pointing to the old qcow2 file, so if Nova tries
to use that attachment it will start writing on the old qcow2 file.
A flow showing this issue is:
- Attach NFS volume
- Create snapshot
- Hard reboot
After that the VM will start using the base image, breaking the qcow2
chain.
If we delete the snapshot in the meantime, then the VM will fail to
reboot.
This patch fixes this inconsistency by updating the connection info
field inside the remotefs driver.
We usually prefer that drivers don't to touch the DB, directly or
indirectly (using OVOs), but in this case we are using OVOs methods
instead of the usual model update on the volume manager because there
are cases in the driver where a snapshot is created (cloning via
snapshot) and we have to update the attachment without the manager, as
it is unaware that a temporary snapshot is being created.
Besides that main reason there are other less critical reasons to do the
attachment update in the driver:
- Smaller code change
- Easier to backport
- Limit change impact on other areas (better for backport)
- The snapshot_create model update code in the manager does not support
updating attachments.
- There are cases in the cinder volume manager where the model update
values returned by snapshot_create are not being applied.
Snapshot deletion belonging to in-use volumes are not affected by this
issue because we only do block commit when the snapshot file we are
deleting is not the active file. In _delete_snapshot_online:
if utils.paths_normcase_equal(info['active_file'],
info['snapshot_file']):
Closes-Bug: #1860913
Change-Id: I62fcef3169dcb9f4363a5344af4b2711edfef632
Recently we merged change I43036837274a7c8dba612db53b34a6ce2cfb2f07
which adds format info support for *fs type volumes.
This seems to cause issues when volume has groups or we are cloning
from a bootable volume.
This patch disables the format info support for volumes with groups
and fixes the issue with cloning.
Change-Id: I41ffedfa1abd0708c84494a0aaaa3815810102b8
This feature adds format info in filesystem type
drivers with the following changes:
1) Store format info in admin_metadata while creating/cloning
volumes
2) Use format info while extending volumes
3) Modify volume format when performing snapshot delete
(blockRebase) operation on attached volume.
4) Return format in connection_info
blueprint add-support-store-volume-format-info
Change-Id: I43036837274a7c8dba612db53b34a6ce2cfb2f07
This continues moving code only used by volume
drivers or the volume manager to volume_utils.
The result of this is that fewer drivers import
cinder.utils (and everything it imports), and less code
is loaded by non-volume cinder code (api service,
cinder-manage, etc.)
Closes-Bug: #1912278
Change-Id: I5aa82cf0de4c70f53ddc998bf25e64f4ad8f5774
md5 is not an approved algorithm in FIPS mode, and trying to
instantiate a hashlib.md5() will fail when the system is running in
FIPS mode.
md5 is allowed when in a non-security context. There is a plan to
add a keyword parameter (usedforsecurity) to hashlib.md5() to annotate
whether or not the instance is being used in a security context.
In the case where it is not, the instantiation of md5 will be allowed.
See https://bugs.python.org/issue9216 for more details.
Some downstream python versions already support this parameter. To
support these versions, a new encapsulation of md5() has been added to
oslo_utils. See https://review.opendev.org/#/c/750031/
This patch is to replace the instances of hashlib.md5() with this new
encapsulation, adding an annotation indicating whether the usage is
a security context or not.
Reviewers need to pay particular attention as to whether the keyword
parameter (usedforsecurity) is set correctly. Almost all instances
of md5 usage appear to be to refer to etags, to do checksums, or to
generate uuids for paths.
I had hoped to update the bandit config to enable scanning for instances
of md5 and bad algorithms, so that instances would not creep in in future,
but I couldn't find the bandit config.
With this patch (and the corresponding os-brick and oslo-versioned_object
dependent changes) all the functional tests and alnmost all the unit tests
pass on a FIPS enabled system.
Issues I found were as follows:
- Cinder appears to be using md5 in a security context in
cinder/volume/drivers/synology/synology_common.py. If this is really
the case, then we'll need to consider how to replace md5 in this usage.
This case did not appear to exercised in the unit or functional tests I ran.
- Cinder appears to use md5 in a security context in
cinder/volume/drivers/stx/client.py, which resulted in the failed unit test
cinder.tests.unit.volume.drivers.test_seagate.TestSeagateClient.test_login
This was the only unit test that failed.
Change-Id: I57ec3e7e99c78535fa8051d011d970adb7fb89ab
Depends-On: https://review.opendev.org/#/c/756151
Fixed an issue with creating a snapshot on an NFS backend
if the snapshot name is not specified.
Closes-Bug: 1886222
Change-Id: I33da9c65ef56b3e4967170e3a0fb25f12e067876
Volume encryption helps provide basic data protection in
case the volume back-end is either compromised or outright
stolen. The contents of an encrypted volume can only be
read with the use of a specific key;
Volume encryption: Check volume encryption key in
'_do_create_volume' method (remotefs) and use
'_create_encrypted_volume_file' when encryption is
required.
Snapshot encryption: To create an encrypted volume from a
snapshot, we need to pass the Barbican key of the
snapshot.volume to 'convert_image' method. Because of this
I've added 'src_passphrase_file' parameter.
This patch doesn't handle encrypted volume -> unencrypted
Current error prompted: 'Invalid input received: Invalid
volume_type provided: aeac5517-6bc8-4b59-9eb2-76e84369bd0
(requested type is not compatible; recommend omitting the
type argument). (HTTP 400)'
Implements: blueprint nfs-volume-encryption
Co-Authored-By: Sofia Enriquez <lsofia.enriquez@gmail.com>
Change-Id: I896f70d204ad103e968ab242ba9045ca984827c4
snapshot.id doesn't have `tmp-snap` in it as id
is not passed as a option while creating snapshot
object. This should be change to
`snapshot.display_name` at same location
Closes-Bug: #1875570
Change-Id: I66da0212a61d778fe9795d382b3af5b225a8aa54
This feature expands the usability of Glance multiple stores for volumes that
are created from images.
In this implementation, a volume created from image sends its
base image id to glance so that glance can store the current volume image
where the base image resides (whether be single or multiple stores).
An conflict between the 'image_service:store_id' [1] and the
'base_image_ref' passed to Glance is expected to be handled on the Glance
side.
Implements: bp copy-image-in-multiple-stores
[1] https://review.opendev.org/#/c/661676/
Change-Id: I5dd00e8d373fd8a7dd4f97e4e5924aefe599d1d9
Glance now has ability to configure multiple stores at a
time. To use this feature in cinder for uploading volume to image, operator
need to define a new field named 'image_service:store_id' in the
volume-type extra-specs. At a time of volume upload to image request, if
'image_service:store_id' is present in the associated volume type, then
image will be uploaded to specified 'store_id'. The value 'store_id' is
nothing but store identifier defined in glance-api.conf. If the value
of 'image_service:store_id' is null or not set in volume-type then the
image will be uploaded to default store in glance.
Co-authored-by: Sagar Waghmare <sawaghma@redhat.com>
Co-authored-by: Abhishek Kekane <akekane@redhat.com>
DocImpact
Implements: bp support-glance-multiple-backend
Change-Id: Ica56833a1d9fb9f47b922dbbc6558901bb3a2800
Use the destination volume id instead of the source volume id
in the temporary snapshot file name. This is likely not strictly
needed after Change I64e041fe, which ensures that multiple clone
volume operations won't run simultaneously from the same source
volume, but is still a good idea to ensure that there is less
that can go wrong in a failure scenario.
Change-Id: I5bd185d04dbda673a5882d61aaab7acdd99b74a6
Related-Bug: #1851512
Closes-Bug: #1840712
Any method in the remotefs/nfs code that manipulates
the qcow2 snapshot chain must be run separately
from other methods that may touch this snapshot chain.
This code intended to do this with a lock on the
volume id, but it unintentionally locked only on
the destination volume id rather than the source
volume id where the snapshots are.
This causes concurrent clone operations to fail in
the NFS driver. This patch fixes this in the
RemoteFSSnapDriverDistributed class which fixes the
NFS driver and a handful of others.
A follow up patch should be applied for the
RemoteFSSnapDriver class with a similar change, but as
that class is only used by one driver (which I can't
test), this patch only adds a TODO for that change.
Related-Bug: #1840712
Related-Bug: #1852449
Closes-Bug: #1851512
Change-Id: I64e041feaeb50c95808da46a34f334a9985018a8
Much of our code renames this at import already --
just name it "volume_utils" for consistency, and
to make code that imports other modules named "utils"
less confusing.
Change-Id: I3cdf445ac9ab89b3b4c221ed2723835e09d48a53
Adds context to _create_cloned_volume method in order
to allow taking a snapshot during cloning. Also saves
the temp_snapshot in order to enable Nova to update the
snapshot state. Destroys the temp_snapshot after usage.
This affects the NFS, WindowsSMBFS, VZStorage and
Quobyte drivers.
Closes-Bug: #1744692
Change-Id: I328a02d0f26e8c3d41ec18a0487da6fd20b39b04
This reverts commit a62c9dfdd4.
This did not account for cases where truncate is
called w/o elevated privileges.
Related-Bug: #1818504
Change-Id: I3cb85be854e68fda525cfebe254ce7c85d8e3d37
The Windows SMB driver has been broken by a recent change [1],
which is attempting to handle info file permissions, using the
'truncate' command along the way, which is not available on Windows.
We're not handling file permissions on Windows, so we can just skip
this step, avoiding this issue.
Change-Id: I1f92cef19cd2eed7ba845210f7ff89d88ba78f49
Closes-Bug: #1811369
Fix snapshot issues that occur if cinder does not have regular (non-root)
write permission on an NFS share. This is done by following the volume
driver's model of creating files as root, followed by calling
_set_rw_permissions().
Fix backup issues that occur if cinder's group ID changes, which can
happen when migrating from bare metal to a containerized service. If the
share's group ownership and permission needs to be modified, then do it
recursively so that previously made backups remain accessible.
Closes-Bug: #1807760
Change-Id: I6c20c4825af0a365b6a20fb633c810c2f2fe48b0
Add '-d' flag to qemu-img commit operations during
snapshot deletion in remotefs driver.
Change-Id: I66396fb7e2616be734b7c8f73b87c650b1e603bf
Closes-Bug: #1805853
for x in some_dict.keys() can be written as for x in some_dict
Change-Id: I9cdb3e6802fbf85fe49f3855ccc2a68ce5cc56c4
Signed-off-by: Chuck Short <chucks@redhat.com>
allocated_capacity_gb should not be reported by drivers and let the
manager handle this.
provisioned_capacity_gb is reporting allocated physical space. Return
provisioned.
Change-Id: I7e1b8d5b399a8dd15bb0dee477090a45c2faa6fa
Closes-Bug: #1746233
Signed-off-by: Kien Ha <kienha9922@gmail.com>
Zuul