Xen Fehlerbehebung

• manchmal machen proprietäre Grafiktreiber Probleme
• die Fehlermeldungen sind nicht immer die richtigen, man muss oft systematisch die Fehlerquellen ausschließen.
• brctl show muss eine Ausgabe erzeugen
• die Zeitzone muss manchmal bei den domUs angepasst werden. Bei Debian mit tzconfig oder direkt auf Berlin setzen:

  cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

• volle 4 GB auf 32Bit Xen: 32 bit Xen-dom0 mit 4GB Ram

1. den Xen-Debug modus anschalten: In der Datei /etc/xen/xend-config.sxp die beiden Zeilen entsprechend diesem Muster entkommentieren:

   (logfile /var/log/xen/xend.log)
   (loglevel DEBUG)

   Die ausführlichen Logfiles werden dann in /var/log/xen angelegt.

2. In den aufgerufenen Shell-Scripten (Verzeichnis /etc/xen/scripts) lässt sich der Debugmodus einschalten, indem man #!/bin/bash ein -x anhängt (also: !/bin/bash -x). Dann werden alle Befehlszeilen zusätzlich ausgegeben.

Wenn Xen abstürzt, startet es automatisch den Rechner neu. Da der Fehler bei nächsten Neustart immer noch existiert, startet der Rechner andauernd neu.

Dieses Verhalten kann mit der „noreboot“-Options verhindert werden:

Grub-Beispiel:

      title           Xen 3.1-1-i386 / Debian GNU/Linux, kernel 2.6.18-5-xen-686
      root            (hd0,0)
      kernel          /xen-3.1-1-i386.gz noreboot
      module          /vmlinuz-2.6.18-5-xen-686 root=/dev/foo ro console=tty0
      module          /initrd.img-2.6.18-5-xen-686

Fehlermeldung

      CDROM boot failure code 0002
      or CDROM boot failure code 0003
      Boot from cd-Rom failed
      Fatal: Could not read the boot disk.

Xen kann gerade nicht von einem ISO starten.

Workaround: Mit losetup ein „loopback“-Gerät erstellen und es in der Xen-Konfiguration einstellen.

Beispiel:

• prüfen, welches ein freies Gerät ist:

  sudo losetup -f 

  /dev/loop9

• eine neues „loopback“-Gerät erstellen:

  sudo losetup -f /path/to/mycd.iso

• überprüfen ob es geklappt hat:

  losetup /dev/loop9

  Die Ausgabe dürfte ähnlich sein:

  /dev/loop9: [fe04]:3096598 (/path/to/mycd.iso)

Nun kann man /dev/loop9 in der Xen-Konfiguration nutzen.

      disk = [ 'phy:/dev/vg1/xpsp3,ioemu:hda,w', 'phy:/dev/loop/0,ioemu:hdc:cdrom,r' ]

nach einem Neustart ist die Konfiguration hinfällig und muss wieder auf die alten Werte gesetzt werden.

Die Fehlermeldung „Error: Device 0 (vif) could not be connected. Backend device not found“ stellte sich als ein Bug im Xen-Script vif-common.sh unter Debian 4 (Etch) heraus.

Bei mir ist sowohl eine ipv4 als auch eine ipv6-Adresse gesetzt. Deshalb erkennt die ursprüngliche Version die IP-Adresse nicht eindeutig (beide IPs werden zurückgegeben) was zur Folge hat, dass das Erstellen des vif-Interfaces fehl schlägt und die Fehlermeldung ausgegeben wird.

Ursprünglicher Code:

function ip_of()
{
  ip addr show "$1" | awk "/^.*inet.*$1\$/{print \$2}" | sed -n '1 s,/.*,,p'
}

neuer Code:

function ip_of()
{
  ip addr show "$1" | awk "/^.*inet.*$1\$/{print \$2}" | sed 's!/.*!!'
}

Das sed -n '1 s,/.*,,p' muss also durch sed 's!/.*!!' ersetzt .

Eine alternative (aber unsaubere) Lösung wäre head -n 1, damit wird nur die erste Zeile (mit der ipv4-Adresse) zurückgeliefert.

siehe Debian Bug report logs - #437127 xen-utils-common: vif-common fails to identify ip address of ethernet device

mögliche Gründe:

1. in der Konfigurationsdatei wurde der Pfad zu den Images nicht richtig angegeben
2. Neue DomUs können nicht gestartet werden, weil die maximale Anzahl von Images (mit loop) bereits gemounted ist.

Lösung: siehe Arbeiten mit Images.

Auf meiner AMD-CPU (Dual-Core → k8) funktionierte mit dem Xen-Kernel der Stromsparmodus nicht mehr. Natürlich nicht ohne im Systemprotokoll (syslog) jede Minute x-mal drauf hinzuweisen. So ist die Diagnose von anderen Problemen nervig, von den schnell wachsenden Protokollen mal zu schweigen.

Eine schnelle Recherche ergab, das sich das Problem durch das setzen der minimalen Taktfrequenz beheben lässt. Man muss auf den maximalen Takt setzen damit erst gar kein Stromsparmodus aktiviert wird, keine umweltfreundliche Lösung, aber funktioniert nicht anders.

