On Fri, Aug 26, 2011 at 09:15:43AM -0600, Eric Blake wrote: > 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. I don't have a strong feeling on it, as long as we have a way to get back the snapshots when recreating a transient guest. So lets go with your suggestion. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list