Emile "iMil" Heitor 's home » Virtualisation

KVM/QEMU, rtl8139 et Segmentation Fault

iMil — Thu, 25 Sep 2008 22:09:41 +0000

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.

Un après-midi à Montgallet

iMil — Sun, 07 Oct 2007 20:33:31 +0000

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 ?

sous les pavés, NetBSD

iMil — Fri, 28 Sep 2007 13:12:50 +0000

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’

3.1, it’s the magic numbeeer

iMil — Wed, 19 Sep 2007 11:19:45 +0000

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

64 / 2

iMil — Wed, 19 Sep 2007 09:05:48 +0000

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.

64 putain de bits

iMil — Mon, 10 Sep 2007 18:59:28 +0000

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.

Xen vs b44

iMil — Sat, 10 Feb 2007 15:50:41 +0000

Après moult heures passées à backporter des bouts de Xen 3.0.4 vers Xen 3.0.3 pour essayer de garder un peu de cohérence dans mon packaging, j’ai fini par choisir la solution de facilité et récupérer Xen 3.0.4 chez XenSource. Eh-bin-ça-marche. Enfin cette saloperie de broadcom 4400 daigne faire transiter des lutins magiques depuis un dom0.
Bon leur quenelle est en 2.6.16, le boot est un peu chaotique, mais j’ai du link convivial.

update

Rappel des faits.

Y’a quelques semaines, on m’a confié ce monstre pour en faire un calculateur meteo de poche. Muni d’un Xen -c’est ce que j’ai proposé-, le laptop, modulo le support des instructions VT et assez de RAM, devra pouvoir faire tourner une version minimale de nos solutions.
Premier echec, le modèle initial était muni d’un chip Intel T5500, et comme on peut le lire sur cette page de wikipedia, ce CPU ne supporte pas les instructions VT.
Patience est mère de toutes les vertus, après quelques jours d’attente, je reçois donc le même modèle muni d’un T5600. Un rapide grep vmx /proc/cpuinfo finit de me rassurer.
Confiant, j’installe gentiement une debian des familles, apt-get install xen-blabla, reboot, nickel, ssh pwet: no route to host. “Qu’est-ce que…”, ifconfig -a: pas d’eth0. Et là, c’est le début de l’enfer, un tour rapide sur google me renseigne sur la detresse qui va être la mienne: le module b44, supportant la Broadcom 4400 qui munit ce laptop, ne fonctionne pas sous Xen 3.0.3 (une histoire sordide de DMA_BITS hardcodé à 31). Je hacke, je tweake, je backporte, avec panic‘s pour seuls résultats.
En désespoir de cause, je récupère, comme dit plus haut, la version binaire de Xen 3.0.4 et là… dhclient eth0, boum, ça marche.

Epilogue

Il a tout de même subsisté un petit stress, alors que je m’appretais à xm create mon premier domU hvm, je me vois rembarré par une erreur du style: “unable to start hvm, is your CPU VT/AMD-V compatible or is it enabled in your BIOS ?”. Eh bin non justement, c’est absolument pas enabled dans le BIOS pour la simple raison que ces petites truites de chez HP ne permettent pas, par defaut, d’agir sur l’activation des instructions VT du nx7400. Avouez que c’est quand même particulièrement crétin de vendre du matos de ouf sans fournir la possibilité de s’en servir. Fort heureusement, en fouillant un peu sur le site d’HP, je finis par découvrir un upgrade pour le bios en question, dont la mention “ready for Vista” ne laisse absolument pas présumer qu’il ajoute une entrée dans le BIOS: “Enable Virtualization Technology”.
Bref, flashage, reboot, activation du VT, reboot, et ?… crash de Xen.
C’est fatiguant un peu.
Reboot sur un kernel classique, las, je re-apt-get xen-blabla, re-install.sh du Xen 3.0.4 binaire, je traffique un peu mon menu.lst, et là, probablement parce ce laptop en avait plus qu’assez que je le maltraite, reboot et…ça-marche.
Pour finir, re-packaging d’un noyau Xenifié à l’aide de make-kpkg en utilisant le tarball source de XenSource, dpkg -i, et me voici enfin en possession d’une debian Xenifiée fonctionnelle sur un portable muni d’un CPU VT-capable.

