Jak bezpiecznie wyjść z tej sytuacji?
Szczegóły są następujące:
Serwer Xen ma przypisane urządzenia blokowe do maszyn wirtualnych. Ale te urządzenia zostały również zamontowane w Xen.
W rzeczywistości 44 z tych urządzeń blokowych zostało zamontowanych w ten sposób. Co gorsza, każde urządzenie fizyczne jest widoczne przez 4 ścieżki i każde z nich jest zamontowane na osobnym punkcie montowania. Innymi słowy, urządzenia są faktycznie montowane 5 razy.
System operacyjny gościa VM widzi ścieżkę za pośrednictwem pseudo urządzenia PowerPath (przydzielonego jako urządzenie phy: block do domU)
Niektóre urządzenia są sformatowane jako ext2 i reiserfs.
Nie muszę wyjaśniać ryzyka związanego z uszkodzeniem systemu plików.
Obawiam się, że nawet samo odmontowanie systemu plików może spowodować uszkodzenie i uważam, że w tym momencie odłączenie zasilania od hosta jest najbezpieczniejszą opcją .
Należy pamiętać, że aplikacje, w większości bazy danych Oracle, na wszystkich maszynach wirtualnych są nadal uruchomione i używane.
Odkryłem to podczas badania wysokiego zużycia procesora na dom0. Istnieje niemożliwy do zabrania proces „znajdowania”, w którym cwd -> / media / disk-12 jest montowany z / dev / sdf1, który należy do / dev / emcpowerr
Zanim ktokolwiek zapyta, raz widziałem, że procesy nie mogą zostać zabite i nadal używają procesora i pamięci RAM (w przeciwieństwie do nieistniejącego procesu / zombie), kiedy występują zaległe operacje we / wy, np. Synchronizacja zwrócona, ale jeszcze fizycznie na dysku . Częściej występuje to na taśmach I / O.
Propozycje!?
PS Oczekiwałbym, że urządzenia zostaną „zarezerwowane” po zamontowaniu, aby zapobiec tego typu rzeczom? Czy to nie jest możliwe w Linuksie?
EDYCJA: Po pierwsze jestem przekonany, że winowajcą jest KDE w hiperwizorze). Wygląda na to, że KDE montuje urządzenia, które może zalogować podczas tworzenia ikon pulpitu. To samo nie dzieje się jednak na innych serwerach Xen, ale na wszystkich pozostałych serwerach działa znacznie starsza wersja SLES, a KDE ... V4 wydaje się być winny, a 3.4 zachowuje się lepiej.
Ponadto zawieszono dwie niekrytyczne maszyny wirtualne. Po ich zamknięciu nie uruchomią się ponownie z powodu uszkodzenia systemu plików. Główna / produkcyjna maszyna wirtualna nadal działa, a baza danych nadal działa, ale najwyraźniej jest to bomba zegarowa. Klient próbuje odbudować środowisko na innej maszynie wirtualnej na innym serwerze, ale utknął na problemach z konfiguracją niektórych składników, dlatego czekamy ...
W każdym razie uważam, że jak dotąd żadna z odpowiedzi nie była czymś więcej niż „najlepsza praktyka jest zawsze zamykana z wdziękiem” I mam nadzieję, że uda mi się uzyskać coś bardziej konkretnego… W każdym razie uważam, że ta sytuacja może wymagać większej ostrożności myślący. Czy zamknięcie spowoduje zsynchronizowanie zaległych operacji we / wy, w szczególności aktualizacji metadanych systemu plików z hiperwizora, i może spowodować potencjalnie poważne uszkodzenie systemu plików?