Archives du mot-clef lenny

Debian devient (presque) “time based” !

Posté le by
Répondre

La nouvelle est sortie il y a deux jours, et elle va faire pas mal de remous dans les sphères linuxiennes : Debian change de mode de release !
Pour le coup, on peut vraiment parler d’une révolution chez la distribution à la spirale :D

Je ne vais pas faire de gros billet là-dessus, d’autres le feront mieux que moi, j’essaye pour l’instant d’en imaginer les conséquences et de formuler quelques observations.

Concrètement, dorénavant, la version Testing freezera obligatoirement en décembre de chaque année impaire (donc Décembre 2009 pour Squeeze, Décembre 2011 pour Squeeze+1, …), et la release se fera dans l’année qui suivra, dans l’idéal au printemps.
Le cycle complet sera donc de deux ans.

C’est de là que vient mon “presque” du titre : en effet, au lieu de déterminer à l’avance la date de sortie (date butoir qui affecte directement la qualité finale de la distribution) comme le fait Ubuntu, c’est uniquement la date de freeze qui est bloquée, seules les fonctionnalités seront affectées (donc au pire, une fonctionnalité prévue pourra être écartée si elle n’est pas prête à temps).

Comme solution intermédiaire, je la trouve plutôt intelligente, les durées sont suffisamment grandes pour pouvoir développer sereinement la distribution et consacrer du temps à la résolution de bugs (4-5 mois), et elle donne beaucoup plus de visibilité sur le planning à venir.
(rappelons-nous du ridicule de l’annonce prématurée de la sortie de Lenny en septembre, alors qu’elle ne vit le jour qu’en février, soit 5 mois plus tard)

Sur la volonté de synchronisation avec Ubuntu LTS, cela pose pas mal de questions (voir le billet de Lucas Nussbaum) mais tant que l’impact n’est pas trop grand sur la qualité de Debian, ça m’importe peu.
Et si ça permet de meilleures LTS pour Ubuntu, tant mieux.
Lucas pointe d’ailleurs un élément intéressant : les LTS d’Ubuntu sortiront finalement presque en même temps que les releases de Debian, ce qui va les rendre vraiment très semblables à chaque fois. Il va être intéressant de voir comment elles se différencieront.

La durée de 2 ans est un assez bon équilibre pour la cible visée par Debian stable (d’autant plus que les versions intermédiaires “-n-a-half” arriveront à la moitié de la vie de chaque stable, apportant leur lot de support matériel supplémentaire)
Et en encadrant bien les releases dans le temps, ça rassurera pas mal de gens qui avaient plutôt tendance à préférer Ubuntu Server pour ne pas avancer vers l’inconnu.

Maintenant, à la communauté et aux développeurs Debian de faire en sorte que la qualité de Debian n’en pâtisse pas.

Je leur fais confiance là-dessus ;)
(d’autant plus que Lenny a été développée en 22 mois, soit 2 mois de moins que ce que ce nouveau cycle permettra)

Échanger deux disques sans perte avec LVM

Posté le by
1

Je viens de recevoir une commande de la semaine dernière, portant sur une jolie petite bête : un Seagate 7200.12 1To 32Mo :p

Ce disque me sert a remplacer le disque de 320Go qui tourne actuellement pour la partie stockage/NAS de mon serveur, 320Go qui est destiné a réintégrer mon desktop, il n’était dans le serveur que temporairement.

Ayant conçu dès le départ l’espace de stockage comme étant nécessairement modulaire (je veux pouvoir étendre l’espace disque simplement en rajoutant un disque à chaud, en en enlevant un, etc …), je l’ai mis en place avec LVM.

Aujourd’hui je vais donc ajouter le nouveau disque au groupe de volumes puis retirer l’ancien pour qu’il n’y ait plus que le nouveau utilisé dans le groupe.

L’existant

Pour la partie stockage je n’ai donc qu’un volume physique (mon 320Go), un groupe de volumes (“vg_data”), et un seul volume logique (“fichiers”), formaté en Ext3.

