On 04/13/2012 03:15 PM, Jiri Denemark wrote:
>> Is there a reason for calling virDomainLockDiskDetach only
when SetImageLabel
>> fails and not calling it if mirroring itself fails?
>
> Simplicity of code - it's easier to code up permissions granting (and
> leaking that) then it is to figure out which permissions need to be
> reversed. I'll attempt to do a better job in v5, at least when
> mirroring fails. But revoking permissions after 'drive-reopen' is a
> bear - you can't do it immediately after the 'drive-reopen' command, but
But there's no drive-reopen involved here. We only issue drive-mirror command
that starts the process. And if it fails, i.e., we don't even start copying
data, we don't call virDomainLockDiskDetach to undo virDomainLockDiskAttach.
It's possible we don't need to call that because the file is unlinked in the
end, which is sufficient to remove the lock but I'm not sure and that's why
I'm asking :-)
I'm not sure whether virDomainSnapshotCreateXML shares the same bug, or
whether when I converted things over to the 'transaction' command if I
got it fixed. At any rate, you're right that I should at least clean up
this instance, since we know the failure path of drive-mirror is a lot
simpler than the success path of drive-reopen.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org