Demarrage d’un noyau Xen en réseau via PXE

Un article précédent décrit brièvement comment booter une machine sur le réseau en utilisant PXE. Je me suis donc amusé à booter, cette fois ci, non pas un noyau classique mais un moyau Xen. De prime abord cela pourrait sembler être semblable mais il n’en est rien !

L’utilisation de Xen demande de booter un premier noyau “gen.gz” qui va lui-même, par la suite, booter un second noyau compilé spécifiquement. L’utilisation de pxelinux.0 comme bootloader n’est donc plus possible dans un tel cas. Voici donc la procédure à suivre :

  • Il faut tout d’abord créer un noyau compatible Xen et acceptant un boot depuis le reseau, pour celà, je vous renvoie à l’article précédent qui indiques les options que celui-ci doit supporter. Ce noyau devra en outre être compilé pour une cible de type XEN.
  • Il faut ensuite récupérer un bootloader adapté, celui-ci se trouve dans le package Syslinux (il est possible qu’il ne soit pas livré avec votre distribution, il suffit alors de le télécharger sur le net). Le bootloader en question est mboot.c32 ; il se trouve dans syslinux/com32/modules. Ce fichier sera placé dans le répertoire tftpboot sur serveur.
  • La configuration de PXE se fait dans le fichier dhcp.conf, exactement comme nous l’avions fait précédemment. Rien ne change.
  • Dans le fichier de démarrage (tftpboot/pxelinux.cfg/mac-adress ) nous allons trouver la configuration suivantes :
    default linux
    label linux
      kernel mboot.c32
      append xen.gz dom0_mem=192000 --- vmlinuz_xen root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=10.0.0.20:/share/homeXen initrd=initrd_xen
    prompt   1
    timeout  10
    • Le noyau qui sera booté en premier est le fameux mboot.c32
    • Celui-ci va lancer la couche basse de XEN (xen.gz) qui est à récupérer dans le package de XEN
    • Le premier noyau va être configuré avec 192Mo de mémoire
    • Il va ensuite lancer le noyau linux compilé pour XEN : vmliuz_xen
    • Le boot se fera depuis le réseau, la configuration etant obtenue par dhcp
  • Le noyau ainsi démarré va encore poser un problème : lorsque XEN demarre en mode bridge, il tombe l’interface réseau, ce qui bien sure lors d’un boot NFS plante la suite du démarrage. Une des solution est l’utilisation du mode rootage plutot que bridge. Il faut modifier le fichier /etc/xen/xend-config.sxp :
    • Mettre en commentaire les deux lignes de confugration du bridge :(network-script network-bridge) et (vif-script vif-bridge)
    • Décommenter les lignes du mode routage : (network-script network-route) (vif-script vif-route)

    Pour ceux qui comme moi tiendraient vraiment à utiliser une configuration de type bridge, je n’ai rien trouvé de mieux que d’utiliser une seconde carte réseau sur la machine …

Utilisation d’un fichier comme SWAP avec Linux

Sur un pc sans disque (mais aussi parfois sur une machine virtuelle), il n’est par définition pas possible de créer une partition dédiée au swap, dans ce cas, il est possible d’utiliser un fichier en temps que swap.
La création consiste en les étapes suivantes :

  • Créer un fichier de swap : dd if=/dev/zero of=/swapfile bs=1024 count=xxx avec xxx = taille en Ko du swap
  • Créer en temps que swap : mkswap /swapfile
  • Il faut ensuite associer ce fichier à un périphérique : losetup /dev/loop0 /swapfile
  • Puis activer ce swap : swapon /dev/loop0

Créer un disquette de boot permettant de faire un demarrage PXE sans ROM réseau

Dans un précédent article, j’ai indiqué comment booter depuis un PC diskless en utilisant la fonction boot-pxe de la carte réseau. Toutefois sur un pc un peu ancien il est rare de trouver une carte supprotant le pxe… Dans ce cas, il y a une solution simple : créer une disquette de boot minimaliste avec les driver PXE pour ensuite demarrer sur le réseau. (je retrouve ainsi enfin une utilité à mon lecteur de disquette !! génial !)

La démarche est assez simple d’autant que tout est automatiser : il faut créer une disquette de boot sur le site suivant : http://rom-o-matic.net/5.4.2/

  • Choisir la carte réseau dans la liste
  • Choisir le format de sortie : Floppy bootable ROM image (.zdsk)
  • Choisir customize ROM Option et choisir :
    • USE_STATIC_BOOT_INFO en indiquant toute la configuration (je ne sais pour quelle raison, les infos dhcp ne sont pas reçu sur le client dans ma config)
    • PXELOADER_KEEP_ALL
  • Sélectionner le bouton “Get ROM”
  • ecrire le fichier sur une disquette : cat eb-5.4.2-driver.zdsk > /dev/fd0
  • configurer le serveur pxe comme indiqué dans le précédent article
  • booter !