J’f'rais pas ça tous les jours.

LVM, Xen et snapshots

iMil — Fri, 26 Jan 2007 15:32:03 +0000

Alors que j’étais plein d’entrain et que je m’apprétais à utiliser les snapshots LVM avec mon Xen, je lance, confiant, un

lvcreate -s -L2048M -n lvconvivial /dev/vgconvivial/base

et je me mange un

LV vgconvivial/lvconvivial in use: not deactivating
Couldn't deactivate new snapshot.

Je cherche donc un peu, et je tombe sur ça http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343671#msg20
Je m’empresse donc d’éditer le-dit udev-rules, comme mentionné dans le ticket, pis ça marche.

Tu notes ça dans un coin ?

rhaaa mais arrête de kiffer t’en fous partouuuut

iMil — Sat, 20 Jan 2007 13:40:42 +0000

Je pouvais evidemment pas résister à transformer tatooine, ma ws ubuntu, en convi-Xen0. Muni d’une carte graphique à base de chipset nvidia, j’avais lu de-ci de-la qu’il existait des patches pour faire fonctionner les drivers du malin sur un domaine 0.Voici donc les quelques liens sur lesquels je me suis basé ainsi que quelques confs

. Procédure de chez OpenSUSE pour patcher les-dits drivers

Perso, j’ai pas litteralement suivi la procédure, après patchage, j’ai simplement executé nvidia-installer, présent à la racine de l’archive NVIDIA-Linux-x86-1.0-9631-pkg1.

. Une doc fort bien concue sur la xenification d’une debian, l’adaptation à ubuntu est triviale

Mon /etc/network/interfaces :

auto xenbr0
iface xenbr0 inet static
  pre-up brctl addbr xenbr0
  post-up brctl addif xenbr0 eth0
  post-up ifconfig xenbr0 up
  post-up ifconfig eth0 up
  post-down brctl delbr xenbr0
  address 192.168.0.2
  netmask 255.255.255.0
  gateway 192.168.0.1
  bridge-ports eth0
  bridge_maxwait 0

Mon NetBSD-domU, basique :

kernel = "/home/xen/netbsd/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
name = "netbsd"
disk = [ 'file:/home/xen/netbsd/netbsd.qcow,ioemu:hda1,w',
	'file:/home/xen/netbsd/i386cd-3.1.iso,ioemu:hdc:cdrom,r' ]
vif = [ 'bridge=xenbr0' ]

Et le resultat :)

Addon

J’ai noté d’horribles ralentissements lors de l’utilisation intensive du disque virtuel, et après quelques recherches, je suis tombé sur ceci dans la FAQ de Xen :

2.3. Error about root device still mounted when it’s not mounted, zombie domU that can’t be killed, domU hangs under heavy I/O (e.g disk) access

This is an unresolved problem with Xen 3.0.

You may try to pass nousb to dom0 kernel command line, or pass ignorebiostables, or try to disable software IRQ affinity for 1850/2850 systems.

Et effectivement, après avoir ajouté l’option ignorebiostables dans mon menu.lst, tout semble réagir au poil :

title           XEN/2.6.17
root            (hd0,0)
kernel          /boot/xen-3.0-i386.gz ignorebiostables
module          /boot/xen0-linux-2.6.17-6-generic-xen0 root=UUID=387cb651-f182-4
b1f-a5b9-a2e5ef119d5a ro
module          /boot/xen0-linux-2.6.17-6-generic-xen0.initrd.img

MOI GNAIME PAS ÇA TOUS LES GNAGROUTS

iMil — Mon, 08 Jan 2007 16:57:25 +0000

Si ton Xen t’insulte tout plein avec des phrases du genre :

Error: Device (vbd) could not be connected. Backend device not found.

Pas de panique ami lutin, le pauvre Xen n’a juste tout plus de devices loopback à disposition. Rend leur heureux, et agrémente ton /etc/modprobe.conf de cette petite ligne magique :

options loop max_loop=64

Et tu pourras xm create tout plein de domaines supplémentaires.