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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]