Et voila … une machine sans disque dur qui boote sur le réseaux avec une carte réseau ne supportant pas PXE ;o)

Intégrer une carte mère de Dell Gx150 dans un PC standard

A destination de ceux qui comme moi souhaiteraient intégrer dans un boitier standard une carte mere de Dell Gx150 … C’est possible …
Tout d’abord il faut faire un peu de bricolage car avec Dell tout est presque standard ! Par exemple le panneau arrière est presque ATX … bref, il faut s’équiper d’une scie à métaux, d’un marteau, d’une perceuse … et c’est possible !

Ensuite l’etape ultime est la connexion des boutons de l’interface sur le connecteur “FrontPanel” non documenté … dont je vous livre ici les principaux secrets !

   A o o o C D   F o ... H o o
   B o o o o o E G o ... o o o

Le repere est la patte manquante entre D et F, les o indiquent les pattes dont je n’ai pas evalué l’usage. Pour le reste :

  • A & B : Speaker resp. – et +
  • C & D : Power Led resp. – et +
  • F & G : Power Switch
  • E & H : HDD Led resp. – et +

Bon bricolage !

Configuration mémoire d’une JVM (suite)

Suite a mon article sur un peu d’optimisation mémoire en Java, J’ai reçu une question interressante ; ma réponse me semble pouvoir être partagée en complément :

Je me demande si il existe une formule permettant de déterminer quelle taille maximum peut on allouer a l option -Xmx en fonction de la ram, de la taille des fichiers d’échange, …. Si tu as des infos …

En première approche, sans contexte, il ne me semble pas possible de répondre à cette question sous la forme d’une formule toutefois, voici les principaux éléments auxquels je pense :
Je ne pense pas qu’il y ait de formule magique … Java va utiliser la mémoire tant qu’il y en a, y compris s’il n’en a plus besoin en ne passant plus le GC, en tout cas jusqu’a atteindre Xmx – Xms … bref, ca va swapper et ce n’est pas forcement conseillé !
Tout dépend de ce que tu souhaites : éviter un crash de la JVM a tout prix ou preserver les performances. Si l’appli demande plus de mémoire qu’il n’y en a sur le système, je n’ai qu’un conseil : acheter de la RAM.

Pour mon usage personnel, je concidèrerai le paramétrage suivant (à noter qu’il ne s’agit que d’une borne max) :

Xmx – Xms < RAM_totale – RAM_utilisée_hors_JVM – marge (RAM_totale*0.1)

Ce qui peut être proche de :
Xmx < Xms + 0.9*RAM_libre

Ce qui ne répond qu’à moitier à la question puisqu’il reste à déterminer Xms.
Là, tout dépend de l’application ; plus Xms est grand plus tu augmentes Xmx dans mon équation et moins tu risques de saturer la mémoire de la JVM (si c’est le pbm) mais plus tu risques de swapper.
Par ailleurs, attention, si Xmx > RAM_totale tu pénalises les applications autres que Java car Java va utiliser toute la mémoire qu’on lui donne. Dans ce cas tu peux avoir des impacts très forts sur les applications telles que la base de donnée par exemple et pénaliser ton application… d’où bien prendre en compte la RAM_utilisée_hors_JVM et une marge pour ces applications.

Le risque en saturant la RAM est que lors d’un pic d’utilisation tu auras à la fois une JVM surchargée et des applications tierses sans mémoire = écroulement du serveur…(c’est peut-être une banalité ce que je dis là mais rien ne dis qu’il n’y aura pas de la perte de mémoire dans la JVM alors que les autres appli seront dejà HS)
Sauf contexte particulier, la RAM ne coute pas chere et les performances disques sont beaucoup trop médiocres … donc achetez de la RAM !

A l’opposé, si je peux aussi proposer un conseil à ceux qui ne cessent d’acheter de la RAM et voient toujours leur serveur saturés… jouez un peu sur les paramétrages, Java, mais d’autres appli comme Oracle commencent par se mettre la RAM sous le coude ou ne la libère que quand il n’y en a plus… bref, plus on en met et plus ca en consomme. De belles économies en perspective et un meilleurs partages des ressources pour les applications plus eco-citoyennes en quelque sorte.