hippo:~# pvdisplay
 --- Physical volume ---
 PV Name               /dev/sdc1
 VG Name               vg_data
 PV Size               298,09 GB / not usable 2,81 MB
 Allocatable           yes (but full)
 PE Size (KByte)       4096
 Total PE              76310
 Free PE               0
 Allocated PE          76310
 PV UUID               wlwUyT-XhIG-G2FO-Azxi-12HX-xx4e-U4GO0J

 --- Physical volume ---
 PV Name               /dev/md0
 VG Name               vg_system
 PV Size               232,65 GB / not usable 1,38 MB
 Allocatable           yes
 PE Size (KByte)       4096
 Total PE              59557
 Free PE               47075
 Allocated PE          12482
 PV UUID               lexqD6-B9pR-htYi-uBQu-v15N-mpK5-vgRDDN
hippo:~# vgdisplay
 --- Volume group ---
 VG Name               vg_data
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  2
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                1
 Open LV               1
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               298,09 GB
 PE Size               4,00 MB
 Total PE              76310
 Alloc PE / Size       76310 / 298,09 GB
 Free  PE / Size       0 / 0
 VG UUID               wgtYBn-UvcL-V31e-gOsf-Kdf3-GheH-TiMBLx

 --- Volume group ---
 VG Name               vg_system
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  22
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                10
 Open LV               10
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               232,64 GB
 PE Size               4,00 MB
 Total PE              59557
 Alloc PE / Size       12482 / 48,76 GB
 Free  PE / Size       47075 / 183,89 GB
 VG UUID               KMYKeg-AOqC-nUte-BZyS-T3te-05JS-CtjDD8

(/dev/md0 est mon volume physique RAID-1 qui me sert à stocker le système et les DomU, il est attribué à un autre groupe de volumes, vg_system.)

/dev/sdc1 est mon disque de 320Go, attribué à vg_data.
(oui, j’ai pris l’habitude d’initialiser mes volumes physiques sur une partition prenant tout l’espace du disque, plutôt que directement sur le disque – /dev/sdc1 plutôt que /dev/sdc)

Quasi toutes les opérations suivantes peuvent être effectuées à chaud et volume monté, mais par propreté, j’ai préféré stopper le DomU de stockage ;)

Préparation du nouveau disque dur

Confort du S-ATA, on peut se permettre de brancher le disque à chaud, ce que j’ai fait, et aussitôt, /dev/sdd fait son apparition.

Un petit coup de cfdisk pour créer une partition prenant l’intégralité du disque :

hippo:~# cfdisk /dev/sdd
[...]
Disk has been changed.

WARNING: If you have created or modified any
DOS 6.x partitions, please see the cfdisk manual
page for additional information.

De suite, on initialise comme volume physique cette nouvelle partition sdd1 :

hippo:~# pvcreate /dev/sdd1
 Physical volume "/dev/sdd1" successfully created

On ajoute ce nouveau volume physique au groupe de volume existant :

hippo:~# vgextend vg_data /dev/sdd1
 Volume group "vg_data" successfully extended

À ce moment-là, mon groupe de volumes est étendu sur les deux disques durs, le 320Go et le 1To :

hippo:~# vgdisplay
 --- Volume group ---
 VG Name               vg_data
 System ID
 Format                lvm2
 Metadata Areas        2
 Metadata Sequence No  3
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                1
 Open LV               1
 Max PV                0
 Cur PV                2
 Act PV                2
 VG Size               1,20 TB
 PE Size               4,00 MB
 Total PE              314776
 Alloc PE / Size       76310 / 298,09 GB
 Free  PE / Size       238466 / 931,51 GB
 VG UUID               wgtYBn-UvcL-V31e-gOsf-Kdf3-GheH-TiMBLx
[...]

Sauf que ce que cherche à accomplir, c’est de ne plus utiliser que le disque de 1To pour ce groupe de volumes.

Sortir le premier disque dur du groupe de volumes

Voilà la situation des deux disques concernés :

