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 ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
