[libvirt] RFC [3/3]: Lock manager usage scenarios

[Daniel P. Berrange]

On Mon, Sep 20, 2010 at 03:47:11AM -0400, Itamar Heim wrote:
> > From: libvir-list-bounces at redhat.com
> [mailto:libvir-list-bounces at redhat.com]
> > On Behalf Of Daniel P. Berrange
> ...
> > > Could containers make isolation exceptions for
> > > - shared storage devices?
> > > - shared /var/run/sync_manager/watchdog/ so that the system watchdog
> > >   could monitor all sync_manager instances?
> > 
> > Yes, resources (files) from the primary OS can be exposed in the
> > container on a case by case basis & potentially be visible inside
> > many containers. If we did a full virtual chroot setup, then the
> > container would only be able to see designated paths. It is also
> > possible to hide the containers chroot heirarchy from the host
> > completely. In any case, we can share paths between containers and
> > the host as needed.
> > 
> > A process inside the container would not be able to see any processes
> > outside the container. Processes outside can, however, see processes
> > inside the container, but its view of the PIDs will be different.
> > eg PID 1 inside the container may be PID 2345 outside.
> > 
> > The point I was trying to make, is that if the supervisor process
> > wants to connect back to a central lock daemon directly this might
> > run into trouble. If the supervisor process only needs to access
> > file resources on disk, it should be fine.
> [IH] how would Libvirt know to give security context to the leases area of
> the VM? it would be a different implementation per lock manager (say, I'd
> like to lock a row in a central remote db for this)?

That's easy enough to handle. If it is a shared lease file between all
VMs, then presumably that needs to be created ahead of time. SElinux
policy can defined a suitable default label, or the label can be set
as part of creation process. If there is a per-VM lease file that needs
the per-VM security context, then this can be specified as a config
parameter in the VM XML. If its a remote DB, then we don't need to care
about it.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|