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@xxxxxxxxxx +1-919-301-3266 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