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

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

>>> On 12/19/2014 at 06:25 PM, in message 
>>> <1418984720.20028.15.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> 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@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. 
>  
> 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. 

OK. I see. I think this user case is more like how to use the snapshot, rather
than how to implement snapshot. Right?
'Gold image' or 'Gold domain', the needed work is more like cloning disks.

>  
> > > 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 users wants 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). 

Got it. So that's simply disk-only snapshot when domian is active. As you
mentioned below, that needs guest agent to quiesce the disks. But currently
xen hypervisor can't support that, right?

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

Understand. I think most questions here are about a general overview vs a xl
specific view. Which I provided is xl specific, which you suggested is a
general overview. I'll update.
 
>  
> >  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?

Ah, see. I should add words here. As described above, snapshot is not supported
when domain is being shutdown or dying.

Thanks very much for your precious time before holiday.
Merry Christmas! 

-Chunyan

> 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. 
>  
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@xxxxxxxxxxxxx 
> http://lists.xen.org/xen-devel 
>  
>  


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