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

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.