On Thu, Feb 02, 2017 at 12:09:07 +0000, Daniel Berrange wrote: > On Thu, Feb 02, 2017 at 01:05:17PM +0100, Peter Krempa wrote: > > On Thu, Feb 02, 2017 at 10:02:54 +0000, Daniel Berrange wrote: > > > On Thu, Feb 02, 2017 at 10:58:50AM +0100, Peter Krempa wrote: > > > > On Wed, Feb 01, 2017 at 18:11:28 +0000, Daniel Berrange wrote: > > > > > On Wed, Feb 01, 2017 at 07:04:54PM +0100, Peter Krempa wrote: > > > > > > On Wed, Feb 01, 2017 at 16:54:01 +0000, Daniel Berrange wrote: [...] > > Yes, if the block job finishes/fails while libvirtd is not running the > > file will remain locked forever. I still consider that a serious problem > > since you can't recover from that and the image stays locked. > > > > The tracking of the block job is still required though and we don't do > > that currently. > > > > > reliable while libvirtd is running that is good enough to let us enable > > > > Off topic: I'd rather not make "good enough" a sufficient measure for > > adding stuff to libvirt ... > > In general if libvirtd is not running, then all bets are off wrt to > management of VMs. We've made reasonable effort to clean up / fix > things but we've never said everything will work correctly if libvirtd > is stopped while key events occur. Also once we have the job tracking done, we can always unlock the image file once the block job vanishes after libvirtd restart. That way we won't ever leak the lock and qemu should not touch the file afterwards anyways. But we still need to unlock it regardless of how the job finished.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
