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.

I may be overlooking a use case though, so let me know if I'm missing something

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"?

(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.

(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.

*** Bug 1090819 has been marked as a duplicate of this bug. ***

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

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].

We are stopping use of this bugzilla tracker and using the upstream virt-manager github issue tracker. I've folded in this request to a similar one that there: https://github.com/virt-manager/virt-manager/issues/142