hippo:~# pvdisplay
 --- Physical volume ---
 PV Name               /dev/sdc1
 VG Name               vg_data
 PV Size               298,09 GB / not usable 2,81 MB
 Allocatable           yes (but full)
 PE Size (KByte)       4096
 Total PE              76310
 Free PE               0
 Allocated PE          76310
 PV UUID               wlwUyT-XhIG-G2FO-Azxi-12HX-xx4e-U4GO0J

 --- Physical volume ---
 PV Name               /dev/sdd1
 VG Name               vg_data
 PV Size               931,51 GB / not usable 3,19 MB
 Allocatable           yes
 PE Size (KByte)       4096
 Total PE              238466
 Free PE               238466
 Allocated PE          0
 PV UUID               ij945a-IFIn-12qa-qOqG-Z1cb-nG2H-l9WwNH
 [...]

On constate que même si sdd1 fait partie de vg_data, aucun de ses physical extents (PE) n’est utilisé, et pour cause, toutes les données sont restées sur sdc1.
On ne peut donc pas l’enlever tout de suite, on va d’abord devoir migrer toutes les données de sdc1 vers le reste du groupe de volumes, le vider en quelque sorte. ;)

Une simple petite commande :

hippo:~# pvmove -v /dev/sdc1
 Finding volume group "vg_data"
 Archiving volume group "vg_data" metadata (seqno 3).
 Creating logical volume pvmove0
 Moving 76310 extents of logical volume vg_data/fichiers
 Found volume group "vg_data"
 Updating volume group metadata
 Creating volume group backup "/etc/lvm/backup/vg_data" (seqno 4).
 Found volume group "vg_data"
 Found volume group "vg_data"
 Suspending vg_data-fichiers (253:10) with device flush
 Found volume group "vg_data"
 Creating vg_data-pvmove0
 Loading vg_data-pvmove0 table
 Resuming vg_data-pvmove0 (253:11)
 Found volume group "vg_data"
 Loading vg_data-pvmove0 table
 Suppressed vg_data-pvmove0 identical table reload.
 Loading vg_data-fichiers table
 Resuming vg_data-fichiers (253:10)
 Checking progress every 15 seconds
/dev/sdc1: Moved: 0,2%
/dev/sdc1: Moved: 0,5%

[...]

 /dev/sdc1: Moved: 99,9%
 /dev/sdc1: Moved: 100,0%
 Found volume group "vg_data"
 Found volume group "vg_data"
 Loading vg_data-fichiers table
 Suspending vg_data-fichiers (253:10) with device flush
 Suspending vg_data-pvmove0 (253:11) with device flush
 Found volume group "vg_data"
 Found volume group "vg_data"
 Found volume group "vg_data"
 Resuming vg_data-pvmove0 (253:11)
 Found volume group "vg_data"
 Resuming vg_data-fichiers (253:10)
 Found volume group "vg_data"
 Removing vg_data-pvmove0 (253:11)
 Found volume group "vg_data"
 Removing temporary pvmove LV
 Writing out final volume group after pvmove
 Creating volume group backup "/etc/lvm/backup/vg_data" (seqno 6).

Une heure et demie plus tard, voilà le résultat :

hippo:~# pvdisplay
 --- Physical volume ---
 PV Name               /dev/sdc1
 VG Name               vg_data
 PV Size               298,09 GB / not usable 2,81 MB
 Allocatable           yes
 PE Size (KByte)       4096
 Total PE              76310
 Free PE               76310
 Allocated PE          0
 PV UUID               wlwUyT-XhIG-G2FO-Azxi-12HX-xx4e-U4GO0J

 --- Physical volume ---
 PV Name               /dev/sdd1
 VG Name               vg_data
 PV Size               931,51 GB / not usable 3,19 MB
 Allocatable           yes
 PE Size (KByte)       4096
 Total PE              238466
 Free PE               162156
Allocated PE          76310
 PV UUID               ij945a-IFIn-12qa-qOqG-Z1cb-nG2H-l9WwNH
[...]

sdc1 est désormais vidé (allocated PE à 0), tous les PE sont passés sur sdd1.

Le disque est désormais retirable du groupe de volumes :

hippo:~# vgreduce vg_data /dev/sdc1
 Removed "/dev/sdc1" from volume group "vg_data"

Je l’éteins de façon logicielle pour pouvoir le débrancher à chaud :

hippo:~# hdparm -Y /dev/sdc

/dev/sdc:
 issuing sleep command

Je le débranche donc et je le retire du serveur :)

Redimensionnements

Mais si le groupe de volumes occupe désormais le disque de 1To, le volume logique “fichiers” (la “partition” finale sous LVM) fait toujours l’ancienne taille (donc à peu près 300Go).

Il faut l’étendre, je demande donc à ce qu’il occupe la totalité du groupe de volumes :

hippo:~# lvextend -l 100%VG /dev/vg_data/fichiers
 Extending logical volume fichiers to 931,51 GB
 Logical volume fichiers successfully resized

Étape finale, il faut maintenant redimensionner le système de fichiers Ext3 pour qu’il utilise la totalité du volume logique, car il fait encore 300Go.
C’est uniquement pendant cette étape que le système de fichiers doit être démonté.

hippo:~# resize2fs /dev/vg_data/fichiers
resize2fs 1.41.3 (12-Oct-2008)
SVP exécutez « e2fsck -f /dev/vg_data/fichiers » d'abord.

Soit, je m’exécute :

hippo:~# e2fsck -f /dev/vg_data/fichiers
e2fsck 1.41.3 (12-Oct-2008)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
/lost+found n'a pas été trouvé. Créer<o>? oui

Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe

/dev/vg_data/fichiers: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
/dev/vg_data/fichiers : 127313/19537920 fichiers (2.6% non contigus), 71360208/78141440 blocs

Puis :

hippo:~# resize2fs /dev/vg_data/fichiers
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/vg_data/fichiers to 244189184 (4k) blocks.
Le système de fichiers /dev/vg_data/fichiers a maintenant une taille de 244189184 blocs.

Et le résultat, dans mon DomU de partage de fichiers :

hippo-nas:~# df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/xvda1            6,0G  583M  5,1G  11% /
tmpfs                 513M     0  513M   0% /lib/init/rw
udev                   10M   16K   10M   1% /dev
tmpfs                 513M  4,0K  513M   1% /dev/shm
/dev/xvda2            917G  268G  603G  31% /var/fichiers

La voilà, ma grosse partition :D

Grapiller un peu de place

Mais pas assez grosse à mon goût, en effet, avec un disque de 1To, seulement 268+603 = 871Go d’espace exploitable, ça fait un peu mal.

Le journal Ext3, les inodes, et le marketing des fabricants font certes perdre un peu de place, mais pas autant, et pour cause : Ext3, par défaut pour des raisons de fiabilité du système, réserve 5% d’espace disque à root.
5%, dans l’absolu c’est peu, mais sur un disque de 1To, ça représente quand même 50Go, dommage, surtout pour un volume qui n’est pas du tout destiné à stocker des fichiers système.

Je rabaisse donc cette réservation à 0% (la manipulation peut se faire avec le système de fichiers monté) :

hippo-nas:~# tune2fs -m0 /dev/xvda2
tune2fs 1.41.3 (12-Oct-2008)
Initialisation du pourcentage de blocs réservés à 0% (0 blocs)

Le résultat parle de lui-même :

hippo-nas:~# df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/xvda1            6,0G  583M  5,1G  11% /
tmpfs                 513M     0  513M   0% /lib/init/rw
udev                   10M   16K   10M   1% /dev
tmpfs                 513M  4,0K  513M   1% /dev/shm
/dev/xvda2            917G  268G  650G  30% /var/fichiers

47Go miraculeusement retrouvés !

L’opération est désormais terminée, j’ai plein d’espace à remplir et j’ai libéré mon 320Go pour qu’il parte vers d’autres horizons. :D

LVM, c’est le bien