In der Datei /etc/sysfs.conf reicht für jede CPU eine Zeile:

devices/system/cpu/cpu0/cpufreq/scaling_min_freq=28000000
devices/system/cpu/cpu1/cpufreq/scaling_min_freq=28000000

Hier wurde also die minimale Taktfrequenz auf 2,8 Ghz gesetzt (diese werden in khz angeben, war 28000000 khz ergibt).

siehe auch: Prozessortaktung, Power Management Anleitung (Gentoo).

Fehlermeldung+reboot (Kernel panic):

PAE mode mismatch between Xen and DOM0 (xen=no, dom0=yes)''

************************************
Panic on CPU 0:
Could not set up DOM0 guest OS
************************************

mit anschließendem Neustart. Der Xen generic kernel unterstützt kein PAE, wenn man sich also das Server-image installiert, braucht man das PAE-Paket.

Lösung: die Installation des Pakets xen-hypervisor-3.0-i386-pae (sudo aptitude install xen-hypervisor-3.0-i386-pae), update-grub wird gleich anschließend ausgeführt.

Siehe: Xen on Edgy 3.0.

Falls die Hardwareunterstützung nicht funktioniert, wird das Starten der Gäste mit folgenden Fehlermeldung fehlschlagen:

Error: HVM guest support is unavailable: is VT/AMD-V supported by your CPU and enabled in your BIOS?

Für die Nutzung der Vollvirtualisierung für nicht angepasste Systeme sollte prüfen ob die Hardwareunterstützung vorhanden ist:

1. An den Xen-Fähigkeiten (xen-caps) beim Aufruf von

   sudo xm info

   müsste eine ähnlich aussehende Zeile auftauchen:

   xen_caps               : xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p 

2. Beim Xen-Bootvorgang:

   sudo xm dmesg

   stehen dann die Zeilen

   (XEN) HVM: VMX enabled
   (XEN) VMX: MSR intercept bitmap enabled

   Hier lässt sich die Aktivierung von HVM (hardware virtualized machines) erkennen. Man kann auch auf einen Blick die fraglichen Einträge anzeigen lassen:

   xm dmesg | egrep '(SVM|VMX)'

3. auf CPU-Ebene erkennt mit

   cat /proc/cpuinfo

   bei Intel: Prozessor-Flag „vmx“ oder AMD Prozessor-Flag „svm“.

Der Grund dieser Fehlermeldung ist eine nicht angepasste Standardbibliothek (glibc) oder das genannte Programm benutzt Funktion die Xen emulieren muss. Dies ist ressourcenintensiv und langsam. Zwar wird normalerweise die libc6-xen mitinstalliert, dies ist aber offensichtlich nicht passiert.

Lösung: Ein installieren der libc6-xen ersetzt die normale libc6 und der Fehler ist behoben.

• Xen FAQ: How do I fix the 4gb seg fixup messages in my syslog?

Wenn DomUs beim wechseln der Runlevel (genauer beim starten, rebooten oder shutdown) hängen bleiben, dann liegt das an den *hwclock-Skripten (z.B. S11hwclock.sh in /etc/rcS.d) die versuchen die Hardware-Uhr zu setzen. Deshalb sollte man alle hwclock-Skripte in den Verzeichnissen

1. /etc/rcS.d
2. /etc/rc0.d
3. /etc/rc6.d

löschen (mit

rm ???hwclock*

).

Im Log einer mit den xen-tools erstellten DomU finden sich häufig folgende Hinweise:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.ISO-8859-15"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C")

Bei Debian reichen zwei Zeilen:

sudo aptitude install locales
sudo dpkg-reconfigure locales

Der Bug sollte ab 3.0~beta1-1 geschlossen sein.

Evtl. (ewil ich es noch nicht getestet hab) kann man dies vorher vermeiden indem man die richtigen Einstellungen vornimmt:

nano /root/dbootstrap_settings

und die folgenden Zeilen reinkopieren.

# Inserted by languagechooser.
LANG_INST="de_DE"
LANGUAGE_INST="de_DE"
# Inserted by kbd-chooser.
KEYBD="i386/qwertz/de-latin1-nodeadkeys"
# inserted by prebaseconfig
SUITE="etch"

Die Fehlermeldung

Cannot open master side of pty: Datei oder Verzeichnis nicht gefunden (2)

erscheint wenn man in mc STRG-O drückt.

Zur Lösung des Problems trägt eine Zeile in der /etc/fstab bei:

none  /dev/pts  devpts  mode=0620    0    0

anschließend kann man mit mount /dev/pts das mounten veranlassen. Falls eine Fehlermeldung erscheint, dass der moint point /dev/pts nicht vorhanden sei: Einfach anlegen mit

mkdir /dev/pts

Dauerhaft lässt sich das Problem so allerdings nicht lösen. Der Ordner in /dev ist dann wieder weg. Deshalb ist die Installation von udev eine Möglichkeit:

aptitude install udev

