[libvirt] [PATCH v2 6/7] domain_lock: Implement metadata locking
Daniel P. Berrangé
berrange at redhat.com
Tue Aug 21 08:28:02 UTC 2018
On Mon, Aug 20, 2018 at 07:13:46PM +0200, Michal Prívozník wrote:
> On 08/20/2018 05:07 PM, Daniel P. Berrangé wrote:
> > On Tue, Aug 14, 2018 at 01:19:42PM +0200, Michal Privoznik wrote:
> >> In order for our drivers to lock resources for metadata change we
> >> need set of new APIs. Fortunately, we don't have to care about
> >> every possible device a domain can have. We care only about those
> >> which can live on a network filesystem and hence can be accessed
> >> by multiple daemons at the same time. These devices are covered
> >> in virDomainLockMetadataLock() and only a small fraction of
> >> those can be hotplugged (covered in the rest of the introduced
> >> APIs).
> >
> > I'm not sure I understand the rationale behind saying we only care
> > about resources on network filesystems.
> >
> > If I have 2 locally running guests, and both have a serial port
> > backed by a physical serial port, eg
> >
> > <serial type="dev">
> > <source path="/dev/ttyS0"/>
> > <target port="1"/>
> > </serial>
> >
> > we *do* care about locking /dev/ttyS0, as libvirtd isn't doing
> > mutual exclusion checks anywhere else for the /dev/ttyS0 device
> > node.
>
> Ah you mean that the system wide daemon and session daemon could clash
> when relabeling /dev/ttyS0? Well, we don't do relabeling for session
> daemons and running two system daemons is not supported (you're gonna
> hit more serious problems when trying that anyway).
We certainly *do* have relabelling for session daemons, for SELinux:
$ ls -alZ ~/VirtualMachines/demo.img
-rw-r--r--. 1 berrange berrange unconfined_u:object_r:virt_home_t:s0 1073741824 Aug 21 09:25 /home/berrange/VirtualMachines/demo.img
$ virsh uri
qemu:///session
$ virsh start QEMUGuest1
Domain QEMUGuest1 started
$ ls -alZ ~/VirtualMachines/demo.img
-rw-r--r--. 1 berrange berrange unconfined_u:object_r:svirt_image_t:s0:c310,c831 1073741824 Aug 21 09:25 /home/berrange/VirtualMachines/demo.img
but I was more thinking about the future where we have the libvirt shim
concept that allows starting & managing of QEMU processes independantly,
and libvirtd is merely there for aggregated data reporting. In that case
you'd have many instances of the security driver operating in parallel.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list
mailing list