Die genaue Fehlermeldung war “Error: Device 0 (vif) could not be connected. Hotplug scripts not working.“. In der Datei “/var/log/xen/xen-hotplug.log” war außerdem zu lesen: “/etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected".

Anscheinend ist an der entsprechenden Stelle im genannten Skript nun eine Variable leer, die eigentlich gefüllt sein sollte. Das Ergebnis ist nun jedoch ungültig, woraufhin das Skript auf die Nase fällt. Bis Novell ein Update zur Verfügung stellt, um den Fehler zu beheben (ich hoffe, dass Novell die Lösung beisteuert) kann man sich mit einem Workaround helfen, der darin besteht, die Zeilen 24 und 25 im Skript "/etc/xen/scripts/xen-hotplug-cleanup" anzupassen:

aus:

if [ $(xenstore-read "$vm_dev" 2>/dev/null) != "" ]
&& [ "${path_array[1]}” = “vbd” ]; then

wird:

if [ x$(xenstore-read "$vm_dev" 2>/dev/null) != "x" ]
&& [ x"${path_array[1]}" = "xvbd" ]; then

Damit sollte das Problem umgangen werden können. Bisher funktioniert's bei mir ohne Probleme.

UPDATE (20.07.2010):

Meine Xen-Umgebung lief in den letzten Tagen ziemlich wackelig. Das Starten von domU's war möglich, wenn ich allerdings eine der Instanzen stoppen oder neu starten musste, befand sie sich für ca. eine Minute im "paused"-Zustand und brach dann ab. Die Meldung war (wie gehabt) "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.".

Ich habe Foren durchsucht, Manuals gelesen und diverse Mailinglisten umgegraben, doch zunächst schien nichts zu helfen, was auch immer ich versuchte.

Nun habe ich endlich das Problem für mich isoliert und "vorerst" behoben. SLES11SP1 nutzt in der Standardauslieferung für Xen das Kernelpaket "kernel-xen-2.6.32.12-0.7.1". Damit lief alles reibungslos. Dann kam vor einigen Tagen ein Kernel-Patch heraus, Version "kernel-xen-2.6.32.13-0.4.1". Und hiermit fing - wie anfangs bereits vermutet - der ganze Ärger an. Ich habe mittlerweile die Version wieder auf den Originalzustand zurück gedreht und schon funktioniert alles wieder reibungslos. Ich hatte war vor ein paar Tagen schon probiert, den Kernel zurück zu drehen, doch ich hatte auf meinem Server noch ein weiteres Problem, dass mit dem Booten von Software-RAID-Partitionen zusammen hing. Das konnte ich beheben, indem ich "mkinitrd-2.5.10-4.6.1" installierte. Ich glaube aber nicht, dass es sich hierbei um ein grundsätzliches Problem handelt... aber wer weiß. :-)

Die Vorgehensweise:

1. Installation

Ich nutze derzeit openSUSE 11.2 (i586). Leider existiert derzeit noch kein offizielles RPM für AVLD, daher muss es von Hand kompiliert werden. Zur Vorbereitung wurden die RPMs “gcc”, “make”, “patch” und “kernel-source” installiert. Außerdem wurde natürlich die aktuellste Version von AVLD (momentan 0.1.4) heruntergeladen und entpackt.

Das Kommando “make” im entpackten Ordner lieferte direkt einen ernüchternden Fehler… “error: ‘v4l_compat_ioctl32’ undeclared here”. Sollte das schon das Ende sein? Nein, glücklicherweise fand sich in den Weiten des Internets einen Patch für AVLD, der für den Kernel 2.6.31 passt. Der Patch wird in das avld-Verzeichnis kopiert. Daraufhin wird das Kommando “patch -Np1 -i avld_0.1.4-2.6.31.patch_.txt” ausgeführt, wodurch die Datei “video_device.c” angepasst wird. Nun steht dem Befehl “make” und dem danach als root ausgeführten Kommando “make install” nichts mehr im Wege. Damit ist das Kernel-Module “avld.ko” nun nutzbar.

2. Laden und Verwenden des Moduls

Das Modul kann – wie bei Linux üblich – mittels “modprobe avld” geladen werden. An dieser Stelle ist es jedoch sehr wichtig, zu verstehen, dass das Device nur eine fest eingestellte Auflösung beherrscht, sich also nicht automatisch der Quelle (z.B. einem Video – siehe unten) anpasst. Werden dem Modul also keine Optionen mitgegeben, verwendet es standardmäßig eine Auflösung von 340×240 Pixel. Möchte man die Größe direkt beim Laden ändern, ruft man modprobe inkl. Parametern auf:

modprobe avld width=640 height=480 fps=25

Hat man das Modul hingegen bereits geladen, können die Parameter angepasst werden, indem man die Optionen per echo an das entsprechende Device schickt, also so:

echo "width=800 height=600 fps=25" > /dev/video0

(ggf. muss hier die Device-Nr. angepasst werden).

Die Fake-Webcam kann nun bereits verwendet werden. Ein Test kann mit MPlayer durchgeführt werden:

mplayer tv:// -tv "driver=v4l:device=/dev/video0:noaudio:outfmt=rgb24"

Sie sollte als ganz normal Gerät auftauchen und ein schwarzes Bild liefern. Möchte man stattdessen lieber bewegte Bilder präsentieren, kann man auf einfache Weise ein Video an das Gerät senden. Das erfolgt mit dem Programm “mencoder” aus dem MPlayer-Paket:

mencoder MOVIECLIP.XYZ -nosound -ovc raw -vf format=bgr24
-of rawvideo -o /dev/video0

Hat soweit alles geklappt, kann der Spaß beginnen… auch ohne echte Kamera. Mir fiele da z.B. der gute alte Casino-Räuber-Trick ein, bei dem man zunächst ein unscheinbares Video aufzeichnet, das dann statt des echten Webcam-Bildes wiedergegeben wird, um dem Betrachter das eigentliche Geschehen vor zu enthalten. :-)