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 appareils ont également été montés à l'intérieur de Xen.
En fait, 44 de ces dispositifs à blocs ont été montés comme ceci. Pour aggraver les choses, chaque périphérique physique est vu sur 4 chemins et chacun d'entre 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é VM voit le chemin via un pseudo périphérique PowerPath (alloué en tant que périphérique phy: block 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 qu'à ce stade, couper 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 en étudiant une utilisation élevée du processeur sur le dom0. Il existe un processus de "recherche" impossible à éliminer, avec cwd -> / media / disk-12 qui est monté à partir de / dev / sdf1, qui appartient à / dev / emcpowerr
Avant que quiconque ne le demande, la seule fois où j'ai vu des processus ne peut pas être tué 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 attente, par exemple une synchronisation 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 au sein de l'hyperviseur) est le coupable. Il semble que KDE monte les périphériques qu'il peut lors de 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 KDE ... V4 semble être la version incriminée, la 3.4 se comportant mieux).
De plus, deux machines virtuelles non critiques ont été bloquées. Après les avoir arrêtés, ils ne redémarreraient pas en raison d'une 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 sur elle fonctionne toujours, mais il s'agit clairement d'une bombe à retardement. Le client tente de reconstruire l'environnement sur une autre machine virtuelle sur un autre serveur mais est bloqué par des problèmes de configuration de certains composants, nous attendons donc ...
En tout cas, j'estime qu'aucune des réponses n'a jusqu'à présent été plus que "les meilleures pratiques sont toujours fermées gracieusement" et j'espère obtenir quelque chose de plus concret ... En tout cas, j'estime que cette situation mérite une attention en pensant. L'arrêt entraînera-t-il la synchronisation des E / S en cours, en particulier les mises à jour des métadonnées du système de fichiers de l'hyperviseur, et entraînera-t-il une corruption potentiellement majeure du système de fichiers?