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

[Ian Campbell <Ian.Campbell@citrix.com>]

On Thu, 2014-12-18 at 22:45 -0700, Chun Yan Liu wrote:
> 
> >>> On 12/18/2014 at 11:10 PM, in message <1418915443.11882.86.camel@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> 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.

I was reading this section as a more generic overview of snapshotting,
without reference to where/how things might ultimately be implemented.

>From a design point of view it would be useful to cover the various use
cases, even if the solution is that the user implements them using CLI
tools by hand (xl) or the toolstack does it for them internally
(libvirt).

This way we can more clearly see the full picture, which allows us to
validate that we are making the right choices about what goes where.

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

The user has an active domain which they want to backup, but backup
software often does not cope well if the data is changing under its
feet.

So the userswants to take a snapshot of the domains disks while leaving
the domain running, so they can backup that static version of the disk
out of band from the VM itself (e.g. by attaching it to a separate
backup VM).

This may require a guest agent to quiesce the disks.

> >  
> > > * 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,

what about libvirt? This section is an overview, so making toolstack
specific assumptions is confusing.

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

What I meant was what happens if you try to snapshot a domain while it
is being shutdown or being migrated? There clearly has to be some sort
of interaction, even if it is "there is a global toolstack lock" or "the
user is advised not to do this".

Ian.