Bug 1868114 - RHV-M UI/Webadmin: The "Disk Snapshots" tab reflects incorrect "Creation Date" information.
Summary: RHV-M UI/Webadmin: The "Disk Snapshots" tab reflects incorrect "Creation Dat...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.3.10
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.4.4
: 4.4.4
Assignee: Ahmad Khiet
QA Contact: Evelina Shames
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-11 17:46 UTC by Bimal Chollera
Modified: 2022-07-28 16:28 UTC (History)
8 users (show)

Fixed In Version: ovirt-engine-4.4.4.4
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-02 13:57:12 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 RHSA-2021:0381 0 None None None 2021-02-02 13:57:41 UTC
oVirt gerrit 111964 0 master MERGED webadmin: Added Snapshot creation Date column to Disk Snapshots 2021-01-15 00:32:16 UTC

Description Bimal Chollera 2020-08-11 17:46:41 UTC
Description of problem:

From the RHV-M UI/Webadmin -> Compute -> Storage Domain -> Disk Snapshots.
The "Creation Date" is not correct appears to be creation date of the Active Snapshot.

-	From the RHV-M UI/Webadmin -> Disk Snapshots Tab
	The "Creation Date" shows "Aug 7, 2020, 10:53:56 AM"

~~~
Size	|	Creation Date			|	Disk Alias	|	Snapshot Description	|	Attached To	|	Status	|	Disk Snapshot ID
--------+---------------------------+---------------+---------------------------+---------------+-----------+---------------------------------------
1GB		|Aug 7, 2020, 10:53:56 AM	|	test_Disk1	|	test					|	test		|	OK		|	4f83f524-7707-4454-a401-aba9bac8cb05
~~~

-	From the RHV-M DB
	In the images table, the vm_snapshot_id 0fb21491-43ea-4cfe-8a21-d94385b0f10e is associated to the image 4f83f524-7707-4454-a401-aba9bac8cb05
	In the snapshots tables, the snapshot_id 0fb21491-43ea-4cfe-8a21-d94385b0f10e shows creation_date 2020-08-11 12:04:44.078-04

~~~
images: 
              image_guid              |            image_group_id            |            vm_snapshot_id            |               parentid               
--------------------------------------+--------------------------------------+--------------------------------------+--------------------------------------
 4f83f524-7707-4454-a401-aba9bac8cb05 | 36ef8965-c8f1-4091-8ada-1471d61ed6ff | 0fb21491-43ea-4cfe-8a21-d94385b0f10e | 00000000-0000-0000-0000-000000000000 
 02895277-e47b-4513-9577-36c3b19f620a | 36ef8965-c8f1-4091-8ada-1471d61ed6ff | 746a0e86-f7e3-4d8f-8fc2-2542059b2aeb | 4f83f524-7707-4454-a401-aba9bac8cb05 
(2 rows)

 
snapshots:
             snapshot_id              | snapshot_type | status | description |       creation_date        
--------------------------------------+---------------+--------+-------------+----------------------------
 746a0e86-f7e3-4d8f-8fc2-2542059b2aeb | ACTIVE        | OK     | Active VM   | 2020-08-07 13:53:38.501-04 
 0fb21491-43ea-4cfe-8a21-d94385b0f10e | REGULAR       | OK     | test        | 2020-08-11 12:04:44.078-04 
(2 rows)
~~~


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

4.3.10

How reproducible:

100%

Steps to Reproduce:
1.  Create a snapshot and check the "Creation Date" in the "Disk Snapshots" tab.

2.  The run the following on the RHV-M ovirt-engine and check the creation_date
    Note:  replace v.vm_name with your VM name.

~~~
/usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "SELECT i.image_guid, i.image_group_id, i.vm_snapshot_id,  b.disk_alias, i.parentid, s.snapshot_id, s.description, s.snapshot_type, i.creation_date FROM images as i JOIN snapshots AS s ON (i.vm_snapshot_id = s.snapshot_id) LEFT JOIN vm_static AS v ON (s.vm_id = v.vm_guid) JOIN base_disks AS b ON (i.image_group_id = b.disk_id) WHERE v.vm_name = 'test' ORDER BY creation_date, description, disk_alias;"
~~~

3.

Actual results:

Incorrect creation_date reflected.

Expected results:

Correct creattion_date should be shown.

Additional info:

Comment 1 Bimal Chollera 2020-08-11 21:28:20 UTC
My browser in different TZ, hence there is 3 hour different.

The Creation Date in the RHV-M GUI/Webadmin appears to be from when the image was created and not when the Active snapshot was created.

~~~
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -x -c "SELECT i.image_guid, i.image_group_id, i.vm_snapshot_id,  b.disk_alias, i.parentid, s.snapshot_id, s.description, s.snapshot_type, i.creation_date FROM images as i JOIN snapshots AS s ON (i.vm_snapshot_id = s.snapshot_id) LEFT JOIN vm_static AS v ON (s.vm_id = v.vm_guid) JOIN base_disks AS b ON (i.image_group_id = b.disk_id) WHERE v.vm_name = 'test' ORDER BY creation_date, description, disk_alias;"
-[ RECORD 1 ]--+-------------------------------------
image_guid     | 4f83f524-7707-4454-a401-aba9bac8cb05
image_group_id | 36ef8965-c8f1-4091-8ada-1471d61ed6ff
vm_snapshot_id | 0fb21491-43ea-4cfe-8a21-d94385b0f10e
disk_alias     | test_Disk1
parentid       | 00000000-0000-0000-0000-000000000000
snapshot_id    | 0fb21491-43ea-4cfe-8a21-d94385b0f10e
description    | test
snapshot_type  | REGULAR
creation_date  | 2020-08-07 13:53:56-04  <<======

