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:
>>> should leave file intact if and only if the restore failed, and:
>>
>> The problem there is that you are changing the command behaviour.
>> The user may snapshot the disk separately and use this to implement
>> a simplified domain snapshot. Doing the remove may avoid troubles
>> for those not knowing what they are doing, but also break something
>> for those who know what they are doing.
>
> 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. Loading then looks for that bit,
and fails to restore an image with the bit set unless you pass a --force
option.
Of course, if the image is read-only, we can't mark the bit stating that
the image has been successfully restored, so the best we can do in that
case is just print a warning suggesting that since the restore is
successful, the user should remove the file.
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.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org