Comment sortir de cette situation en toute sécurité ?
Les détails sont les suivants :
Un serveur xen a des périphériques de bloc alloués aux machines virtuelles. Mais ces dispositifs ont également été montés à l'intérieur de Xen.
En fait, 44 de ces dispositifs de bloc ont été montés comme ceci. Pour aggraver les choses, chaque périphérique physique est vu sur 4 chemins et chacun d'eux est monté sur un point de montage séparé. En d'autres termes, les appareils sont en fait montés 5 fois chacun.
Le système d'exploitation invité de la VM voit le chemin via un pseudo-périphérique PowerPath (alloué en tant que périphérique phy :bloc au domU)
Certains appareils sont formatés en ext2 et reiserfs.
Pas besoin de m'expliquer les risques de corruption du système de fichiers impliqués ici.
Je crains que même le simple démontage des systèmes de fichiers puisse entraîner une corruption, et je pense que à ce stade, retirer l'alimentation de l'hôte est l'option la plus sûre .
Notez que les applications, les bases de données Oracle pour la plupart, dans toutes les machines virtuelles sont toujours en cours d'exécution et en cours d'utilisation.
J'ai découvert cela lors d'une enquête sur l'utilisation élevée du processeur sur le dom0. Il existe un processus de "recherche" impossible à tuer, avec cwd -> /media/disk-12 qui est monté à partir de /dev/sdf1, qui appartient à /dev/emcpowerr
Avant que quelqu'un ne demande, la seule fois où j'ai vu des processus ne pas être tués et continuer à utiliser le CPU et la RAM (contrairement à un processus défunt/zombie), c'est quand il y a des E/S validées en suspens, par exemple la synchronisation est retournée mais pas encore physiquement sur le disque . Le plus souvent, cela se produit sur les E/S de bande.
Suggestions ! ?
PS Je me serais attendu à ce que les appareils soient "réservés" une fois montés, pour éviter ce genre de chose ? Ou n'est-ce pas possible sous Linux ?
EDIT :Tout d'abord, je suis convaincu que KDE dans l'hyperviseur) est le coupable. Il semble que KDE monte les périphériques qu'il peut sur la journalisation pour créer des icônes de bureau. La même chose ne se produit cependant pas sur les autres serveurs Xen, mais tous les autres serveurs exécutent une version beaucoup plus ancienne de SLES et de KDE… La V4 semble être la plus fautive, la 3.4 se comportant mieux).
De plus, deux machines virtuelles non critiques se sont bloquées. Après les avoir arrêtés, ils ne redémarreraient pas en raison de la corruption du système de fichiers. La machine virtuelle principale/de production est toujours en cours d'exécution et la base de données dessus fonctionne toujours, mais il s'agit clairement d'une bombe à retardement. Le client tente de reconstruire l'environnement sur une autre VM sur un autre serveur mais est bloqué sur des problèmes de configuration de certains composants, nous attendons donc…
En tout cas, j'ai l'impression qu'aucune des réponses n'a jusqu'à présent été plus que "la meilleure pratique est toujours fermée avec élégance" Et j'espère obtenir quelque chose de plus concret… En tout cas, je pense que cette situation peut justifier une réflexion plus approfondie. L'arrêt entraînera-t-il la synchronisation des E/S en attente, en particulier les mises à jour des métadonnées du système de fichiers à partir de l'hyperviseur, et entraînera-t-il une corruption majeure du système de fichiers ?
En relation :Obtenir plusieurs colonnes à partir d'une sous-requête de sélection ?Réponse acceptée :
Si les disques sont écrits à partir d'un seul point de montage, aucun mal n'est fait. Effectuez un arrêt propre (sauvegardez-le à partir de l'état suspendu si vous le souhaitez) fixez les supports. N'exécutez rien d'autre que les applications nécessaires sur le Dom0. Si, OTOH, les partitions sont écrites à partir de plusieurs chemins, c'est MAUVAIS et empire à la seconde. Débranchez la prise.