Bjoern Franke wrote:
Hi,
thanks for your reply!
I have never used openvz, but adjusted some protocols to deal with openvz aware kernels (which means that they used and checked their namespace - so nothing really fancy).
What must be done for device drivers to make them work on OpenVZ? Have you tried it and where have found you problems?
OpenVZ-Containers use the same kernel as the host system and I can build and load the module on the host, but I don't know how to access /proc/net/batman-adv from within the container. The container uses a own proc-fs.
Ok, that is correct. I wanted to check how to work around such problems and how to implement it in the new configuration api/multiple bat-device implementation for 0.3 (or later) - but unfortunately OpenVZ for 2.6.32 was only good to crash my system very hard. (but it is at least a known upstream bug :) ) So it can take a little bit longer until I really checked what we can do here.
Just some small question: Why do you want batman-adv in a VE? batman-adv runs entirely inside the kernel. This means there is no benefit in running it in a "secure" environment because it doesn't run there. The real hardware used for the mesh is also part of the host and not the ve (unless you do some kind of device sharing with VE_NUMBER.conf - which seems to be a little bit overcomplicated).
To me it sounds easier and more straight forward to use veth inside the kernel and do the configuration outside (it only configures the kernel - so no security or separation benefits). The userspace applications like tinc can now run inside the ve with the correct setup in the host.
Best regards, Sven