[libvirt] [PATCH 0/3 TCK] Some tests for snapshot management

[Eric Blake]

On 08/26/2011 09:03 AM, Daniel P. Berrange wrote:
>>> IMHO, we should be allowed to call 'virDomainDestroy' on a
>>> transient guest with snapshots, and then later 'virDomainCreateXML'
>>> to re-create the guest and still have access to the snapshots
>>
>> But leaving the snapshot metadata files behind is problematic.  If
>> you create a new domain with the same name but a different uuid,
>> then those existing metadata files _will_ cause problems with the
>> domain definition.
>
> Surely this simply means that the snapshot metadata files shold
> be recording the orignal domain UUID,

They are.  Even before my series, the original UUID was the _only_ thing 
about the domain that it was storing (my series fixes things to store 
the entire <domain> xml, which is needed for proper reversion to a 
snapshot, but at least old existing snapshots can already be recognized).

> so that we can safely
> ignore/discard them if the guest is re-defined with the same
> name but new uuid ?

We have two options for when to nuke stale metadata - at the point when 
the domain goes down, or at the point when a new domain is created whose 
name differs from what was stored in the stale metadata.

I guess you are leaning towards the latter - if a new domain is created 
with the right uuid, then the snapshots are already available; but if 
created with the same name but a new uuid, then we finally know to clean 
up the mess.

But I'm not convinced that it scales well - if you create lots of 
transient domains, all with snapshots, but never reuse the same name, 
then the metadata directory keeps growing without bounds even though you 
never have that many domains at any given point of time.  Besides, since 
the only way to use libvirt to delete snapshot metadata is via a 
virDomainSnapshotPtr object, but the only way to get at a snapshot is 
via a virDomainPtr object, I think it is risky to leave stale metadata 
in libvirt's directory trees that _cannot_ be removed by any existing 
libvirt API.

Cleaning at the time the transient domain goes away is nicer for 
scalability.  It means that nothing will be stored in 
/var/lib/libvirt/qemu/ unless it can also be accessed via a current 
virDomainPtr.  It is also nicer for migration - remember, in my RFC, I 
mentioned how snapshots and migration interact - the only sane way is 
for the destination to start from a blank state, then recreate the same 
snapshot hierarchy as was present on the source alongside the migration, 
then remove the snapshot metadata on the source.  If we keep snapshot 
metadata around even after a transient domain is no longer running on a 
host, then it becomes harder to start from a clean slate when migrating 
a new guest by that name onto the host.

>> If resurrecting previous snapshots is important, then it should be
>> done with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE.
>
> This is all workable, but is it overkill compared to just validating
> the original VM uuid against the new UUID when loading metdata ?

I hope that we can come to agreement on whether or not making the 
management app of the transient domain have to track snapshot metadata 
counts as overkill or not.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org