[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V6] Libxl Domain Snapshot API Design
On Tue, 2014-09-09 at 23:53 -0600, Chun Yan Liu wrote: > > 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. Great! I'm glad we are on the same page. > 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). What is this qmp command, what does it do and what arguments does it require? Perhaps it's something like "the snapshot chain of $disk may have changed, go and figure out what to do"? Or is it more complicated than that? > 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. So, the issue here is deleting a snapshot where there is an actively running domain using some other snapshot in the chain, is that right? Specifically we aren't interested in deleting a snapshot which is actually being used right now? Would that case be handled by destroying the domain in question first? So in the simplest case we might have: BASE -> SNAPSHOT A -> SNAPSHOT B And there may be a domain running which is using any of BASE, A or B? Do we then need to be able to delete either of the other two snapshots? If a domain is running using SNAPSHOT A then I presume SNAPSHOT B can be trivially deleted without needing to communicate with that domain. If a domain is running using SNAPSHOT B and we want to delete SNAPSHOT A then the domain needs to know that it should rescan the chain to discover that it is has become: BASE -> SNAPSHOT B Or is the qemu associated with the domain actually responsible for making that happen (i.e. folding the contents of SNAPSHOT A into either BASE or SNAPSHOT B as appropriate at runtime)? Or does that happen elsewhere? I think there are more complex cases with tree's of snapshots etc (e.g): ----- SNAPSHOT A ' ' BASE ----x , , ----- SNAPSHOT B But lets deal with the simple linear case first ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |