Re: [libvirt] RFCv2: virDomainSnapshotCreateXML enhancements
On 08/12/2011 08:33 AM, Eric Blake wrote:
On 08/11/2011 08:36 PM, Eric Blake wrote:
> In implementing this in virsh, I found that for backwards compatibility
> reasons, it would be easier to two flags instead of one, since both use
> cases seem plausible (do the bare minimum to remove my domain, but
> wihtout losing snapshot data, vs. nuke everything including my snapshot
> data that was associated with the domain). Hence I'm modifying this
> slightly to be:
>
> VIR_DOMAIN_UNDEFINE_SNAPSHOTS_FULL -> maps to
> virDomainSnapshotDelete(,0), can be emulated on older servers
> VIR_DOMAIN_UNDEFINE_SNAPSHOTS_METADATA -> maps to
> virDomainSnapshotDelete(,VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY),
> cannot be simulated with server older than 0.9.5
And to make it easier to detect whether a domain has libvirt snapshot
metadata, I need to add:
virDomainSnapshotNum(,VIR_DOMAIN_SNAPSHOT_NUM_METADATA)
Other parts of this RFC talk about refusing to revert to a snapshot if
any of its descendants are an external disk-snapshot. I'm thinking it
would be nice to make it easier to expose a list of descendants of a
given snapshot; this can be emulated at the application layer but can be
much faster if done in libvirt. I have two approaches:
1. Reuse the existing API - right now, virDomainSnapshotList is
output-only. Implementing this would involve making a new RPC, and
special casing the remote code to call one of two different RPC's based
on whether either of two new flags are present.
virDomainSnapshotList(domain, names, nameslen, 0) => names is
output-only, nameslen is max array len on input, return value is actual
return size or -1 on error, and use the old RPC to list all snapshots
virDomainSnapshotList(domain, names, nameslen,
VIR_DOMAIN_SNAPSHOT_LIST_CHILDREN) => names is in/out: names[0] is the
name of the parent snapshot to start listing from, or NULL to start
listing from the current snapshot (if any), and output is the immediate
children (if any) of the designated snapshot; nameslen is used the same,
and pessimistically has to be set to virDomainSnapshotNum on input; use
the new RPC to pass in a single name
virDomainSnapshotList(domain, names, nameslen,
VIR_DOMAIN_SNAPSHOT_LIST_DESCENDANTS) => like LIST_CHILDREN in treatment
of names[0] of where to start and use of new rpc, but result is
transitive closure of all descendants rather than just direct children
2. Abandon any idea about back-porting this, and just add it for 0.9.5
and later by adding two new functions and one new flag:
int virDomainSnapshotNumChildren(virDomainSnapshotPtr snapshot, unsigned
int flags);
int virDomainSnapshotListChildren(virDomainSnapshotPtr snapshot, char
**names, int nameslen, unsigned int flags);
virDomainSnapshotNumChildren(snap, flags) is a much finer bound on the
maximum array size needed by virDomainSnapshotListChildren with the same
flags; snap may be NULL to use current snapshot (if any)
virDomainSnapshotListChildren(snap, names, nameslen, 0) lists direct
children of snap; snap may be NULL to use current
virDomainSnapshotListChildren(snap, names, nameslen,
VIR_DOMAIN_SNAPSHOT_LIST_DESCENDANTS) lists all descendants of snap
Thoughts on which approach is nicer (rpc hacks vs. new API)?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org