64 / 2

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.