I have a home network that contains a mixture of devices, some of which that receive a...
Generally when using X-based applications inside an OpenVZ or Proxmox container, the host node will run the X server and the container will use X forwarding through SSH to run the application. An article at the Open VZ Wiki explains this in more detail.
However, I wanted to have an X server inside the container itself. Moreover, it should also have support for sound (ALSA). The reason behind this is to have a container capable of running FreeSWITCH (a high performance VoIP switch similar to Asterisk) with the Skypiax trunk (for Skype connectivity) fully independent.
There are various methods of implementing the X server inside an OpenVZ or Proxmox container, especially if no direct video output is required. However, there is very little information available on how to enable sound inside an OpenVZ or Proxmox container. This article will explain how to do this.
The host node requires the proper sound modules installed. For example, on a server that does not require actual output through attached speakers, snd_dummy is sufficient. Enter the following command to load the snd_dummy module:
You can verify if everything went well with:
lsmod | grep snd
Which will display an output similar to:
snd_dummy 23168 0 snd_pcm 97288 1 snd_dummy snd_timer 35464 1 snd_pcm snd 79784 3 snd_dummy,snd_pcm,snd_timer soundcore 18208 1 snd snd_page_alloc 19984 1 snd_pcm
If this is the case, then you’d want to make sure the snd_dummy will be loaded at boot time. Simply issue the following command:
echo "snd_dummy" >> /etc/modules
The next step is preparing the OpenVZ or Proxmox container. By default, the container does not have access privileges to the sound device, so this needs to be setup from the host node (assuming “100” is the actual container ID):
vzctl set 100 --devices c:116:all:rw --devices c:4:all:rw --save
The following step involves recreating the /dev/snd layout from the host node in the container. Let’s first see what the layout looks like on the host node:
ls -la /dev/snd
This will give an output similar to:
crw-rw---- 1 root audio 116, 6 2009-08-14 20:42 controlC0 crw-rw---- 1 root audio 116, 5 2009-08-14 20:42 pcmC0D0c crw-rw---- 1 root audio 116, 4 2009-08-14 20:42 pcmC0D0p crw-rw---- 1 root audio 116, 3 2009-08-14 20:42 seq crw-rw---- 1 root audio 116, 2 2009-08-14 20:42 timer
It is important that the same device IDs are being recreated in the container. I.e., the device ID for seq is 116,3 in the above example.
Enter the container and start and issue the following commands, depending on the output given on the host node:
vzctl enter 100 rm -r /dev/snd mkdir /dev/snd mknod /dev/snd/controlC0 c 116 6 mknod /dev/snd/pcmC0D0c c 116 5 mknod /dev/snd/pcmC0D0p c 116 4 mknod /dev/snd/seq c 116 3 mknod /dev/snd/timer c 116 2 chmod 660 /dev/snd/* chown :audio /dev/snd/*
At this point you have cloned copy of the host node’s sound devices and are ready to be used.
Please note that the application that wishes to use the sound devices require the proper privileges. The easiest method is to add the UID to the audio group. For example, if Skype runs under uid “skype”, issue this command:
adduser skype audio
There are various X server variants that can be installed in the container, especially if no video output is required. The most popular one is undoubtedly Xvfb.
I have opted for using the Xorg Server with a dummy video, mouse and keyboard driver instead (as this was dedicated server without any of these devices). This section details how I have installed it on Debian-based distributions.
First step, inside a container, is to soft-link TTY1 to TTY0:
rm /dev/tty0 ln -s /dev/tty1 /dev/tty0
If nscd is installed, remove this first:
aptitude remove nscd
Next we install the required packages for Xorg and some device drivers, incuding ALSA for sound support:
aptitude -R install xorg xserver-xorg-video-dummy xserver-xorg-input-kbd xserver-xorg-input-mouse alsa-base linux-sound-base libaudiofile0 dbus udev-
The last step is configuring Xorg, by editing the /etc/X11/xorg.conf file as following:
Section "InputDevice" Identifier "Dummy Input" Driver "void" EndSection Section "Device" Identifier "Dummy Video" Driver "dummy" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Dummy Video" EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Dummy Input" EndSection
You can now start X instances using:
where <DISPLAY#> is the display to be used (without the brackets, or omit entirely for default settings). X-based applications will now be able to run on any of these displays. For example, to run Skype (for Skypiax) on a specific display and under UID “skype”:
su skype -c "echo secret:password | DISPLAY=:1 /usr/bin/skype --pipelogin 2>>skype_errors.log &"
Even though you are using a virtual framebuffer (such as with Xvfb) or dummy video driver, you will still be able to do visual tasks on the server. One method is to use an X forwarding tunnel (ssh -X). I prefer to use Nomachine’s NX server instead.
To install the Nomachine NX server on a Debian-based distribution, issue the following command:
wget http://22.214.171.124/download/3.3.0/Linux/nxclient_3.3.0-6_i386.deb wget http://126.96.36.199/download/3.3.0/Linux/nxnode_3.3.0-17_i386.deb wget http://188.8.131.52/download/3.3.0/Linux/FE/nxserver_3.3.0-22_i386.deb dpkg -i nxclient_3.3.0-6_i386.deb dpkg -i nxnode_3.3.0-17_i386.deb dpkg -i nxserver_3.3.0-22_i386.deb
This assumes you are running a 32-bits version of Linux and the versions listed above are still correct. Please verify this at Nomachine’s website and change as appropriate before issuing the command.
Now you are ready to connect to your Xorg server using Nomachine’s NX Client and do visual tasks (ie., browse the internet if a browser is installed).