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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/