J’espère que cet article vous aura donné envie d’utiliser LVM : on voit comment, avec des commandes simples (LVM a cette beauté d’utiliser une commande par action, au lieu de multiplier les options sur la même commande), on peut réaliser des opérations très puissantes sur nos précieuses données, et gérer avec souplesse son matériel.

Par rapport à du partitionnement classique, ça peut sembler un peu nébuleux, mais il ne faut pas hésiter à lire des tutoriaux, et l’essentiel est de garder à l’esprit l’arborescence :
Disque > Volume physique > Groupe de volumes > Volumes logiques > Systèmes de fichiers

Évidemment, j’aurais bien pu simplement formater directement le nouveau disque, lancer un rsync de l’ancien vers le nouveau, et modifier le montage pour aboutir au même résultat.
Mais ç’aurait été moins nerd, n’est-ce pas ? ;)

Et surtout, avec plus de deux disques, les choses seraient devenues beaucoup moins simples.

Pour conclure : utilisez LVM !

Nouveau serveur, les détails

Posté le by
8

Comme promis, quelques détails concernant le nouveau serveur de Hippopota.me : il est donc opérationnel depuis la semaine dernière, la migration s’est très bien faite (hormis deux-trois bêtises de ma part, c’était prévisible :D ) et tout tourne parfaitement.

Comparé à l’ancien (un petit P3 1Ghz avec 256Mo de RAM et un disque de 250Go IDE, sous Ubuntu Server 7.10), j’ai fait les choses en grand ;)

Un nouveau hardware

Laissez-moi donc vous le présenter :

Son hostname est “hippo”, pour la base il s’agit d’un PC constitué d’un processeur Core 2 Duo E4400 et de 4 Gio de PC2-6400, montés sur une carte mère Gigabyte GA-EP35-DS3.

C’est tout simplement mon ancien PC desktop, que j’ai reconverti ;)
(et dans un nouveau boîtier)

Concernant la partie “disques” :

  • Un binôme de deux disques de 250 Gio (Samsung Spinpoint P120 & Hitachi P7K500) forme un RAID-1 soft qui a pour mission d’héberger le système et les machines virtuelles (j’y reviendrai ;) ). Le but étant d’assurer une continuité en cas de défaillance d’un disque, et éviter de perdre toute la configuration.
  • Un disque de 320 Gio (Samsung Spinpoint F1) s’occupe pour l’instant du stockage de nos fichiers persos. “Pour l’instant” car il est amené à être remplacé prochainement par du plus gros, normalement un 1 Tio.

Petite parenthèse “software” : j’ai tout partitionné en LVM, je peux donc repartitionner à loisir, ajouter et retirer des disques, faire des snapshots, … dans la joie et l’allégresse.

Niveau réseau, je profite de la puce Realtek 1Gbps intégrée, et j’ai ajouté une Intel PRO/100 PCI qui s’occupe du trafic sortant vers Internet (le port 1Gbps étant réservé au réseau local).
Je vais bientôt ajouter une deuxième Intel PRO/100 (le temps de la retrouver) qui sera dédiée à l’administration du serveur.
Il y a enfin une carte Leadtek DTV 1000 T que j’utiliserai pour faire du streaming TNT en local.

Pas de carte graphique ni d’écran ou de clavier, tout est administré par SSH.

Le tout est alimenté pour l’instant par une Seasonic S12 550W (bientôt remplacée par une Corsair CX400W) et assemblé à l’intérieur d’un Antec Three Hundred.

(l’OCZ Vendetta n’est là que temporairement)

Donc une configuration plutôt puissante pour l’usage, mais bon, le but est aussi de se faire plaisir, et c’est également le cas pour la partie software :D

Du software qui arrache

Le système d’exploitation devient donc Debian, en version 5.0 (Lenny) et x86_64 mais, grosse subtilité, il tourne derrière l’hyperviseur libre Xen, en version 3.2-1 :D

De la virtualisation avec un hyperviseur

Sur ce qu’est un hyperviseur, je ne vais pas réinventer la roue, en me contentant de citer Wikipedia :

En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une machine physique en même temps.

