On Wed, Apr 06, 2011 at 08:21:56AM -0600, Eric Blake wrote: > On 04/06/2011 06:51 AM, Daniel Veillard wrote: > > On Wed, Apr 06, 2011 at 05:02:36PM +0800, Osier Yang wrote: > >> ä 2011å04æ06æ 16:50, Daniel Veillard åé: > >>> On Tue, Apr 05, 2011 at 08:55:01AM -0600, Eric Blake wrote: > >> Somehow this is true, but as we have API and virsh commands > >> for snapshot specificly, is it fine to make a change on the virsh > >> manual to tell the user about we remove the state file if restoring > >> succeeded? I did that when doing v3 patch, :-) > > > > Still that can be considered a regression, that behaviour is the > > same since the introduction of the API years ago, we can't change it now > > just because we think it's cool. > > Document the fact that in general once the restore suceeded the > > file should be removed since the data are unlikely to be reusable > > without loss of integrity, but you can't change the behaviour. > > What about this proposal, for being less severe? If we can open the > file read-write, then we modify it on a successful restore to change a > bit to mark that the image is suspect. technically the beginning of the image is an XML dump of the domain if I remember correctly, we could try to do something smart in there to do the detection. > Loading then looks for that bit, > and fails to restore an image with the bit set unless you pass a --force > option. That's still a regression, existing code using for example the LVM for snapshot independantly of our API will still break. > But I agree that since we have already got releases in the wild that do > not delete the file, that we cannot change behavior to delete it at this > point. Same for being able to restore, as there are legitimate uses. I would be okay for a warning to be emitted if we detect a subsequent restore but we cannot make the operation to fail by default in my opinion. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list