On 10/04/2013 01:50 AM, Johan Wilfer wrote:
Hi,

I am evaluating how to migrate my Debian 6 HN's now when support soon will be dropped for Debian 6 and they also drop official support for Openvz.

Right now I testing a Debian 7, with a RHEL-kernel:
2.6.32-openvz-042stab081.3-amd64 with vzctl version 4.5.1

They are converted from rpm with alien and installed with dpkg. As instructed here on page 1: http://www.howtoforge.com/installing-and-using-openvz-on-debian-wheezy-amd64

There is a better way now! We have native Debian Wheezy builds
for kernel and tools, available at http://download.openvz.org/debian
(please see that page for more info). That stuff is still in beta, so
if you can test it and report possible bugs back to us that would
be just great.


I've noticed that when I create a VE with DEVNODES-statement, like this:
DEVNODES="dahdi/channel:rw dahdi/ctl:rw dahdi/pseudo:rw dahdi/timer:rw"

The devices end up in the containers /dev directly, like this (I removed the other devices for clarity):
root@test:/dev# ls -la
crw-r----T  1 root root 196, 254 Oct  3 23:34 channel
crw-r----T  1 root root 196,   0 Oct  3 23:34 ctl
crw-r----T  1 root root 196, 255 Oct  3 23:34 pseudo
crw-r----T  1 root root 196, 253 Oct  3 23:34 timer

This is how it looks like on the HN
root@microhn01:/dev# ls -la /dev/dahdi/
drwxr-xr-x  2 root root      120 okt  3 22:08 .
drwxr-xr-x 19 root root     6600 okt  3 22:08 ..
crw-rw---T  1 root root 196, 254 okt  3 22:08 channel
crw-rw---T  1 root root 196,   0 okt  3 22:08 ctl
crw-rw---T  1 root root 196, 255 okt  3 22:08 pseudo
crw-rw---T  1 root root 196, 253 okt  3 22:08 timer

In OpenVZ on Debian 6 the parent dir "dahdi" was created in the VE, now with this more recent kernel and vzctl all end up in /dev without the dahdi-directory.

I can move them myself to /dev/dahdi in the VE, but the reappear in the /dev-dir after restating the VE.

It seems to be the same with other devices, like /dev/net/* or /dev/usb/* etc.

Any thoughts?

Most probably it has to do something with what distro you have inside a container
rather than the kernel and vzctl.

I tried to reproduce your issue using vzctl-4.5.1 and kernel 2.6.32-042stab082.3,
with a container running centos-6-x86 template, and it works as it should
(well, almost -- see below):

[HOST] # ls -l /dev/cpu/microcode
crw-rw---- 1 root root 10, 184 Oct  3 03:10 /dev/cpu/microcode

[HOST] # vzctl set 1018 --devnodes cpu/microcode:r --save
Setting devices
CT configuration saved to /etc/vz/conf/1018.conf

[HOST] # vzctl enter 1018
entered into CT 1018

[CT] # ls -l /dev/cpu/microcode
crw------- 1 root root 10, 184 Oct  4 14:42 /dev/cpu/microcode

[CT] # logout

[HOST] # vzctl restart 1018
....

[root@dhcp-10-30-21-127 ~]# vzctl exec 1018 ls -l /dev/microcode
crw-r----- 1 root root 10, 184 Oct  4 14:43 /dev/microcode

[root@dhcp-10-30-21-127 ~]# vzctl exec 1018 ls -l /dev/cpu/microcode
crw-rw---- 1 root root 10, 184 Oct  4 14:43 /dev/cpu/microcode

I am not sure why that happens, but it doesn't look like a big issue to me.

I re-did the same test with the debian-7-x86_64 template, with the
same results.

Generally, such requests better to be filed as bugs to bugzilla (but for this one,
so far, WORKSFORME).

Kir.

_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Reply via email to