Description of problem: When deploying large images, particularly from NFS backends, the cpu limit for qemu-img may be hit, causing image->volume operations to fail. This has only been reported on NFS backends, but may affect others as well. The fix is a simple change to increase the cpu limit for the qemu-img process. Reported against RDO in bug 1430756.
Eric, When we mention NFS as backend-> deploying large images, particularly from NFS backends. NFS as backend for Cinder/Glance or Nova? LP link mentions NFS shared storage, looks like it's NFS as Nova backend. Then again why would we need a Cinder fix for this, meaning we probably need Cinder or Glance with NFS backend for verification, correct? Same question holds true for bz 1430756
(In reply to Tzach Shefi from comment #1) > NFS as backend for Cinder/Glance or Nova? The test here is just for a Cinder NFS backend.
Verified on: openstack-cinder-9.1.3-4.el7ost.noarch Fix is incorporated -> cpu_time=8, Created a large snapshot 22G (40G disk) # glance image-show 3ce20a98-dd47-4ffb-a45a-1b037f7a027d +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | container_format | bare | | disk_format | qcow2 | | id | 3ce20a98-dd47-4ffb-a45a-1b037f7a027d | .. | name | Snap22G | | size | 22672113664 Used ^ image to create an LVM backed Cinder volume, works fine. #cinder create 40 --image 3ce20a98-dd47-4ffb-a45a-1b037f7a027d --name LVM_Backed_vol It took a good few minutes but eventually completed fine. # cinder list +--------------------------------------+-----------+----------------+------+-------------+----------+-------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+----------------+------+-------------+----------+-------------+ | cea43e9b-d8c9-47c4-beca-8beb6a277d1a | available | LVM_Backed_vol | 40 | iscsi | true | | Used same image with NFS Cinder backend: # cinder create 40 --image 3ce20a98-dd47-4ffb-a45a-1b037f7a027d --name NFS_Backed_vol --volume_type nfs Again took a while but completed successfully as expected. Created a third NFS_Backed_vol2 volume (nfs) just to be sure also created successfully. [root@cougar09 ~(keystone_admin)]# cinder list +--------------------------------------+-----------+-----------------+------+-------------+----------+-------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+-----------------+------+-------------+----------+-------------+ | 20b92766-50ca-4105-93bc-ae83c8726341 | available | NFS_Backed_vol2 | 40 | nfs | true | | | ca525a5f-0019-4053-8935-a5d441d85014 | available | NFS_Backed_vol | 40 | nfs | true | | | cea43e9b-d8c9-47c4-beca-8beb6a277d1a | available | LVM_Backed_vol | 40 | iscsi | true | | +--------------------------------------+-----------+-----------------+------+-------------+----------+-------------+ Waiting for ON_QA status to officially close as verified.
Any idea why this didn't reach ON_QA state yet? Fix was already introduced (and verified #3) in 9.1.3. I just installed a 9.1.4 build today figured this would hit ON_QA so that I could officially verify.
Verified, see #3.
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, 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/RHBA-2017:1591