Parfois, une VM ne démarre pas, et on a besoin d'accéder à ses filesystems pour corriger le problème. Parfois, on veut juste accéder au contenu de l'image sans démarrer la VM. Pour tout le reste, il y a mastercard, mais pour accéder à notre image disque, il y a un peu plus de travail.

Dans l'exemple suivant, nous allons accéder aux volumes logiques LVM contenus dans une image brute (type="raw"), sur un hyperviseur KVM.

Montage des volumes

Attention : ne pas réaliser cette opération alors que la VM est active (ou a minima en s'assurant que tout montage se fait en read-only, et soyez prudents avec cette tronçonneuse, ça coupe).

Dans l'état initial, je n'ai qu'un seul vg visible sur l'hyperviseur :

# vgs
VG           #PV #LV #SN Attr   VSize   VFree
hypervg        1   3   0 wz--n- 247.22G 146.19G

Regardons maintenant quel est le premier device loopback disponible, et associons notre image disque à ce device :

# losetup -f
/dev/loop0
# losetup /dev/loop0 virtual-vdisk

Il faut maintenant détecter le partitionnement interne du fichier image pour le faire reconnaître par l'hyperviseur :

# kpartx -av /dev/loop0
add map loop0p1 : 0 256977 linear /dev/loop0 63
add map loop0p2 : 0 33559785 linear /dev/loop0 257040
add map loop0p3 : 0 33559785 linear /dev/loop0 33816825
add map loop0p4 : 0 2216970 linear /dev/loop0 67376610

La couche LVM de l'hyperviseur peut maintenant détecter le (ou les) VG contenu(s) dans l'image disque :

# vgs
VG           #PV #LV #SN Attr   VSize   VFree
hypervg        1   3   0 wz--n- 247.22G 146.19G
virtualvg      1   7   0 wz--n-  16.00G   7.50G

Si par hasard ce n'était pas visible directement, la commande "vgscan" force un rescan.

Il ne reste qu'à activer le VG pour pouvoir accéder aux LV :

# vgchange -ay virtualvg
7 logical volume(s) in volume group "virtualvg" now active
# mount /dev/virtualvg/rootfs /mnt

On peut monter de la même manière tous les LV de tous les VG contenus dans la VM. On peut également accéder à des partitions physiques directes, par exemple pour accéder au /boot de la VM qui correspond à la première partition :

# mount /dev/mapper/loop0p1 /mnt

Démontage des volumes

Le démontage, c'est à peu près la même chose à l'envers.

# umount /mnt
# vgchange -an virtualvg
# kpartx -dv /dev/loop0
del devmap : loop0p1
del devmap : loop0p2
del devmap : loop0p3
del devmap : loop0p4
# vgs
VG           #PV #LV #SN Attr   VSize   VFree
hypervg        1   3   0 wz--n- 247.22G 146.19G
# losetup -d /dev/loop0

Autres types de fichiers images

Ce genre d'opération est également possible avec d'autres types de fichiers images, voir par exemple cet article pour le montage d'images au format qcow2.

Il y a eu pas mal de problèmes documentés autour de la cohabitation ZFS/PowerPath, et j'en tiens un beau. Une LUN de ma connaissance est baladée occasionnellement entre plusieurs serveurs pour permettre des gros transferts de données avec un débit raisonnable. Pour des raisons de compatibilité entre les différents systèmes impliqués, j'ai créé un dataset ZFS sur une partition de cette LUN.

Le volume s'est promené entre différentes machines sans soucis, puis, un beau matin, au moment de la ramener sur un serveur, j'ai eu droit au tristement célèbre "insufficient replicas" :

monpool                     UNAVAIL  insufficient replicas
c5t5006000000000000d0s6  UNAVAIL  cannot open

Pourtant, ce même volume fonctionnait à merveille sur le serveur voisin (qui certes n'utilisait pas PowerPath, mais tout de même)!

En regardant d'un peu plus près, il s'avère que le système n'arrive pas à lire tous les labels, ce qui en soit ne devrait pas poser de soucis, c'est pour ça qu'ils sont redondés, mais ça indique tout de même un problème de détection du device :

# zdb -l /dev/dsk/c5t5006000000000000d0s6
--------------------------------------------
LABEL 0
--------------------------------------------
version=10
name='monpool'
state=1
[...]
--------------------------------------------
LABEL 1
--------------------------------------------
version=10
name='monpool'
state=1
[...]
--------------------------------------------
LABEL 2
--------------------------------------------
failed to read label 2
--------------------------------------------
LABEL 3
--------------------------------------------
failed to read label 3

Là encore, l'autre serveur voit les 4 labels correctement. Plus amusant encore, si on se réfère au device PowerPath, là, les 4 labels sont corrects!

# zdb -l /dev/dsk/emcpower123g
--------------------------------------------
LABEL 0
--------------------------------------------
version=10
name='monpool'
state=1
[...]
--------------------------------------------
LABEL 1
--------------------------------------------
version=10
name='monpool'
state=1
[...]
--------------------------------------------
LABEL 2
--------------------------------------------
version=10
name='monpool'
state=1
[...]
--------------------------------------------
LABEL 3
--------------------------------------------
version=10
name='monpool'
state=1
[...]

Aha! Voilà une piste sérieuse. Il est donc probable que le zpool import scanne le répertoire /dev/dsk et s'arrête à la première occurrence de mon pool, trouvée en /dev/dsk/c5tXXX, et ignore donc celle trouvée en /dev/dsk/emcpowerXXX. Malheureusement, il n'y a pas de moyen direct de forcer l'import avec un device spécifique. J'ai envisagé un moment de créer un nouveau lien sur le /dev/dsk/emcpower123g dans un autre répertoire, pour utiliser l'option -d du zpool import, mais ce type de manipulation m'ayant déjà planté un serveur, je n'étais pas très motivé.

Au final, un message obscur trouvé au fin fond des forums OpenSolaris m'a donné une idée, qui s'est avérée payante : un simple trespass de la LUN sur le Clariion a résolu le problème!

Il y a donc visiblement au moins deux incompréhensions entre ZFS et la couche PowerPath:

• d'une part, le fait que ZFS s'arrête aux devices cXtXdX en ignorant les emcpowerXXX (sans doute pour des raisons d'ordre alphabétique) est limitant
• d'autre part, dans le cas d'un chemin multipathé par PowerPath, il peut y avoir un problème d'I/O si on attaque un device cXtXdX sous-jacent plutôt que l'autre, selon le SP actuellement possesseur de la LUN. C'est d'ailleurs d'autant plus étrange que chaque fibre est reliée au deux SP, mais passons.

A noter, le serveur est configuré en actif/passif classique sur le Clariion (mode 1), il serait intéressant de voir ce que ça donne en ALUA (mode 4), mais il faut au moins du PowerPath 5.1 pour ça, et ma version installée est trop ancienne, c'est donc un test que je ne ferai pas.

Possesseur depuis peu d'un iPad, j'ai cherché un remplaçant au bon vieux TouchTerm que j'utilisais sur mon téléphone (téléchargé à l'époque où il était encore gratuit), ce dernier ne gérant pas la résolution native de l'iPad. Après un petit tour d'horizon, je n'ai trouvé qu'une seule application réellement gratuite, il s'agit de Rove Mobile Admin Client. L'application est à la base développée pour administrer une solution propriétaire de la société, mais les fonctionnalités de type SSH incluses sont accessibles indépendamment de leur suite d'outils. Ca ne fonctionne bien qu'en mode paysage, mais l'interface est sobre et claire.

A noter, une autre application du même type semble gratuite, mais limite en fait les sessions de la version d'essai à 150 touches pressées, il s'agit de zatelnet, à éviter donc si vous cherchez une solution gratuite.

J'ai récemment eu à supprimer et recréer une LUN sur un Clariion. Ladite LUN était présentée à la fois à un serveur Solaris 10 et à un serveur Linux, avec un filesystem ZFS créé sur la machine Linux et prévu pour servir d'espace de transfert.

Seulement, pas de chance, au moment de faire redécouvrir la LUN sur le serveur Solaris 10, impossible de la voir.

Les commandes que j'utilise habituellement pour cela sont les suivantes :

# cfgadm -al -o show_FCP_dev
# devfsadm -Cv
# powermt config

Sauf que, visiblement, ça ne suffisait pas :

# zpool import
no pools available to import

En creusant un peu, j'ai découvert qu'il restait des traces de la LUN supprimée, et qu'elle empêchait la prise en compte de la nouvelle sur le même numéro de device :

# powermt display dev=all                                                     
Pseudo name=emcpower77a
CLARiiON ID=CKMXXXXXXXX
Logical device ID=600601606FXXXXXXXXXXXXXXXX [MA_LUN]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0
Owner: default=SP B, current=SP B
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
### HW Path                 I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
3077 pci@8/SUNW,qlc@1          c3t500601623B207225d0s0 SP A2     active  dead       0      1
3077 pci@8/SUNW,qlc@1          c3t500601683B207225d0s0 SP B0     active  dead       0      1
3078 pci@8/SUNW,qlc@2          c5t500601603B207225d0s0 SP A0     active  dead       0      1
3078 pci@8/SUNW,qlc@2          c5t5006016A3B207225d0s0 SP B2     active  dead       0      1

Il fallait donc nettoyer tout ça et recréer le device proprement :

# powermt check                                                                                  
Warning: CLARiiON device path c3t500601623B207225d0s0 is currently dead.
Do you want to remove it (y/n/a/q)? a
Warning: CLARiiON device path c3t500601683B207225d0s0 is currently dead.
Warning: CLARiiON device path c5t500601603B207225d0s0 is currently dead.
Warning: CLARiiON device path c5t5006016A3B207225d0s0 is currently dead.
# powercf -q                                                                                     
Could not validate the entry:
---------------------------------------
emcpower77: user ID = fd00000268
---------------------------------------
removing emcpower77
# powermt config
# powermt display dev=emcpower77c                                                                
Pseudo name=emcpower77a
CLARiiON ID=CKM00104900008 [cesena]
Logical device ID=6006016069F02A000C1FADD01186E011 [TRANSFERT_BI]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0
Owner: default=SP B, current=SP B
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
### HW Path                 I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
3077 pci@8/SUNW,qlc@1          c3t500601623B207225d0s0 SP A2     active  alive      0      0
3077 pci@8/SUNW,qlc@1          c3t500601683B207225d0s0 SP B0     active  alive      0      0
3078 pci@8/SUNW,qlc@2          c5t500601603B207225d0s0 SP A0     active  alive      0      0
3078 pci@8/SUNW,qlc@2          c5t5006016A3B207225d0s0 SP B2     active  alive      0      0

Et voilà, notre nouvelle LUN est bien détectée.

Bien que le noyau Linux supporte nativement les filesystems ufs, la fonction n'est pas présente par défaut sur les RHEL. Voici comment l'activer sur une RHEL 5.5 - le principe sera le même sur d'autres versions, sachant que les versions plus récentes devraient pouvoir s'épargner la mise à jour du module-init-tools.

A cause d'un petit bug, une mise à jour mineure est nécessaire avant l'opération. On va donc télécharger le package module-init-tools-3.3-0.pre3.1.60.el5_5.1.x86_64.rpm chez RedHat  (souscription RHN nécessaire) et le mettre à jour.

# mount -o remount,rw /boot
# rpm -Uvh ./module-init-tools-3.3-0.pre3.1.60.el5_5.1.x86_64.rpm
Preparing...                ########################################### [100%]
1:module-init-tools      ########################################### [100%]

On télécharge ensuite le package kmod-ufs correspondant à notre version de RHEL, et on installe.

# rpm -ivh ./kmod-ufs-0.0-1.el5.elrepo.x86_64.rpm
warning: ./kmod-ufs-0.0-1.el5.elrepo.x86_64.rpm: Header V3 DSA signature: NOKEY,
key ID baadae52
Preparing...                ########################################### [100%]
1:kmod-ufs               ########################################### [100%]
Working. This may take some time ...
Done.

Et ça y est, on peut monter un filesystem ufs (dans l'exemple ci-dessous, le filesystem a été créé sur un serveur Sparc, directement dans un fichier) :

# mount -t ufs -o ro,loop,ufstype=sun ./testufs /mnt
# cd /mnt
/mnt# ls
lost+found  victory
/mnt# cat victory
Ca marche.

Quand on gère un serveur SMTP sortant, il peut arriver que l'on souhaite filtrer totalement les messages émis à destination d'un domaine, tout en donnant l'impression à l'émetteur que le message est bien parti. C'est le cas par exemple quand une plate-forme de test souhaite émettre de nombreux messages pour tester ses capacités d'envoi.

Après avoir essayé différentes approches, la plus élégante à mes yeux est l'utilisation de transport_maps, qui permet de spécifier des relais particuliers en fonction de la destination.

Déclarons tout d'abord un tel fichier dans le main.cf de Postfix :

transport_maps = dbm:/etc/postfix/trounoir_map

Notez ici que l'utilisation de dbm est un choix de portabilité, j'ai déjà eu à faire ce type d'opération sur des versions de Postfix compilées sans pcre, par exemple.

Le fichier en question peut contenir des lignes du type :

exemple.fr     discard:silently

Puisque j'ai spécifié un type dbm, il faut générer les maps à partir du fichier texte :

# postmap -c /etc/postfix /etc/postfix/trounoir_map

Il ne reste plus qu'à redémarrer postfix, et les messages à destination du domaine exemple.fr génèreront des entrées de ce type (notez le discard au début de la ligne et le silently à la fin) :

postfix/discard[3923]: [ID 197553 mail.info] 8E816F5D: to=<daniel@exemple.fr>, relay=none, 
delay=13, delays=13/0/0/0, dsn=2.0.0, status=sent (silently)

Dans un environnement hétérogène, il est possible que tous les serveurs n'utilisent pas la même version de NFS, certains étant encore en v3, d'autres en v4. Pour afficher la version utilisée par un montage spécifique, on peut utiliser la commande nfsstat :

# nfsstat -m /montage
/montage from serveur_nfs:/montage
Flags:         vers=4,proto=tcp,sec=sys,hard,intr,link,symlink,rsize=32768,wsize=32768,
retrans=5,timeo=600
Attr cache:    acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

Selon les cas, on verra vers=3 ou vers=4.

Oracle vient d'annoncer la sortie en 2011 du SPARC SuperCluster, une nouvelle gamme de serveurs complets pour faire tourner, bien entendu, de l'Oracle RAC. S'appuyant sur des processeurs T3, utilisant les extensions SSD Flashfire, et intégrant des boîtes de type ZFS Storage 7420, ces serveurs disposent également d'un switch InfiniBand interne.

Oracle nous propose donc là une bien belle solution rassemblant leurs évolutions techniques les plus intéressantes, et les performances sont au rendez-vous : d'après les benchmarks d'Oracle, le record de transactions par minute (TPM) serait pulvérisé, avec 30 millions de TPM, soit trois fois plus que le record actuellement détenu par une base DB2 sur une plate-forme IBM à base de Power 7. Les spécifications du serveur capable de ces performances ont elles aussi de quoi donner le tournis : 108 processeurs T3 (soit 1728 cores, ou 13 824 threads hardware!), 13 TB de mémoire, 246 TB de stockage SSD, et 1.7 PB de stockage total.

On peut imaginer que le prix de la solution sera en rapport.

Il arrive occasionnellement qu'un fichier soit effacé sur le filesystem malgré le fait qu'il soit toujours ouvert dans un processus. Ce problème, aussi connu sous le nom plus pragmatique de "mézouépassélespace", est dans l'immense majorité des cas un problème d'interface chaise-clavier, parfois également appelée erreur humaine.

Le symptôme typique de ce problème est une incohérence entre l'espace annoncé par df et celui annoncé par du, généralement détecté au moment où le filesystem est rempli.

Par exemple :

# df -h /xxx
Filesystem            Size  Used Avail    Use%    Mounted on
/dev/mapper/xxx
1G      1G     0    100%    /xxx

# du -sh /xxx
350M      /xxx

# lsof | grep deleted
coupable       1664   user    1w      REG    253,3    4  197939 /xxx/fichier (deleted)

La version Express de Solaris 11 est disponible chez Oracle. On notera entre autres la présence d'un LiveCD et l'absence de code source. Si ce dernier point vous gêne, allez plutôt voir du côté d'Illumos, le fork d'OpenSolaris réalisé par la communauté.

Parmi les éléments notables de Solaris 11 (par rapport à Solaris 10, bien sûr, la plupart de ces éléments étant depuis un bon moment dans OpenSolaris), on retrouve :

• Image Packaging System (IPS) : le nouveau (enfin!) système de gestion de paquets via le réseau, basé sur des repositories, dans la lignée des APT et autres YUM. La gestion des patchs est également intégrée, ceux-ci devenant simplement des nouvelles versions de paquets.
• Boot Environments (BE) : de multiples environnements de démarrage du système, basés sur les snapshots ZFS, que l'on peut mettre à jour indépendamment (notamment mettre à jour un BE inactif puis rebooter dessus).
• Automated Install : le successeur du jumpstart, capable d'installer des machines à partir d'un profil et d'un repository IPS
• Virtualisation réseau : le projet Crossbow a complètement abouti, et Solaris 11 dispose maintenant d'une virtualisation complète au niveau réseau : VNIC (interfaces complètement virtuelles, pouvant être dédiées à une zone), switchs virtuels, et routeurs virtuels, ainsi que des outils de contrôle de bande passante sur les interfaces réelles comme virtuelles.
• ZFS devient le fs par défaut pour le rootfs, et incorpore de nouvelles fonctionnalités : déduplication, dataset chiffrés, et diff entre des snapshots
• root est maintenant uniquement un rôle, et plus un compte
• Solaris 11 supporte les containers Solaris 10 (autrement dit, une zone qui se comporte comme une machine Solaris 10), et offre des fonctionnalités P2V/V2V pour migrer les serveurs ou zones Solaris 10 existants
• Support des processeurs T3
• Support NUMA amélioré
• Amélioration des performances DISM pour Oracle