Archívum

Posts Tagged ‘Hyper-V’

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: 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: ,

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 🙂

VM migráció 2008 R2-ről 2012 R2-re

június 11, 2015 Hozzászólás

Adott helyen a kollégák át akartak mozgatni egy 2008 R2-es rendszeren futó virtuális gépet egy 2012 R2 gazdagépre. Nos, ebben az esetben a javasolt megoldás (ha nincs SCVMM) a VM export-import elvégzése. Igen ám, de a 2012 R2-re történő import során hibaüzenetbe futottak:

Hyper-V did not find virtual machines to import from location ‘E:\VM’

Ugyanez a gép csont nélkül importálható volt egy tesztelésre felhúzott „sima”, R2 nélküli Windows 2012-re, így egyértelműen nem az export során keletkezett hiba – de a továbblépéshez a segítségem kérték.

Anélkül, hogy túlzottan belemennénk, a történet csak annyi, hogy míg Windows 2012-ben „csak” elavult technológiának lett minősítve a „WMI root\virtualization namespace v1” névtér (ezt használja a Hyper-V), s mellé be lett vezetve a v2, az R2-ben előbbi eltávolításra is került. Az export viszont még természetesen a v1-el készült, amit a 2012 R2 már nem tud értelmezni. Elég sok kerülő megoldás létezik, ebből talán a legegyszerűbb, ha az eredeti virtuális gép .xml állományát (ami maga a gépet írja le) bemásoljuk az exportot tartalmazó mappába – s máris sikeres importnak lehetünk tanúi.

Igen ám, de hol találjuk ezt az .xml-t? Nos, ha nem konfiguráltuk szét a rendszert (mint a kollégák), akkor ott, ahol a többi VM állománya is van, ezt akár grafikus felületen is meg tudjuk nézni (a Hyper-V gazdagép tulajdonságainál). Ha viszont már rengeteg módosítás történt, szanaszét szórták a Snapshot, Smart Page, merevlemez állományok helyét, akkor valószínűleg grafikusan már nem tudjuk megállapítani. Windows 2012-től ezt több módon is lekérdezhetjük, például PS segítségével, ahol emelt szinten futtatva a

$Config = (Get-VM VirtuálisGép).ConfigurationLocation

parancsot a $Config változóba megkapjuk a hőn áhított útvonalat. Ugyanezt le tudjuk kérdezni grafikus felületen is, ahol a virtuális gép „Move…” utasítását kiadva, „Move the virtual machine’s storage” opciót választva, majd azon belül „…different locations” lehetőségével élve tudjuk elég részletesen szabályozni a tárolandó adatok helyét.

2008/2008 R2-nél még nincs ez a lehetőségünk, sem PS-utasítások, sem a grafikus felület nem áll rendelkezésünkre egy szétkonfigurált rendszer adatainak összeolvasásához. Ekkor talán a legegyszerűbb, ha a kályhától kezdjük: a Hyper-V konzol az alábbi mappából olvassa be a virtuális gépeket a kezelőfelületbe:

C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines

Abban az esetben, ha az .xml nincs az előbbi mappában, akkor létrehoz ide egy szimbólikus linket, amely a virtuális gép „valódi” .xml-jére mutat, tehát a szimbólikus link tulajdonságait megnézve, sőt, az „Open folder location”-t megnyomva máris megnyílik a kívánt mappa.

VmWare konverzió

június 6, 2014 6 hozzászólás

Bár arra számítottam, hogy kissé utolérem magam (bloggolásban is), egy közepes projekt esett rám (Scale-Out Fileserver-ek, fürtök), így lehet, hogy továbbra is marad a ritka bejegyzés-sűrűség (persze, ha belefutok egy-két nyalánkságba, kiteszem).

Kezdjük mindjárt az elejével. Megszüntetjük a VmWare virtualizációt, teljesen áttérünk Hyper-V-re, viszont van még néhány Windows 2000 (igen, még létezik 🙂 ), amelyeket ideiglenesen nem szabad kiütni. Nos, ezek konverziója nem sikerült teljesen zökkenőmentesen. Figyelembe kellett venni, hogy SCSI-lemezeket használtak rendszer-lemezként – ezt pedig csak a 2012 R2 (Gen2) tudja, de Win2012-től a Windows 2000 már nem támogatott vendég.

A kollégák ettől függetlenül megpróbálták konvertálni – s a legtöbb konverziós módszer elvérzett (pl. eleve a Disk2vhd kiesett, a VSS hiánya miatt), a kapott hiba: 0x0000007B, Inaccessible_Boot_Device.

A megoldás során csatoltunk egy IDE-lemezt (ez lehet akár üres is), így indítva a virtuális gépet „rendesen”* települ az IDE-driver is. Ezután már akár jó lehetne – esetünkben nem volt elég, át kellett tükrözni a C: tartalmát az IDE-lemezre (pl. Paragon, Acronis), s arról bootolni.

* A neten természetesen vannak módszerek, hogy miként lehet offline módon, akár konverzió után is betenni az IDE-meghajtót, de amíg van működőképes VmWare-gépünk, jobb előre felkészülni.

Az, hogy a támogatás hiánya miatt a 2008 R2-s Hyper-V integrációs komponenseket kell telepíteni, már csak legyintésre volt méltó… – még mindig jobb, mint a Win98-as integrációs komponensei (amit egy Virtual Server 2005-ből kellene venni) 🙂