Oh, and I was about to forget..
The system I am talking about is PlanetLab, that we now manage with libvirt/lxc instead of
the old vserver-based stuff (although the public testbed still is vastly vserver-based)
And in that context too, it’s much more efficient for us to plug an incoming ssh request
inside the host to a simple fork that runs in the container context, instead of relying
here again on ssh to reach the container..
My $0.02 — thanks again — Thierry
On 20 Jan 2014, at 18:53, Thierry Parmentelat <thierry.parmentelat(a)inria.fr> wrote:
Hi
Well if I need to run anything in the container context, short of entering it through
e.g. ssh - hoping this is properly set up - well, I can’t..
I am using libvirt / lxc to set up a build box; essentially every night I would spawn a
set of fresh VMs of some flavours (fedora18, ubuntu, what not) and use this to rebuild my
system from scratch
In this context it’s a real hassle to have to even set up ssh, there is no good reason
for the build VM to run an ssh service at all, and I am concerned it might pull
dependencies that I do not need/want
I’d much rather have a direct means to just run some command inside the container.
Admittedly I’m brain-damaged after having used vservers for too long, and their ‘vserver
<container> exec command to run’ feature is in my genes now ;)
Now maybe I am the one who is missing something and there already is something to do that
?
Using the trick below I essentially have what I need mind you, I’m just concerned that it
kind of works by accident :-)
Thanks for the feedback in any case — Thierry
On 20 Jan 2014, at 12:49, Daniel P. Berrange <berrange(a)redhat.com> wrote:
> On Mon, Jan 20, 2014 at 11:38:08AM +0100, Thierry Parmentelat wrote:
>> Hello there
>>
>> I am trying to locate the namespaces in place for a given lxc container
(specifically /proc/<pid>/ns/*)
>>
>> And to this end I was wondering what is the recommended way to probe for an lxc
container's init pid
>> (mostly I'm after the mnt and pid namespaces, and probably network ones, but
the actual list probably should not matter)
>>
>> I've found about "virsh domid" but this gives me the pid for
libvirt_lxc, which turns out to have unmodified namespaces (at least as far as the mnt
ns)
>> OTOH this process has exactly one child which is the container's init, which
seems to have the right set of namespaces
>>
>> My angle right now is to look in /proc/<domid_pid>/task/children for a -
hopefully single - pid and
>> that seems to work for now, but I am concerned this code may be fragile so I
would rather use a more
>> robust approach; or maybe this is robust ?
>
> We don't really wish to expose the container PIDs to the host or namespace
> details to client apps. Can you give more info about what you're trying to
> achieve overall. I'd like to understand if there's some higher level API
> we're missing that would more directly address your needs.
>
>
> 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 :|