L’hyperviseur est un noyau hôte allégé et optimisé pour ne faire tourner que des noyaux d’OS invités adaptés et optimisés pour tourner sur cette architecture spécifique, les OS invités ayant conscience d’être virtualisés.

Concrètement, ça me permet de faire fonctionner plusieurs OS en même temps sur le même serveur, de les affecter par exemple à telle ou telle carte réseau (ou utiliser des vlan), afin d’obtenir le même résultat qu’en ayant plusieurs machines, mais avec les contraintes d’une seule (consommation électrique, encombrement, …).

La différence avec un logiciel comme VirtualBox, c’est qu’il s’agit ici de para-virtualisation (PV) : l’OS invité est modifié pour pouvoir tourner au dessus de l’hyperviseur.
On comprend donc bien que cela n’est possible qu’avec des OS libres : actuellement on peut faire tourner du Linux, NetBSD, OpenSolaris et FreeBSD (expérimentalement pour l’instant).

Xen supporte également la virtualisation complète (HVM), mais :

  • Il est nécessaire de posséder un processeur disposant des instructions de virtualisation hardware (VT chez Intel, AMD-v chez AMD)
  • Les performances sont bien inférieures à du PV

Alors qu’en PV, n’importe quel processeur x86 ou x86_64 est supporté, et les performances sont de l’ordre de 80-90% du natif.

Néanmoins, cela permet de faire fonctionner un Windows comme machine virtuelle de Xen.
(c’est se donner beaucoup de mal pour faire tourner un mauvais OS, vous en conviendrez :D )

Sous Xen, il existe deux types de machines virtuelles, qui sont appelées “domaines” :

  • Le Domaine 0 (Dom0) : Il ne faut pas le confondre avec l’OS hôte, ici l’OS hôte c’est Xen, le Dom0 n’est qu’un système invité, une machine virtuelle, même si il est un peu spécial.
    Il ne peut y en avoir qu’un sur la machine (et il est indispensable), c’est la machine virtuelle principale, celle à laquelle l’hyperviseur accorde tous les privilèges liés au matériel et la seule qui peut gérer les autres machines virtuelles. C’est aussi à l’intérieur du Dom0 que sont transmises toutes les tâches d’I/O liées aux disques et au réseau, entre autres.
    Sa sécurité est capitale, quiconque prend la main sur le Dom0 peut administrer toutes les autres machines virtuelles.
  • Les DomU : ce sont les machines virtuelles qui n’ont aucun privilège matériel accordé par Xen, elles ne peuvent accéder qu’aux ressources qu’on leur accorde dans leur fichier de configuration.

Typiquement, pour des impératifs de sécurité et de performance, il faut faire tourner le moins de choses possible dans le Dom0 (et même rien du tout, si possible) et blinder le plus possible sa sécurité, pour faire tourner les services dans différents DomU, que l’on segmentera selon ses besoins.
Il est théoriquement possible de faire tourner autant de DomU que l’on veut, les seules limites seront matérielles (la mémoire est en général le facteur limitant).

Chaque DomU est un système indépendant (un kernel propre à chacun, et la possibilité de faire tourner des systèmes différents). Pour la sécurité, c’est un gros avantage, car si l’on a bien conçu son réseau et ses domaines, la perte d’un DomU n’entame pas la sécurité des autres.
De la même manière, diversifier ses DomU (OpenSolaris, NetBSD, Linux) permet de ne pas “mettre tous ses oeufs dans le même panier”, encore un avantage du point de vue sécurité.

En pratique

Sur mon serveur, il y a donc deux DomU différents pour la partie web : un DomU pour la base de données, et un autre pour Apache/PHP. Ils sont situés sur la partie “exposée” (DMZ) de mon réseau.

J’ai également un autre DomU qui me sert de NAS (NFS & Samba), situé directement sur mon réseau local.

Pour l’instant, tous mes DomU sont des Debian Lenny x86_64.

En lançant diverses commandes depuis le Dom0, on peut gérer ses domaines, ici par exemple pour afficher l’état des domaines qui tournent :

