Bonjour,
Je gère des VM Debian sous VMware et j'ai un problème d'activation des périphériques LVM au boot. Gros problème : c'est aléatoire.
En résumé, *parfois* une VM ne peut pas démarrer car il lui manque un disque, si on se connecte sur la console de secours, on voit bien le LV et on peut l'activer et le monter à la main (donc le disque est bien là → c'est un problème d'activation). Si je ne fais aucune action et que je reboote la VM plantée, elle redémarre sans problème.
On a une utilisation très simple de LVM : 1 VMDK = 1 PV = 1 VG = 1 LV.
Le problème touche aussi bien des Debian 11 ou 12. On n'a aucun problème sur nos VM Red Hat & dérivés.
On a quelques spécificités mais rien de foufou :
- on créé nos PV directement sur les disques plutôt que sur des partitions LVM (pvcreate /dev/sdc et non pas pvcreate /dev/sdc1), cela nous permet d'étendre facilement les disques et les LV,
- on expose les UUID des disques à la VM, c'est la préférence disk.EnableUUID, cela permet à l'OS de voir les serial/wwn des disques et nous ça nous permet de faire le lien dans l'API vSphere,
- on utilise parfois le paramètre issue_discards=1 mais sinon on utilise la conf LVM par défaut de Debian,
- on utilise le boot BIOS, pas EFI.
J'ai essayé d'activer le debug LVM et pour l'instant ya rien de flagrant en cas de problème.
Les pistes :
- Debian peut « mélanger » les disques au démarrage : le disque qui est sur SCSI0:0 ne sera pas forcément /dev/sda alors que Red Hat respecte l'ordre, ça pourrait perturber l'activation LVM ?
- le mode de démarrage EFI qui serait plus fiable que le mode legacy ?
- utiliser une activation « basique » des périphériques LVM au lieu de passer par toutes les règles et les mécanismes qui sont là pour gérer les cas complexes ?
Si vous avez des idées je suis preneur.
En cherchant sur le net je trouve des problèmes similaires mais c'est souvent sur des PC ou des serveurs physiques qui ont des conf un peu spécifiques (multipath, LUKS, raid logiciel, etc.)
Bonne journée,
Le Mon, Dec 16, 2024 at 11:58:45AM +0100, Nicolas Cuissard via FRsAG [frsag@frsag.org] a écrit: (...)
Non, les PV ont un uuid qui sert a l'identifier, pas le nom du device.
Ce qui me semble le plus "probable" c'est que le device n'apparaisse que plus tard. Un "dmesg" sur le shell de l'initrd "bloque" peut le confirmer.
Ce que tu peux regarder ( tu ne precises pas ), c'est le type de peripherique virtuel utilise dans le Vmware, pour exposer le disque.
J'avais eu un problème similaire à ce que tu décris il y a quelques années : dans mon cas, comme mentionné par Dominique, le device apparaissait quelques secondes plus tard (mais trop tard par rapport au démarrage de la VM), et était visible en mode secours. Dans mon cas, un *rootdelay=60 rootwait* au niveau de grub avait permis de régler le souci.
Le 16/12/2024 à 12:13, Dominique Rousseau a écrit :
C'est vrai mais avant que LVM puisse découvrir les périphériques LVM, il faut que udev passe pour créer tous les liens entre les noms canoniques et les noms persistants des périphériques.
S'il y a du cache quelque part, sous Red Hat il n'y a rien à mettre à jour car rien ne change d'un démarrage à l'autre alors que sous Debian comme l'ordre des disques peut changer il y a un travail de redécouverte à faire.
Je lancerai un "dmesg" au prochain cas. Après ce serait étrange d'avoir un problème de timing sur du virtualisé...
Ce que tu peux regarder ( tu ne precises pas ), c'est le type de peripherique virtuel utilise dans le Vmware, pour exposer le disque.
On utilise le contrôleur de disque paravirtualisé donc c'est vraiment hyper standard :
description: Serial Attached SCSI controller produit: PVSCSI SCSI Controller fabriquant: VMware identifiant matériel: 0 information bus: pci@0000:03:00.0 nom logique: scsi0 version: 02 bits: 64 bits horloge: 33MHz fonctionnalités: sas pciexpress msi pm msix bus_master cap_list rom configuration: driver=vmw_pvscsi latency=0 ressources: irq:18 portE/S:4000(taille=8) mémoire:fd4f8000-fd4fffff mémoire:fd400000-fd40ffff
description: SCSI Disk produit: Virtual disk fabriquant: VMware identifiant matériel: 0.0.0 information bus: scsi@0:0.0.0 nom logique: /dev/sdb version: 2.0 numéro de série: 6000c29360459368b5764a2d1ae5a26c taille: 6GiB (6442MB) fonctionnalités: partitioned partitioned:dos configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512 signature=5c88addf
On 16/12/2024 11:58, Nicolas Cuissard via FRsAG wrote:
Bonjour, j'ai rencontré un problème similaire après avoir cloné des disques sur un serveur physique. De mémoire, une régénération d'initramfs (surement via tous ses hooks et mises à jour de cache) avait réglé la situation. Bien entendu avec le paquet lvm2 installé. Bonne soirée. Luc.
-
Dominique Rousseau -
Gaël SECHAUD -
Luc Bégault -
Nicolas Cuissard