On 3/12/19 7:57 AM, Ján Tomko wrote:
> On Mon, Mar 11, 2019 at 09:38:32PM -0500, Eric Blake wrote:
>> Right now, copying the state of a transient domain with snapshots from
>> one host to another requires multiple API calls on both machines - on
>> the host: get the domain XML, get a list of the snapshots, and then
>> for each snapshot get the snapshot's XML; then on the destination:
>> create the domain, then multiple domain snapshot create calls (must
>> be in topological order) with the REDEFINE flag. This patch aims to
>> make the process use fewer APIs by making it possible to grab the XML
>> for all snapshots at once on the source, then redefine from that same
>> list at the destination. In fact, although it is easy to match recent
>> changes to allow output in topological order, it is also easy to do
>> bulk redefine in arbitrary order.
>>
>> Consideration was given to adding a flag to existing APIs; but to do
>> that, there would be an asymmetry of dumping <snapshots> as a
>> sub-element of <domain> during virDomainGetXMLDesc(), vs. redefining
>> <snapshots> as a top-level element (and different than the normal
>> top-level element) of virDomainSnapshotCreateXML(). Thus, it is
>> cleaner to have two new APIs:
>>
>> virDomainGetSnapshotsXMLDesc
>> virDomainImportSnapshotsXML
> 
> These do not share a common prefix, but that makes them look nicer IMO.

In particular, they do NOT have the virDomainSnapshot prefix, which
means I don't have to special-case them in the python generator :)

> 
>>
>> Signed-off-by: Eric Blake <ebl...@redhat.com>
>> ---
>> include/libvirt/libvirt-domain-snapshot.h |  16 ++-
>> src/driver-hypervisor.h                   |  13 ++-
>> src/libvirt-domain-snapshot.c             | 122 +++++++++++++++++++++-
>> src/libvirt_public.syms                   |   2 +
>> 4 files changed, 148 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/libvirt/libvirt-domain-snapshot.h
>> b/include/libvirt/libvirt-domain-snapshot.h
>> index 602e5def59..7c2e001b87 100644
>> --- a/include/libvirt/libvirt-domain-snapshot.h
>> +++ b/include/libvirt/libvirt-domain-snapshot.h
>> @@ -3,7 +3,7 @@
>>  * Summary: APIs for management of domain snapshots
>>  * Description: Provides APIs for the management of domain snapshots
>>  *
>> - * Copyright (C) 2006-2014 Red Hat, Inc.
>> + * Copyright (C) 2006-2019 Red Hat, Inc.
> 
> Do we actually care about updating these?

I have an emacs hook that prompts me to auto-update on files I touch. I
know we haven't been insistent on keeping things up-to-date, but I also
don't think it hurts.

> But an include file will possibly be read by people without git access.

Yeah, especially for public-facing files, having a reliable year in
there might matter (although these days, I hope that any court
litigating a copyright claim against open source would be smart enough
to rely more on version control history than any thing in the file under
question).


>> + *
>> + * Returns a count of snapshots imported on success, or -1 on failure.
> 
> This says nothing about partial success, i.e. whether the count returned
> can be different from the number of snapshots present in the file.

Partial success is not possible; it's an all-or-none return. But I can
try to tweak that wording to make it clearer.

>> /**
>>  * virDomainSnapshotGetXMLDesc:
>>  * @snapshot: a domain snapshot object
>> @@ -254,8 +314,8 @@ virDomainSnapshotCreateXML(virDomainPtr domain,
>>  * VIR_DOMAIN_SNAPSHOT_XML_SECURE; this flag is rejected on read-only
>>  * connections.
>>  *
>> - * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case
>> of error.
>> - *         the caller must free() the returned value.
>> + * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case
>> + * of error.  The caller must free() the returned value.
> 
> Unrelated change.

Noticed while copy-and-pasting. If needed, I can split it out as a
trivial patch.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to