Auch die Fehler bei der automatische bash-Vervollständigung bei Debian Lenny, Fehlermeldung:

/dev/fd/62: Datei oder Verzeichnis nicht gefunden
-bash: /dev/fd/60: Datei oder Verzeichnis nicht gefunden

lässt sich so beheben.

Beim Start eines Gastes kommt unten aufgeführter Kernelbug und es geht Netzwerk nicht mehr bzw. der Start bleibt dabei hängen. Grund könnte bei einer paravirtualisierten DomU die fehlerhafte Angabe type=ioemu sein. statt

vif  = [ 'mac=00:16:3e:12:12:12, ip=192.168.0.1, type=ioemu, bridge=xenbr0' ]

muss also

vif  = [ 'mac=00:16:3e:12:12:12, ip=192.168.0.1, bridge=xenbr0' ]

angegeben werden.

Sep 24 10:15:45 dhcp kernel: vif vif-0: 2 parsing device/vif/0/mac
Sep 24 10:15:45 dhcp kernel: netif_release_rx_bufs: 0 xfer, 0 noxfer, 256 unused
Sep 24 10:15:45 dhcp kernel: ------------[ cut here ]------------
Sep 24 10:15:45 dhcp kernel: kernel BUG at net/core/dev.c:3341!
Sep 24 10:15:45 dhcp kernel: invalid opcode: 0000 [#1]
Sep 24 10:15:45 dhcp kernel: SMP 
Sep 24 10:15:45 dhcp kernel: Modules linked in:
Sep 24 10:15:45 dhcp kernel: CPU:    0
Sep 24 10:15:45 dhcp kernel: EIP:    0061:[<c0232acb>]    Not tainted VLI
Sep 24 10:15:45 dhcp kernel: EFLAGS: 00010206   (2.6.18-6-xen-686 #1) 
Sep 24 10:15:45 dhcp kernel: EIP is at unregister_netdevice+0x65/0x1ca
Sep 24 10:15:45 dhcp kernel: eax: 00000003   ebx: c0068000   ecx: 00000000   edx: 00000000
Sep 24 10:15:45 dhcp kernel: esi: c74e4820   edi: c74e4ae8   ebp: c02e6b44   esp: c0ea1f40
Sep 24 10:15:45 dhcp kernel: ds: 007b   es: 007b   ss: e021
Sep 24 10:15:45 dhcp kernel: Process xenwatch (pid: 7, ti=c0ea0000 task=c039baa0 task.ti=c0ea0000)
Sep 24 10:15:45 dhcp kernel: Stack: c0068000 c74e4820 c0232c3f c039da00 c0219aab c039da00 c00682c0 c0068000 
Sep 24 10:15:45 dhcp kernel:        c0ea1f90 c039da00 c74e4820 c74e4ae8 c02e6b44 c020fc8c 00000000 c74e4800 
Sep 24 10:15:45 dhcp kernel:        c02b29d5 c039da00 c74e4820 c74e4ae8 c02e6b44 c02120bc c74e4840 c039da10 
Sep 24 10:15:45 dhcp kernel: Call Trace:
Sep 24 10:15:45 dhcp kernel:  [<c0232c3f>] unregister_netdev+0xf/0x15
Sep 24 10:15:45 dhcp kernel:  [<c0219aab>] backend_changed+0x6f8/0x725
Sep 24 10:15:45 dhcp kernel:  [<c020fc8c>] xenbus_read_driver_state+0x1c/0x2b
Sep 24 10:15:45 dhcp kernel:  [<c02120bc>] otherend_changed+0x74/0x79
Sep 24 10:15:45 dhcp kernel:  [<c0210856>] xenwatch_handle_callback+0x12/0x44
Sep 24 10:15:45 dhcp kernel:  [<c021129b>] xenwatch_thread+0x105/0x11b
Sep 24 10:15:45 dhcp kernel:  [<c012b701>] autoremove_wake_function+0x0/0x2d
Sep 24 10:15:45 dhcp kernel:  [<c0211196>] xenwatch_thread+0x0/0x11b
Sep 24 10:15:45 dhcp kernel:  [<c012b635>] kthread+0xc0/0xeb
Sep 24 10:15:45 dhcp kernel:  [<c012b575>] kthread+0x0/0xeb
Sep 24 10:15:45 dhcp kernel:  [<c010293d>] kernel_thread_helper+0x5/0xb
Sep 24 10:15:45 dhcp kernel: Code: ed ff 83 c4 0c 8b 83 b4 01 00 00 85 c0 75 19 53 53 68 fe 6b 2b c0 e8 ef 89 ee ff b8 ed ff ff ff 83 c4 0c e9 65 01 00 00 48 74 08 <0f> 0b 0d 0d 7a 69 2b c0 f6 43 5c 01 74 07 89 d8 e8 25 ff ff ff 
Sep 24 10:15:45 dhcp kernel: EIP: [<c0232acb>] unregister_netdevice+0x65/0x1ca SS:ESP e021:c0ea1f40
Sep 24 10:15:45 dhcp kernel:  <4>XENBUS: Timeout connecting to device: device/vif/0 (state 5)