[libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org