Bug 1440472

This is a dup of BZ1433052
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1433052#c15

*** This bug has been marked as a duplicate of bug 1433052 ***

Regardless of live snapshot we also changed the behavior to fetch QCOW compat from the storage domain instead from the OVF in this bug: 
https://bugzilla.redhat.com/1430447

It should be fixed in the next build

(In reply to Maor from comment #2)
> Regardless of live snapshot we also changed the behavior to fetch QCOW
In this bug there is NO live snapshot - VM is down all of the time .

> compat from the storage domain instead from the OVF in this bug: 
> https://bugzilla.redhat.com/1430447

Bug 1430447 is about showing the wrong qcow version from the REST API VM path  , this bug look at the right path which is from storage domain REST API path .

> It should be fixed in the next build

Are you sure this is a duplicate issue?

(In reply to Avihai from comment #3)
> (In reply to Maor from comment #2)
> > Regardless of live snapshot we also changed the behavior to fetch QCOW
> In this bug there is NO live snapshot - VM is down all of the time .
> 
> > compat from the storage domain instead from the OVF in this bug: 
> > https://bugzilla.redhat.com/1430447
> 
> Bug 1430447 is about showing the wrong qcow version from the REST API VM
> path  , this bug look at the right path which is from storage domain REST
> API path .
> 
> > It should be fixed in the next build
> 
> Are you sure this is a duplicate issue?

From the reproduce steps (step 2: "& start VM") I thought that the VM was running, since you mention now that it was not running it should not be a dup,
but looking over this bug again, it doesn't looks like a bug:

A snapshot was created - That means that the new created volume is the *active* volume now (which should be with compat level 1.1)
The new snapshot (s2) is basically the old active volume which was with QCOW2_V2.

You can see that the new volume guid is "c4164386-e2f7-4708-be4a-715d2f3c405", 
this is the active volume with the qcow compat.
the snapshots that were queried were:
"f7f52326-89d9-4077-9831-2946fee440f2"
"bd36cc45-941f-423c-be3b-b36890bbe9e5"

You can verify this with the following query:
"SELECT image_group_id, image_guid, qcow_compat, parentid, volume_format, active FROM images where image_group_id = '8eab9385-6652-450b-88d5-0caa85f70e53' order by image_group_id, volume_format, qcow_compat;

if you see that the DB output is not synced with the REST output please feel free to re-open it.
If it does sync with the DB output please change the close reason to not a bug.

(In reply to Maor from comment #4)
> (In reply to Avihai from comment #3)
> > (In reply to Maor from comment #2)
> > > Regardless of live snapshot we also changed the behavior to fetch QCOW
> > In this bug there is NO live snapshot - VM is down all of the time .
> > 
> > > compat from the storage domain instead from the OVF in this bug: 
> > > https://bugzilla.redhat.com/1430447
> > 
> > Bug 1430447 is about showing the wrong qcow version from the REST API VM
> > path  , this bug look at the right path which is from storage domain REST
> > API path .
> > 
> > > It should be fixed in the next build
> > 
> > Are you sure this is a duplicate issue?
> 
> From the reproduce steps (step 2: "& start VM") I thought that the VM was
> running, since you mention now that it was not running it should not be a
> dup,
> but looking over this bug again, it doesn't looks like a bug:
> 
> A snapshot was created - That means that the new created volume is the
> *active* volume now (which should be with compat level 1.1)
> The new snapshot (s2) is basically the old active volume which was with
> QCOW2_V2.
> 
> You can see that the new volume guid is
> "c4164386-e2f7-4708-be4a-715d2f3c405", 
> this is the active volume with the qcow compat.
> the snapshots that were queried were:
> "f7f52326-89d9-4077-9831-2946fee440f2"
> "bd36cc45-941f-423c-be3b-b36890bbe9e5"
> 
> You can verify this with the following query:
> "SELECT image_group_id, image_guid, qcow_compat, parentid, volume_format,
> active FROM images where image_group_id =
> '8eab9385-6652-450b-88d5-0caa85f70e53' order by image_group_id,
> volume_format, qcow_compat;
> 
> if you see that the DB output is not synced with the REST output please feel
> free to re-open it.
> If it does sync with the DB output please change the close reason to not a
> bug.

So to clarify, what you are saying is that test flow is wrong because :
creating a new snapshot on V4.1 (s2) its snapshot disk should be on v0.1 as its based the old active volume which was with v0.1 & it does not create a new v1.1 disk for the new snapshot , right ?

So what I am missing in the test is to create ANOTHER snapshot s3 that it will contain the old active volume which should be v1.1 ?

(In reply to Avihai from comment #5)
> So to clarify, what you are saying is that test flow is wrong because :
> creating a new snapshot on V4.1 (s2) its snapshot disk should be on v0.1 as
> its based the old active volume which was with v0.1 & it does not create a
> new v1.1 disk for the new snapshot , right ?

yes, the new snapshot is simply the old volume.

> 
> So what I am missing in the test is to create ANOTHER snapshot s3 that it
> will contain the old active volume which should be v1.1 ?

This is one way to do that.
The main idea is that the QCOW2 compatibility of the volumes will be reflected correctly through the REST.

(In reply to Maor from comment #6)
> (In reply to Avihai from comment #5)
> > So to clarify, what you are saying is that test flow is wrong because :
> > creating a new snapshot on V4.1 (s2) its snapshot disk should be on v0.1 as
> > its based the old active volume which was with v0.1 & it does not create a
> > new v1.1 disk for the new snapshot , right ?
> 
> yes, the new snapshot is simply the old volume.
> 
> > 
> > So what I am missing in the test is to create ANOTHER snapshot s3 that it
> > will contain the old active volume which should be v1.1 ?
> 
> This is one way to do that.
> The main idea is that the QCOW2 compatibility of the volumes will be
> reflected correctly through the REST.

Hi Maor , 

After trying to add another snapshot after upgrade,
,2 snapshots in total s5 & s6,I still see that after merge qcow2 is 0.1.

I see an even stranger thing that might indicate that there is a deeper issue with live merge itself
-> after merge s5 is merged to s6 I see that the snapshot disks id's of the new merged snapshot s6 are s5 snapshot disks ids ! 

snapshot disks before merge are qcow2_v3 :

Before merge:
snapshot s6 snapshot disks ids:
id="ad5fee2e-cca5-4298-9398-2bf3406f22ab" -> qcow2_v2
id="6759b353-eacf-4ee7-8d34-2749be0ee8d8" -> qcow2_v2

snapshot s5 snapshot disks ids:
id="21ada8c6-1e72-41dc-988f-7412f314b4cc"-> qcow2_v3
id="a1b689a6-dc1b-41d7-ad1b-d3d38e46c15c"-> qcow2_v3
 
After merge:
snapshot s6 snapshot disks id's are s5 snapshot disks ids !  :
21ada8c6-1e72-41dc-988f-7412f314b4cc-> qcow2_v2
a1b689a6-dc1b-41d7-ad1b-d3d38e46c15c-> qcow2_v2

Timestamp of the live merge :
Apr 18, 2017 11:56:57 AM - Snapshot 's5' deletion for VM 'vm_TestCase18346_REST_NFS_1810525477' has been completed.

Created attachment 1272262 [details]
engine & vdsm logs

This is not an issue as CURRENT merge behavior always keep the old snapshots disks id's of the older snapshot & its matching qcow version .

so merging qcow 0.10 & 1.1 snapshots will always result in merge snapshot with qcow 0.1 .

closing bug