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

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

>>> On 1/8/2015 at 08:26 PM, in message <1420719995.19787.62.camel@xxxxxxxxxx>, 
>>> Ian
Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Mon, 2014-12-22 at 20:42 -0700, Chun Yan Liu wrote: 
> >  
> > >>> 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? 
>  
> Correct, what the user is actually trying to achieve with the 
> functionality. 
>  
> > 'Gold image' or 'Gold domain', the needed work is more like cloning disks. 
>  
> Yes, or resuming multiple times. 

I see. But IMO it doesn't need change in snapshot design and implementation.
Even resuming multiple times, they couldn't use the same image but duplicate
the image multiple times.

>  
> > > > > 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? 
>  
> I don't think that's relevant right now, let me explain: 
>  
> I think it's important to consider all the use cases for snapshotting, 
> not because I think they need to be implemented now but to make sure 
> that we don't make any design decisions now which would make it 
> *impossible* to implement it in the future (at least without API 
> changes). 
>  
> As a random example, we would want to avoid designing a libxl API where 
> it is impossible to send the quiesce request at the right point for some 
> reason. 
>  
> So we need to consider these use cases now and have the design, but not 
> necessarily the implementation, be able to deal with them, or at least 
> to convince ourselves we most likely aren't tying our hands for future 
> work.

Understand. If this user case is included in design, then I think
libxl_disk_snapshot_create is not enough, better to have
libxl_domain_snapshot_create, in future if guest agent is implemented,
the process would be:
if 'disk-only':
   pause domain;
   drain cache data to disk;
   take disk snapshot;
   resume domain;
else:
   save memory;
   take disk snapshot;
   resume domain.

And in 'xl xnapshot-create' snap.cfg, reserve 'memory' and 'memory_path'
for future extension.

Will update. Thanks.

>  
> > Merry Christmas!  
>  
> And (retrospectively) to you! 
>  
> Ian. 
>  
>  
>  


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