On Fri, Jan 03, 2020 at 14:08:03 +0000, Daniel Berrange wrote: > On Fri, Jan 03, 2020 at 02:56:50PM +0100, Gionatan Danti wrote: > > Il 03-01-2020 11:26 Daniel P. Berrangé ha scritto: [...] > > > There are some issues with libvirt's locking though where we haven't > > > always released/re-acquired locks at the correct time when dealing > > > with block jobs. As long as your not using snapshots, block rebase, > > > block mirror APIs, it'll be ok though. > > > > While I am not an heavy user of external snapshot and other block-related > > operation, I occasionally use them (and, in these cases, I found them very > > useful). > > > > Does it means that I should avoid relying on virtlockd for locking? Should I > > rely on Qemu locks only? > > As above, QEMU's locking is good enough to rely on for file based > images. > > The flaws I mention with libvirt might actually finally be something we > have fixed in 5.10.0 with QEMU 4.2.0, since we can finally use "blockdev" > syntax for configuring disks. Copying Peter to confirm/deny this... The main issue was that we were leaking locks on the backing chain. This should be now fixed with -blockdev as we call the appropriate apis to lock/unlock the images but I didn't try it with virtlockd. Certainly if there's still a problem now we have well defined places where we know what's happening to images so it should be easy to fix them. _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
