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

Re: [libvirt] [PATCH] qemu: turn on virtlockd by default



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:
> 
> [..]
> 
> > > We can and we do, the problem is only if libvirt would not run at that
> > > point, when it's hard to re-detect what's happening. We also don't track
> > > which job we've started for non-active commit and block pull and thus
> > > can't infer from the backing chain which was dropped.
> > > 
> > > > contain enough info to correlate back to libvirt's record of the job.
> > > 
> > > Well it won't be that hard to fix for the active case. We need to track
> > > the backing chain fully anyways. The problem only remains in case when
> > > we need to infer whether it was or wasn't successful if we missed the
> > > event.
> > > 
> > > I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1405537 a while
> > > ago so that I don't forget about this issue.
> > > 
> > > I'm currently working on the support for blockdev-add and friends so
> > > this work will be somewhat relevant to that. I'll let you know once all
> > > known locking issues are resolved.
> > 
> > So based on the above we only have a show stopper problem if libvirtd
> > is restarted while a job is running. IMHO if we can make job handling
> 
> 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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|


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