container console access #1129

Open
jsimonetti opened this Issue Sep 23, 2015 · 22 comments

Projects

None yet

10 participants

@jsimonetti
Contributor

Currently there is no way to connect to the console of a container using lxd/lxc.
The lxc-console command from lxc-tools works on lxd locally started containers if you add the -P parameter to point to /var/lib/lxd/containers.
It would be awesome if lxd would allow acces to a containers' console or tty over the network.

lxc attach remote:containername <console|ttyX>

Or something similar...

Are there any plans to do this, and if so is there allready a specification for it?

@stgraber
Member

There are currently no plans for it. Most LXD images actually don't spawn gettys whenever possible to save pts devices and cpu/memory resources.

It's also not a concept which maps particularly well across different operating systems so the API design for this may be tricky.

So it's not out of the question that we'd grow support for attaching to /dev/console (probably not for the other ttys though as we don't even set those up at all with LXD) but we'd need a very good use case for this feature that can't be covered with exec.

@jsimonetti
Contributor

Wel, the only reasonable use case would be to troubleshoot container startup and shutdown issues or tot centrally serve up consoles like the VPS providers do.
When playing around with lxc-console today I noticed soms shutdown errors (umount failing, which is totally expectable).
I would not have known about those if I didn't have the console output.
I wanted to see if I could use vncterm to serve the container console to a vnc client. Which actually worked pretty nice.
If lxc would have a console command, you could then use one central point to serve up all consoles instead of individually on each host.

Other then these I have nog found a usecase yet.

@stgraber stgraber added this to the later milestone Sep 28, 2015
@srkunze
Contributor
srkunze commented Dec 11, 2015

Couldn't this be customized by using aliases like: #1395

@jsimonetti
Contributor

An alias to execute a shell inside the container namespace is not the same as actual console access using /dev/console.

I dont like the console name in the alias example as it is very different. 'shell' would be a better name.

@srkunze
Contributor
srkunze commented Dec 11, 2015

Seems like the denominations 'shell', 'console' and 'terminal' are blurring.

@stgraber stgraber added the API label Apr 27, 2016
@candlerb

I have a use case for this: a virtual networking lab, where lxd containers are routers and/or simulated end-user PCs.

You want to provide the students with out-of-band access to each container so that they can configure its network interfaces and debug problems.

If vncterm works, that may actually be a better solution.

@candlerb

I have been trying this out further. I am using Ubuntu 14.04 with the lxd PPA (deb http://ppa.launchpad.net/ubuntu-lxc/lxd-stable/ubuntu trusty main)

lxc-console

i.e. access to emulated serial console.

lxc-console -P as described above didn't work. It took me a while to work out that you also have to provide the -t 0 flag, after which it's fine:

# lxc list
+--------+---------+--------------------------------+------+------------+-----------+
|  NAME  |  STATE  |              IPV4              | IPV6 |    TYPE    | SNAPSHOTS |
+--------+---------+--------------------------------+------+------------+-----------+
| centos | RUNNING |                                |      | PERSISTENT | 0         |
+--------+---------+--------------------------------+------+------------+-----------+
| xenial | RUNNING | 10.10.0.159 (eth0)             |      | PERSISTENT | 0         |
|        |         | 10.69.255.106 (eth1)           |      |            |           |
+--------+---------+--------------------------------+------+------------+-----------+
# lxc-console -n xenial -P /var/lib/lxd/containers -t 0

Connected to tty 0
Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Ubuntu Xenial Xerus (development branch) xenial console

xenial login:

It would indeed be very nice if lxd could support this. (Redirecting a character stream over HTTP perhaps would be best done with websockets?)

Aside: inside the container, I can see there is a single getty process running.

root       535  0.0  0.0  15668   940 console  Ss+  07:45   0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 linux

In the old lxc, apparently you could set lxc.tty to get more ttys. But I can't see a corresponding setting for lxd profiles. Is it possible?

vncterm

i.e. access to emulated text console: a memory buffer of NxM characters.

In ubuntu, I believe this is the tool 'linuxvnc' from the package also called 'linuxvnc'.

@jsimonetti: how did you get this to work?

Running directly on the outer host it's fine: linuxvnc 1 will open /dev/tty1 and /dev/vcs1 or /dev/vcsa1 and mirrors the host's own text virtual console.

But inside a guest lxd container, there are no /dev/tty<N> (only /dev/tty) and no /dev/vcs*

As far as I can tell, even if I were able to set lxc.tty this would create only PTYs (effectively serial consoles, not screen buffers)

Also, for my purposes I would need to run linuxvnc on the host and attach it to the console in the guest. This is so that linuxvnc uses a port on the host's own IP address, and is reachable even if the guest's networking is broken. (If the guest had sufficient networking to run linuxvnc inside it, then I could just as well ssh into the guest)

Unfortunately, I can't see any way to use vncterm to share anything other than one of the host's own virtual consoles.

@candlerb

And of course,

lxc exec xenial /bin/bash

is something completely different - it's just running a command directly inside the container and exposing its stdin/stdout to the client.

I don't have a two-host test rig so I haven't found out if this works interactively to a remote host or not.

@hallyn
Member
hallyn commented Apr 28, 2016

lxc exec xenial /bin/bash


is something completely different - it's just running a command directly inside the container and exposing its stdin/stdout to the client.

I don't have a two-host test rig so I haven't found out if this works interactively to a remote host or not.

lxc exec works remotely.

@candlerb

Thanks - I see that now. In that case, most of what's needed for a remote console is probably already there; but I suspect most people will be happy just to have remote exec.

@jsimonetti
Contributor

Iirc I used vncterm from Proxmox (https://git.proxmox.com/?p=vncterm.git;a=summary), which has some heavy modifications. It still needs to be run on the host though.

Op 28 apr. 2016 12:56, bij 12:56, Brian Candler notifications@github.com schreef:

I have been trying this out further. I am using Ubuntu 14.04 with the
lxd PPA (deb http://ppa.launchpad.net/ubuntu-lxc/lxd-stable/ubuntu trusty main)

lxc-console

i.e. access to emulated serial console.

lxc-console -P as described above didn't work. It took me a while to
work out that you also have to provide the -t
0

flag, after which it's fine:

# lxc list
+--------+---------+--------------------------------+------+------------+-----------+
|  NAME  |  STATE  |              IPV4              | IPV6 |    TYPE   
| SNAPSHOTS |
+--------+---------+--------------------------------+------+------------+-----------+
| centos | RUNNING |                                |      | PERSISTENT
| 0         |
+--------+---------+--------------------------------+------+------------+-----------+
| xenial | RUNNING | 10.10.0.159 (eth0)             |      | PERSISTENT
| 0         |
|        |         | 10.69.255.106 (eth1)           |      |           
|           |
+--------+---------+--------------------------------+------+------------+-----------+
# lxc-console -n xenial -P /var/lib/lxd/containers -t 0

Connected to tty 0
Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a
itself

Ubuntu Xenial Xerus (development branch) xenial console

xenial login:

It would indeed be very nice if lxd could support this. (Redirecting a
character stream over HTTP perhaps would be best done with websockets?)

Aside: inside the container, I can see there is a single getty process
running.

root       535  0.0  0.0  15668   940 console  Ss+  07:45   0:00
/sbin/agetty --noclear --keep-baud console 115200 38400 9600 linux

In the old lxc, apparently you could set
lxc.tty
to get more ttys. But I can't see a corresponding setting for lxd
profiles
.
Is it possible?

vncterm

i.e. access to emulated text console: a memory buffer of NxM
characters.

In ubuntu, I believe this is the tool 'linuxvnc' from the package also
called 'linuxvnc'.

@jsimonetti: how did you get this to work?

Running directly on the outer host it's fine: linuxvnc 1 will open
/dev/tty1 and /dev/vcs1 or /dev/vcsa1 and mirrors the host's own
text virtual console.

But inside a guest lxd container, there are no /dev/tty<N> (only
/dev/tty) and no /dev/vcs*

As far as I can tell, even if I were able to set lxc.tty this would
create only PTYs (effectively serial consoles, not screen buffers)

Also, for my purposes I would need to run linuxvnc on the host and
attach it to the console in the guest. This is so that linuxvnc uses
a port on the host's own IP address, and is reachable even if the
guest's networking is broken. (If the guest had sufficient networking
to run linuxvnc inside it, then I could just as well ssh into the
guest)

Unfortunately, I can't see any way to use vncterm to share anything
other than one of the host's own virtual consoles.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1129 (comment)

@stgraber stgraber added the Maybe label Jul 5, 2016
@naisanza
Contributor
naisanza commented Aug 8, 2016

The use case for this would be to extend the claims of being "just like virtual machines"

Since, in its current state, it's not quite like a virtual machine, and LXD covers maybe only half the use cases for VMs (such as running non-gui services), but it doesn't cover things such as certain types of analysis and research, and user desktop sessions

@srkunze
Contributor
srkunze commented Aug 8, 2016 edited

certain types of analysis and research

Could you be more specific on that?

user desktop sessions

Impossible right now with the current infrastructure?
And if this work can be done via more code, should this code reside in LXD?

@naisanza
Contributor
naisanza commented Aug 9, 2016

@srkunze I'll have to followup with more details, but for the user desktop sessions, something along the lines of:

  1. Create container
  2. apt install desktop-environment
  3. SSH with X11 forwarding
  4. Run desktop-session

Currently, that isn't possible(?), but I would love to be completely wrong about that

@srkunze
Contributor
srkunze commented Aug 15, 2016

@stgraber Is this possible?

@stgraber
Member

Console access wouldn't help you at all to run a desktop inside a container as what we've been calling console access here is about a tty, so a text-only interface.

To run a desktop inside a container you either need a privileged container with a bunch of bind-mounts to have raw access to the host tty devices, dri kernel interface and any GPU endpoint (for nvidia/amd ones).

Or you need to run the X server outside the container on the host and then pass /tmp/.X11-unix to the container as a bind-mount and tweak the X ACL on the host to allow connections from within the container (if you don't care "xhost +" disables all ACLs).

@srkunze
Contributor
srkunze commented Aug 15, 2016

Some resources (from docker): https://blog.docker.com/2013/07/docker-desktop-your-desktop-over-ssh-running-inside-of-a-docker-container/

They use xpra.

@naisanza Does this help somehow?

@stgraber Is it worth making this easier for LXD users?

@stgraber
Member

We've been trying to keep LXD pretty generic as far as the OS it runs on as Linux isn't the only platform that supports containers. Now that there also are several display managers on Linux alone, I really wouldn't want to have any of this show up in the LXD API.

There is also the small snag that this will effectively only work on machines where the LXD client and daemon are on the same box, which would further reduce its use.

Especially as running X applications (including a full desktop if you so wish) is pretty straightforward:

stgraber@dakara:~$ lxc launch ubuntu:16.04 test -c environment.DISPLAY=${DISPLAY}
Creating test
Starting test

stgraber@dakara:~$ lxc config device add test x disk source=/tmp/.X11-unix/ path=/tmp/.X11-unix/
Device x added to test

stgraber@dakara:~$ xhost +
access control disabled, clients can connect from any host

stgraber@dakara:~$ lxc exec test -- apt install x11-apps -y
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  fontconfig-config fonts-dejavu-core libfontconfig1 libfreetype6 libice6
  libsm6 libxaw7 libxcursor1 libxfixes3 libxft2 libxkbfile1 libxmu6 libxpm4
  libxrender1 libxt6 x11-common xbitmaps
Suggested packages:
  mesa-utils
The following NEW packages will be installed:
  fontconfig-config fonts-dejavu-core libfontconfig1 libfreetype6 libice6
  libsm6 libxaw7 libxcursor1 libxfixes3 libxft2 libxkbfile1 libxmu6 libxpm4
  libxrender1 libxt6 x11-apps x11-common xbitmaps
0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded.
Need to get 2831 kB of archives.
After this operation, 9540 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu xenial/main amd64 x11-common all 1:7.7+13ubuntu3 [22.4 kB]
Get:2 http://archive.ubuntu.com/ubuntu xenial/main amd64 libice6 amd64 2:1.0.9-1 [39.2 kB]
Get:3 http://archive.ubuntu.com/ubuntu xenial/main amd64 libsm6 amd64 2:1.2.2-1 [15.8 kB]
Get:4 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxfixes3 amd64 1:5.0.1-2 [11.1 kB]
Get:5 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxrender1 amd64 1:0.9.9-0ubuntu1 [18.5 kB]
Get:6 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxcursor1 amd64 1:1.1.14-1 [22.8 kB]
Get:7 http://archive.ubuntu.com/ubuntu xenial/main amd64 fonts-dejavu-core all 2.35-1 [1039 kB]
Get:8 http://archive.ubuntu.com/ubuntu xenial/main amd64 fontconfig-config all 2.11.94-0ubuntu1 [49.9 kB]
Get:9 http://archive.ubuntu.com/ubuntu xenial/main amd64 libfreetype6 amd64 2.6.1-0.1ubuntu2 [316 kB]
Get:10 http://archive.ubuntu.com/ubuntu xenial/main amd64 libfontconfig1 amd64 2.11.94-0ubuntu1 [131 kB]
Get:11 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxft2 amd64 2.3.2-1 [36.1 kB]
Get:12 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxpm4 amd64 1:3.5.11-1 [33.1 kB]
Get:13 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxt6 amd64 1:1.1.5-0ubuntu1 [160 kB]
Get:14 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxmu6 amd64 2:1.1.2-2 [46.0 kB]
Get:15 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxaw7 amd64 2:1.0.13-1 [173 kB]
Get:16 http://archive.ubuntu.com/ubuntu xenial/main amd64 libxkbfile1 amd64 1:1.0.9-0ubuntu1 [65.1 kB]
Get:17 http://archive.ubuntu.com/ubuntu xenial/main amd64 x11-apps amd64 7.7+5+nmu1ubuntu1 [624 kB]
Get:18 http://archive.ubuntu.com/ubuntu xenial/main amd64 xbitmaps all 1.1.1-2 [28.1 kB]
Fetched 2831 kB in 0s (21.9 MB/s)
Selecting previously unselected package x11-common.
(Reading database ... 25429 files and directories currently installed.)
Preparing to unpack .../x11-common_1%3a7.7+13ubuntu3_all.deb ...
Unpacking x11-common (1:7.7+13ubuntu3) ...
Selecting previously unselected package libice6:amd64.
Preparing to unpack .../libice6_2%3a1.0.9-1_amd64.deb ...
Unpacking libice6:amd64 (2:1.0.9-1) ...
Selecting previously unselected package libsm6:amd64.
Preparing to unpack .../libsm6_2%3a1.2.2-1_amd64.deb ...
Unpacking libsm6:amd64 (2:1.2.2-1) ...
Selecting previously unselected package libxfixes3:amd64.
Preparing to unpack .../libxfixes3_1%3a5.0.1-2_amd64.deb ...
Unpacking libxfixes3:amd64 (1:5.0.1-2) ...
Selecting previously unselected package libxrender1:amd64.
Preparing to unpack .../libxrender1_1%3a0.9.9-0ubuntu1_amd64.deb ...
Unpacking libxrender1:amd64 (1:0.9.9-0ubuntu1) ...
Selecting previously unselected package libxcursor1:amd64.
Preparing to unpack .../libxcursor1_1%3a1.1.14-1_amd64.deb ...
Unpacking libxcursor1:amd64 (1:1.1.14-1) ...
Selecting previously unselected package fonts-dejavu-core.
Preparing to unpack .../fonts-dejavu-core_2.35-1_all.deb ...
Unpacking fonts-dejavu-core (2.35-1) ...
Selecting previously unselected package fontconfig-config.
Preparing to unpack .../fontconfig-config_2.11.94-0ubuntu1_all.deb ...
Unpacking fontconfig-config (2.11.94-0ubuntu1) ...
Selecting previously unselected package libfreetype6:amd64.
Preparing to unpack .../libfreetype6_2.6.1-0.1ubuntu2_amd64.deb ...
Unpacking libfreetype6:amd64 (2.6.1-0.1ubuntu2) ...
Selecting previously unselected package libfontconfig1:amd64.
Preparing to unpack .../libfontconfig1_2.11.94-0ubuntu1_amd64.deb ...
Unpacking libfontconfig1:amd64 (2.11.94-0ubuntu1) ...
Selecting previously unselected package libxft2:amd64.
Preparing to unpack .../libxft2_2.3.2-1_amd64.deb ...
Unpacking libxft2:amd64 (2.3.2-1) ...
Selecting previously unselected package libxpm4:amd64.
Preparing to unpack .../libxpm4_1%3a3.5.11-1_amd64.deb ...
Unpacking libxpm4:amd64 (1:3.5.11-1) ...
Selecting previously unselected package libxt6:amd64.
Preparing to unpack .../libxt6_1%3a1.1.5-0ubuntu1_amd64.deb ...
Unpacking libxt6:amd64 (1:1.1.5-0ubuntu1) ...
Selecting previously unselected package libxmu6:amd64.
Preparing to unpack .../libxmu6_2%3a1.1.2-2_amd64.deb ...
Unpacking libxmu6:amd64 (2:1.1.2-2) ...
Selecting previously unselected package libxaw7:amd64.
Preparing to unpack .../libxaw7_2%3a1.0.13-1_amd64.deb ...
Unpacking libxaw7:amd64 (2:1.0.13-1) ...
Selecting previously unselected package libxkbfile1:amd64.
Preparing to unpack .../libxkbfile1_1%3a1.0.9-0ubuntu1_amd64.deb ...
Unpacking libxkbfile1:amd64 (1:1.0.9-0ubuntu1) ...
Selecting previously unselected package x11-apps.
Preparing to unpack .../x11-apps_7.7+5+nmu1ubuntu1_amd64.deb ...
Unpacking x11-apps (7.7+5+nmu1ubuntu1) ...
Selecting previously unselected package xbitmaps.
Preparing to unpack .../xbitmaps_1.1.1-2_all.deb ...
Unpacking xbitmaps (1.1.1-2) ...
Processing triggers for systemd (229-4ubuntu7) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Setting up x11-common (1:7.7+13ubuntu3) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Setting up libice6:amd64 (2:1.0.9-1) ...
Setting up libsm6:amd64 (2:1.2.2-1) ...
Setting up libxfixes3:amd64 (1:5.0.1-2) ...
Setting up libxrender1:amd64 (1:0.9.9-0ubuntu1) ...
Setting up libxcursor1:amd64 (1:1.1.14-1) ...
Setting up fonts-dejavu-core (2.35-1) ...
Setting up fontconfig-config (2.11.94-0ubuntu1) ...
Setting up libfreetype6:amd64 (2.6.1-0.1ubuntu2) ...
Setting up libfontconfig1:amd64 (2.11.94-0ubuntu1) ...
Setting up libxft2:amd64 (2.3.2-1) ...
Setting up libxpm4:amd64 (1:3.5.11-1) ...
Setting up libxt6:amd64 (1:1.1.5-0ubuntu1) ...
Setting up libxmu6:amd64 (2:1.1.2-2) ...
Setting up libxaw7:amd64 (2:1.0.13-1) ...
Setting up libxkbfile1:amd64 (1:1.0.9-0ubuntu1) ...
Setting up x11-apps (7.7+5+nmu1ubuntu1) ...
Setting up xbitmaps (1.1.1-2) ...
Processing triggers for systemd (229-4ubuntu7) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...

stgraber@dakara:~$ lxc exec test xeyes
@hieuit7
hieuit7 commented Sep 22, 2016

I found docs for contaner exec command here: https://github.com/lxc/lxd/blob/master/doc/rest-api.md#10containersnameexec

I used it for my project and use request to call api. I can't wait for websocket connection. How to get it?

I want execute command via api with websocket connection!

@alexforster
alexforster commented Dec 4, 2016 edited

For anyone who hits this issue from Google like I did, you can access an LXD container's console device like this–

~# lxc profile device show default
# (...sic...)
console:
  path: /dev/console
  type: unix-char
tty:
  path: /dev/tty
  type: unix-char
tty0:
  path: /dev/tty0
  type: unix-char
ttyS0:
  path: /dev/ttyS0
  type: unix-char

Add with:

lxc profile device add default console unix-char path=/dev/console

lxc profile device add default tty unix-char path=/dev/tty

lxc profile device add default tty0 unix-char path=/dev/tty0

lxc profile device add default ttyS0 unix-char path=/dev/ttyS0

Open console with:

lxc-console -P /var/lib/lxd/containers -t 0 -n my-container

I use an lxcon bash alias:

alias lxcon='lxc-console -P /var/lib/lxd/containers -t 0 -n'

@veselins
veselins commented Jan 10, 2017 edited

I am playing with LXD for couple of months and managed to set up really good Desktop Environment experience inside LXC/LXD container. However, I have some problems and any advice or solution will be appreciate.

To run desktop environment I am using xdummy driver (didn't test Xpra, but I think it will provide better experince). This allows me to connect and interact with container as headless machine via vnc. I personally prefer it instead ssh -X.

However, if you look for closed to 'as Virtual Machine' experience, than I thing the solution mention from Stéphane Graber ( @stgraber ) is good one. Install X server on host and link it to LXD container. He got really nice article about it.

But I do have some problems and look for any advice or solutions:

  1. On first run and login as non-root, I am able to run 0 A.D. (the game) with no problems. However, if I stop container and start it again, when 0 A.D. is started there is time lag (close to 10-15 min) before the game really appears. The same experience happens with other 3d rendering applications. I am not quite sure, but seems there is some time-out which blocks the application launch. And this happens only when I am logged as non-root. If I am logged with root, there is no time lag.

@stgraber may you help with next problem: Any comment or advice will be appreciate I am really blocked.

  1. I assume that the rendering acceleration is done via xdummy (which is not like real hardware acceleration), I am trying to link the hardware video card (which is integrated Intel chipset not powerfull one using lxc configure device add gpu .... command. On host itself I has the following output:

~# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

~# lshw -c display
*-display
description: VGA compatible controller
product: Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 06
width: 64 bits
clock: 33MHz
capabilities: vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0

~# modinfo i915
filename: /lib/modules/4.8.0-30-generic/kernel/drivers/gpu/drm/i915/i915.ko
license: GPL and additional rights
description: Intel Graphics
author: Intel Corporation
author: Tungsten Graphics, Inc.
firmware: i915/bxt_dmc_ver1_07.bin
firmware: i915/skl_dmc_ver1_26.bin
firmware: i915/kbl_dmc_ver1_01.bin
firmware: i915/kbl_guc_ver9_14.bin
firmware: i915/bxt_guc_ver8_7.bin
firmware: i915/skl_guc_ver6_1.bin
srcversion: FC4F6C60C5003AE62620322
alias: pci:v00008086d0000593Bsvsdbc03sci
alias: pci:v00008086d00005927svsdbc03sci
...............

However when I linked the gpu to container, and running above commands I have:

~# lxc exec ct1 -- lshw -c display
*-display
description: VGA compatible controller
product: Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 06
width: 64 bits
clock: 33MHz
capabilities: vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0

~# lxc exec ct1 -- modinfo i915
libkmod: ERROR ../libkmod/libkmod.c:586 kmod_search_moddep: could not open moddep file '/lib/modules/4.8.0-30-generic/modules.dep.bin'
modinfo: ERROR: Module alias i915 not found.

What might be the problem there, why modinfo can't access i915 driver?

And I was wondering, let's say that GPU device will be linked to 2 containers and on both containers we have install xserver, how the synchronization will be take place when both X servers try to access same gpu hardware? Is there any legible case to share same GPU to more than one container ?

Thanks

@brauner
Member
brauner commented Jan 10, 2017

Likely because /lib/modules is not mounted. Have you tested whether gpu access works? For a quick test, install mesa-utils and run glxgears.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment