Archívum

Archive for the ‘Virtual Server/Hyper-V’ Category

BIOS vs Hyper-V

szeptember 28, 2020 Hozzászólás

Adott helyen egy tavaly vásárolt szerver mellé idén vettek egy másodikat, fürtözés céljából. Ebből a gondolatmenetből kifolyólag ugyanolyan gyártó, ugyanolyan típus lett véve, majd az újra is telepítették a Win2019-et.

Előkészítés után (tartományba léptetés, iSCSI beállítások, stb) után sikeresen létrehozták a fürtöt, majd következett a tesztelés: egy adott Hyper-V virtuális gép mozgatása. S itt jött az érdekes hibaüzenet:

System 21502:

Live migration of ‘Virtual Machine VM1’ failed.

Virtual machine migration operation for ‘VM1’ failed at migration destination ‘H1’.

The virtual machine ‘VM1’ is using processor-specific features not supported on physical computer ‘H1’. To allow for migration of this virtual machine to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine.

Ekkor nyomták meg a piros gombot.

A hibakeresés során természetesen ellenőriztük a gépek, azon belül kiemelten a procik adatait, amelyek megegyeztek. Időközben viszont jött az első tippjük és egyben kérésük: eszükbe jutott, hogy tavaly még Legacy (BIOS) módban történt a Windows telepítése, idén pedig már UEFI módban. Kérték, hogy mielőbb továbbmegyünk, lehetőség szerint tegyem át a régit is UEFI-módba. Szerencsére korszerű oprendszerrel dolgozva, nincs sok tennivalónk: egy teljes körű mentés után – kis üzemszünettel számolva – át tudjuk állítani.

Emelt szinten futtassuk az MBR2GPT parancsot, előbb csak validálás üzemmódban, megbizonyosodva, hogy valóban működhet a konverzió. Ha nincs gond, akkor futtassuk újra, most már élesben, s hamarosan jelzi, hogy a gép készen áll az újraindításra. Az oprendszer elindulásához ne felejtsük BIOS-ban átállítani a Boot-folyamatot UEFI módba, s jó esetben ki is pipálhatjuk ezt a kérdést.

Adott helyen a Windows sikeres indítása után volt még egy apró gond, ugyanis a VM-ek nem voltak hajlandóak elindulni:

“Virtual Machine could not be started because the hypervisor is not running”

Ellenőrizve a BCD-t, megtaláljuk a hibát, amit az alábbi sorral orvosoltunk:

bcdedit /set hypervisorlaunchtype Auto

Ezt is rendbetéve, jöhetett a valódi probléma körbejárása. Természetesen megoldhattuk volna úgy, hogy a VM-eknél egyesével bekapcsoljuk a processzornál a kompatibilitást, de akik ismernek, tudják, hogy szeretem körbejárni alaposan a problémát (B-tervnek természetesen ott van ez is).

Néhány célzott keresés vezetett erre a cikkre. Nos, ellenőrizve, igaz, hogy már a tavalyi gépen található BIOS sem volt régi, bőven a Spectre utáni, de azóta kijött még két verzió, amelyek az új gépre már felkerültek. Szerencsére a gyártó honlapján volt leírás a BIOS-verziók újdonságairól, így amikor azt láttam, hogy “Updated the Processor Microcode“, reménysugár csillant meg az alagút végén. A letöltés, majd telepítés után valóban megnyugodhattunk, ugyanis a problémás hibaüzenet már nem jelentkezett, a mozgatás is sikerült.

A kollégáknak is tanulság volt, hogy a driverek, javítófoltok stb mellett érdemes figyelni a BIOS-verziókra is – főleg egy fürt tagjai esetén, hiszen eltérő verziók esetén ilyen gond is felmerülhet 🙂

Kategóriák:Virtual Server/Hyper-V Címkék: , ,

Hyper-V apróságok

június 18, 2020 Hozzászólás

Kissé el vagyok havazva, így most csak két apróságot jegyzek fel:

  1. Management konzol “History” törlés

Néha zavaró tud lenni, ha egy megszűnt/elgépelt Hyper-V gazdagép nevét látjuk a varázslókban (gazdagép hozzáadása, replika létrehozása, stb), de szerencsére könnyen orvosolható.

Természetesen bezárt Hyper-V Manager konzol mellett nyissuk meg az %AppData%\Microsoft\Windows\Hyper-V\Client\1.0\ könyvtárat, majd itt a VMBrowser.Config állományt nevezzük át/töröljük.

  1. VM mozgatás

Amennyiben egy másik gépre mozgatjuk a VM-et, szétválasztva szokás szerint a konfigurációs állományokat a virtuális lemezektől, ugyanakkor a gépre bízva az útvonalválasztást (Move virtual machine / Move virtual machine’s data by selecting where to move the items / Move the virtual machine’s data automatically), egy “apróságra” érdemes figyelni.

Hiába van bármi beállítva a cél Hyper-V konfigjában, a varázsló ugyanolyan betűjelű meghajtóra akarja tenni a virtuális lemezeket, mint a forrás oldalon – tehát ha nincs/nem elérhető az a meghajtó, hibát fog dobni. Megoldása itt sem bonyolult, a virtuális lemezek mozgatása oldalon más opciót választunk. Természetesen a Hyper-V-VMMS eseménynapló itt is segít, ha elakadnánk a hiba felderítésében…

VM nem indul automatikusan

szeptember 25, 2019 Hozzászólás

Adott helyen felmerült a kérdés, hogy egy adott VM miért nem indul el automatikusan, amikor a host-ot újraindítják. A srácok nem igazán értették, ezért a mélyebb megértéshez elővettük az Application naplót, konkrétabban a Microsoft/Windows/Hyper-V-Worker/Admin eseménytárat, abban az alábbi megjelenő 4 hibaüzenetet (időrendi sorrendben alább):

12162: ‘VM’: Failed to configure ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’: The storage where the virtual hard disk is located does not support virtual hard disk sharing.

