Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu

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

>>> On 12/19/2014 at 06:38 PM, in message 
>>> <1418985490.20028.27.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/18/2014 at 11:27 PM, in message  
> <1418916436.11882.101.camel@xxxxxxxxxx>, 
> > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:  
> > > On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote:  
> > > > Changes to V8:  
> > > >   * remove libxl_domain_snapshot_create/delete/revert API  
> > > >   * export disk snapshot functionality for both xl and libvirt usage  
> > > >   
> > > >  
> ===========================================================================  
> > > > Libxl/libxlu Design  
> > > >   
> > > > 1. New Structures  
> > > >   
> > > > libxl_disk_snapshot = Struct("disk_snapshot",[  
> > > >     # target disk  
> > > >     ("disk",            libxl_device_disk),  
> > > >   
> > > >     # disk snapshot name  
> > > >     ("name",            string),  
> > > >   
> > > >     # internal/external disk snapshot?  
> > > >     ("external",        bool),  
> > > >   
> > > >     # for external disk snapshot, specify following two field  
> > > >     ("external_format", string),  
> > > >     ("external_path",   string),  
> > >   
> > > Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum  
> > > (with values INTERNAL and EXTERNAL)? 
> > The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items, 
> > INTERNAL doesn't, and no third types. 
> >  
> > > This would automatically make the  
> > > binding between external==true and the fields which depend on that.  
> > >   
> > > external_format should be of type libxl_disk_format, unless it is  
> > > referring to something else?  
> >  
> > Yes. That's right. I'll update. 
> >  
> > >   
> > > Is it possible for format to differ from the format of the underlying  
> > > disk? Perhaps taking a snapshot of a raw disk as a qcow? 
> >  
> > This is related to implementation details. As I understand qemu's 
> > implementation, taking an external disk snapshot is actually a way: 
> > origin domain disk: a raw disk 
> > external= true, external_format: qcow2, external_path: test 
> > a), create a qcow2 file (test.qcow2) with  backing file (the raw disk) 
> > b), replace domain disk, now domain uses test.qcow2 (the raw disk 
> >      is actually to be the snapshot) 
> >  
> > So, I think the external_format can only be those supporting backing file. 
>  
> Not sure what you mean here. 
>  
> What about a phy snapshot via lvm snapshotting? 
>  
> > > In any case  
> > > passing in UNKNOWN and letting libxl choose (probably by picking the  
> > > same as the underlying disk) should be supported. 
> >  
> > If external_format is not passed (NULL), by default, we will use qcow2. 
>  
> I think you need to base this on the type of the original disk, if it is 
> e.g. vhd then making a qcow snapshot seems a bit odd. 
>  
> >  
> > >   
> > > > /*  This API might not be used by xl, since xl won't take care of  
> deleting  
> > > >  *  snapshots. But for libvirt, since libvirt manages snapshots and 
> > > > will  
> > > >  *  delete snapshot, this API will be used.  
> > > >  */  
> > > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid,  
> > > >                                libxl_disk_snapshot *snapshot, int nb);  
> > >   
> > > The three usecases I mentioned in the previous mail are important here,  
> > > because depending on which usecases you are considering there maybe a  
> > > many to one relationship between domains and a given snapshot (gold  
> > > image case). This interface cannot support that I think. 
> >  
> > I'm not quite clear about the three usecases, especially the 3rd usercase, 
> > so really not sure what's the requirement towards deleting disk snapshot. 
>  
> I hope my reply to the previous mail helped clear this up a bit. The 
> reason deleting a disk is interesting is because that is what you would 
> do after the backup was finished. 
>  
> > > When we discussed this in previous iterations I suggested a libxl  
> > > command to tell a VM that it needed to reexamine its disks to see if any  
> > > of the chains had changed. I'm sure that's not the only potential answer  
> > > though. 
> >   
> > About delete disk snapshot in a snapshot chain, whether we need to do 
> > extra work to avoid data break, it can be discussed: 
> > a). For external snapshots, usually it's based on backing file chain, qemu 
> > does this, vhd-util does this. In this case, to delete a domain snapshot, 
> > one doesn't need to do anything to disk (no need to delete disk snapshot 
> > at all). Downside is, there might be a long backing chain. 
>  
> I'm not sure what you mean here I'm afraid. If you are deleting a domain 
> snapshot why do you not want to delete the disk snapshots associated 
> with it? 
>  
> > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support 
> > snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot 
> > won't affect others. 
>  
> For either internal or external if you are removing a snapshot from the 
> middle of a chain which ends in one or more active disks, then surely 
> the disk backend associated with those domains need to get some sort of 
> notification, otherwise they would need to be written *very* carefully 
> in order to be able to cope with disk metadata changing under their 
> feet. 
>  
> Are you saying that the qemu/qcow implementation has indeed been written 
> with this in mind and can cope with arbitrary other processes modifying 
> the qcow metadata under their feet? 

Yes.

I add qemu-devel Kevin and Stefan in this thread in case my understanding
has somewhere wrong.

Kevin & Stefan,

About the qcow2 snapshot implementation,  in following snapshot chain case,
if we delete SNAPSHOT A, will it affect domain 1 and domain 2 which uses
SNAPSHOT B and SNAPSHOT C?

From my understanding, creating a snapshot will increases refcount of original 
data,
deleting a snapshot only descreases the refcount (won't delete data until the 
refcount
becomes 0), so I think it won't affect domain 1 and domain 2.
Is that right?

Thanks,
Chunyan

>  
> e.g.  
> BASE---SNAPSHOT A---SNAPSHOT B --- domain 1 
>                  `--SNAPSHOT C --- domain 2 
>  
> If SNAPSHOT B and C are in active use then I would expect the deletion 
> of SNAPSHOT A would need to notify the backends associated with domain 1 
> and domain 2 somehow, so they don't get very confused. 
>  
> It's possible that this relates to a use case which you aren't intending 
> to address (e.g. the gold image use case), in which case it might be out 
> of scope here. 
>    
> Ian. 
>  
>  
>  


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