-[ RECORD 2 ]--+-------------------------------------
image_guid     | 02895277-e47b-4513-9577-36c3b19f620a
image_group_id | 36ef8965-c8f1-4091-8ada-1471d61ed6ff
vm_snapshot_id | 746a0e86-f7e3-4d8f-8fc2-2542059b2aeb
disk_alias     | test_Disk1
parentid       | 4f83f524-7707-4454-a401-aba9bac8cb05
snapshot_id    | 746a0e86-f7e3-4d8f-8fc2-2542059b2aeb
description    | Active VM
snapshot_type  | ACTIVE
creation_date  | 2020-08-11 12:04:34-04
~~~

Comment 2 Ahmad Khiet 2020-09-06 15:16:52 UTC
HI Bimal,
I checked in my environment, and I did not see this issue.

what I did is the following: 
1- under storage-> storage domains -> [select the storage domain the with the needed VM) -> Disk Snapshots 
 
2- in the database I did the following query (and replaced v.vm_name to the vm name) : 
SELECT i.image_guid, i.image_group_id, i.vm_snapshot_id,  b.disk_alias, i.parentid, s.snapshot_id, s.description, s.snapshot_type, i.creation_date FROM images as i JOIN snapshots AS s ON (i.vm_snapshot_id = s.snapshot_id) LEFT JOIN vm_static AS v ON (s.vm_id = v.vm_guid) JOIN base_disks AS b ON (i.image_group_id = b.disk_id) WHERE v.vm_name = 'test' ORDER BY creation_date, description, disk_alias;


comparing the results from 1 & 2, I see the same creation date and time. with no time gaps or time zones issue.

I recommend to check the system date time, ovirt date time, and if there's a settings for that in the database. I guess its a configuration issue, not code related issue.

I'm waiting for you response.

Comment 3 Bimal Chollera 2020-09-07 23:05:44 UTC
Hello Ahmad.

Let try this way.

From the RHV-M UI/Webadmin.
Compute -> Virtual Machine -> Select the VM.
Lower Pane, click on Snapshots.
Click on General (eye) icon to expand on the Snapshots.

The non Active VM snapshot will ahve a Date info.
Note this date/time.

Now, from the RHV-M UI/Webamdin
Compute ->  Storage Domain -> Select the Storage Domain.
Click on Disk Snapshots.
See the Creation Date on the snapshot that is attached.

The date/time from the Virtual Machine snapshot info and the Storage domain Disk snapshot is different.

Thanks
Bimal.

Comment 4 Ahmad Khiet 2020-09-08 15:02:10 UTC
Hi Bimal, 

After follwoing the steps in Comment #3, I can see that the date time between sql/storage domain snapshots/vm snapshots does not match.
the root cause for this bug is that there's a mismatch in the date viewing in each snapshot.

for example in VM snapshots:
the Active Vm (Disk) does not show a date time.
the snapshot after, shows the date time of the active vm.
the next snapshot shows the date time of the previous snapshot.
and so on.

Thanks for the information, it helped a lot.

Comment 5 Ahmad Khiet 2020-09-17 13:27:25 UTC
Hi Bimal,

After further debugging and investigating this bug, I though that there is a mismatch between date time rows at first because of what I saw.
then, I see that the dates are correct, see the Disks sub-tab on each snapshot and check if the dates are right.
the creation date of an image will be different from the snapshot creation date, because of the image is created first, until the response is back from vdsm, the snapshot creation date will be updated.
so its not a bug, you can close it if you see that's the case in your environment.

Comment 11 Evelina Shames 2020-12-24 07:07:16 UTC
Verified with the following steps:

From Compute -> Virtual Machines -> vm_name > Snapshots > Expand the General tab:
~~~
ACTIVE 
Date - Current

s1
Date Dec 24, 2020, 8:49:59 AM
~~~


From Compute -> Storage Domain -> sd > Disk Snapshots:
~~~
s1
Creation Date Dec 24, 2020, 8:49:59 AM

Version: rhv-4.4.4-6

Ahmad, is that ok? Is there something else I need to check?

Comment 12 Ahmad Khiet 2020-12-24 09:26:03 UTC
Hi Evelina, 
you need to check the snapshot creation date see https://imgur.com/a/Eq1phXh
this date will be also present in disks under Compute -> Virtual Machines -> vm_name > Snapshots

Comment 13 Evelina Shames 2020-12-24 09:50:11 UTC
(In reply to Ahmad Khiet from comment #12)
> Hi Evelina, 
> you need to check the snapshot creation date see https://imgur.com/a/Eq1phXh
> this date will be also present in disks under Compute -> Virtual Machines ->
> vm_name > Snapshots

That's what I did :)
Checked both  Virtual Machines -> vm_name > Snapshots and Storage Domain -> sd > Disk Snapshots and the date it the same.
Just Asked if I didn't miss anything else.
Thanks.

Moving to Verified.

Comment 17 errata-xmlrpc 2021-02-02 13:57:12 UTC
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 (Low: RHV-M(ovirt-engine) 4.4.z security, bug fix, enhancement update [ovirt-4.4.4]), 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/RHSA-2021:0381

Comment 18 meital avital 2022-07-28 16:28:14 UTC
Due to QE capacity, we are not going to cover this issue in our automation


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