Przeniosłem maszynę z VMware i nie startuje: dysk jest, drogi do niego nie ma

Import się skończył, dysk widnieje na liście, maszyna startuje, a potem zatrzymuje się z komunikatem o urządzeniu startowym, do którego nie może dotrzeć. Pierwszy odruch to myśl, że coś przepadło przy konwersji. Prawie zawsze nic nie przepadło.

Dysk jest tam, gdzie powinien. Zmieniła się droga do niego.

Dlaczego tak się dzieje

Maszyna wirtualna nie rozmawia z dyskiem. Rozmawia z kontrolerem dysków, a kontroler jest częścią tego, co pokazuje jej hipernadzorca. VMware pokazywał jeden rodzaj. Proxmox pokazuje inny.

Byłoby to nieszkodliwe, gdyby gość ładował każdy sterownik, którego kiedykolwiek mógłby potrzebować. Nie ładuje. System operacyjny ładuje tylko mały zestaw sterowników, zanim uzyska dostęp do własnego dysku, a ten zestaw został ustalony w dniu instalacji. Jeśli kontrolera przed dyskiem tam nie ma, gość nie widzi niczego, z czego mógłby wystartować, i mówi to jedynym sposobem, jaki zna: nie ma urządzenia startowego.

Objaw wskazuje więc na dysk, a przyczyna leży warstwę wcześniej.

Dwie różne awarie, które wyglądają podobnie

Traktuje się je jak jeden problem, a nim nie są.

W ogóle brak urządzenia startowego. Często winne jest oprogramowanie układowe, a nie kontroler. Maszyna utworzona pod EFI nie wystartuje pod starym BIOS-em, i odwrotnie tak samo. Z dyskiem nic nie jest nie tak; maszyna jest uruchamiana w sposób, do którego nigdy jej nie instalowano.

Start się zaczyna, a potem zatrzymuje ze skargą na urządzenie startowe. To przypadek kontrolera. Oprogramowanie układowe było właściwe, program ładujący zadziałał, a potem jądro nie dotarło do wskazanego mu dysku.

Odróżnienie tych dwóch przypadków przed dotknięciem czegokolwiek oszczędza całe popołudnie, bo lekarstwa są różne, a zastosowanie złego dokłada drugi objaw do pierwszego.

Trzy pytania, zanim czegokolwiek dotkniesz

Czy dysk naprawdę jest podłączony do maszyny? Sprawdź konfigurację maszyny, nie magazyn. Zaimportowany dysk może istnieć w magazynie i nie być podłączony, a to poprawka na dwie sekundy wyglądająca jak katastrofa.

Pod jakim oprogramowaniem układowym tę maszynę instalowano? Jeśli przyszła ze środowiska EFI, potrzebuje takiego, a potrzebuje też miejsca na przechowywanie wpisów startowych.

Czy gość w ogóle ma sterownik nowego kontrolera? Nie "czy jest zainstalowany", tylko "czy istnieje wewnątrz tego obrazu dysku". Maszyna z Windows, która nigdy nie spotkała kontrolera VirtIO, tego sterownika nie ma i nie może go pobrać, dopóki nie wystartuje.

Droga, która pozostaje odwracalna

Są dwa podejścia i nie są jednakowo bezpieczne.

Daj gościowi kontroler, który już zna. Podłącz dysk do interfejsu, który gość obsługuje od dnia instalacji, wystartuj normalnie, zainstaluj nowy sterownik z wnętrza działającego systemu, wyłącz, a potem zmień kontroler. Każdy krok jest mały i każdy da się cofnąć.

Sztuczka, która czyni to bezbolesnym: przed zmianą podłącz drugi, malutki dysk nowego typu kontrolera. Gość wystartuje starą drogą, zobaczy nieznany sprzęt i pozwoli spokojnie zainstalować jego sterownik. Potem zmiana prawdziwego dysku przejdzie bez historii, bo sterownik już tam jest.

Wstrzyknąć sterownik do obrazu z zewnątrz. Szybciej i działa, ale jeśli nie zadziała, zostaje ci dochodzenie na obrazie, który jest teraz inny niż ten, od którego zaczynałeś. To właściwe narzędzie, gdy masz wiele maszyn i znany przepis. Dla pierwszej jest niewłaściwe.

⚠️ Zmieniaj jedną rzecz naraz. Oprogramowanie układowe i kontroler razem to najczęstszy sposób zamiany rozwiązywalnego problemu w niejasny: maszyna nadal nie startuje, a podejrzanych jest już dwóch.

Goście na Linuksie: ta sama przyczyna, cichszy objaw

Dzieje się to samo i czyta się inaczej. Program ładujący działa, a potem system stoi, czekając na urządzenie główne, które nigdy się nie pojawia. Powód jest identyczny: wczesny obraz startowy zbudowano bez sterownika nowego kontrolera, bo na starym hipernadzorcy nigdy nie był potrzebny.

Lekarstwo ma ten sam kształt. Wystartować z obrazu ratunkowego, przebudować wczesny obraz startowy ze sterownikiem w środku, i dopiero potem zmienić kontroler.

Czego nie robić

Nie buduj maszyny od nowa, żeby podpiąć do niej stary dysk. Nowa maszyna będzie miała ten sam kontroler i ten sam wynik, a teraz masz dwie maszyny do pilnowania.

Nie kasuj jeszcze maszyny źródłowej. Migracja kończy się, gdy nowa wystartowała, wykonała prawdziwą pracę i trafiła do kopii zapasowej. Nie wtedy, gdy kopiowanie dobiegło końca.

Nie zdziw się później szybkim uruchamianiem. Gość Windows wyłączony przy włączonym szybkim uruchamianiu nie wyłącza się do końca, więc zmiana sprzętu zrobiona w tym stanie trafia na system, który myśli, że wznawia, a nie startuje.

Co robi Atlas

Atlas umieszcza na jednym ekranie te dwie rzeczy, między którymi żyje ten problem. Widok sprzętu maszyny pokazuje razem dysk, kontroler, do którego jest podłączony, i ustawienie oprogramowania układowego, więc na pytanie "które z dwóch jest złe" odpowiada się patrząc, a nie próbując.

Łańcuch zasobów odpowiada też wprost na pierwsze z trzech pytań: mapa rysuje od maszyny aż po dysk fizyczny, więc dysk zaimportowany, ale nigdy niepodłączony, widocznie brakuje w łańcuchu, zamiast chować się na liście magazynów.

Zanim taka zmiana zostanie zastosowana, Atlas robi migawkę, żeby odwracalna droga pozostała odwracalna nawet wtedy, gdy gość zareaguje źle. Dotknięte zasoby są wypisane przed uruchomieniem, i właśnie to sprawia, że "jedna rzecz naraz" jest wykonalne, a nie tylko rozsądne.