VMware-ből átköltöztetett gép nem indul el: a lemez megvan, az odavezető út nincs

Az importálás befejeződött, a lemez szerepel a listában, a gép elindul, majd megáll egy üzenettel: nem éri el az indító eszközt. Ilyenkor az első gondolat az, hogy az átalakítás során elveszett valami. Szinte soha nem veszett el semmi.

A lemez ott van, ahol lennie kell. Az odavezető út változott meg.

Miért történik ez

A virtuális gép nem a lemezzel beszél. Egy lemezvezérlővel beszél, és a vezérlő része annak, amit a hypervisor felkínál neki. A VMware egyfajta vezérlőt kínált. A Proxmox másikat kínál.

Ez ártalmatlan lenne, ha a vendégrendszer minden szóba jöhető illesztőprogramot betöltene. Nem tölt be mindet. Az operációs rendszer csak egy szűk illesztőprogram-készletet tölt be, mielőtt hozzáférne a saját lemezéhez, és ez a készlet a telepítés napján dőlt el. Ha a lemez előtt álló vezérlő nincs benne ebben a készletben, a vendégrendszer nem lát semmit, amiről indulhatna, és ezt az egyetlen módon jelzi, ahogy tudja: nincs indító eszköz.

A tünet tehát a lemezre mutat, az ok pedig egy réteggel előtte van.

Két különböző hiba, amely egyformának látszik

Egyetlen problémaként kezelik őket, pedig nem azok.

Egyáltalán nincs indító eszköz. Ez gyakran a firmware kérdése, nem a vezérlőé. Az EFI alatt létrehozott gép nem indul el hagyományos BIOS alatt, és fordítva sem. A lemezzel semmi baj nincs: a gép olyan módon indul, amilyenre soha nem telepítették.

Az indulás elkezdődik, majd megáll, és az indító eszközre panaszkodik. Ez a vezérlő esete. A firmware jó volt, a betöltő lefutott, majd a kernel nem érte el azt a lemezt, amelyet használnia kellett volna.

A kettő megkülönböztetése még bármilyen módosítás előtt egy egész délutánt megspórol, mert a megoldás más és más, a rossz megoldás pedig az első tünet mellé egy másodikat is hoz.

Három kérdés minden beavatkozás előtt

Valóban a géphez van csatolva a lemez? A gép beállításait érdemes megnézni, nem a tárolót. Az importált lemez elhelyezkedhet úgy a tárolón, hogy közben egyetlen géphez sincs csatolva, és ez kétmásodperces javítás, amely katasztrófának látszik.

Milyen firmware alatt telepítették ezt a gépet? Ha EFI környezetből érkezett, akkor EFI kell neki, és kell egy hely is, ahol az indítási bejegyzéseit tárolja.

Megvan egyáltalán a vendégrendszerben az új vezérlő illesztőprogramja? Nem az a kérdés, hogy "telepítve van-e", hanem az, hogy "ott van-e a lemezképben". Az a Windows rendszer, amely soha nem találkozott VirtIO vezérlővel, nem rendelkezik ezzel az illesztőprogrammal, és nem is tudja beszerezni, amíg nem tud elindulni.

A visszafordítható megoldás

Két megközelítés létezik, és nem egyformán biztonságosak.

Olyan vezérlő adása a vendégrendszernek, amelyet már ismer. A lemezt olyan csatolófelületre kell kötni, amelyet a vendégrendszer a telepítés napja óta támogat, majd következik a szokásos indítás, az új illesztőprogram telepítése a futó rendszeren belülről, a leállítás, végül a vezérlő átváltása. Minden lépés kicsi, és mindegyik visszavonható.

A fogás, amitől ez fájdalommentessé válik: az átváltás előtt érdemes egy második, apró lemezt csatolni az új vezérlőtípuson. A vendégrendszer a régi úton indul, ismeretlen hardvert lát, és az illesztőprogram nyugodt körülmények között telepíthető hozzá. Ezután az igazi lemez átváltása eseménytelen, mert az illesztőprogram már a helyén van.

Az illesztőprogram beültetése a lemezképbe kívülről. Gyorsabb, és működik, de ha mégsem működik, olyan lemezképen kell hibát keresni, amely már nem azonos a kiindulóval. Sok gép és bevált recept esetén ez a megfelelő eszköz. Az elsőnél viszont nem ez a helyes eszköz.

⚠️ Egyszerre csak egy dolgot érdemes megváltoztatni. A firmware és a vezérlő együttes módosítása a leggyakoribb módja annak, hogy egy megoldható problémából áttekinthetetlen legyen: a gép továbbra sem indul, és már két gyanúsított van.

Linux vendégrendszerek: azonos ok, csendesebb tünet

Ugyanaz történik, csak másképp olvasható. A rendszerbetöltő lefut, majd a rendszer megáll, és olyan gyökéreszközre vár, amely soha nem jelenik meg. Az ok azonos: a korai indítási lemezkép az új vezérlő illesztőprogramja nélkül készült, mert a régi hypervisoron soha nem volt rá szükség.

A megoldás formája is ugyanaz. Indítás mentőlemezképről, a korai indítási lemezkép újraépítése az illesztőprogrammal együtt, és csak ezután a vezérlő átváltása.

Amit nem érdemes megtenni

A gép újraépítése és a régi lemez rácsatolása nem megoldás. Az új gépen ugyanaz a vezérlő lesz, és ugyanaz lesz az eredmény, viszont innentől két gépet kell nyilvántartani.

A forrásgép törlése még korai. A költöztetés akkor fejeződik be, amikor az új gép elindult, valódi munkát végzett, és készült róla biztonsági mentés. Nem akkor, amikor a másolás véget ér.

A gyorsindítás beállítása ne utólag okozzon meglepetést. A bekapcsolt gyorsindítással leállított Windows vendégrendszer nem áll le teljesen, így az ebben az állapotban végzett hardvermódosítást olyan rendszer fogadja, amely azt hiszi, folytatja a működést, nem pedig újraindul.

Mit tesz az Atlas

Az Atlas egy képernyőre teszi azt a két dolgot, amely között ez a probléma él. A gép hardvernézete együtt mutatja a lemezt, a hozzá tartozó vezérlőt és a firmware beállítást, így a "melyik a kettő közül a hibás" kérdés ránézésre megválaszolható, nem próbálgatással.

Az erőforráslánc a három kérdés közül az elsőt is közvetlenül megválaszolja: a térkép a gépet a fizikai lemezig lerajzolja, így az importált, de soha nem csatolt lemez láthatóan hiányzik a láncból, ahelyett hogy egy tárolólistában rejtőzne.

Az ilyen módosítás alkalmazása előtt az Atlas pillanatképet készít, így a visszafordítható út akkor is visszafordítható marad, ha a vendégrendszer rosszul reagál. Az érintett erőforrások a módosítás futtatása előtt fel vannak sorolva, és éppen ez teszi az egyszerre egy dolog megváltoztatását kivitelezhetővé, nem pusztán ajánlott elvvé.