Xen, USB und X11.app
Konfiguration:
- Dell PowerEdge 2970, 2x Quad-Core AMD Opteron(tm) Processor 2352
- Xen-3.3.0 (compiled from source, gcc-4.1.2)
- Debian-4.0 (stable)
amd_64
(dom0 & domUs)
Damit fing alles an: das Kompilieren verlief problemlos, das erste Booten mit Xen-Kernel war eine Freude, und auch wenn der Dell die Devices ein wenig banane benennt: das System rennt. Die domUs
tun brav ihren Dienst. Nun sollen im wöchentlichen Wechsel zwei USB-Platten angeschlossen und immer einer bestimmten domU
zur Verfügung gestellt werden. Natürlich hat keiner Lust, das in der Konfiguration der domU
fest einzubauen und nach jedem Wechsel einen Reboot zu initiieren, also – so dachte ich mir – muss es da Alternativen geben.
Eine Möglichkeit, auf die ich mich hier nun beziehen möchte, ist der qemu
-Monitor. Der funktioniert nicht im Zusammenspiel mit VNC (das wurde aus Sicherheitsgründen deaktiviert), man muss SDL aktivieren. Ein valides Konfig-File für eine HVM könnte also beispielsweise so aussehen:
## kernel and memory
kernel = '/usr/lib/xen/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen/bin/qemu-dm'
memory = '2048'
vcpus = '2'
## display options
vnc=0
sdl=1
monitor=1
## disk devices
disk = [ 'file:/vm/hubert/main.img,hda,w', 'file:/vm/hubert/data.img,hdb,w' ]
boot = 'c'
## networking and hostname
vif = [ 'mac=cc:00:ff:ff:ee:ee' ]
dhcp = 'dhcp'
name = 'hubert'
## behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
Ich bin per SSH von meinem Mac aus auf der betreffenden Maschine eingeloggt, habe im xterm
meines Mac ein xhost +
(weil ich faul bin) und auf der Maschine ein export DISPLAY="$IP_MEINES_MAC:0.0"
ausgeführt. Nun starte ich auf der Maschine meine domU
(xm create hubert
), und auf dem Display meines Mac baut sich im Schneckentempo ein Fenster auf, in dem ich den weiteren Bootvorgang beobachten kann. Um es vorweg zu nehmen: es läuft derart langsam, dass es eigentlich nicht praktikabel ist. Das allerdings ist das geringere Problem – mein Ziel ist es ja, in den qemu
-Monitor zu gelangen, um dort das USB-Device zur (laufenden) domU
hinzufügen zu können. Wie also geht das?
Nun, eigentlich in meinem grottenlangsamen SDL-Fenster, indem ich die Tastenkombination Strg+Alt+2
drücke. Das ist der Default, und bisher konnte ich nicht finden ob (und wenn ja wo) sich das ändern ließe. Was passiert nun also, wenn ich das tue? Nichts. Exakt nichts. Kein qemu
-Monitor, einfach nichts. Sicherheitshalber prüfe ich, auf welche Art die domU
gestartet wurde? Aber das sieht doch alles recht gesund aus:
$ /usr/lib/xen/bin/qemu-dm -d 13 -domain-name hubert -k en-us -monitor vc -vcpus 2 -append ip=:127.0.255.255::::eth0:dhcp -boot c -acpi -net nic,vlan=1,macaddr=cc:00:ff:ff:ee:ee,model=rtl8139 -net tap,vlan=1,ifname=tap13.0,bridge=xenbr0 -M xenfv
Aber halt, auf der dom0
existiert ein Logfile. Flugs hineingeschaut, und was erblickt mein krankes Auge?
Warning: no scancode found for keysym 310
Warning: no scancode found for keysym 310
Mit jedem Mal, wo ich Strg+Alt+2
drücke, kommt eine derartige Zeile hinzu – Alt
wird falsch interpretiert. Großartig, wirklich ganz großartig… Und liegt offenbar am Zusammenspiel mit Apples X11.app. Danke, Apple. Ich hab’ dann noch so manches ausprobiert, hat aber alles nichts genutzt (xmodmap
, xev
, Umstellung Tastatur-Layout, Neustarten des X-Servers, …), sprich: das Debugging läuft noch.
Achja, und noch ein Hinweis: verhält sich die Tastatur im SDL-Fenster irgendwie merkwürdig – bei mir erschien bei Drücken von Enter plötzlich ein großes J – so ist in den Preferences von X11.app die Option Follow system keyboard layout
im Reiter Input zu aktivieren. Dann geht zumindest das…
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten