[Lxc-users] Dynamic devices...

Daniel Lezcano daniel.lezcano at free.fr
Sun Mar 7 14:48:25 UTC 2010


Michael H. Warfield wrote:
> Hey all,
>
> This is sort of a jump ball for both the OpenVZ camp and the LXC camp.
> Maybe some food for thought as well.  I think it's something that needs
> to be thought out.
>
> I know udev does not work in containers.  Neither OpenVZ nor LXC.  Ok,
> fine.  So devices are static.  Problem is that I've got a situation
> where I need dynamic devices, specifically some USB devices.
>
> I have an 8 port serial to USB converter used for controlling the serial
> consoles of a cluster of remote servers.  So ttyS0 on each server is
> hooked to a port on the controller and configured for serial console
> (they also have serial BIOS console redirection as well - very VERY nice
> for remote management where you don't have a remote IP KVM).
>
> That converter then plugs into a USB sharing device which shares the
> converter between 4 of the servers.  So...  Any one of the four servers
> can take control of the converter and can then access all of the 8
> serial consoles for all of the servers.  Nice redundancy.
>
> I want to grant access to that subsystem to selected containers so
> certain administrators can be given their very own container and be able
> to access the host consoles over serial ports, then.  Simple so far.
> Just allow those containers access to the usbsharing device and the
> ttyUSB* devices.
>
> Here's where the rub comes in.  The way the USB sharing device works.
> Any server which does NOT have the consoles sees a USB hiddev device (it
> looks like an USB human input device).  It accesses that device to
> request (or demand) control of the controlled USB devices.  The server
> with the consoles, does NOT see that device at all.  What it does see
> are the controlled USB devices (the ttyUSB* devices in this case) which
> the other servers do NOT see.  So the logic goes that if you see the
> usbsharing device, you do not have the consoles but may request them. If
> you do NOT have the usb sharing device you should have the ttyUSB*
> devices and may access them.  So those devices come and go dynamically.
>
> How to do this in a container?
>
> (Yes, obviously, I can try to open the device and get an error.  But,
> really...  That's an ugly answer.)
>
> I suppose I can apply the dynamics in the udev rules in the host machine
> and create matching devices in the container's dev directory using a hot
> plug run script.  That's what I'm working on now.  Is that really the
> answer though?
>
> Just food for thought for developers and users alike.  There has to be
> more situations that just this.
>   
Actually the udev daemon receives events from the kernel via a netlink 
socket.
This socket is part of the network namespace which is isolated from the 
container.
In the kernel there is only one socket belonging to the init network 
namespace, so all the events are sent to the host.

This is something to be implemented in the kernel and maybe not 
acceptable as we may send multiple events to multiple namespaces.

But before looking at this, there is the sysfs per namespace to be 
merged in the mainline (it's out of tree right now).
The code is ready but needs a port on the latest kernel version and be 
tested again (current version is 2.6.32-rc5). Part of the patchset was 
already merged.

At this point, the udev events for the network devices should be 
implemented to send events only for the container where the network 
devices belong.
And then generalize the udev events for all the containers.

When udev per container will be implemented, I will be curious to see a 
"good" lxc.cgroup.devices configuration :)






More information about the lxc-users mailing list