Emile “iMil” Heitor ’s home

Depuis un petit moment, je constate que les derniers builds du QEMU contenus dans KVM explosent en vol au démarrage de la VM. Flemmard, je continuais donc à utiliser le QEMU de la version 68 qui, lui, fonctionnait. Et puis ça a fini par vraiment me démanger. Je comprend à grands renforts de gdb que lorsque l’output SDL est activé en même temps que le support d’une carte réseau virtuelle, QEMU coredumpe.
À tout hasard, j’essaye de passer à un modele de carte virtuelle different de la rtl8139 émulée par defaut, puisque les dernieres versions de QEMU/KVM en supportent desormais bien plus qu’auparavant, et là, bingo, plus de Segmentation Fault. Ainsi, le démarrage de mes VMs NetBSD ressemble désormais à ceci :

/usr/local/bin/qemu-system-x86_64 /data/virt/netbsd.img \
	-net nic,macaddr=00:56:01:02:03:04,model=i82557b \
	-net tap,ifname=tap0,script=/etc/qemu-ifup \
	-m 256 \
	-no-acpi \
	-localtime \
	-daemonize

Où model=i82557b demande l’émulation d’une carte réseau de type Intel.

Et ouais… les vacances sont finies.

J’en mourais d’envie: après avoir manipulé des machines VT-capable au boulot, je ne pouvais plus rentrer chez moi et ne pas démarrer un kvm ou un domU non modifié. Alors j’ai craqué. Après 4 heures passées rue Montgallet façon de Pretty-Woman, voici le setup que je me suis monté à moindres frais, afin de pouvoir, chez moi, gouter aux joies de la Virtualisation native :

. CPU: Intel Core 2 Duo E6300: 119€
. Carte Mère ASUS P5L 1394: 63€
. 2GB DDR2 Kingston: 58€

Moyennant un upgrade plus que perilleux en Gutsy, me voici donc avec un kvm NetBSD rugissant :)~~ hrRRMMMmmmm

Juste pour le plaisir :

imil@tatooine:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 3736.16
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 3642.95
clflush size    : 64

Tu vois le ptit flag vmx là ? tu le vois ?

En echo à ce très bon post montrant une configuration réseau qui fonctionne pour qemu / kvm, je vous propose ma petite sauce. La finalité étant :

. Une VM NetBSD 3.1 sur le même LAN que le host
. Son fonctionnement en background
. Son administration potentielle via VNC en cas de crash

à la Xen quoi.

Le host est une debian x86, et evidemment le hardware supporte les instructions VT :

$ grep vmx /proc/cpuinfo |uniq
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

Ça va être rapide :

- Création de l’image disque avec qemu-img :

$ qemu-img create -f raw netbsd.img 4G

J’ai essayé les formats qcow et qcow2 sans succès, ils sont vus comme des disques de 0 octets. Il faudra que j’essaye en convertissant l’image raw.

- Fichier de démarrage :

$ cat bin/netbsd
#!/bin/sh

kvm /home/imil/kvm/netbsd.img \\
        -net nic,model=ne2k_pci \\
        -net tap,ifname=tap0,script=/etc/qemu-ifup \\
        -m 512 \\
        -smp 1 \\
        -no-acpi \\
        -localtime \\
        -vnc :1 \\
        -daemonize

Quelques explications, /etc/qemu-ifup ressemble à ceci :

#!/bin/sh

BRIDGE=br0

ifconfig $1 0.0.0.0 up
brctl addif $BRIDGE $1

Je choisis une carte de type ne2k-pci, la seule qui ne pose aucun souci de type “watchdog timeout”, je désactive l’acpi, source classique d’emmerdements, je demande la créaction d’un display VNC sur le port 5901 et enfin je daemonize l’ensemble afin de faire tourner tout ce beau monde en background.

Pour l’installation du guest, vous aurez besoin d’ajouter ceci au fichier de commandes :

	-cdrom /path/vers/i386cd-3.1.iso \\
	-boot d

happy virt’

alors moi je dis: y.e.s.

