Bug 1416153 - Virtual and Actual size on preallocated disk mismatch after snapshot deletion
Summary: Virtual and Actual size on preallocated disk mismatch after snapshot deletion
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.6
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.1.0-beta
: ---
Assignee: Maor
QA Contact: Elad
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-24 17:22 UTC by Koutuk Shukla
Modified: 2020-03-11 15:43 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Previously, after deleting a snapshot in a data center the original volume’s allocation policy and size differed from the pre-snapshot state. In this release, if a snapshot is created from a preallocated volume, when the snapshot is deleted qemu-img is called to copy data from the top volume to the base volume. As a result, the original volume’s allocation policy and size are identical.
Clone Of:
Environment:
Last Closed: 2017-04-25 00:43:52 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:0997 0 normal SHIPPED_LIVE Red Hat Virtualization Manager (ovirt-engine) 4.1 GA 2017-04-18 20:11:26 UTC

Description Koutuk Shukla 2017-01-24 17:22:06 UTC
Description of problem:

Virtual and Actual size on preallocated disk mismatch after snapshot deletion

Version-Release number of selected component (if applicable):

Red Hat Virtualization Manager Version: 4.0.6

How reproducible: 100 %

Steps to Reproduce:

1. Create a snapshot on vm. ( VM with a preallocated disk on NFS domain )
2. Shutdown vm.
3. Delete the vm snapshot

Actual results:
Virtual and Actual size of the disk mismatch. 

Expected results:
As the disk was created as a preallocated with Virtual and Actual size same. It should retain the same status after deletion.

Additional info:
This test was carried out with vm having a preallocated disk on NFS storage domain and vm was shutdown before snapshot deletion.

Not sure if the behavior is same for ISCSI and FC domain.

Comment 3 Maor 2017-01-25 14:42:00 UTC
Hi Koutuk,

I was trying to reproduce this on my env but it seems that the disks returned to their original state and size.

Can you please share more information how the size was mismatched?
Also, if you can share more info on the reproduce steps, were there any other operations that was done with the VM and the disks, maybe while the VM was UP?

Can you please share the following output from your Host (see [1] for exmaple):

1) Before the snapshot:
sudo vdsClient -s 0 getVolumeSize sd_id sp_id image_id volume_id
du /rhev/data-center/{sp_id}/{sd_id}/images/{image_id}/{volume_id}

2) After the creation of the snapshot:
sudo vdsClient -s 0 getVolumeSize sd_id sp_id image_id volume_id
sudo vdsClient -s 0 getVolumeSize sd_id sp_id image_id volume_id2 (of the snapshot)
du /rhev/data-center/{sp_id}/{sd_id}/images/{image_id}/{volume_id}
du /rhev/data-center/{sp_id}/{sd_id}/images/{image_id}/{volume_id2} (of the snapshot)

3) After the deletion of the snapshot
sudo vdsClient -s 0 getVolumeSize sd_id sp_id image_id volume_id
du /rhev/data-center/{sp_id}/{sd_id}/images/{image_id}/{volume_id}


Also, while you are trying to reproduce it please also attach the VDSM and engine logs which might help.

Thanks,
Maor


[1]
sudo vdsClient -s 0 getVolumeSize 3e2b9770-a220-4098-b1a4-23d008924ddd 00000001-0001-0001-0001-000000000311 84ab8933-dab4-4caf-82f3-38ac27452adb 0c863cfa-4d28-4015-b615-546bc17f8231
        apparentsize = '5368709120'
	truesize = '5368713216'

 sudo vdsClient -s 0 getVolumeSize 3e2b9770-a220-4098-b1a4-23d008924ddd 00000001-0001-0001-0001-000000000311 84ab8933-dab4-4caf-82f3-38ac27452adb c4b29269-02b0-4d04-b6b3-8bc48ccb5d49
        apparentsize = '197120'
	truesize = '200704'

 du -h 84ab8933-dab4-4caf-82f3-38ac27452adb/0c863cfa-4d28-4015-b615-546bc17f8231 
5.1G	84ab8933-dab4-4caf-82f3-38ac27452adb/0c863cfa-4d28-4015-b615-546bc17f8231

du  84ab8933-dab4-4caf-82f3-38ac27452adb/c4b29269-02b0-4d04-b6b3-8bc48ccb5d49
196	84ab8933-dab4-4caf-82f3-38ac27452adb/c4b29269-02b0-4d04-b6b3-8bc48ccb5d49

Comment 7 Maor 2017-01-26 14:22:49 UTC
I know that the behavior of cold merge was changed since 4.1 that is why this was not reproduced on my env.
before 4.1 the merge of the snapshot was done on the latest volume and now the merge is being done on the older volume.
Nir, is this behavior described in the bug is part of the known behavior in 4.0? Could it be that the change which was done in cold merge already considered this behavior change?

Comment 8 Nir Soffer 2017-01-26 15:05:16 UTC
(In reply to Maor from comment #7)
Maor, the description in the bug is not clear, I don't know what is:
"Virtual and Actual size of the disk mismatch."

Please ask more specific data from the reporter.

Comment 9 Maor 2017-01-26 15:10:41 UTC
(In reply to Nir Soffer from comment #8)
> (In reply to Maor from comment #7)
> Maor, the description in the bug is not clear, I don't know what is:
> "Virtual and Actual size of the disk mismatch."
> 
> Please ask more specific data from the reporter.

It is being explained in comment 4

Comment 10 Maor 2017-01-29 10:50:12 UTC
After a quick research, it seems that the fix for this issue has been already introduced as part of the remove snapshot feature in DC 4.1 (see [1])

The behavior for 4.0 DCs (and below) is to create a temporary volume, and data is copied from base volume to the temporary volume using qemu-img rebase while the behavior for 4.1 DCs is to call qemu-img commit so data is copied from top to base.

I doubt if we can backport this behavior to older oVirt/DC versions since this feature contained many behavior changes and infrastructure changes.

[1] https://www.ovirt.org/develop/release-management/features/storage/remove-snapshot/

Comment 11 Nir Soffer 2017-01-29 11:03:18 UTC
(In reply to Maor from comment #10)
> I doubt if we can backport this behavior to older oVirt/DC versions since
> this feature contained many behavior changes and infrastructure changes.

There is no doubt, we cannot backport major 4.1 feature to 4.0. 4.1 will be 
release soon, so I think we should close this as wontfix.

Maor, did you check if issue exists in 3.6 and older versions?

Comment 12 Yaniv Kaul 2017-01-29 11:13:07 UTC
(In reply to Nir Soffer from comment #11)
> (In reply to Maor from comment #10)
> > I doubt if we can backport this behavior to older oVirt/DC versions since
> > this feature contained many behavior changes and infrastructure changes.
> 
> There is no doubt, we cannot backport major 4.1 feature to 4.0. 4.1 will be 
> release soon, so I think we should close this as wontfix.

NEXTRELEASE is a better and correct resolution. 
In practice, we'd want to move this to ON_QA,  havebit verified and included in the errata with the correct doctext. 

> 
> Maor, did you check if issue exists in 3.6 and older versions?

Comment 13 Maor 2017-01-29 13:26:40 UTC
(In reply to Nir Soffer from comment #11)
> (In reply to Maor from comment #10)
> > I doubt if we can backport this behavior to older oVirt/DC versions since
> > this feature contained many behavior changes and infrastructure changes.
> 
> There is no doubt, we cannot backport major 4.1 feature to 4.0. 4.1 will be 
> release soon, so I think we should close this as wontfix.
> 
> Maor, did you check if issue exists in 3.6 and older versions?

No, I tried to do that on DC 4.0 and the behavior described in this bug was reproduced, but 4.1 DC seem to reflect the expected behavior.

Comment 14 Maor 2017-01-29 13:28:13 UTC
Move that to ON_QA as Yaniv suggested so it will be in the errata with the correct doctext.

Comment 15 Yaniv Kaul 2017-01-29 13:35:43 UTC
(In reply to Maor from comment #14)
> Move that to ON_QA as Yaniv suggested so it will be in the errata with the
> correct doctext.

Please add it to the errata - it's not going to be added automatically

Comment 16 Maor 2017-01-29 14:36:51 UTC
Raz,

Can u please give a qa ack so I can add the errata

Comment 17 Raz Tamir 2017-01-29 14:46:14 UTC
Done

Comment 18 Elad 2017-01-30 12:54:47 UTC
After snapshot merge, disk actual size is similar to its virtual size.
Verified according to the steps in the description using:
rhevm-4.1.0.2-0.2.el7.noarch
vdsm-4.19.2-2.el7ev.x86_64


Note You need to log in before you can comment on or make changes to this bug.