What does udev listen to while under container (or host)? Is it possible to generate events from a host process to each containerized udevd, and let udevd do it's job? I'm not familiar; a "spoofed" kernel event generator of sorts
On Mar 6, 2010, at 11:49 AM, "Michael H. Warfield" <m...@wittsend.com> 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. > > Regards, > Mike > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the > best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure > of it! > --- > --- > --- > --------------------------------------------------------------------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxc-users mailing list > Lxc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users