Upgrade de Xen en 3.1 sur mon lappy boulot, juste pour voir, et YES, enfin ce !@#!@# de module b44 (BCM4401-B0) fonctionne out-of-the-box !
Il s’agit d’une debian testing, pour laquelle j’ai suivi ce tuto, excepté pour la partie mkinitrd qui pedalait dans le vide, je lui ai donc préféré mkinitramfs, utilisé de cette façon :

# mkinitramfs -o /boot/initrd.img-2.6.18-xen 2.6.18-xen

Décidemment, le “choix” de l’OS d’un domU n’est pas si large qu’il n’y parait…
Nous avions statué l’archi suivante pour zone0 :

. dom0: debian stable amd64 + Xen 3.1
. domU services: OpenBSD 4.1 amd64
. domU shells: OpenBSD 4.1 amd64
. domU www1: NetBSD 3.1 x86
. domU www2: NetBSD 3.1 x86

Le choix de NetBSD x86 avait été dicté par le fait que l’installation même de la version 64 bits s’avérait impossible, cette dernière ne trouvant jamais le media cd0.

Du fait de l’architecture de services un peu particulière que nous avions à l’esprit, nous avons du compiler certains ports OpenBSD… et là, mauvaise surprise, un bête ./configure faisait loader la machine à 3 et prenait en moyenne un quart d’heure, à raison de 3 secondes par ligne ! Après quelques recherches, nous trouvons quelques threads sur des problèmes similaires, mais toutes les pistes évoquées -même un vilain patch du cpu.c du noyau- ne donnent aucun résultat.

Hier soir, nous nous sommes donc rabattus sur la version x86 d’OpenBSD, et comme on pouvait s’y attendre: plus de soucis. Les deux domUs carburent, les ./configure et autres compilations sont rapides, et les machines virtuelles semblent stables, mêmes soumises à quelques stress tests de forking et de memoire.

Il semble que le problème concerne l’utilisation de fork() -qu’un ./configure utilise evidemment massivement-.

L’archi finale est donc :

. dom0: debian stable amd64 + Xen 3.1
. domU services: OpenBSD 4.1 x86
. domU shells: OpenBSD 4.1 x86
. domU www1: NetBSD 3.1 x86
. domU www2: NetBSD 3.1 x86

Une dernière astuce, pour une raison que j’ignore, une de plus, le boot cd cd41.iso fait paniquer le domU dès le chargement du noyau, aussi, pour installer OpenBSD 4.1, j’ai utilisé l’image cdemu qui n’a posé aucune complication.

Rackage imminent.

tu sais ce que c’est que ça lutin ?

ça, c’est le nombre de CDs / UNICes / Linux que j’ai du tester avant de tomber sur une configuration adéquate pour :

. Faire tourner un dom0 Xen en 64 bits
. Faire tourner autre chose que du Linux en domU 64 bits

Le magic combo, c’est Debian Stable (Etch) amd64 + Xen 3.1

Pour le moment je fais tourner un domU OpenBSD amd64 et un domU NetBSD amd64 en hvm (CPU VT capable evidemment)

Pour le setup debian/Xen 3.1, je me suis calé la dessus: http://bderzhavets.blogspot.com/2007/08/xen-3_27.html

Ma conf de bridging ressemble à ça :

auto eth0
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet dhcp
      bridge_ports eth0
      bridge_maxwait 0

Et un domU classique à ça :

kernel = '/usr/lib/xen-default/boot/hvmloader'
builder = 'hvm'

memory  = '1024'
name = 'services'

device_model = '/usr/lib/xen-default/bin/qemu-dm'

nic=1
vif = [ 'type=ioemu, bridge=xenbr0' ]

sdl=0
# L'output sera visible sur un serveur vnc sur son display 1
vnc=1
vnclisten='192.168.10.20'
vncunused=0
vncdisplay=1
vncpasswd=''

disk = [ 'phy:/dev/mapper/pwepwetvg-jolilv,ioemu:hda,w', 'file:/home/imil/iso/
i386cd.iso,hdc:cdrom,r' ]

boot = 'd'

Petit hint, l’export vnc ne fonctionne par “out of the box”, une rapide recherche nous indique qu’il faut installer ceci :

aptitude install libsdl1.2debian-all

Je posterai la conf complète de zone0, la future machine GCU que je setupe de cette façon, sur le wiki GCU dès qu’on aura atteint un état définitif.