[Libvir] [RFC] 3 of 4 Linux Container support

[Daniel Veillard]

On Thu, Mar 20, 2008 at 02:43:28PM -0700, Dave Leskovec wrote:
> Daniel Veillard wrote:
> >  so it's restricted to root, it's probably fine, as we can go though the
> > daemon for normal users, ssuming they get authenticated.
> 
> Yes it's restricted to root.  That could be removed if file capabilities were
> set appropriately.  I'll look into how feasible that would be.
[...]
> >   so we can only list domains created by this libvirt instance, right ?
> > Or I'm missing something, I assume virsh list works but I don't see how.
> 
> Well, yes and no.  The list of vms is local to the process however all container
> configs are stored to file when they're created.  So, a later instance of
> libvirt (later being after a container is created) will pick up the config file
> and know about that container.  However, if 2 instances of libvirt are running
> and one creates a container, the other won't know about it until it's restarted
> or reconnected.  This and a few related issues have been sticking in the back of
> my mind for a little while.  I'm wondering if the solution isn't to have the lxc
> driver under libvirtd.  That or load and unload the list of vms around every
> operation.

  It's probably a good option, at least as a first step, maybe a separate
daemon may be needed to keep persistance of runtime data like the open
file descriptors (admitedly I didn't yet tried to digest all the technical
description in part 4). Repetitive load/unload is not acceptable I'm afraid,
we should aim at lightweight virtualization for containers, let's not start
multiplicating I/O access on operations, we have enough pain with the xend
side. Another important feature is not loosing state or data (like file
descriptors for console and the like) when libvirtd is stopped and restarted.
That probably mean we should be able to list running process associated
to containers (if possible in a lightweight fashion). 
  It may take a bit of time to find the right solutions, the good thing
is that we are completely isolated by the API, and as long as the 
support for containers is not declared stable, I'm fine changing some
of the implementation details even if it means a bit of pain during
libvirt details. I'm a believer in pushing code out and refining it based
on feedback :-)

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/