hippo:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   946     1     r-----   6105.4
hippo-mysql                                 13   512     1     -b----     29.8
hippo-nas                                   11  1024     1     -b----     32.4
hippo-web                                   12  1024     1     -b----    193.5

(on peut observer dans l’ordre mon Dom0, puis mes 3 DomU, leur ID à ce moment-là, leur quantité de RAM allouée, le nombre de CPU virtuels affectés à chacun, leur état (ici “blocked” c’est à dire en idle) et l’utilisation totale CPU pour chacun.)

Pour se logger sur un domaine, on le fait soit classiquement par SSH (ou un autre moyen type VNC, …), soit directement depuis le Dom0 avec un “xm console <nomdudomU>”.

Il y a aussi un “top” spécifique, qui affiche en temps réel l’occupation en ressources de chaque domaine, etc … toutes les commandes sont décrites dans le manuel.

Les possibilités sont vraiment immenses, pour peu que l’on prenne le temps de lire la doc et de regarder un peu comment tout fonctionne.

Au final

Bref, ayant mis tout ça en place, j’en suis bien content, ça tourne à merveille et c’est vraiment sympa à faire :)
(en plus c’est un truc de nerd, ce qui ne gâche rien)

A l’avenir ça va évoluer, le nombre de DomU augmentera avec l’ajout de services de streaming, réseau, internet, mail, …

Cet article pourrait faire des pages entières, je pense pour l’instant me contenter de cette présentation succinte, et sûrement faire des articles au fur et à mesure sur des points précis de la configuration, mais n’hésitez pas à me demander des choses plus précises dans les commentaires (en même temps je ne fais que débuter dans le domaine …)

Cet article était surtout une manière de vous présenter ma jolie machine et de vous faire part de ma satisfaction quant à la manière dont je l’ai réalisée :)

Ah, j’allais oublier, la petite tradition pour chaque nouvelle machine, un petit “uname -a” s’impose :

Linux hippo 2.6.26-2-xen-amd64 #1 SMP Wed May 13 18:43:45 UTC 2009 x86_64 GNU/Linux

Longue vie à lui ! ;)


Quelques références sur Xen :

Debian 5.0 “Lenny” est stable !

Posté le by
2

Grand jour que ce 14 février, qui est non seulement celui de la Saint-Valentin (que je passe au lit, mais malheureusement pas en charmante compagnie, je suis malade à crever – et oui, tout ce que je trouve à faire, c’est de blogger :D ),  mais également, comme prévu, celui de la réalisation de l’arlésienne : le passage de Debian Lenny en Stable :D

L’annonce est ici.

La distribution de référence en matière de stabilité (les esprits taquins parleront plutôt de vétusté) et de liberté, est donc enfin disponible dans sa nouvelle version 5.0, après 22 mois de développement en tant que version Testing.

(toutes les versions de Debian portent le nom d’un des personnages de Toy Story, Lenny est la paire de jumelles :) )

Si Lenny devient stable, cet évènement a d’autres conséquences :

  • Le passage de Debian 4.0 “Etch” au statut “Oldstable”, et le début du compte à rebours pour la fin de son support, d’une durée d’un an à partir d’aujourd’hui, c’est le temps que les utilisateurs de Etch ont pour migrer.
  • La fin du freeze de Sid, il va donc y avoir des évolutions de paquets en pagaille :D
  • Et enfin, la création d’une nouvelle Testing, de son petit nom “Squeeze”, l’extra-terrestre à 3 yeux, toujours dans Toy Story :

Bon vent à Lenny et Squeeze donc !

PS : les images ISO ne sont pas encore disponibles, pas de panique, elles sont en cours de création et devraient être prêtes cette nuit.

PS2 : le serveur de hippopota.me va sûrement passer à Lenny cette année, en effet, il tourne depuis le début sous Ubuntu Server, héritage de mes débuts sous GNU/Linux :) (et je dois dire que ça a toujours tourné très bien)

PS3 : post depuis mon Acer Aspire One tout neuf, je vous en reparle bientôt ;)

Edit : images d’installation dispo !