Par aileurs, cette analyse ne tiens pas vraiment compte de la façon dont le système gère son cache. Hors pour ce qui est de linux, la mise en swap se fait par page mémoire (de l’ordre de 4K) On peut donc imaginer qu’une partie de la mémoire de la JVM, les objets non référencés mais pas encore libérés, va rapidement être mise en swap ; si necessaire et sans domage pour les performances. Alors, pourquoi ne pas libérer la mémoire de la JVM plus tot ? (on en revient à la formule initiale !). Autre impact : le risque de swapper des objets toujours référencés mais peu utilisés ce qui augmentera les temps de réponse sur ces objets. Je reste donc sur ma formule précédente.

Pour finir par un lien avec l’article précédent, Xms ne doit pas être trop grand sans quoi le garbage collector ne passera que rarement et la consommation mémoire “de croisière” pourrait être plus forte que nécessaire ; toutefois c’est à moindre mal.

EyeOs – le futur de l’informatique ?

EyeOs est ce que l’on pourrait appelé un OS riche en quelque sorte… sauf qu’il n’a pas grand chose à voir avec un OS. C’est en tout cas une application assurant la mise à disposition d’application, au travers d’un client léger, au sein d’une interface graphique semblable à celle des systèmes d’exploitation usuels.

EyesOs est plus un demonstrateur qu’un outil réellement utilisable. Il n’en reste pas moins qu’il s’agit d’un bel exemple des capacités liées aux technologies Ajax / Web2. D’un look & feel très proche de ce que propose meebo, EyesOs permet a un utilisateur identifié par un login / mdp d’accéder à un ensembles d’outils basiques tels qu’un calendrier, un traitement de texte simpliste …. le tout réunit dans une interface similaire aux gestionnaires de fenêtre de windows ou mac os X.

Ce qu’il y a d’intéressant :

  • Le menu d’accès aux applications au look mac-os, le choix de différents look & feel (dont mac-os X)
  • La possibilité de lancer plusieurs “application” en même temps
  • Manipuler ces applications comme on manipule des applications sur un système de gestion de fenêtre classique
  • Le fait que des applications hétérogènes cohabitent au sein de la même page web

On est encore loin du système d’exploitation intégré au client léger d’autant que l’on ne parle pas d’ordonnancement de tâches ni même de processus. Mais c’est un démonstrateur intéressant.

Il me semble que l’étape majeure qu’il reste à franchir est de standardiser sur ce type de portail des interfaces permettant à des applications tierces d’être intégrées ; le parc applicatif ainsi mis à disposition pourrait permettre de rendre ces systèmes plus attractifs.

Toutefois, quel intérêt y trouverons nous hors mis la prouesse technique ? C’est en quelque sorte une réinvention du terminal X, quelque couches logicielles en plus non ?

Nouveau passeport biométrique

Il est beau ! Un peu comme l’ancien, mais en bien mieux puisqu’il contient un puce contenant certaines informations comme mon nom, prénom, adresse, sexe, date et lieu de naissance mais aussi ma photo.

Alors je me pose (légitimement) la question suivante : Qui peut accéder à ces informations et à quelle distance ? A partir du moment où tous les aéroport de France et de navarre peuvent récupérer ces information, je considère qu’elles sont publique… reste à savoir à quelle distance elles peuvent être lues et là, j’ai peur qu’avec quelque moyens ad-hoc celle-ci puisse s’exprimer en mètres. Auquel cas je me pose la question suivante : quelle liberté me reste-t-il de manisfester par exemple sans être automatiquement identifié ?!?

Vous allez voir qu’en 2010 demander son n° de téléphone à une fille va être has-been !!

Controler la vitesse des ventilateurs d’une carte mère

Sur les dernières cartes mère, il est possible de contrôler via soft la vitesse des ventilateurs (fan-control). Cette fonctionnalité permer de jouer sensiblement sur le bruit de la machine.

Sur les carte MSI KT8 (utilisant un chip NForce 3 équipée d’un chip w83627thf) il est possible de controler la vitesse des ventilateurs au travers du périphérique associé dans /sys (pour peu que vous soyez bien en noyau 2.6)

La commande suivante permet celà :
echo $valeur > /sys/bus/i2c/devices/2-0290/pwm1
$valeur est un nombre entre 0 et 240. 0 étant l’arret complet du ventilateur. pwm1 correpond au premier ventilateur. La carte peut en gérer 3 qui seront alors pwm1, pwm2 et pwm3.