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
The get_qemu_data method in image_utils file raises an exception when
disk_format is not of type RAW. The message supposed to say what disk type
are using, but return False instead.
So i change the log message to something more general, just specifying that
the disk are being used is not of RAW type.
Closes-Bug: #2008041
Change-Id: I5c73b85531897656cb6a9d55391933ce40eb0635
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
Previous patch I79d70543856c01a45e2d8c083ab8df6b9c047ebc
implemented filtering of glance "os_glance..." metadata
but its logic overlooked the fact that the glance metadata
to be filtered are actually in a "properties" sub-dict
as adjusted by the "_merge_volume_image_meta" method in
cinder/volume/api.py.
This patch re-invokes the filtering loop on
the "properties" sub-dict when it is present.
New unit test covers filtering in both cases.
Closes-bug: #1945500
Change-Id: I06b8c363c4017adfa1ad134ad7a8a0954c005e62
Cinder is currently not able to upload a volume that is based on an
image back to glance. This bug is triggered if glance multistore is
enabled (devstack in this example).
When enabling multistore, the following properties will be stored in Cinder:
* os_glance_failed_import=''
* os_glance_importing_to_stores=''
Those properties will cause problems when Cinder tries to perform some
actions with Glance. Error msg:
```
cinderclient.exceptions.BadRequest: HTTP 403 Forbidden: Access was denied to this resource.: Attribute 'os_glance_failed_import' is reserved. (HTTP 400)
```
Nova had the same issue and solved it with:
50fdbc752a/releasenotes/notes/absolutely-non-inheritable-image-properties-85f7f304fdc20b61.yaml
and
dda179d3f9
Therefore, this patch is intended to apply a similar solution in Cinder.
Change-Id: I79d70543856c01a45e2d8c083ab8df6b9c047ebc
Closes-Bug: #1945500
Also add a more general check to convert_image that the image format
reported by qemu-img matches what the caller says it is.
Change-Id: I3c60ee4c0795aadf03108ed9b5a46ecd116894af
Partial-bug: #1996188
As stated in I8f06b53, qemu-img 2.10 was
released in 2017. Assume we are running
with it or a newer release.
Change-Id: I29314273f87a452caf589babca4974bcc98ad4b9
Support for the human format by oslo_utils.imageutils.QemuImgInfo was
deprecated since oslo.utils 4.9.1 [1]. This change replaces the human
format with the json format which will be used by default.
[1] 73eb0673f627aad382e08a816191b637af436465
Closes-Bug: #1940540
Change-Id: Ia0353204abf849467106ee08982d1271de23101a
Add new config option `image_conversion_disable`, when it's set to
`True`, image disk_format and volume format must be the same format.
Otherwise will raise ImageUnacceptable exception.
`image_conversion_disable` config is bool option, default to `False`.
The idea behind this was that in certain high scale environments,
it is possible that a cloud allows both qcow2 and raw image uploads.
However, uploading a qcow2 image and creating a large number of
volumes can cause a tremendous amount of conversions that will kill
cinder-volume. It may be undesirable to have this, so a cloud
operator can opt to disallow conversions and enforce that the user
uploads the correct image type if they want to have volumes (aka
raw in rbd case).
Closes-Bug: #1970115
Change-Id: Ic481d68639d9460d1fd14225bc17a0d8287d5fd9
This works in Python 3.7 or greater and is
cleaner looking.
See PEP-585 for more info.
https://peps.python.org/pep-0585/
Change-Id: I4c9da881cea1a3638da504c4b79ca8db13851b06
When the encryption spec is missing the cipher field,
just fail the request rather than sending an invalid
request to Castellan and letting the Barbican server
reject it.
This happens when an admin had previously created an
invalid encryption spec.
Similarly, check for a malformed cipher field in
image_utils decode_cipher, such as "aes" instead of
"aes-xts-plain64". An invalid cipher field like this
would previously cause a failure during volume creation
in some volume drivers.
Partial-Bug: #1926630 (1/2)
Change-Id: Ia4b1c303a057fe70cf88bdbbebc1d4f62474f011
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
Remove unused params and code.
This is only ever called with user_id,
project_id, and size set to None.
Change-Id: Icf8a4829a02a3b3bba9375af7a27f86e24a850b7
These files can be rather large at times, prefix
them with identifiers so that when troubleshooting
Cinder, it is possible to identify what is
consuming disk space.
Closes-Bug: #1911766
Change-Id: I660ed16a36ad9415a5de757b32a6770e27b1294c
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
During copy image to encrypted volume operation, we create a
temporary image file to convert source image into an encrypted
image and rename it to source image name.
If any error occurs during this process, there is no code to
cleanup the temporary '.luks' file.
This patch adds the following cleanup.
Change-Id: I05dfc996a635299990fdafba841ab6c4fd7d32c7
Closes-Bug: 1873738
This patch adds the exisiting glance image colocation feature for
virtuozzo driver (which was restored recently).
Change-Id: I5278d97c98f44ca2f4dddf185cf108f72735d7b0
Closes-Bug: #1873463
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
Instead of having a hardcoded value the conversion prlimits are
now operator configurable. These settings have always been arbitrary
as it depends on the environment.
Change-Id: I462cecc3152bf838b7d42d5abc3ca31610567e5e
Closes-Bug: #1705340
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
The 8 second timeout is not always sufficient for
large images.
Bump to 30s, which matches what Nova currently
uses for this same limit.
Change-Id: I0c26c400f08d91c8c125c69e06e4c90302bcdbb1
Closes-Bug: #1705340
When trying to upload volume to glance as image, currently all the
format transformation is done by software and the performance is not
good.
Leverage hardware accelerator to do the image compression, so as to
offload CPU, release CPU to do more common and complex thing.
Professional hardware accelerator will get better performance and
shorter conversion time than software solution. Currently hardware
accelerator is getting more popular and some are integrated in server
chipset by default.
This patch includes:
1. Uses the new image container_format 'compressed' introduced by Glance
in the Train release
2. Implemented a simple framework: if there's an accelerator detected in
system, then try to use it
3. Supported Intel QAT as one of the accelerator
4. Add command filter for command 'qzip' and 'gzip' in rootwrap
5. New configuration option 'allow_compression_on_image_upload' and
'compression_format' added
6. Releasenote added
Change-Id: I8460f58d2ad95a6654cf4d6a6bb367f3c537536b
Implements: blueprint leverage-compression-accelerator
Signed-off-by: Liang Fang <liang.a.fang@intel.com>
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
The call to convert the image was set to always compress instead
of paying attention to the keyword argument.
Change-Id: Idc18b1c5b17d4f9b29deb87d29faba574d3432b2
Related-bug: #1824821
Related-bug: #1839069
We were missing the 'compress' parameter in the upload_volume method,
yet we were passing it on the driver, which meant that the call would
always fail with:
TypeError: upload_volume() got an unexpected keyword argument
'compress'
Related-Bug: #1824821
Closes-Bug: #1839069
Change-Id: Ibe9a0e78ab452c54cc3f1da1f4377034190dd14e
When possible (based on the image format), compress
images that are uploaded to Glance. For now, this is
done for the qcow2 format, but can be expanded to
other formats as needed.
This should be a performance win for some deployments,
consuming less network/storage at the expense of CPU.
An "image_compress_on_upload" option is provided to
disable this behavior for deployments that want to
prioritize minimal CPU usage, etc.
Closes-Bug: #1824821
Change-Id: I22bd2be6653bdc4e755ea8a9d8780e8e67b4485a
The previous patch to update hacking
and pycodestyle turned off some new errors to
keep the patch smaller.
Fix those errors here.
Change-Id: Ib22f63e98eefb36b9b2a8be55c15271824408d5d
A lot of our config option reference documentation was out of date, with
deprecated and removed options and changed defaults. This changes the
"Additional options" configuration reference to use the config-table
directive so the published docs stay in sync with changes in the code.
Closes-bug: #1814910
Change-Id: Ib891435dc69eb795ea6d4d0fb6626259e95cf27f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
When glanceclient raises an IOError with a different errno than ENOSPC,
cinder-volume silently masked it and continued its volume creation
process. The result was volumes with invalid content being successfuly
created.
With the patch, an ImageDownloadFailed exception is raised in this case,
which makes the volume creation process fail and gives enough
information to operators for troubleshooting.
Change-Id: Ic011fe30b4840e5098db1a594ea276ec98768bff
Closes-Bug: #1799221
Provide message when there is not enough space for image conversion
With rbd as cinder backend, when creating volume from image, two steps
follow to create the volume:
1. image is downloaded to image_conversion_dir
2. image is converted to raw in the same location
If no space left in image_conversion_dir happened in step1, function
fetch() in image_utils.py will catch this (IOError with e.errno ==
errno.ENOSPC), and exception.ImageTooBig will be re-raised. If happened
in step 2, no "space" specific message will be logged in current code.
This patch provided the space specific log to indicate no space.
Change-Id: I56057475cf55e4be77bbd1dfeabf2bf20d3e1311
Co-authored-by: Irina Mihai <irina.mihai@windriver.com>
Signed-off-by: Liang Fang <liang.a.fang@intel.com>
When doing image operations in Cinder we may start getting errors on
RabbitMQ and DB connections, which result in the volume service
appearing as down to the scheduler.
This is caused by file I/O operations, that in some cases block
greenthreads, preventing switching to another greenthread on I/O as they
should.
This results in many different errors, so this patch makes sure that
image operations (fetch, put, verify image, ...) that could prevent
greenthread switching are executed in native threads.
Closes-Bug: #1801958
Change-Id: I8a8fbf96875319a7e5ca167fcd2bca45f57649c8
Zuul