Re: RFCv2: virDomainSnapshotCreateXML enhancements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]