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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Dec 17, 2014 at 08:34:07PM -0700, Chun Yan Liu wrote:
> 
> 
> >>> On 12/17/2014 at 08:17 PM, in message
> <20141217121750.GF1904@xxxxxxxxxxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
> wrote: 
> > On Tue, Dec 16, 2014 at 02:32:55PM +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 
> > >  
> > > 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. 
> > >  
> > > Domain Snapshot Support and Not Support: 
> >  
> > I think this list applies to xl (last item and [1]). If so please state 
> > clearly to prevent confusion with other toolstack (say, libvirt) and 
> > functionalities of the library (libxl). 
> >  
> > > * 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. 
> > >  
> >  
> > I think I understand your reasoning, but it's a bit convoluted to me. 
> >  
> > Domain can be in both active and inactive state (libvirt term) when 
> > using xl.  When domain is active, we cannot guarantee in xl that domain 
> > is quiesced so a disk-only snapshot may contain inconsistent data.
> 
> That's right.
> 
> > When 
> > domain is inactive, there's no point in taking a disk-only snapshot 
> > because it would be the same as the base image.
> 
> xl doesn't have inactive domains. Libvirt has. (in libvirt, one can 'define'
> a domain but not 'starte', like old xend which can 'new' a domain but not
> 'start' it.) xl only can 'create' a domain, when domain is shutdown, it's
> not visible to user.
> 

Per the definition in the first patch, inactive domain is a domain
"created but not started", so I thought the domain created by "xl create
-p dom.cfg" falls into this category. I was wrong.

I think the "created but not started" should be "defined but not
started" (using libvirt's terminology).

> For inactive domain, disk-only snapshot is useful. Since later user
> may run VM with base image and base image would change. Then the
> disk-only snapshot is a usable backup.
> 
> That's why, libvirt can support disk-only snapshot, xl won't support
> disk-only snapshot. Do I describe it clearly?
> 

Yes. I think the libvirt terminology is "defined", not "created".

http://wiki.libvirt.org/page/VM_lifecycle

Wei.

> > So the conclusion is 
> > that xl doesn't need to support disk-only snapshot. 
> >  
> > Does the above reasoning equals to yours? Is it clearer or more 
> > confusing? 
> >  
> > Wei. 
> >  
> > >  
> > > 2. Requirements 
> > >  
> > > General Requirements: 
> > > * ability to save/restore domain memory 
> > > * ability to create/delete/apply disk snapshot [2] 
> > > * 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. 
> > >  
> > >  
> > > 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