brctl show
muss eine Ausgabe erzeugencp /usr/share/zoneinfo/Europe/Berlin /etc/localtime
/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.
/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:
sudo losetup -f
/dev/loop9
sudo losetup -f /path/to/mycd.iso
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.
mögliche Gründe:
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:
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
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)'
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.
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
/etc/rcS.d
/etc/rc0.d
/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)