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

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

>>> On 1/12/2015 at 09:54 PM, in message <1421070890.26317.69.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Mon, 2015-01-12 at 00:01 -0700, Chun Yan Liu wrote: 
> >  
> > >>> 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. 
>  
> Perhaps, but the use case should be included so that this rationale for 
> not worrying about it can be written down (so that people like me don't 
> keep asking...)  

Got it. Thanks!

>  
> >  
> > >   
> > > > > > > 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. 
>  
> You don't mention the poking of the agent here, I think it comes before 
> the if, or maybe just after in the disk-only case (it can't come after 
> the pause)? 
>  
> It might be that a mechanism for quiescing all disks + pausing would be 
> sufficient, meaning you could leave libxl_disk_snapshot_create as it is 
> and implement the snapshot for backup similarly as quiesce+pause + 
> libxl_disk_snapshot create. 

Yeah, that's sufficient, if a mechanism for quiescing disks could be
provided. Then we can keep libxl_disk_snapshot_create.

Will update all docs.

Thanks a lot!

- Chunyan

>  
> Either way by considering this usecase now we can decide whether 
> libxl_disk_snapshot_create is sufficient or whether we should go with 
> lixbxl_domain_snapshot_create from day one. 
>  
> Ian. 
>  
>  
>  


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