Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 12/18/2014 at 11:10 PM, in message 
>>> <1418915443.11882.86.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * add an overview document, so that one can has a overall look 
> >     about the whole domain snapshot work, limits, requirements, 
> >     how to do, etc. 
> >  
> > ===================================================================== 
> > Domain snapshot overview 
>  
> I don't see a similar section for disk snapshots, are you not 
> considering those here except as a part of a domain snapshot or is this 
> an oversight? 
>  
> There are three main use cases (that I know of at least) for 
> snapshotting like behaviour. 
>  
> One is as you've mentioned below for "backup", i.e. to preserve the VM 
> at a certain point in time in order to be able to roll back to it. Is 
> this the only usecase you are considering? 

Yes. I didn't take disk snapshot thing into the scope.

>  
> A second use case is to support "gold image" type deployments, i.e. 
> where you create one baseline single disk image and then clone it 
> multiple times to deploy lots of guests. I think this is usually a "disk 
> snapshot" type thing, but maybe it can be implemented as restoring a 
> gold domain snapshot multiple times (e.g. for start of day performance 
> reasons). 

As we initially discussed about the thing, disk snapshot thing can be done
be existing tools directly like qemu-img, vhd-util.

>  
> The third case, (which is similar to the first), is taking a disk 
> snapshot in order to be able to run you usual backup software on the 
> snapshot (which is now unchanging, which is handy) and then deleting the 
> disk snapshot (this differs from the first case in which disk is active 
> after the snapshot, and due to the lack of the memory part). 

Sorry, I'm still not quite clear about what this user case wants to do.

>  
> Are you considering all three use cases here or are you explicitly 
> ruling out anything but the first? I think there might be some subtle 
> differences in the requirements, wrt which operations need to consider 
> the possibility of an active domain etc, depending on which cases are 
> considered. It would be good to be explicit about the use cases you are 
> not trying to address here so we are all on the same page. 
>  
> If you are ruling these other usecases out then I think it would be 
> useful to briefly describe them and then note that they are out of scope 
> for this design, so that we have an agreed understanding of what is in 
> or out of scope and/or can debate to what extent such use cases ought to 
> be considered in the design if not the implementation.

OK. I'll add this.

>  
> > 1. Purpose 
> >  
> > Domain snapshot is a system checkpoint of a domain. Later, one can 
> > roll back the domain to that checkpoint. It's a very useful backup 
> > function. A domain snapshot contains the memory status at the 
> > checkpoint and the disk status (which we called disk snapshot). 
>  
>  
> > Domain snapshot functionality usually includes: 
> > a) create a domain snapshot 
> > b) roll back (or called "revert") to a domain snapshot 
> > c) delete a domain snapshot 
> > d) list all domain snapshots 
> >  
> > But following the existing xl idioms of managing storage and saved 
> > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, 
> > cp etc), xl snapshot functionality would be kept as simple as 
> > possible: 
> > * xl will do a) and b), creating a snapshot and reverting a 
> >   domain to a snapshot. 
> > * xl will NOT do c) and d), xl won't manage snapshots, as xl 
> >   doesn't maintain saved images created by 'xl save'. So xl 
> >   will have no idea of the existence of domain snapshots and 
> >   the chain relationship between snapshots. It will depends on 
> >   user to take care of the snapshots, know the snapshot chain 
> >   info, and delete snapshots. 
>  
> This is a case where the usecases being considered might apply. If the 
> third case I outlined above is in scope then xl may need to somehow 
> support deleting a snapshot from under the feet of an active domain etc 
> (which need not necessarily imply knowledge of snapshot chains or 
> snapshot management, but might involve a notification to the backend for 
> example). 
>  
> > Domain Snapshot Support and Not Support: 
> > * support live snapshot 
> > * support internal disk snapshot and external disk snapshot 
> > * support different disk backend types. 
> >   (Basic goal is to support 'raw' and 'qcow2' only). 
> >  
> > * not support snapshot when domain is shutdowning or dying. 
> > * not support disk-only snapshot [1]. 
> >  
> >  [1] To xl, it only concerns active domains, and even when domain 
> >  is paused, there is no data flush to disk operation. So, take 
> >  a disk-only snapshot and then resume, it is as if the guest 
> >  had crashed. For this reason, disk-only snapshot is meaningless 
> >  to xl. Should not support. 
> >  
> >  
> > 2. Requirements 
> >  
> > General Requirements: 
> > * ability to save/restore domain memory 
> > * ability to create/delete/apply disk snapshot [2] 
>  
> Is "apply" the same as "revert to"? Worth adding to the terminology 
> section and using consistently.

Yes. In qemu-img terms, it's 'apply'. In libvirt qemu driver domain snapshot
terms, it's 'revert'. I'll add to the terminology section.

>  
> > * ability to parse user config file 
> >  
> >   [2] Disk snapshot requirements: 
> >   - external tools: qemu-img, lvcreate, vhd-util, etc. 
> >   - for basic goal, we support 'raw' and 'qcow2' backend types 
> >     only. Then it requires: 
> >     libxl qmp command or "qemu-img" (when qemu process does not 
> >     exist) 
> >  
> >  
> > 3. Interaction with other operations: 
> >  
> > No. 
>  
> What about shutdown/dying as you noted above? What about migration or 
> regular save/restore? 

Since xl now has no idea of the existence of snapshot, so when writing this
document I turned to depends on users to delete snapshots before or after
deleting a domain (like shutdown, destroy, save, migrate away). User should
know where memory is saved, and disk snapshot related info.

Chunyan

>  
> >  
> > 4. General workflow 
> >  
> > Create a snapshot: 
> >   * parse user cfg file if passed in 
> >   * check snapshot operation is allowed or not 
> >   * save domain, saving memory status to file (refer to: save_domain) 
> >   * take disk snapshot (e.g. call qmp command) 
> >   * unpause domain 
> >  
> > Revert to snapshot: 
> >   * parse use cfg file (xl doesn't manage snapshots, so it has no 
> >     idea of snapshot existence. User MUST supply configuration file) 
> >   * destroy this domain 
> >   * create a new domain from snapshot info 
> >     - apply disk snapshot (e.g. call qemu-img) 
> >     - a process like restore domain 
>  
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel