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@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 :|

On Mon, Jan 20, 2014 at 06:53:28PM +0100, Thierry Parmentelat 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 :-)

Yes, it already exists, albeit as a lxc specific custom command/api: $ virsh lxc-enter-namespace $CONTAINER /path/to/command/to/run arg1 arg2... There's a corresponding API in the libvirt-lxc.so library virDomainLxcEnterNamspace Eventually we'll turn this into a proper libvirt API with a less sucky virsh command name. 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 :|

Hi again So I did give this interesting lxc-enter-namespace feature a try I found a few glitches that I thought might be of interest; I recall that I use a stock f20 box which probably is already behind as compared to the devel version root@warhol ~/thierry # rpm -q libvirt libvirt-1.1.3.2-1.fc20.x86_64 So what I can see is that the exec’ed command seems to have a very limited PATH - if the feature is enabled at all: # virsh lxc-enter-namespace my-01 -- ls /etc/yum.repos.d/building.repo # virsh lxc-enter-namespace my-01 -- /usr/bin/ls /etc/yum.repos.d/building.repo /etc/yum.repos.d/building.repo So my comments are, - first that defining some even minimal PATH would help; - and second that in this first form, it would be great if virsh could write some error on stderr instead of being almost totally silent, it took me some time to figure that it kind of worked Does this mean we would lose any message sent on stderr ? — In the same conditions our own local tool would do this # lxcsu -ro my-01 -- ls /etc/yum.repos.d/building.repo /etc/yum.repos.d/building.repo Hope this helps — Thierry On 20 Jan 2014, at 19:03, Thierry Parmentelat <thierry.parmentelat@inria.fr> wrote:

Oh, I had totally failed to spot that one.. Thanks for the tip, I’ll give this a try :-)

On 20 Jan 2014, at 18:59, Daniel P. Berrange <berrange@redhat.com> wrote:

...

On Mon, Jan 20, 2014 at 06:53:28PM +0100, Thierry Parmentelat 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 :-)

Yes, it already exists, albeit as a lxc specific custom command/api:

$ virsh lxc-enter-namespace $CONTAINER /path/to/command/to/run arg1 arg2...

There's a corresponding API in the libvirt-lxc.so library virDomainLxcEnterNamspace

Eventually we'll turn this into a proper libvirt API with a less sucky virsh command name.

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 :|

...

So I did give this interesting lxc-enter-namespace feature a try

Thank you.

This is great, it solves my initial problem quite nicely, and I have given up on using my own tool :-)

...

So my comments are, - first that defining some even minimal PATH would help;

PATH relative to the container? Yes, that might be a nice addition; would you like to propose the means of passing that information through to the child?

Maybe I can describe my needs a little bit more Typically I need to run ‘make’ in the guest as part of its ‘preparation’ before I hand it over to users Unfortunately not all guests have the ‘make’ binary at the same location - esp. with the recent usrmove business… Actually what I am doing right now is to let bash handle that with virsh lxc-enter-namespace container /bin/bash -c “make -C /build” which fits my needs to not have to decide where make might sit This seems to work fine, although I am not sure to have covered all the corner cases yet --- This being said, this is fine as long as I use that in scripts, but having to do this in everyday life would be a hassle I am not sure that I see any good reason not to just call ‘execvp’ instead of ‘execv’ in cmdLxcEnterNamespace It is true that the PATH as set in the host might not be the best setting for the guest, but it could serve as a decent approximation for a daily usage

...

- and second that in this first form, it would be great if virsh could write some error on stderr instead of being almost totally silent, it took me some time to figure that it kind of worked Does this mean we would lose any message sent on stderr ?

No, stderr is preserved. But I have patches awaiting review that make the process nicer, including informing you of any non-zero exit status of the executed command: https://www.redhat.com/archives/libvir-list/2013-December/msg01247.html

This change would have been welcome during my very first attempt :-)

-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On Wed, Jan 22, 2014 at 05:35:27PM +0800, Gao feng wrote:

On 01/21/2014 01:59 AM, Daniel P. Berrange wrote:

...

On Mon, Jan 20, 2014 at 06:53:28PM +0100, Thierry Parmentelat 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 :-)

Yes, it already exists, albeit as a lxc specific custom command/api:

$ virsh lxc-enter-namespace $CONTAINER /path/to/command/to/run arg1 arg2...

There's a corresponding API in the libvirt-lxc.so library virDomainLxcEnterNamspace

Eventually we'll turn this into a proper libvirt API with a less sucky virsh command name.

Sorry for another question, lxc-enter-namespace is unavailable on the remote machine, you can't use virsh -c lxc+ssh://root@x.x.x.x/ lxc-enter-namespace $CONTAINER /path/to/command/to/run arg1 arg2.

I want to know what's the major handicap that we cannot support lxc-enter-namespace on remote machine.

That's just the way this command is designed to work. It uses setns() to directly move the command into the namespace, while preserving all aspects of its environment such as stdio/env variables/etc. If we wanted to make it work remotely, we'd have to setup some kind of I/O tunnelling, in which case you start to loose functionality - such as proper handling of terminal features like SIGWINCH That all said, I would like to see some kind of "execute" command in the libvirt API that worked remotely, albeit with some restrictions on its features as compared to lxc-enter-namespace. 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 :|