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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/