[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

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?

> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.