VMware ESXi nie widzi datastore po restarcie – odzysk LUN [scenariusz korporacyjny]

Restart serwera VMware po awarii zasilania potrafi skończyć się brakiem dostępu do datastore i całej grupy maszyn wirtualnych. To scenariusz krytyczny, bo jedno pochopne działanie po starcie — re-scan, odbudowa RAID albo zapis w złym miejscu — może pogorszyć stan metadanych.

W tym materiale omawiamy typowe przyczyny znikającego datastore po restarcie oraz bezpieczną kolejność działań przy problemach z VMFS, LUN i macierzą. Datastore to magazyn danych maszyn wirtualnych, a LUN to logiczny wolumen udostępniany serwerowi przez macierz.

Opisujemy scenariusz środowiska VMware ESXi, w którym najważniejsza była metoda pracy: najpierw zabezpieczenie stanu, potem diagnoza VMFS i macierzy, a dopiero na końcu naprawa logiczna. W przypadku takich awarii warto zacząć od ścieżki B2B dla firm oraz analizy RAID/NAS, bez odbudów RAID wykonywanych "na ślepo".

Dlaczego datastore znika po restarcie serwera VMware

Po awarii zasilania ESXi może widzieć LUN jako dostępny, ale nie zamontować datastore VMFS. Przyczyną bywa uszkodzenie metadanych VMFS, błąd ścieżek multipath, problem z kontrolerem RAID albo niespójność po stronie macierzy SAN.

Wtedy w vSphere datastore może być oznaczony jako nieznany, a maszyny wirtualne stają się niedostępne. Nie warto usuwać datastore z inwentarza ani tworzyć go ponownie, dopóki nie wiadomo, czy metadane można jeszcze odczytać.

Objawy utraty datastore po restarcie

Jeśli LUN jest online na macierzy, ale ESXi nie montuje datastore, najpierw zabezpiecz logi i aktualny stan mapowania. Nie usuwaj LUN, nie twórz nowego datastore i nie wymuszaj zmian metadanych, dopóki nie wiadomo, czy problem dotyczy VMFS, ścieżek czy macierzy.

Przy problemach z LUN i VMFS pracuje się na zabezpieczonym obrazie lub kopii roboczej. Dopiero na niej analizuje się układ wolumenu, pliki VMDK i spójność maszyn wirtualnych.

Bezpieczna procedura przy utracie datastore

Przy zniknięciu datastore najpierw trzeba zabezpieczyć stan infrastruktury i przerwać przypadkowe próby naprawy. Warto zebrać logi, sprawdzić stan macierzy SAN, ustalić, którego LUN dotyczy problem, wykonać pełną kopię konfiguracji ESXi oraz, jeśli macierz na to pozwala, snapshot LUN przed kolejnymi działaniami.

Diagnostyka obejmuje obrazowanie dysków, analizę struktury RAID i odtworzenie układu macierzy w środowisku roboczym. Dopiero na tak przygotowanym materiale można szukać początku partycji VMFS i oceniać, czy da się bezpiecznie przywrócić dostęp do maszyn wirtualnych.

W takich przypadkach liczy się kolejność działań. Celem nie jest szybka próba naprawy na produkcji, tylko zachowanie możliwie pełnego obrazu środowiska, ograniczenie ryzyka nadpisania struktur i praca na kopii roboczej.

Scenariusz: wiele maszyn wirtualnych po restarcie ESXi

W podobnych awariach po planowanym restarcie serwera VMware może zniknąć część datastore'ów, a maszyny wirtualne nie startują mimo widocznego LUN. Wcześniejszy rescan adaptera pamięci masowej albo próba ponownego utworzenia datastore może naruszyć metadane, dlatego dalsze działania powinny zacząć się od zabezpieczenia stanu i odtworzenia układu poza środowiskiem produkcyjnym.

W laboratoryjnym podejściu proces dzieli się na etapy: zabezpieczenie nośników, obrazowanie, rekonstrukcja RAID lub LUN, analiza VMFS i weryfikacja maszyn. Dopiero po takim rozpoznaniu można określić, jaki zakres danych jest realnie dostępny i jak bezpiecznie planować dalsze uruchamianie usług.

Co przygotować przed kontaktem w sprawie środowiska VMware lub LUN

W przypadku środowisk firmowych najważniejsze są: topologia macierzy, liczba hostów, kolejność dysków, ostatnie operacje administracyjne i dokładny moment utraty datastore. Warto od razu zebrać logi, zrzuty komunikatów z ESXi oraz informację, czy po restarcie wykonywano rescan, remount albo jakiekolwiek próby naprawy VMFS. Dzięki temu szybciej da się ustalić, czy problem dotyczy warstwy logicznej, macierzy czy samego LUN. Pomocne mogą być też wpisy o odzysku danych z VMware, Hyper-V i SAN oraz awarii RAID w firmie.

Kiedy nie warto już improwizować po restarcie hosta

Jeżeli datastore nadal znika, część maszyn wirtualnych nie widzi plików, a panel pamięci masowej pokazuje błędy lub stan degraded, każdy kolejny restart i każda próba naprawy "na produkcji" zwiększa ryzyko przestoju. W takich sytuacjach lepiej wstrzymać dalsze operacje, zabezpieczyć informacje o konfiguracji i przejść do uporządkowanej diagnostyki. Gdy środowisko obsługuje systemy księgowe, ERP albo kopia zapasowa, sensownym krokiem jest też szybkie opisz host, datastore i LUN, zanim problem przejdzie z poziomu logicznego w wielowarstwową awarię całej infrastruktury.

Jak domknąć incydent bez dokładania ryzyka biznesowego

Jeżeli środowisko VMware obsługuje produkcję, system księgowy, ERP albo kluczowe maszyny wirtualne, liczy się nie tylko sam odzysk, ale też tempo i porządek działań. Najlepiej wtedy od razu wybrać uporządkowaną ścieżkę:

To bezpieczniejsze niż kolejne restarty, rescan albo improwizowana rekonstrukcja w działającym środowisku produkcyjnym.