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

Daniel P. Berrange berrange at redhat.com
Tue Jan 26 14:35:29 UTC 2016


On Tue, Jan 26, 2016 at 01:47:02PM +0000, Daniel P. Berrange wrote:
> On Tue, Jan 26, 2016 at 02:28:56PM +0100, Ján Tomko wrote:
> > On Fri, Jan 22, 2016 at 03:56:08PM +0000, Daniel P. Berrange wrote:
> > > We have had virtlockd available for a long time now but
> > > have always defaulted to the 'nop' lock driver which does
> > > no locking. This gives users an unsafe deployment by
> > > default unless they know to turn on lockd.
> > 
> > Does the default setup of virtlockd offer any safety?
> > 
> > After looking at:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1191802
> > It seems that with dynamic_ownership enabled we first apply
> > the security labels, then check the disk locks by calling
> > virDomainLockProcessResume right before starting the CPUs
> > in virDomainLockProcessResume. After that fails, resetting
> > the uid:gid back to root:root cuts off the access to the disk
> > for the already running domain.
> > 
> > Is there a reason why the locks are checked so late?
> > 
> > I assume this only ever worked for the case of migration with
> > shared storage (and shared lockspace).
> 
> NB, the virtlockd integration is intended to protect the
> *content* of the disk image from being written to by two
> processes at once.
> 
> Protecting the image metadata not a goal, since that is
> something that should be dealt with by the security drivers.
> ie the security driver should be acquiring suitable locks of
> its own so that it does not block away in-use labels for other
> VMs. We've had patches floating around for the security drivers
> for a while, but never got as far as merging them yet.

Having said all that, I wonder if we should actually *not* turn
on virtlockd, until we have addressed the problem in the security
driver. Without the latter fix, it seems we'll get a never ending
stream of bug reports about this issue.


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




More information about the libvir-list mailing list