Emile "iMil" Heitor 's home

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.

CINQ HEURES ! CINQ PUTAIN D’HEURES on vient de passer avec _mat et ofredj à essayer de débugger cette SALOPERIE de netfilter. Pour faire court, toujours dans les peripeties de zone0, je me disais ce matin “bon peinard, je sette les redirections de ports du dom0 vers les domUs et on part racker”: AH-AH. Et que jte PREROUTE, et que jte FORWARD et qu’on browse, qu’on lit des histoires de checksums erronés, de mode nat pour Xen, on essaye, on casse, on boit. Bref, la misère: impossible de faire un minable petit forwarding de port du dom0 vers un domU. En désespoir de cause, je tente ma chance avec IPVS, dont je connais la robustesse par le biais de mon boulot. Et bah… 10mn de lecture de man, 3mn de commandes, et ça marche. Là comme ça direct. Je vous l’accorde, c’est un peu le marteau pilon pour écraser une mouche, mais à bien y reflechir, les capacités de ce module kernel à faire du load balancing nous ouvrent potentiellement de nouveaux horizons…
Un chouillat de conf pour faire envie

Je déclare une VIP (Virtual IP) de service (ici, DNS) load-bancé suivant l’algo Round-Robin :

ipvsadm -A -u 192.168.20.30:53 -s rr

Puis j’attache à cette VIP un (mais surtout plusieurs) serveur réel, ici je n’attache qu’un serveur, mais en TCP et UDP :

ipvsadm -a -t 192.168.20.30:53 -r 192.168.50.1:53 -m
ipvsadm -a -u 192.168.20.30:53 -r 192.168.50.1:53 -m

Et un peu d’output :

root@zone0:~# ipvsadm -L
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.20.30:domain rr
  -> services:domain              Masq    1      0          0         
UDP  192.168.20.30:domain rr
  -> services:domain              Masq    1      0          1         
TCP  192.168.20.30:www rr
  -> gcu:www                      Masq    1      0          0         
TCP  192.168.20.30:2222 rr
  -> gcu:ssh                      Masq    1      0          0         
TCP  192.168.20.30:ldap rr
  -> services:ldap                Masq    1      0          0         

Ça change du –par-ici –par-la –sourceroutingcroise -j ACCEPT -i eth0 -A -I -O -P -L –ouaisouais non ?

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.

Bon c’est pas encore super brillant, j’imagine que ça fera hurler les puristes, mais au cas ou quelqu’un aurait besoin d’une toute petite classe de rien du tout pour manipuler des fichiers de conf “basiques” du type :

# ce genre de format
clé: valeur
# ou celui-ci
clé= valeur
# ou encore celui là
clé	valeur

J’ai pondu un truc ici.
Ça s’utilise comme ça :

>>> import simpleconf   
>>> cf = simpleconf.SimpleConf()
>>> test = cf.read('/etc/nsswitch.conf')
>>> cf.valueupdate('group', 'pwetpwet')
>>> cf.write('/tmp/out.tmp')

et magie :

$ grep ^group /tmp/out.tmp
group:       pwetpwet

Améliorations bienvenues toussa.