> No, because the copy-on-write is another layer on top of the snapshot > and AFAICT, they don't persist when moving between snapshots. > > The equivalent for external snapshots would be: > > base0 <- base1 <- base2 <- image > > And then if I wanted to move to base1 without destroying base2 and > image, I could do: > > qemu-img create -f qcow2 -b base1 base1-overlay.img > > The file system can keep a lot of these things around pretty easily but > with your proposal, it seems like there can only be one. If you support
> many of them, I think you'll degenerate to something as complex as a > reference count table. > > On the other hand, I think it's reasonable to just avoid the CoW overlay > entirely and say that moving to a previous snapshot destroys any of it's > children. I think this ends up being a simplifying assumption that is > worth investigating further. No, both VMware and FVD have the same semantics as QCOW2. Moving to a previous snapshot does not destroy any of its children. In the example I gave (copied below), it goes from Image: s1->s2->s3->s4->(current-state) back to snapshot s2, and now the state is Image: s1->s2->s3->s4 |->(curren-state) where all snapshots s1-s4 are kept. From there, it can take another snapshot s5, and then further go back to snapshot s4, ending up with Image: s1->s2->s3->s4 |->s5 | |-> (current-state) FVD does have a reference count table like that in QCOW2, but it avoids the need for updating the reference count table during normal execution of the VM. The reference count table is only updated at the time of creating a snapshot or deleting a snapshot. Therefore, during normal execution of a VM, images with snapshots are as fast as images without snapshot. FVD can do this because of the following: "FVD's reference count table only tracks the snapshots (s1, s2, ...), but does not track the "current-state". Instead, FVD's default mechanism (one-level lookup table, journal, etc.), which exists even before introducing snapshot, already tracks the "current-state". Working together, FVD's reference count table and its default mechanism tracks all the states. In QCOW2, when a new cluster is allocated during handling a running VM's write request, it updates both the lookup table and the reference count table, which is unnecessary because their information is redundant. By contrast, in FVD, when a new chunk is allocated during handling a running VM's write request, it only updates the lookup table without updating the reference count table, because by design the reference count table does not track the "current-state" and this chunk allocation operation belongs to the "current-state." This is the key why FVD can get all the functions of QCOW2's internal snapshot but without its memory overhead to cache the reference count table and its disk I/O overhead to read or write the reference count table during normal execution of VM." Regards, ChunQiang (CQ) Tang, Ph.D. Homepage: http://www.research.ibm.com/people/c/ctang