12140: ‘VM’: Failed to open attachment ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’. Error: ‘A virtual disk support provider for the specified file was not found.’ (7864368). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12010: ‘VM’ Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error ‘A virtual disk support provider for the specified file was not found.’ (0xC03A0014). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12030: ‘VM’ failed to start. (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

Ami furcsa, hogy mivel Gen1-es gép boot-lemezéről van szó, ezért értelemszerűen csak IDE-s vezérlő jöhet szóba, s természetesen arra is van kötve (virtual hard disk sharing pedig csak scsi csatoló esetén jöhet szóba). Ugyanakkor feltűnhet, hogy a másik hibaüzenet az, hogy nem találja az állományt.

Akkor gondoljuk végig. Amennyiben kézzel indítjuk a virtuális gépet, akkor csont nélkül elindul – tehát az állomány létezik, van elég jogosultság hozzáférni. Nézzük, akkor melyik köteten van, valamint van-e még másik VM boot ugyanitt: igen, van, az pedig automatikusan el is indul.

Igen ám, de a kötet milyen lemezen van? Nos, egy iscsi LUN-ról beszélünk, tehát még az is lehet, hogy azért nem találja a kötetet (s ezzel együtt az állományt), mert még nincs felcsatolódva, amikor elindul a VM. Ennek az elméletnek igazolása után meg is fejtettük a dolgot, egy kérdés maradt még hátra: ha ez így van, akkor a másik VM (ugyanerről a kötetről) miért indul el? Erre megkaptuk a választ, amint belenéztünk a beállításokba: azért, mert az 120sec-es időkésleltetéssel volt indítva.

A probléma feltárva, a megoldást már a srácokra bíztam (ezt is késleltetik, átteszik másik kötetre, stb), pipa 🙂

Hyper-V VM-ek vCPU

november 23, 2018 Hozzászólás

Bár utána lehet nézni a neten, egyik kolléga tőlem kérdezte meg, hogy „Egy Hoston lévő fizikai processzor magok számánál, lehet-e több magot kiosztani a vm-ek közt?”

Nos, a válasz* nem egyszerű igen vagy nem, hanem attól függ (s itt jöhetne egy kétopciós válasz (2016 előtt és után), de kicsit menjünk részleteibe).

Kezdjük a szerver oprendszerű gazdagépekkel. Ha Windows 2008/R2 fut a host-on, akkor a Microsoft által támogatott vCPU-k száma 4 (azért ez a megfogalmazás, mert technikailag megoldható ennek a határnak az átlépése, de az már nem lesz támogatott).

Ha 2012/R2 a gazdagép, akkor már képbe jön a vendég-gép oprendszere is (szerencsére a 2012 R2 esetén megjelenő Gen2 még nem), ideális esetben számolhatunk 64-el – de max a logikai processzorok száma (Logical processors = Sockets * Cores * HyperThreading).

Ha 2016 vagy 2019-ről beszélünk, akkor még bonyolultabb a válasz, ugyanis képbe jön a VM generációja, illetve a vendég OS fajtája: korszerű OS esetén (2016, 2019) G1 VM-nél 64 vCPU, G2 VM-nél 240 vCPU-ig tornászható fel a szám (még ha fizikailag nincs is annyi, de ez – a méretezés – már egy másik téma). Amennyiben 2012 R2, 2012 vagy 2008 R2-nk van, akkor egységesen 64 vCPU a limit, „sima” 2008 esetén pedig max 8.

Amennyiben Windows 10-es host-ról van szó, akkor kicsit változhatnak a számok.

* Ismerve a kollégát, értettem a kérdését is – ugyanis lehet méretezésre is gondolni, de ő most konkrétan nem azt akarta kérdezni 🙂

Ismét Win10 RS3

december 4, 2017 2 hozzászólás

Nem gondoltam volna, hogy ilyen hamar sor kerül az előző cikk folytatására… Igaz, hogy az utolsó gondolatokban említettem a VLan-ozás problémáját, de azt nem sejtettem, hogy milyen bug-ot feature-t építenek a kollégák ebbe az őszi frissítésbe.

Kezdjük azzal, hogy ha valaki szeretne VLan-t használni a Win10-en, akkor switch-független megoldásként két fő lehetősége van: vagy használja a hálókártya gyártójának saját programját (ha van), ami le tudja kezelni a vlan-tageket, vagy feltelepíti a Hyper-V komponenst, létrehoz egy External típusú virtuális switchet, amibe beteszi a pipát és a VLan-azonosítót. Előbbivel az a gond, hogy vagy van ilyen program, vagy nincs; ha nem egységes a hálózat, akkor esetenként különböző programokat kell használni; esetleg a program nem kompatibilis valamilyen más programmal. Utóbbi esetén hátrány lehet, hogy fent van a virtualizációs komponens (további réteg meg biztonsági megfontolások, ugyebár), illetve ennek előzménye a megfelelő hardver (no igen, soha senki nem vesz virtualizációt nem tudó gépet, mert olyan khm… nem is létezik).

No de visszatérve a fő csapásra. Adva vannak a gépek, szépen beállítva, mindegyiken ott figyel a Vlan. Erre jön az őszi frissítés, ami szépen csili-vili gépet varázsol az ócskaságból – egy apró hibával. A jól beállított, Vlan-al rendelkező virtuális switch-ből eltünteti a VLan taget és a Vlan-kapcsoló pipát, ráadásul úgy, hogy szürkévé teszi a bekapcsolás lehetőségét. Nem akartam nagyon a mélyére ásni, hogy ezt milyen megfontolásból, inkább a probléma megszüntetése volt előtérben.

Első körben természetesen a legegyszerűbb megoldás jutott eszembe: törölni a virtuális kapcsolót, s újat létrehozni megfelelő beállításokkal. Igen ám, de az új létrehozásakor mindenféle hibát dobott ki, mely szerint valamit nem talál, nincs ilyen, stb. Eseménynaplót ellenőrizve kiderül, hogy a hálózati kártya azonosítójával van baja, azt nem tudja megemészteni. A kártya letiltása, engedélyezése nem segít, egyedül az oldotta meg számomra a problémát, ha a kártyát eltávolítottam (driver maradhat), illetve ismét felismertettem vele – ezután már csont nélkül létre lehetett hozni a kapcsolót.

Ha belegondolok, hogy egy nagyobb cég esetén ezt tömegesen kell(ene) elvégezni, csak azt tudom mondani, hogy kösz MS.

Hyper-V: Default switch

november 20, 2017 2 hozzászólás

Aki már váltott a Windows 10 1709-es verziójára, s netalán telepítve volt (vagy utólag telepíti) a Hyper-V komponens(t), meglepődve tapasztalhatja, hogy alapból létrejön egy „Default switch” nevű virtuális kapcsoló, aminek alapbeállításain nem tudunk módosítani, sőt, eltávolítani sem tudjuk. Ennek kapcsán felmerült néhány gondolatom, a teljesség igénye nélkül.

Bár történetét tekintve állítólag ez a kapcsoló egy régi felhasználói kérés, bizonyos szempontból nem igazán nyerte el a tetszésem. De mielőtt elmondanám a gondjaim, lássuk, milyen célt is szolgál:
– a hozzá csatlakoztatott gépek NAT-on keresztül kilátnak a hálózatra, elvileg attól függetlenül, hogy vezetékesen vagy vezeték nélkül csatlakozik a gazda-gép
– minden Win10 gépen azonos azonosítóval (GUID) rendelkezik, így a VM-ek mozgatása ezek között nem okoz fejfájást (eddig külön szoktunk erre figyelni)

Ez szép és jó, de miért nem tetszik? Nos, egyrészt kezdjük azzal, hogy mindenki kap a gazdagépen egy újabb hálózati csatlakozót (természetesen azokra gondolok, akiknek telepítve van a Hyper-V komponens). Egy olyan környezetben, ahol eleve van több csatlakozó (fizikai vagy virtuális), még egy további megjelenése megosztott figyelmet igényel. Ez elkerülhető lett volna azzal, hogy akinek nem tetszik, az távolíthassa el. Természetesen meg lehet próbálni kikapcsolni rajta a különböző protokollokat és szolgáltatásokat (ipv4, Client for MS Networks, …), de ez csak egy ideig megoldás, hiszen a Windows automatikusan helyreállítja a kapcsoló állapotát.

Egy másik gondomat oktatóként közelítem meg. Eddig a Hyper-V oktatásokon megmutattuk, hogy miként lehet beállítani a kapcsolókat, melyiket milyen célra használjuk, de az emberek lustasága (persze, tudom, lusta ember nincs is…) abba az irányba fogja terelni a többséget, hogy a VM-nek adjuk oda az „alapértelmezett” kapcsolót, s kész. Lesz internet, lesz minden, mehetünk szórakozni. Mondjuk akiket valóban érdekel a téma, azok szinte biztos, hogy belemélyednek majd, s létrehozzák a „hagyományos” kapcsolókat, de lehet, hogy ők akkor az előző pontba futnak majd bele: el szeretnék távolítani ez az új kapcsolót – sikertelenül.

További problémaként (s itt ismét szeretném kihangsúlyozni, hogy nem teljes körűen megvilágítva) a biztonságosságot vetném fel. A VM-ek gépek közötti mozgatásánál oda kellett figyelni, hogy melyiken milyen kapcsolók vannak – ezzel ez kikerülhető. Sőt, ha elképzelem azt, hogy egy rosszindulatú programozó majd ír egy olyan kódot, ami egy virtuális gépben (sőt, ne csak hagyományos VM-ben, hanem mondjuk pl. Docker konténerben gondolkozzunk) fut, annak elég megadni a jól ismert kapcsoló GUID-ját (hiszen minden gépen azonos, nyelvtől, időjárástól, stb függetlenül), hogy kilásson az internetre, s „láthatatlanul” küldjön csomagokat – mondjuk egy szaki vélhetően hamar megtalálja, de egy otthoni felhasználó? Igaz, utóbbinak nem kell Hyper-V, de akkor gondoljunk mondjuk egy KKV-ra, ahol nincs profi rendszergazda, de valamiért szükséges a gépeken az említett modul (ismerek konkrét esetet, amikor pl. VLan-ozás miatt kellett telepíteni ezt a virtualizációs komponenst).

Egy szó, mint száz, még nem igazán nyerte el a tetszésemet – s ekkor még finoman, nőiesen fogalmaztam 😊

Hyper-V guest vs. USB

november 10, 2016 6 hozzászólás

Adott helyen ismét előkerült egy ősrégi probléma: Hyper-V vendéggépre szerették volna a gazdagép USB-portjára csatlakoztatott eszközt átvinni. Ez sajnos mindig egy fájó pont, kerülő-megoldásokkal próbáltuk itt is megoldani a problémát.

Egyrészt megoldás lehet a távoli asztali kapcsolat (RDP), hiszen annak beállításai között szerepel a helyi USB-erőforrások átadása. De mi van abban az esetben, ha (bármilyen okból kifolyólag) nem szeretnénk hálózattal ellátni a vendég-gépet? Ekkor az RDP bizony nem járható út.

Egy másik megközelítés a 2012 R2 óta létező korlátozott megoldás. Ehhez ugyanis Gen2 gépek szükségesek, s ebben az esetben a VMBus-on keresztül át tudjuk adni a legtöbb USB-eszköz kezelését a vendég-gépnek (természetesen bekapcsolt Enhanced Session Mode kapcsolóval). Sajnos a Gen2 gépeknek elég komoly korlátozásai vannak, a konkrét esetben 32-bites Win7 futtatására lett volna szükség – ez sajnos “duplán” megbukott (32-bit és Win7).

Mivel szerencsére itt a saját gépen megvalósítandó környezet elég (értsd: nem távoli szerveren, automatikusan induló virtuális gép, stb), így kipróbáltunk egy alternatív virtualizációs eszközt, a VirtualBox-ot is. Ez bizonyos dolgokat nem tud, amire egy “rendes” virtualizációs réteg képes, de erre a feladatra akár alkalmas lehet.

Hogy ott, adott környezetben annyira speciális USB-eszköz volt, hogy sem az RDP-s megközelítés, sem a VirtualBox nem hozott megoldást – hát, sajnos van ilyen…

Kategóriák:Virtual Server/Hyper-V Címkék: ,

Exchange mentések vs Hyper-V

szeptember 15, 2016 Hozzászólás

Adott helyen egy VM (történetesen egy Exchange) átkerült egy 2012-es gazdagépről egy 2012 R2-t futtató gépre. A mozgatás után látszólag minden rendben működött, így a rendszergazda kollégák nem bolygatták többet.

Egy bizonyos idő eltelte után a szerver nem volt hajlandó fogadni a leveleket, a monitorozó-rendszer erőforráshiányra panaszkodott. Megnézve a paramétereket, a kollégák egyből kiszúrták, hogy itt bizony merevlemez-kapacitás hiányzik, s tudjuk, hogy az Exchange-be épített Back-pressure hatására inkább visszautasítja a levelek fogadását, mint veszélyeztesse „saját épségét”. Tüneti kezelésként gyorsan felszabadítottak némi helyet, de természetesen nem hagyták annyiban a dolgot, biztos, ami biztos alapon segítséget is kértek.

Utánajárva, hogy miért lett tele a kötet, kiderült, hogy a naplók törlése nem történt meg (ez akkor történik meg, amikor egy teljes mentés készül az Exchange-ről). Kiderült, hogy magán a levelező szerveren nem volt beállítva mentés, de a gazdagépen viszont igen, mégpedig a teljes VM mentése. Ez „triggerelni” szokta az Exchange-logok törlését is, itt viszont nem történt meg. Az okot keresve elég hamar rátaláltunk, hogy mikor volt az utolsó teljes mentés (Exchange-konzol segítségével kiolvasható), majd mivel a jelzett dátum körül történt a mozgatás, nyilvánvalóvá vált, hogy ezzel függ össze. Szerencsére a gazdagép Hyper-V konzolját megnyitva egyből látszott a probléma: az Integration Services (itt írtam róla legutóbb) nem volt naprakész. A friss, 2012 R2-s kiegészítőket telepítve, majd a VM-et újraindítva a következő mentés egyből ismét helyreállította a rendet.

A lefoglalt vhd esete

július 19, 2016 7 hozzászólás

Egyik cégnél a kollégák már a hajukat tépték, amikor egy aznap délelőtt leállított virtuális gépet akartak ismét elindítani, s folyamatosan hibára futott. Az eseménynaplóban egy olyan hibaüzenetet találtunk csak:

VM-Név

Virtuális-gép-ID

VHD-útvonal.vhd

%%2147942432

0x80070020

The locale specific resource for the desired message is not present

Próbáltunk ennek alapján elindulni. A hibakód azt jelenti, hogy

2147942432: The process cannot access the file because it is being used by another process. (0x80070020).

Tehát próbáltuk kideríteni, hogy ki/mi használhatja ezt az állományt. Mivel a gép leállítása azért történt, mert egy újabb oprendszerű, de azonos nevű VM vette át a feladatát, első sorban erre gyanakodtunk – de a vhd nem volt hozzá csatolva.

Kiderült, hogy egy másik kolléga nem ezt a módszert választotta pár adat kinyeréséhez, hanem a gazdagépre csatolta fel közvetlenül a vhd állományt. Onnan leválasztva, máris elindult a virtuális gép…

Kategóriák:Virtual Server/Hyper-V Címkék: ,

Hyper-V replika gondok

február 9, 2016 Hozzászólás

Adott cégnél próbálták a replikát beállítani, de nem sikerült, a felpattanó 0x80090303 hibák kissé megakasztották a kollégákat:

Hyper-V failed to authenticate the Replica server <server name> using Kerberos authentication. Error: The specified target is unknown or unreachable (0x80090303)

A replika-szerveren keletkező 14050-es eseménynapló bejegyzések következtében rájöttek, hogy az SPN-név regisztrációval van gond, így megpróbálták felvenni kézileg, az ADUC-ban található attributum-szerkesztővel, amit az alábbi parancs vissza is igazolt:

SetSPN hostnév

Ezzel a probléma nem oldódott meg, amit a kétpercenként továbbra is megjelenő 14050 hibabejegyzések is jeleztek. Azt még ellenőrizték, hogy a Self-nek van autoregisztrációs joga, de utána segítséget kértek.

A hiba elhárításához alapul vettük azt a tudásbázis cikket (KB2761899), ami elég jól leírja a problémánkat, így csak azt kellett követni – némi pontosítással; a tűzfalszabály létrehozása után megszűntek a hibák (VMM szolgáltatás újraindítása nélkül is).

Az egyik pontosítás az, hogy a szükséges RPC portok lekérdezéséhez a tartományvezérlőn futtatjuk ezt:

netsh int ipv4 show dynamicportrange tcp

A kapott eredmény elég meglepő volt (bár utána ellenőrizve, bármely SBS 2011-nél alapból ilyen széles a skála): 6005-től 59530 db port (magyarul 6005-65535). Tehát a Hyper-V hostgépeken ezt kell beállítanunk.

Első körben lekérdezzük a meglévő, grafikus felületre nem kivezetett tűzfal-szabályokat, hogy ha netalán már valaki próbálkozott ennek beállításával, akkor azzal legyünk tisztában:

Get-NetFirewallRule -PolicyStore ConfigurableServiceStore

Jelen esetben nem volt semmi zavaró tényező, így mehettünk tovább. A beállítás akár az említett KB cikkben található vbs segítségével, akár PS segítségével megoldható:

$HT = @{

DisplayName = “VMMS (DC-RPC-Out)”

Description = “Outbound rule to allow traffic to DC using RPC on TCP 6005 to 65535”

Direction = “Outbound”

InterfaceType = “Any”

Action = “Allow”

Protocol = “TCP”

Service = “vmms”

Program = “$($env:systemdrive)\WINDOWS\system32\vmms.exe”

Enabled = “TRUE”

RemotePort = “6005-65535”

PolicyStore = “ConfigurableServiceStore”

}

New-NetFirewallRule @HT

Aki inkább COM objektumokkal akarja létrehozni, itt megtalálja a szükséges scriptet. Amennyiben rosszul hoztuk létre a tűzfalszabályt, a törléshez először pontosan leszűrjük a törlendő bejegyzést, majd töröljük:

Get-NetFirewallRule -PolicyStore ConfigurableServiceStore | where {$_.displayname -like “*Felesleges tűzfal*”} | Remove-NetFirewallRule

Alap-probléma elhárítva, jöhetett a replika beállítása 🙂