Re: [Xen-devel] [RFC V6] Libxl Domain Snapshot API Design

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

>>> On 9/9/2014 at 06:13 PM, in message
<1410257637.8217.94.camel@xxxxxxxxxxxxxxxxxxxxxx>, Ian Campbell
<Ian.Campbell@xxxxxxxxxx> wrote: 
> On Tue, 2014-09-09 at 02:43 -0600, Chun Yan Liu wrote: 
> > Generally 
> > it could be like creating domain, xl can list all domains created by xl or  
> virsh, 
> > xl snapshot-list could list domain snapshots created by xl or virsh too. To 
> > show complete snapshot information, I think it's better to include these 
> > at libxl level. 
>  
> I think we have a fundamental disconnect in what we consider a snapshot 
> to be like here and at what level of the toolstacl hierarchy they exist, 
> so I'm going to focus on just this one bit for now since there isn't 
> much point in moving forward with the rest until we've come to an 
> agreement on this. 
>  
> My view is that libxl is primarily concerned with domains which are 
> actually running and the operations which can be performed on them. 
> Therefore it provides mechanisms for listing all running domains which 
> xl and libvirt etc can use to list all running domains. 
>  
> However libxl does not concern itself with domains which are not 
> currently running, it simply has no idea about them. This knowledge of 
> non-running domains exists only at the higher levels of the toolstack. 
> (this is why I said carefully libvirt in the previous paragraph and not 
> virsh, since virsh accesses the higher level toolstack and can therefore 
> list non-running domains too) 
>  
> With xl this is exposed quite fundamentally since a non running domain 
> exists only in the cfg file and disk images, which the user managed by 
> hand. When you save a domain it is to a user provided file, and after 
> that point libxl has no further knowledge of it. 
>  
> With libvirt this manifests as libvirt keeping track of every domain's 
> configuration even when the domain is not running as part of its own 
> state. I'm not 100% sure where a saved domain goes with libvirt but once 
> it is saved I believe libxl no longer knows about the domain and it only 
> exists as part of the libvirt state. 
>  
> A second consequence of this is that libxl has no concept of storage 
> management, i.e. it doesn't know anything about disk images except when 
> it is asked to attach one particular disk image to a domain. With xl 
> users do storage management by hand (with lvcreate and qemu-img etc) 
> whereas libvirt has its own storage management which it uses. 
>  
> In my view a snapshot is more like a saved domain than a running one. As 
> such once the snapshot has been created then libxl should not need to 
> know anything more about it. The snapshotted domain of course keeps 
> running and libxl knows about that, but the snapshot itself is no longer 
> libxl's concern. 
>  
> What this means is that in order to implement "xl snapshot-list" then 
> *xl*, not libxl, would need to manage those shapshots itself. Perhaps by 
> growing a whole bunch of snapshot and storage management functionality, 
> but more likely by passing this responsibility on to the user (i.e. "xl 
> snapshot-list" becomes "run ls on the directory where you store these 
> things""). 
>  
> I think virst snapshot-list is more interesting, but AIUI libvirt's 
> datamodel already includes all of the storage and snapshot management 
> which is required here. It already keeps the state for non-running 
> domains and it already has infrastructure for managing disks and it 
> already knows about snapshotting of domains at a high level etc. 

Yes, that's right.

>  
> So I don't think there is any need (or even desire) for libxl to 
> replicate any of that functionality. It should concern itself with 
> taking a snapshot when asked and then forget all about it. 
>  
> I think things work the same with e.g. qemu and other libvirt backends. 
> A qemu process only exists to track an actual running domain, all of the 
> other state including the configuration when the domain is not running 
> etc is all handled at the libvirt layer. When you take a snapshot of a 
> qemu backed domain then after that snapshot has happened the qemu 
> process knows no more about it. So in this way of thinking qemu and 
> libxl are functionally equivalent bits i.e. things which are used to 
> instantiate actual running domains and perform operations on them. 
>  
> Does that make sense? 

Totally agree with you. I've mixed something in xl and libxl. It's correct
that as libxl it should only do what application asks it to do and then
forget everything. Maintaining state and other information is not libxl's
work, it's the work of high level application. Libvirt does have datamodel
to keep tracking snapshot info, it doesn't need libxl to do that. xl can
maintain snapshot info in application level.

The only problem is snapshot-delete:
to delete disk snapshot, it has to call qmp command, libvirt libxl driver
cannot do that itself (except adding qmp related helper functions, quite
a duplicate with libxl_qmp.c I think).
If we supply libxl_domain_snapshot_delete API, to handle snapshot-chain
(parent, children, sibling), it doesn't work without info about all snapshots.
Or, if we supply libxl_disk_snapshot_delete API, that's also weird with this
only-one disk snapshot API.

>  
> Perhaps my understanding of the libvirt datamodel is incorrect or 
> incomplete, so please point out if this is the case. 
>  
> Ian. 
>  
>  
>  


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