Come posso uscire da questa situazione in sicurezza?
I dettagli sono i seguenti:
Un server xen ha dispositivi a blocchi allocati alle macchine virtuali. Ma questi dispositivi sono stati montati anche all'interno di Xen.
Infatti 44 di questi dispositivi a blocchi sono stati montati in questo modo. A peggiorare le cose, ogni dispositivo fisico è visto su 4 percorsi e ognuno di questi è montato su un punto di montaggio separato. In altre parole, i dispositivi vengono effettivamente montati 5 volte ciascuno.
Il sistema operativo guest VM vede il percorso tramite uno pseudo dispositivo PowerPath (allocato come phy:block device alla domU)
Alcuni dei dispositivi sono formattati come ext2 e reiserfs.
Non c'è bisogno di spiegarmi i rischi di corruzione del file system coinvolti qui.
Temo che anche solo smontare i file system possa causare il danneggiamento e ritengo che a questo punto estrarre l'alimentazione dall'host sia l'opzione più sicura .
Si noti che le applicazioni, per la maggior parte database Oracle, in tutte le macchine virtuali sono ancora in esecuzione e in uso.
L'ho scoperto durante l'analisi dell'utilizzo elevato della CPU sul dom0. C'è un processo "trova" impossibile da uccidere, con cwd -> /media/disk-12 che è montato da /dev/sdf1, che appartiene a /dev/emcpowerr
Prima che qualcuno lo chieda, l'unica volta in cui ho visto che i processi non possono essere uccisi e continuano a usare CPU e RAM (a differenza di un processo defunto/zombie), è quando ci sono I/O in sospeso, ad esempio la sincronizzazione è tornata ma non ancora fisicamente sul disco . Più comunemente ciò si verifica sull'I/O su nastro.
Suggerimenti!?
PS Mi sarei aspettato che i dispositivi fossero "riservati" una volta montati, per evitare questo genere di cose? O non è possibile su Linux?
EDIT:In primo luogo sono convinto che KDE all'interno dell'hypervisor) sia il colpevole. Sembra che KDE stia montando i dispositivi che può durante la registrazione per creare icone sul desktop. La stessa cosa, tuttavia, non sta accadendo su altri server Xen, ma tutti gli altri server eseguono una versione molto più vecchia di SLES e KDE ... V4 sembra essere quello offensivo, con 3.4 che si comporta meglio).
Inoltre, due VM non critiche si sono bloccate. Dopo averli spenti, non si sarebbero riavviati a causa della corruzione del file system. La VM principale/di produzione è ancora in esecuzione e il database su di essa funziona ancora, ma chiaramente questa è una bomba a orologeria. Il cliente sta tentando di ricostruire l'ambiente su un'altra VM su un altro server ma è bloccato su problemi di configurazione di alcuni componenti, quindi stiamo aspettando...
In ogni caso, sento che nessuna delle risposte finora è stata più che "la migliore pratica è sempre chiusa con grazia" E spero di ottenere qualcosa di più concreto... In ogni caso, sento che questa situazione potrebbe giustificare una riflessione più attenta. L'arresto causerà la sincronizzazione dell'IO in sospeso, in particolare gli aggiornamenti dei metadati del file system dall'hypervisor, e causerà un danneggiamento potenzialmente grave del file system?
Correlati:ottenere più colonne da una sottoquery selezionata?Risposta accettata:
Se i dischi vengono scritti da un singolo punto di montaggio, non viene fatto alcun danno. Esegui uno spegnimento pulito (se vuoi, esegui il backup dallo stato sospeso) correggi i supporti. Non eseguire nient'altro che le app necessarie su Dom0. Se, OTOH, le partizioni vengono scritte da più percorsi, è MALE e peggiora di secondo in secondo. Staccare la spina.