Bug 1065077 - RFE: snapshots: Consider showing snapshot hierarchy
Summary: RFE: snapshots: Consider showing snapshot hierarchy
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Keywords:
: 1090819 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-13 20:50 UTC by carcinoma
Modified: 2018-10-22 15:04 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description carcinoma 2014-02-13 20:50:00 UTC
Description of problem:
With the current display of the "available snapshots" view it is impossible to
determine the herarchical structure of the snapshots.

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

How reproducible:
Try to find the parent or parent.parent of a snapshot listed in a VM which contains many branches and leafs.

Steps to Reproduce:
1. Create VM
2. Create a snapshots hirarchy like so:
base
 + test 1
    + experiment 1
 + test 2

Actual results:
The snapshots will be displayed like so:
- base
- experiment 1
- test 1
- test 2

Expected results:
The snapshots are displayed like so:
base
 + test 1
    + experiment 1
 + test 2


Additional info:
none

Comment 1 Cole Robinson 2014-02-13 22:09:11 UTC
Libvirt might track internal snapshots in a hierarchical manner, but in practice the hierarchy is just metadata: each snapshot is totally independent of its parent or children. I explicitly chose not to show things in a hierarchy since it might lead to user confusion like 'what happens when I delete a snapshot with children?' The answer is basically 'nothing happens', which a tree view doesn't suggest.

I understand how the hierarchy could be a useful data point to know about the content of each snapshot, but I don't think it's worth the trade off of potential UI confusion.

Comment 2 Cole Robinson 2014-02-13 22:12:42 UTC
I may be overlooking a use case though, so let me know if I'm missing something

Comment 3 carcinoma 2014-02-14 21:40:57 UTC
It is hard to argue this issue.
The virsh has the ability to display the snapshots in a tree and
it is easier (for human) to find out the "correct" snaphot. 

There could also be the question: Why does virsh provide such and 
option, if it could confuse the user.

In fact, currently i did not tried to delete an snaphot which is not a leaf one.
So, what did you mean by "nothing is happening when deleting an snaphot with cildren and nothing is happening"? I would think that the children would be connected to the parent of the deleted snapshot?.

But you can also can tell me wrong. Is there any way to determine that the, in the example, "experiment 1" is a child of "test 1"?

Comment 4 Cole Robinson 2014-02-14 22:09:37 UTC
(In reply to carcinoma from comment #3)
> It is hard to argue this issue.
> The virsh has the ability to display the snapshots in a tree and
> it is easier (for human) to find out the "correct" snaphot. 
> 
> There could also be the question: Why does virsh provide such and 
> option, if it could confuse the user.
> 

virsh is not an end user targeting tool, it just exposes the raw libvirt API to the user. libvirt does track the parent of snapshots, because for certain types of snapshots this is very important data (external snapshots). However, for internal snapshots, it's not too important except as a small reminder to the user. virt-manager only exposes internal snapshots because they are the most complete for our needs and the easiest to understand.

> In fact, currently i did not tried to delete an snaphot which is not a leaf
> one.
> So, what did you mean by "nothing is happening when deleting an snaphot with
> cildren and nothing is happening"? I would think that the children would be
> connected to the parent of the deleted snapshot?.
> 

For internal snapshots, that is what happens. However for external snapshots, there would be open questions, and deleting a snapshot with children would require a slow rebase operation. Libvirt doesn't support that currently.

> But you can also can tell me wrong. Is there any way to determine that the,
> in the example, "experiment 1" is a child of "test 1"?

From virt-manager? No, short of giving it a clear name. But then again, you could do:

-> take snapshot1
* make a change
-> take snapshot2
* undo that change
-> take snapshot3

Now you have a hierarchy of snapshot1 -> snapshot2 -> snapshot3, but snapshot1 and snapshot3 are identical, so the hierarchy itself isn't a fool proof piece of data, I'd still recommend having a clear name and snapshot description.

I think I need to go play with vmware and virtualbox though to see what they do. The main thing about exposing the hierarchy is that I think we would need to rework the UI quite a lot to show things in a useful way. So I'll leave this bug open to see if other people have comments and we can figure it out at a later date.

Comment 5 carcinoma 2014-02-14 22:29:47 UTC
(In reply to Cole Robinson from comment #4)
> (In reply to carcinoma from comment #3)
> > It is hard to argue this issue.
> > The virsh has the ability to display the snapshots in a tree and
> > it is easier (for human) to find out the "correct" snaphot. 
> > 
> > There could also be the question: Why does virsh provide such and 
> > option, if it could confuse the user.
> > 
> 
> virsh is not an end user targeting tool, it just exposes the raw libvirt API
> to the user. libvirt does track the parent of snapshots, because for certain
> types of snapshots this is very important data (external snapshots).
> However, for internal snapshots, it's not too important except as a small
> reminder to the user. virt-manager only exposes internal snapshots because
> they are the most complete for our needs and the easiest to understand.
got that.
> 
> > In fact, currently i did not tried to delete an snaphot which is not a leaf
> > one.
> > So, what did you mean by "nothing is happening when deleting an snaphot with
> > cildren and nothing is happening"? I would think that the children would be
> > connected to the parent of the deleted snapshot?.
> > 
> 
> For internal snapshots, that is what happens. However for external
> snapshots, there would be open questions, and deleting a snapshot with
> children would require a slow rebase operation. Libvirt doesn't support that
> currently.
got that too.
> 
> > But you can also can tell me wrong. Is there any way to determine that the,
> > in the example, "experiment 1" is a child of "test 1"?
> 
> From virt-manager? No, short of giving it a clear name. But then again, you
> could do:
> 
> -> take snapshot1
> * make a change
> -> take snapshot2
> * undo that change
> -> take snapshot3
> 
> Now you have a hierarchy of snapshot1 -> snapshot2 -> snapshot3, but
> snapshot1 and snapshot3 are identical, so the hierarchy itself isn't a fool
> proof piece of data, I'd still recommend having a clear name and snapshot
> description.
> 
> I think I need to go play with vmware and virtualbox though to see what they
> do. The main thing about exposing the hierarchy is that I think we would
> need to rework the UI quite a lot to show things in a useful way. So I'll
> leave this bug open to see if other people have comments and we can figure
> it out at a later date.
Ah, right. I'm afraid my colleagues will expect those products kind of snaphot presentation. 

I agree to the new state of this buga and i'll try to find more arguments which could help to solve this issue.

Comment 6 Cole Robinson 2014-04-24 12:48:11 UTC
*** Bug 1090819 has been marked as a duplicate of this bug. ***

Comment 7 Cole Robinson 2014-04-24 12:50:23 UTC
Suggestion from the dup'd bug: allow sorting snapshot list by creation date. However it should probably be combined with showing the hierarchy, and sort the hierarchy by date created or last time accessed. Something to think about

Comment 8 Samo Dadela 2014-04-25 11:16:47 UTC
Regarding what vmware and vbox do... 

They do what is expected. You see a tree of snapshots... a branch represents the history of snapshots from the root. 

If you have a branch A<->B<->C and delete B. Rebasing will happen (yes, it's slow) and you will get A<->C. Did not try what happens if B had a branch too:

A<->B<->C
    |->D

... I'd expect you get:
A<->C
|->D

I find that behaviour pretty intuitive.

The only big feature that would make virt-manager on par with the vmware and vbox UI is the snapshot tree (for workstation users). [and of course video drivers.. I get by using qxl... but that's not virt-manager's fault].


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