====== 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:Debian]] mit tzconfig oder direkt auf Berlin setzen: cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime * volle 4 GB auf 32Bit [[xen:Xen]]: [[http://www.nabble.com/32-bit-Xen-dom0-mit-4GB-Ram-td14172481.html|32 bit Xen-dom0 mit 4GB Ram]] ===== Wie kann man allgemein Fehler erkennen und beheben? ===== - 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. - 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. ===== automatische Neustarts verhindern ===== Wenn [[xen: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 ===== CDROM boot failure ===== 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:Xen]] kann gerade nicht von einem ISO starten. Workaround: Mit losetup ein "loopback"-Gerät erstellen und es in der [[xen: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: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. ===== Error: Device 0 (vif) could not be connected. Backend device not found ===== 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 [[netzwerke: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 [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437127|Debian Bug report logs - #437127 xen-utils-common: vif-common fails to identify ip address of ethernet device]] ===== Error: Device 2049 (vbd) could not be connected ===== **mögliche Gründe:** - in der Konfigurationsdatei wurde der **Pfad zu den Images** nicht richtig angegeben - Neue DomUs können nicht gestartet werden, weil die **maximale Anzahl von Images** (mit loop) **bereits gemounted** ist. **Lösung**: siehe [[linux:Arbeiten mit Images]]. ===== Probleme mit Stromsparmodi ===== Auf meiner AMD-CPU (Dual-Core -> k8) funktionierte mit dem Xen-[[linux: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: [[http://wiki.ubuntuusers.de/Prozessortaktung|Prozessortaktung]], [[http://www.stud.uni-karlsruhe.de/~uxhz/gentoo/power-management/power-management-guide-de.html|Power Management Anleitung (Gentoo)]]. ===== PAE mode mismatch ===== 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: [[ http://ubuntuforums.org/showthread.php?t=301300|Xen on Edgy 3.0]]. ===== Vollvirtualisierung: Hardwareunterstützung überprüfen ===== 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: - 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 - 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)' - auf CPU-Ebene erkennt mit cat /proc/cpuinfobei Intel: Prozessor-Flag „vmx“ oder AMD Prozessor-Flag „svm“. ===== 4gb sg fixup (programm) ===== Der Grund dieser Fehlermeldung ist eine nicht angepasste Standardbibliothek (glibc) oder das genannte Programm benutzt Funktion die [[xen: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. * [[http://wiki.xensource.com/xenwiki/XenFaq#head-e05786f1e0d6a833bc146a6096cab2d96f2b30ae|Xen FAQ: How do I fix the 4gb seg fixup messages in my syslog?]] ===== DomUs bleiben beim Start hängen ===== Wenn DomUs beim wechseln der [[linux: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 - ''/etc/rcS.d'' - ''/etc/rc0.d'' - ''/etc/rc6.d'' löschen (mit rm ???hwclock*). ===== Xen-tools: Meldungen über locales ===== 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 [[http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg102607.html|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" ===== Cannot open master side of pty (mc) ===== 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 [[linux:bash]]-Vervollständigung bei [[debian: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. ===== Kernel BUG durch fehlkonfigurierte Netzwerkkarte ===== 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:[] 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: [] unregister_netdev+0xf/0x15 Sep 24 10:15:45 dhcp kernel: [] backend_changed+0x6f8/0x725 Sep 24 10:15:45 dhcp kernel: [] xenbus_read_driver_state+0x1c/0x2b Sep 24 10:15:45 dhcp kernel: [] otherend_changed+0x74/0x79 Sep 24 10:15:45 dhcp kernel: [] xenwatch_handle_callback+0x12/0x44 Sep 24 10:15:45 dhcp kernel: [] xenwatch_thread+0x105/0x11b Sep 24 10:15:45 dhcp kernel: [] autoremove_wake_function+0x0/0x2d Sep 24 10:15:45 dhcp kernel: [] xenwatch_thread+0x0/0x11b Sep 24 10:15:45 dhcp kernel: [] kthread+0xc0/0xeb Sep 24 10:15:45 dhcp kernel: [] kthread+0x0/0xeb Sep 24 10:15:45 dhcp kernel: [] 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: [] 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)