Created attachment 1285704 [details] engine and vdsm logs [reply] [−] Private Description Ameya Charekar 2017-02-04 01:13:42 EST Description of problem: Creating a Clone vm from template with Format "QCOW2" and Target "block based storage" created disks with actual and virtual size same. Version-Release number of selected component (if applicable): Red Hat Virtualization Manager Version: 4.0.6.3-0.1.el7ev How reproducible: Always. Steps to Reproduce: 1. Create a New VM from template. 2. Select Format "QCOW2". 3. Select any block based storage. Actual results: Actual size and Virtual size is same. Expected results: Virtual size should not be same as actual size. Additional info: File based storage do not have this issue.
Tal, didn't we solve something like this already? (note the reported version). Eyal - does this reproduce with modern 4.1.z engines?
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Sorry about the versions confusion, copy-paste error. Versions: Engine - 4.2.0-0.0.master.20170602194647.gitaf23eb5.el7.centos VDSM - 4.20.0-970.gitf0c24e5.el7.centos.x86_64 Also on: Engine - 4.1.3.1-0.1.el7 VDSM - 4.19.17-1.el7ev.x86_64
Continuing the conversation from https://bugzilla.redhat.com/show_bug.cgi?id=1419240. (In reply to Eyal Shenitzky from comment #18) > The relevant operation is create VM from a template as clone with disk QCOW. > not copy disk. > But let's move the conversation to the relevant bug - > https://bugzilla.redhat.com/show_bug.cgi?id=1459455 Create VM will call copy operation from source Template to the VM. As noted in https://bugzilla.redhat.com/show_bug.cgi?id=1419240#c17, I could not find any reference in the log which indicate that the destination storage domain is block storage domain. Can you please share the destination block storage domain the copy was done to, and the log of the copy operation which was done to that block SD?
Create a VM to a block-based storage domain from Template with a disk on block-based storage domain using sdm_copy (data-center 4.2/4.1).
Created attachment 1286818 [details] engine and vdsm logs new
I think that the problem is related to the Template's copy disks. Can you please try to delete the Template disk's copies and try to create a new VM from Template, what is the actual size then?
You right, after removing the disk copies the actual size (6 GB) was smaller than the virtual size (10 GB)
(In reply to Eyal Shenitzky from comment #9) > You right, after removing the disk copies the actual size (6 GB) was smaller > than the virtual size (10 GB) So is this a NOTABUG?
No, it is a bug. Maor found the root cause and I verify that it occurs also in my environment. The problem is that when the template disk has multiple copies, the scenario described above occur, but when the template has no copies it works as expected.
Just to make sure I understand - this is a *display* bug where the disk's size contains the size of the template too? The actual image's size on the storage is OK?
The bug is not only a display bug, there is an issue with the images size. Maor do you have more info?
*** Bug 1480133 has been marked as a duplicate of this bug. ***
Eyal, this relates to your current work around allocation, will this bug be fixed as well in these changes?
My work is currently handling creating a clone VM from template to a file-based storage domain so no, it will not solve it.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Still occurs. Steps to Reproduce: 1. Create a VM with a file-based disk. 2. Create a template from the VM. 3. Copy the template disk to a block-based storage domain. 4. Clone a new VM from the template and select the storage domain to be the same domain from step 3 and the format to be "QCOW2". Actual results: Actual size is bigger than the Virtual size. Expected results: Virtual size should be larger than the actual size.
After you closed this bug. Automation TestCase16968 which was blocked on this issue ran and the issue reproduced. Test scenario: - Create VM with disk format "QCOW2" from template(which has copies on NFS/Gluster/ISCSI/FCP) as clone on block based domain Expected results: - Disk virtual size should be larger than disk actual size Actual results: This is not a UI bug as in UI you can see actual and virtual disk size = 10G. But looking at API/REST you can see that actual disk size(10871635968 which is 10.125G) > virtual disk size(provisioned_size=10737418240=10G) #Taken from https://hosted-engine-06.lab.eng.tlv2.redhat.com/ovirt-engine/api/disks: <disk href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd" id="8d06a217-b5fb-45b4-94bf-fbf1dabb70fd"> <actions> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/reduce" rel="reduce"/> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/copy" rel="copy"/> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/export" rel="export"/> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/move" rel="move"/> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/refreshlun" rel="refreshlun"/> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/sparsify" rel="sparsify"/> </actions> <name>vm_TestCase16968_2416502028_Disk_0</name> <description>rhel8.0_rhv4.3_guest_disk (7d3bff6)</description> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/permissions" rel="permissions"/> <link href="/ovirt-engine/api/disks/8d06a217-b5fb-45b4-94bf-fbf1dabb70fd/statistics" rel="statistics"/> <actual_size>10871635968</actual_size> <alias>vm_TestCase16968_2416502028_Disk_0</alias> <backup>none</backup> <content_type>data</content_type> <format>cow</format> <image_id>529afc64-70f7-4033-bc33-9ea217b63be1</image_id> <propagate_errors>false</propagate_errors> <provisioned_size>10737418240</provisioned_size> <qcow_version>qcow2_v3</qcow_version> <shareable>false</shareable> <sparse>true</sparse> <status>ok</status> <storage_type>image</storage_type> <total_size>10871635968</total_size> <wipe_after_delete>false</wipe_after_delete> <disk_profile href="/ovirt-engine/api/diskprofiles/049728f5-93d0-4ea1-8676-671e78c649d9" id="049728f5-93d0-4ea1-8676-671e78c649d9"/> <quota href="/ovirt-engine/api/datacenters/93d29137-7113-4c3a-be46-f87739d1fc9a/quotas/8c1825ed-e642-4ecb-b1dc-905853a63156" id="8c1825ed-e642-4ecb-b1dc-905853a63156"/> <storage_domains> <storage_domain href="/ovirt-engine/api/storagedomains/1b7bb2ae-67ae-4a46-903a-9e6aaa6c5d3d" id="1b7bb2ae-67ae-4a46-903a-9e6aaa6c5d3d"/> </storage_domains> </disk> DB dump: engine=# select * from all_disks_for_vms where image_group_id='8d06a217-b5fb-45b4-94bf-fbf1dabb70fd'; -[ RECORD 1 ]--------------+------------------------------------- storage_id | 1b7bb2ae-67ae-4a46-903a-9e6aaa6c5d3d storage_name | fcp_2 storage_type | 2 storage_pool_id | 93d29137-7113-4c3a-be46-f87739d1fc9a image_guid | 529afc64-70f7-4033-bc33-9ea217b63be1 creation_date | 2019-11-24 16:50:27+02 actual_size | 10871635968 read_rate | write_rate | read_latency_seconds | write_latency_seconds | flush_latency_seconds | size | 10737418240 it_guid | 00000000-0000-0000-0000-000000000000 imagestatus | 1 lastmodified | 1970-01-01 02:00:00+02 volume_type | 2 volume_format | 4 qcow_compat | 2 image_group_id | 8d06a217-b5fb-45b4-94bf-fbf1dabb70fd description | Active VM parentid | 00000000-0000-0000-0000-000000000000 app_list | vm_snapshot_id | fd5d866b-e3d7-42d8-9a48-51393ea83bf4 active | t volume_classification | 0 entity_type | VM number_of_vms | 1 vm_names | vm_TestCase16968_2416502028 template_version_names | quota_id | 8c1825ed-e642-4ecb-b1dc-905853a63156 quota_name | Default quota_enforcement_type | 0 image_transfer_phase | image_transfer_type | image_transfer_bytes_sent | image_transfer_bytes_total | progress | disk_profile_id | 049728f5-93d0-4ea1-8676-671e78c649d9 disk_profile_name | fcp_2 lun_id | physical_volume_id | volume_group_id | serial | lun_mapping | vendor_id | product_id | device_size | discard_max_size | disk_id | 8d06a217-b5fb-45b4-94bf-fbf1dabb70fd wipe_after_delete | f propagate_errors | Off disk_alias | vm_TestCase16968_2416502028_Disk_0 disk_description | rhel8.0_rhv4.3_guest_disk (7d3bff6) shareable | f sgio | disk_storage_type | 0 cinder_volume_type | disk_content_type | 0 backup | None is_plugged | t logical_name | vm_id | d44facb4-c1e5-4f82-9f46-52d1b604c4ed
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.
Closing old bug. Please reopen if still relevant/you want to work on it.
Reopening as the same issue still occurs on latest rhv-4.3.10-2 (engine-4.3.10-0.2/vdsm-4.40.13-1.el8ev.x86_64) via webadmin in a very simple flow as described from this bug in the beginning. An important note: The issue does not occur/fixed at 4.4 (rhv-4.4.0-31 , engine-4.4.0-0.33/4.40.13-1.el8ev.noarch) as with the same exact scenario Tal, can we see which fix was introduced in 4.4 and maybe backport it to 4.3 as well? Simple scenario: Either via REST/webadmin: 1. Import a template from glance and copy the template disk to several storage domains. 2. Create a New CLONE(NOT THIN!) VM from template on a block based storage domain(ISCSI/FC) 2. Select Format "QCOW2". 3. Select any block based storage. Actual results: Actual size and Virtual size is same via webadmin. In REST you can see actual size is even a litter bigger but as we round it down in UI it looks the same. Expected results: Virtual size should not be same as actual size. Additional info: This is fixed at 4.4 latest (rhv-4.4.0-31 , engine-4.4.0-0.33/4.40.13-1.el8ev.noarch) File based storage do not have this issue.
This bug didn't get any attention in a long time, and it's not planned in foreseeable future. oVirt development team has no plans to work on it. Please feel free to reopen if you have a plan how to contribute this feature/bug fix.
This issue was reproduced in version: ovirt-engine-4.4.9.3-0.3.el8ev.noarch \ vdsm-4.40.90.3-1.el8ev.x86_64 The flow that caused this issue is the same as what aefrat in #c23, #c26. eshenitz - The issue that I see in the reproduction is that the actual size is bigger than the virtual size. How can this affect our product, are there any risks here? Thanks
Nir, is this expected behavior when cloning block-based disks? Amit, can you please add the relevant logs?
Attaching logs from version ovirt-engine-4.4.9.4-0.1.el8ev.noarch, vdsm-4.40.90.4-1.el8ev.x86_64.
(In reply to Avihai from comment #26) > Simple scenario: > Either via REST/webadmin: > > 1. Import a template from glance and copy the template disk to several > storage domains. > 2. Create a New CLONE(NOT THIN!) VM from template on a block based storage > domain(ISCSI/FC) > 2. Select Format "QCOW2". > 3. Select any block based storage. So this is preallocated disk using qcow2 format on block storage. I don't know why you need step 1, isn't this reproducible by Create new disk - storage domain: iSCSI/FC - allocation policy: preallocated - enable incremental backup: true > Actual results: > Actual size and Virtual size is same via webadmin. > In REST you can see actual size is even a litter bigger but as we round it > down in UI it looks the same. This is expected. When using qcow2 format, the image has qcow2 metadata. The size of the metadata can be computed using: $ qemu-img measure --size 100g -O qcow2 required size: 16646144 fully allocated size: 107390828544 107390828544 bytes is 100.016 GiB (1.6% overhead) This size does not include dirty bitmaps that may need to be stored inside the image. In vdsm and engine we use use factor of 1.1 when creating sparse disks. If you create sparse disk with inital_size = virtual size the created disk will be 1.1 * virtual size. This factor is likely too much as we can see from the output of qemu-img measure (10% vs 1.6%). > Expected results: > Virtual size should not be same as actual size. No. Please file a new bug instead of reopening old closed bug. In the new bug, please show this info about the new disk: 1. virtual size in API 2. actual size in API 3. Actual logical volume size 4. The log for createVolume, showing the engine requested parameters 5. The log for creating the logical volume.
(In reply to Nir Soffer from comment #36) > (In reply to Avihai from comment #26) > > Simple scenario: > > Either via REST/webadmin: > > > > 1. Import a template from glance and copy the template disk to several > > storage domains. > > 2. Create a New CLONE(NOT THIN!) VM from template on a block based storage > > domain(ISCSI/FC) > > 2. Select Format "QCOW2". > > 3. Select any block based storage. > > So this is preallocated disk using qcow2 format on block storage. > > I don't know why you need step 1, isn't this reproducible by > > Create new disk > - storage domain: iSCSI/FC > - allocation policy: preallocated > - enable incremental backup: true > > > Actual results: > > Actual size and Virtual size is same via webadmin. > > In REST you can see actual size is even a litter bigger but as we round it > > down in UI it looks the same. > > This is expected. When using qcow2 format, the image has qcow2 > metadata. > > The size of the metadata can be computed using: > > $ qemu-img measure --size 100g -O qcow2 > required size: 16646144 > fully allocated size: 107390828544 > > 107390828544 bytes is 100.016 GiB (1.6% overhead) > > This size does not include dirty bitmaps that may need to be stored > inside the image. > > In vdsm and engine we use use factor of 1.1 when creating sparse disks. > If you create sparse disk with inital_size = virtual size the created > disk will be 1.1 * virtual size. > > This factor is likely too much as we can see from the output of > qemu-img measure (10% vs 1.6%). > > > Expected results: > > Virtual size should not be same as actual size. > > No. > > Please file a new bug instead of reopening old closed bug. > > In the new bug, please show this info about the new disk: > 1. virtual size in API > 2. actual size in API > 3. Actual logical volume size > 4. The log for createVolume, showing the engine requested parameters > 5. The log for creating the logical volume. Just to clarify: 1)Nir,Eyal you state that we are getting the expected behavior in the Actual results but you request to open a new bug, why? I understand RESTAPI shows the correct values for qcow block storage so we are left with the UI showing the same size - is this the new bug you talk about? Not sure it's worth the hassle. 2)Automation tier2 TestCase16968.test_virtual_actual_disk_size_block storage(FC/ISCSI) fails as it expect disk "disk_actual_size < disk_virtual_size" => This is not the expected behavior in block storage(FC/ISCSI) + qcow format and automation should be fixed. Amit, Evelina please open a ticket and fix automation for block storage only ( specifically "assert disk_actual_size < disk_virtual_size"). Skip the TestCase16968 until it's fixed.
Closing the "need_info" in this bug. We need to continue the investigation in order to understand if this is expected behaviour or not. Following Nirs's request, I opened a new (more relevant) bug with all the relevant information needed - bug#2025585 Avihai - in accordance with Nir's answer on the new bug I will refactor TestCase16968.
Following the correspondence above, it was decided to close this bug and open new (and more specific bugs) for each issues mentioned. Opened a new bug regarding "Cloning a VM from a QCOW based template on a block-based storage domain, results with a VM that has a disk with the same actual and virtual size ": https://bugzilla.redhat.com/show_bug.cgi?id=2034531 Closed this bug as a duplicate of 2034531: https://bugzilla.redhat.com/show_bug.cgi?id=1932794 In addition, opened an RFE regarding "reduce size of VM disks that are created from a RAW based template on a block-based storage domain": https://bugzilla.redhat.com/show_bug.cgi?id=2034542 *** This bug has been marked as a duplicate of bug 2034531 ***