[libvirt] [PATCH] qemu: Do not unlink managedsave image if restoring fails.

[Osier Yang]

于 2011年04月06日 22:21, Eric Blake 写道:
> 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.

Agree

>>    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.

Agree

>
> 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.
>

Sounds a good idea, but doesn't it also breaks the behaviour? it means
all the apps need to introduce a new flag then if I understand your
meaning right.

> 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.

I'm thinking:

1) don't change the behaviour, which means won't try to remove the state
file when restoring succeeded.
2) VIR_WARN to tell user the state file should be removed once the
restoring succeeded.
3) Update docs to tell the state file should be remove once the
restoring succeeded.

Regards
Osier