Currently filesystem type drivers (like nfs) rely on format auto-detection for operations like resize. This causes a problem when we write a qcow2 image file on a raw volume and the format is wrongly assumed to be qcow2 causing problems similar to[1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1838653
Verified on: openstack-cinder-18.2.1-0.20220605050357.9a473fd.el9ost.noarch On a deployment with Glance over Cinder, With Cinder using a generic NFS as it's backend. Lets upload a larger than 1G qcow2 image, We keep Cinder's default nfs_qcow2_volumes=false (overcloud) [stack@undercloud-0 ~]$ qemu-img info windows_server_2012_r2_standard_eval_kvm_20170321.qcow2 image: windows_server_2012_r2_standard_eval_kvm_20170321.qcow2 file format: qcow2 virtual size: 12.2 GiB (13096714240 bytes) disk size: 11.2 GiB cluster_size: 65536 Format specific information: compat: 0.10 compression type: zlib refcount bits: 16 (overcloud) [stack@undercloud-0 ~]$ glance image-create --disk-format qcow2 --container-format bare --file windows_server_2012_r2_standard_eval_kvm_20170321.qcow2 --name windows_server_2012_r2_standard_eval_kvm_20170321.qcow2 +------------------+----------------------------------------------------------------------------------+ | Property | Value | +------------------+----------------------------------------------------------------------------------+ | checksum | a05ead3a04ae663da77eee5d2cb2fa73 | | container_format | bare | | created_at | 2022-06-21T12:57:22Z | | direct_url | cinder://default_backend/89aa21c9-238a-4996-8da3-1dea959af9f5 | | disk_format | qcow2 | | id | 0485da6b-aa86-4cff-b6f4-5f0f6c67c8f4 | | min_disk | 0 | | min_ram | 0 | | name | windows_server_2012_r2_standard_eval_kvm_20170321.qcow2 | | os_hash_algo | sha512 | | os_hash_value | 9bd12698b1cb46e09243fd5704e14292e7393c84a4de178f536caaf21b9222c94d5080cbec69eafe | | | 69fd7a7694fe14d792425c5fbb89a89727d2d2615e62890a | | os_hidden | False | | owner | effcf85b11f94d7eb99578caf1467e9b | | protected | False | | size | 12001017856 | | status | active | | stores | default_backend | | tags | [] | | updated_at | 2022-06-21T13:01:11Z | | virtual_size | 13096714240 | | visibility | shared | +------------------+----------------------------------------------------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ cinder list --all-tenants +--------------------------------------+----------------------------------+-----------+--------------------------------------------+------+-------------+----------+-------------+ | ID | Tenant ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+----------------------------------+-----------+--------------------------------------------+------+-------------+----------+-------------+ | 89aa21c9-238a-4996-8da3-1dea959af9f5 | afdbf0760615482492f97721092f431c | available | image-0485da6b-aa86-4cff-b6f4-5f0f6c67c8f4 | 12 | tripleo | false | | +--------------------------------------+----------------------------------+-----------+--------------------------------------------+------+-------------+----------+-------------+ (overcloud) [stack@undercloud-0 ~]$ cinder show 89aa21c9-238a-4996-8da3-1dea959af9f5 +--------------------------------+--------------------------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------------------------+ | attached_servers | [] | | attachment_ids | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2022-06-21T12:57:25.000000 | | description | None | | encrypted | False | | id | 89aa21c9-238a-4996-8da3-1dea959af9f5 | | metadata | glance_image_id : 0485da6b-aa86-4cff-b6f4-5f0f6c67c8f4 | | | image_owner : effcf85b11f94d7eb99578caf1467e9b | | | image_size : 12001017856 | | | readonly : True | | migration_status | None | | multiattach | False | | name | image-0485da6b-aa86-4cff-b6f4-5f0f6c67c8f4 | | os-vol-host-attr:host | hostgroup@tripleo_nfs#tripleo_nfs |--> saved on NFS backend. | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | afdbf0760615482492f97721092f431c | | readonly | True | | replication_status | None | | size | 12 | | snapshot_id | None | | source_volid | None | | status | available | | updated_at | 2022-06-21T13:01:10.000000 | | user_id | 326bade2d20644f5a76e895b98d7f109 | | volume_type | tripleo | +--------------------------------+--------------------------------------------------------+ As shown above, we successfully upload a large 12G image to Glance where Glance uses Cinder generic NFS as it's backend. We notice the extend operation on c-vol logs: - - -] Extend volume completed successfully. /var/log/containers/cinder/cinder-volume.log:3056:2022-06-21 13:01:04.652 11 INFO cinder.volume.drivers.nfs [req-bccf9cfe-c993-4860-a935-0b1b114289ec 326bade2d20644f5a76e895b98d7f109 afdbf0760615482492f97721092f431c - - -] Extending volume 89aa21c9-238a-4996-8da3-1dea959af9f5. /var/log/containers/cinder/cinder-volume.log:3064:2022-06-21 13:01:04.877 11 INFO cinder.volume.manager [req-bccf9cfe-c993-4860-a935-0b1b114289ec 326bade2d20644f5a76e895b98d7f109 afdbf0760615482492f97721092f431c - - -] Extend volume completed successfully. Lets do some more testing create an empty volume and volume from an image, attach them to an instance and prove that the correct volume type is used: (overcloud) [stack@undercloud-0 ~]$ cinder list +--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+ | 279d40cc-114c-427c-8c72-3e6ac61badde | in-use | Pansible_vol | 1 | tripleo | false | cad0b1e5-6b83-4211-b516-6a913d51ee03 | -> vol from an image | 6d667fbc-26fd-4377-a456-fd574637065c | in-use | emptyvol | 1 | tripleo | false | cad0b1e5-6b83-4211-b516-6a913d51ee03 | -> empty vol +--------------------------------------+-----------+--------------+------+-------------+----------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ cinder --os-volume-api-version 3.44 attachment-list +--------------------------------------+--------------------------------------+----------+--------------------------------------+ | ID | Volume ID | Status | Server ID | +--------------------------------------+--------------------------------------+----------+--------------------------------------+ | 47048cab-bb77-46e4-9679-dd98fd8a56cb | 6d667fbc-26fd-4377-a456-fd574637065c | attached | cad0b1e5-6b83-4211-b516-6a913d51ee03 | | 9460e6db-03b4-46f7-89b6-f71c92214cc5 | 279d40cc-114c-427c-8c72-3e6ac61badde | attached | cad0b1e5-6b83-4211-b516-6a913d51ee03 | +--------------------------------------+--------------------------------------+----------+--------------------------------------+ Both show up as raw, as expected cause were using Cinder' default -> nfs_qcow2_volumes=false (overcloud) [stack@undercloud-0 ~]$ cinder --os-volume-api-version 3.44 attachment-show 47048cab-bb77-46e4-9679-dd98fd8a56cb | grep format | format | raw | (overcloud) [stack@undercloud-0 ~]$ cinder --os-volume-api-version 3.44 attachment-show 9460e6db-03b4-46f7-89b6-f71c92214cc5 | grep format | format | raw As excepted both volumes are attached as raw. Now lets change nfs_qcow2_volumes=true, again create two new volumes and attach them. (overcloud) [stack@undercloud-0 ~]$ cinder list +--------------------------------------+-----------+----------------------------------+------+-------------+----------+--------------------------------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+----------------------------------+------+-------------+----------+--------------------------------------+ | 279d40cc-114c-427c-8c72-3e6ac61badde | available | Pansible_vol | 1 | tripleo | false | | | 6d667fbc-26fd-4377-a456-fd574637065c | available | emptyvol | 1 | tripleo | false | | | b00d57ce-f7d7-4b0b-8512-de9e5db6144c | in-use | EmptyVolAfter_NFS_QCOW2_true | 1 | tripleo | false | cad0b1e5-6b83-4211-b516-6a913d51ee03 | | b8101088-ffc3-495d-8436-2e5840398ff6 | in-use | VolFromImageAfter_NFS_QCOW2_true | 1 | tripleo | true | cad0b1e5-6b83-4211-b516-6a913d51ee03 | +--------------------------------------+-----------+----------------------------------+------+-------------+----------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ cinder --os-volume-api-version 3.44 attachment-list +--------------------------------------+--------------------------------------+----------+--------------------------------------+ | ID | Volume ID | Status | Server ID | +--------------------------------------+--------------------------------------+----------+--------------------------------------+ | 23221ee0-cb7a-41ae-89bf-88de489a1048 | b8101088-ffc3-495d-8436-2e5840398ff6 | attached | cad0b1e5-6b83-4211-b516-6a913d51ee03 | | 5b4bf265-57e3-4b96-aaec-e00a6b484f34 | b00d57ce-f7d7-4b0b-8512-de9e5db6144c | attached | cad0b1e5-6b83-4211-b516-6a913d51ee03 | +--------------------------------------+--------------------------------------+----------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ cinder --os-volume-api-version 3.44 attachment-show 23221ee0-cb7a-41ae-89bf-88de489a1048 | grep format | format | qcow2 | (overcloud) [stack@undercloud-0 ~]$ cinder --os-volume-api-version 3.44 attachment-show 5b4bf265-57e3-4b96-aaec-e00a6b484f34 | grep format | format | qcow2 As expected this time the volumes formats are qcow2, Looks good to verify.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543