VMware Workstation hálózati kártya típusok Windows 8 vendég esetén

A nemrég megjelent új programverziók mindig meglepnek mostanában valami új hibával. Most a VMware Workstation 9 a fizikai gépen és Windows 8 a vendég gépen kombináció kápráztatott el.

VMware Workstation 9-ben létrehoztam egy új Custom virtuális gépet, megadtam neki, hogy Windows 8-at fogok telepíteni rá (a 9-es már támogatja ezt), majd később fel is telepítettem (de nem használtam az Easy Install funkciót). Minden tökéletes, megjelent az új Start menü is, nem is volt lassú a virtuális gép, azonban nem volt hálózat.

Megnyitva az Eszközkezelőt ez a kép fogadott:

Hát ezt a hálózati kártyát nem sikerült felismerni. Gyors keresés után kiderül, hogy más is találkozott ilyesmivel: Workstation 9 and Windows 8 – getting internet access?

Elő is kerül a megoldás valami tapasztaltabb fórumozótól: írjuk bele a VMX fájlba, hogy ethernet0.virtualDev = “e1000e” és megy is majd minden.

Igen ám, de miért is kell hirtelen most ezt kézzel elvégezni?

Hálózati kártya típusok VMware Workstation esetén

A Workstation felülete szépen elkeni, hogy tulajdonképpen milyen típusú hálózati kártyát is mutat a virtuális gép felé. ESX/ESXi esetén ez szerepel a GUI-n is, meg van is dokumentáció róla:  Choosing a network adapter for your virtual machine

Workstation esetén viszont marad a VMX fájl szerkesztése kézzel. Ehhez, amennyire tudom, nincs hivatalos séma, úgyhogy marad például ez a jól összeszedett referencia: VMX-file parameters, Advanced network settings Itt három lehetőséget ajánl:

ethernet0.virtualDev = "vlance" 
ethernet0.virtualDev = "vmxnet" 
ethernet0.virtualDev = "e1000"

Ez azonban már kicsit elavult, például nincs benne az e1000e. Ezek szerint kénytelenek leszünk magunk utánajárni ennek;)

PCI  IDs: vendor, device és a többiek

Hogyan deríthető akkor ki, hogy milyen opciók vannak, és azok mit jelentenek? Próbáljuk ki az ESX-ben meglévő opciókat beleírni a VMX fájlba, és nézzük meg, hogy a vendég milyen PCI eszközt lát az Eszközkezelőben. A PCI eszközt többek között a vendor és a device ID kombinációja azonosítja, ezt kell tehát figyelni (ezt utána például a http://www.pcidatabase.com odalon lehet beazonosítani).

Tapasztalatok:

  • Ha nem adunk meg semmit a VMX fájlban (ez az alapeset), akkor VLANCE típusú kártyát mutat. Akkor is, ha fel van telepítve a VMware Tools csomag.
  • VMXNET2 megadása esetén nekem ‘Internal error’ hibára panaszkodott a VMware Workstation, és nem akarta betölteni a virtuális gépet.
  • VMXNET3 esetén elindult, de 100% CPU használatot produkált a Windows 8, és még a Feladatkezelőt se tudta elindítani. Ezt több újraindítás után is reprodukálta, úgyhogy ezzel sem kísérleteztem tovább.

A többi opcióra viszont működött, az alábbi táblázat foglalja össze, hogy mikor milyen hálózati kártyát lát a virtuális gép.

type vendor device subsys revision name driver
vlance 0x1022 0x2000 0x20001022 0x10 AMD PCnet LANCE PCI Ethernet Controller Not in Windows 8
vmxnet 0x15AD 0x0720 0x072015AD 0x10 VMware PCI Ethernet Adapter VMware Tools
e1000 0x8086 0x100F 0x075015AD 0x01 Intel PRO/1000 MT Gibabit Ethernet Adapter In-box Windows 8
e1000e 0x8086 0x10D3 0x07D015AD 0x00 Intel 82574L Gibabit Ethernet Adapter In-box Windows 8

A vlance egy nagyon régi 10 Mbit/s kártya emulálása, a vmxnet a VMware paravirtualizált  hálózati kártyája, az e1000 és az e1000e két Intel kártya emulálása (az e1000e már egész új, az nem olyan régen került bele a VMware termékekbe).

Tehát az alapesetben kiválasztott vlance kártyához jogos, hogy nincs meghajtó, azt már régen kiirtották a Windowsból. Tehát tényleg át kell írni kézzel valami másik típusúra.

Csak azt nem értem, hogy ezt miért nem oldja meg a Workstation, ha már egyszer úgyis megadom neki, hogy milyen operációs rendszert fogok a vendég gépbe telepíteni. Eddig ezzel nem volt gond…

Kategória: Tech | Címke: , | Megjegyzés hozzáfűzése

Google Calendar Sync: error -2146959355

Ez megint egy tanulságos hibakeresés volt. A Google Calendar Sync programot használom most a naptáraim szinkronizálására. A Windows 8 telepítés után azonban az eddig tökéletesen működő alkalmazásban a Google fiókot fel lehetett venni, azonban a szinkronizáció egy ideig gondolkodott, majd a következő hibaüzenetet adta:

Could not connect to Microsoft Outlook: error -2146959355

Ezt meg mi lelte? A -2146959355 értéke hexadecimálisban FFFFFFFF80080005, erre a hibaüzenetre rákeresve pedig a CO_E_SERVER_EXEC_FAILURE hibakódot kapjuk. Ez még túl sokat nem segített.

Hasonló problémák

A Calendar Sync programhoz meglepően sok fórum és blogbejegyzést találni, amik különböző hibákról számolnak be. Jó párat végignéztem, de az én gondomat nem oldották meg:

  • Google Calendar Sync error 2147221164: ez egy másik hibakód (80040154 –> Class not registered), de itt is elég sok tanács van mindenféle szinkronizációs hibára.
  • Unable to sync with Outlook; error -2147319779: itt azt javasolták, hogy töröljük az Office 15 által felrakott registry kulcsokat, de nekem ez sem segített.
  • johanneswerner86  / mySync: ezt javasolták alternatív programként, de én jobb szerettem volna a Google programját újra működésre bírni.
  • Volt egy olyan ötlet is, hogy az Outlook Add-Ins menüjében aktiváljuk kézzel a Calendar Sync bővítményét, de a változatosság kedvéért ez sem segített.

A hiba vizsgálata

Nem maradt más hátra, részletesebben meg kellett nézni a kapott hibát. Szerencsére volt egy kapcsolódó bejegyzés az eseménynaplóban:

Log Name: System
Source: Microsoft-Windows-DistributedCOM
Event ID: 10010
Description:
The server {0006F03A-0000-0000-C000-000000000046} did not register with DCOM within the required timeout.

Jaj. Nem szeretem a COM/DCOM hibákat:) A DCOM konzolt elindítva meg is lett a hivatkozott alkalmazás:

“{0006F03A-0000-0000-C000-000000000046} is Microsoft Outlook Command Button Control”

Mondjuk logikus, a Calendar Sync alkalmazásnak valahogy el kell érni az Outlookot, annak pedig egy COM-os felülete van, azon keresztül lehet bővítményeket írni hozzá.

A Calendar Sync egyébként ezekből a fájlokból áll:

Az exe maga a szinkronizációt végző alkalmazás, a két DLL pedig egy-egy 32 és 64 bites Outlook bővítmény (Add-In). Gyanús volt, hogy azzal van a gond, hogy 64 bites Office van fent a gépemen, bár elvileg a Calendar Sync azt is támogatja (bár ezt nem volt egyszerű megtalálni): Google Calendar Sync upgrades Outlook 2010 support.

Hogy ellenőrzünk ilyen DLL-betöltési problémát? Hát persze, hogy indul egyből a Process Monitor🙂 Ez a lényeges rész:

16:48:56-kor indult a szinkronizáció, elég sok registry kulcshoz hozzáfért, majd 16:48:57-kor elindult két új szál, sokáig semmi, majd 16:49:28-kor kezdi megjeleníteni a hibaüzenetet.

Az új szál által végrehajtott feladatok segíthetnek esetleg, a veremtartalom mutatja ezt. Ebből az érdekesebb rész ez volt:

"40","combase.dll","ObjectStublessClient22 + 0x22a6","0x767b5ba6","C:\Windows\SysWOW64\combase.dll"
"41","combase.dll","CoCreateInstance + 0x169","0x767ac9c2","C:\Windows\SysWOW64\combase.dll"
"42","GoogleCalendarSync.exe","GoogleCalendarSync.exe + 0x16f24","0x416f24","C:\Program Files (x86)\Google\Google Calendar Sync\GoogleCalendarSync.exe"

A SysWOW64 könyvtárban a C:\Windows\system32 könyvtárban lévő DLL-ek 32 bites változatai vannak 64 bites Windowson (igen, kicsit furcsa, hogy a system32 könyvtárban vannak a 64 bites DLL-ek, de ezt így valósították meg: File System Redirector). A GoogleCalendartSync.exe egy 32 bites program, ezért a 32 bites combase.dll-t tölti be neki az OS. Szépen el is indul a COM kérés. Ezeket a kulcsokat kezdi el matatni:

"HKCR\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}"
"HKCR\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\(Default)"
"HKCR\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocHandler"
"HKCR\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocHandler32"

A DCOM konzolon elvileg erre a komponensre jók voltak a biztonsági beállítások (Local Launch, Local Activation), de ekkor jutott eszembe, hogy a 32 bites változatokra külön beállítások vonatkoznak. Ehhez az mmc.exe konzolt 32 bites módban kell elindítani:

mmc comexp.msc /32

Itt már a Local Launch jog ki volt szürkítve, de gondolom azért, mert ez egy 64 bites komponens.

Jó lenne, ha a Calendar Sync is mondana, valamit, hogy mi a baja. Elvileg egy level.txt fájlt kell elhelyezni a C:\Users\username\AppData\Local\Google\Google Calendar Sync\logs könyvtárba, és akkor részletes üzeneteket is rögzít (forrás: Diagnosing Google Calendar Sync Issues). Nekem ez se segített, ide csak a szinkronizáció tartalmáról rögzít adatokat, magáról a program működéséről nem.

Megoldás

Hát nem igazi megoldás, de már kezdett túl sok idő elmenni ezzel, úgyhogy leszedtem és újratelepítettem a Calendar Sync programot. Ez nem szokott segíteni általában, most azonban pont igen. Ugyanúgy beállítva a szinkronizációt ment elsőre minden:( Egyszerűbb lett volna ezzel kezdeni;) A DCOM beállításokkal lehetett valami gond, bár most egy sikeres ProcMon műveletsort összehasonlítva a hibással nem láttam feltűnő különbséget:

Néha a leggyorsabb megoldás sajnos az újratelepítés:(

(Summary: this error is related to some DCOM configuration error, probably because of using the 64 bit version of Office. I was not able to pinpoint the root cause, but a reinstall of Google Calendar Sync helped in my case.)

Kategória: Tech | Címke: | 1 hozzászólás

Windows Server 2012 – DNS Server Powershell cmdlets

Ha már megjelent a végleges Windows Server 2012, akkor gondoltam ezt használom majd az őszi félévben lévő feladatátvételi fürtök (failover cluster) mérésen. Hogy legyen valami kihívás is;), no meg, hogy tárhelyet spóroljunk az öt szükséges virtuális gépnél, Server Core módban telepítem a gépeket. Tényleg egész jó lett a PowerShell támogatás, van majdnem mindenhez natív cmdlet már.

Azért még akadnak hiányosságok. Például ez a hibaüzenet nem túl baráti:

Failed to restar computer

(Mentségére legyen mondva, hogy egy AD DC eltávolítás után voltunk, és pont átmeneti állapot volt.)

Ami viszont sokkal zavaróbb, az a DNS Server PowerShell cmdletei. Ezt mondja a súgó frissítése:

No DnsServer PowerShell help

Pedig még direkt en-US területi beállításokon hagytam a gépet, hogy ezzel ne legyen gond.

Ha megnézzük a http://technet.microsoft.com/library/hh801904.aspx URL-t, akkor ott tényleg nincs DNS Server. Van minden más, de a DNS Server cmdletjeiről nincs leírás. Pedig a cmdletek működnek (pl. van Add-DnsServerPrimaryZone  meg Add-DnsServerResourceRecord), csak éppen a paraméternevekből kell kitalálni, hogy mit is csinálnak.

Pointer rekord hozzáadásáról egy példa van a google szerint az egész Interneten (ami azért elég hihetetlenül hangzik), úgyhogy álljon itt még egy:

# create an AD integrated reverse lookup zone
Add-DnsServerPrimaryZone -ReplicationScope Domain -NetworkId "192.168.170/24" -DynamicUpdate Secure

# add a new PTR record in the zone
Add-DnsServerResourceRecordPtr -ZoneName "170.168.192.in-addr.arpa" -Name 10 -PtrDomainName "dc1.clusterdemo.local"

Remélem azért előbb-utóbb elkészítik a leírást. Kicsit furcsa, hogy így release lehetett…

Kategória: Tech | Címke: | Megjegyzés hozzáfűzése

Windows 8 WLAN profilok

Néhány napja nézegetem már a Windows 8-at, és azért akad benne pár furcsaság. Például a hálózatoknál eltüntették azt a linket, amivel a Wifi hálózatokat / létrehozott profilokat lehet megnézni. Kézzel továbbra is lehet Wifi profilt létrehozni (Set up a new connection or network / Manually connect to a wireless network), viszont a létrehozott profilt nem lehet megnézni vagy szerkeszteni utólag. Lehet, hogy csak én nem találtam meg (bár másnak is hiányzik, lásd Preferred wireless network profiles in Windows 8). Ha éppen látszik az SSID, akkor a kapcsolódás oldalon lehet a hálózat nevére jobb gombbal kattintva szerkeszteni, de ez nem segít pl. rejtett SSID esetén.

Külső programot nem akartam felrakni, de szerencsére eszembe jutott, hogy a netsh is tud ilyesmit.

netsh wlan set profileparameter

És innen lehet mindent szerkeszteni. Azért nem a legkényelmesebb megoldás:)

Kategória: Tech | Címke: | Megjegyzés hozzáfűzése

Memory metrics in VMware ESX 4.1

(Ennek a részei nagyrészt angolul voltak meg korábbról, így ide is angolul írom.)

Handling memory in virtualization can be a complex topic, especially in today’s hypervisors, where a lot of optimization techniques are implemented. This is a slightly older material collected for ESX 4.1, but most of it still can be applied to ESX 5.0 too.

Goal: We wanted to answer a simple question: how much memory does currently a virtual machine consume. Of course this is a rather complicated question, one has to understand the basic of memory management in virtualized systems and know the exact meaning of the numerous memory-related performance metrics presented by ESX.

1. Materials

There are a lot of in-depth materials for memory management in ESX:

  1. For a detailed description of memory management in ESX/ESXi see the vSphere Resource Management Guide  (it includes memory virtualization techniques, overcommitment methods, shares/reservation/limits). The section “Measuring and Differentiating Types of Memory Usage” is especially relevant for understanding the different metrics.
  2. Understanding Memory Resource Management in VMware ESX 4.1 (VMware Technical Paper)  focuses also on memory management in detail.
  3. Another great source of information on performance is the tutorial “VMware Performance for Gurus”.
  4. The official documentation of the memory metrics can be found in the VI API, but it is very limited, and some counters are missing.
  5. A much better explanation is “Memory Performance Chart Metrics in the vSphere Client” (by jbrodeur, VMware Community DOC-10398).
  6. The “Interpreting esxtop 4.1 statistics” (by haiping, VMware Community DOC-11812) contains also a lot of information. However, esxtop uses a different set of counters, and for some of the counters there is no equivalent in the VI API. (The “Memory Performance Analysis and Monitoring [by Scott Drummonds, VMware Community DOC-5430] document contains some mappings.)
  7. “VirtualCenter Memory Statistic Definitions” (by Kit Colbert) contains some explanations to the metrics, and a simple example to calculate granted/consumed and shared/shared common (it is for VI 3.5, but much of the information is valid for VI 4.x).

2. Description of the metrics

What we were really missing in the beginning was an overview figure illustrating the relationships between the counters. A good start is the figure in “Understanding ESX Memory Management at Partner Exchange 2009“, but it lacks some details.

Thus I have put together the following figure based on the information in all the above sources and some experiments with a simple VM. Texts in blue represent metric names in the VI API.

NOTE: the regions are not so well-aligned, they can be distributed along the whole address spaces, this is just for easier illustration.

Relationship between different ESX memory counters

VM level: The virtual machine has some total memory allocated, this is the guest physical memory.

  • As long as the VM does not touch a memory page at least once, ESX does not care about that page. These are the “not touched” region, there is no stat for its size.
  • If there is no memory pressure on the host and no memory overcommit technique is active, then all the other pages has to be mapped to some machine memory pages. This is represented in mem.granted.
    • From the granted memory, some of the pages are fully zeroed out. ESX detects them at some rate, and includes them in mem.zero. These pages are mapped to the same zero page in the machine memory, thus they are stored only in one instance.
    • The Transparent page sharing (TPS) component in ESX detects also those pages, which contain exactly the same data as other pages (in the memory of this VM or other VMs on the same host). These will be also stored only in one instance in machine memory. The number of these pages is mem.shared (this includes also zero pages).
    • A different subset of the granted memory is mem.active. ESX estimates this using sampling and averages, and it takes time to detect the actual value [from Interpreting esxtop: “VMKernel estimates active memory usage for a VM by sampling a random subset of the VM’s memory resident in machine memory to detect the number of memory reads and writes. VMKernel then scales this number by the size”]. Active memory could be shared or private.

If there is not enough memory on the host to satisfy all requests, ESX uses ballooning, memory compression or host level swapping.

  • VMware Tools can reserve memory inside the VM (“ballooning”), these memory pages then would not be mapped to any machine memory page. The current size of the balloon is represented by mem.vmmemctl.
  • ESX can compress some of the guest memory pages, and store them in a compressed format in the machine memory (“memory compression”). The description of these counters is missing from the API documentation (see my question regarding this here), but it seems from our tests that mem.zipped is the relevant counter.
  • Finally, some pages can be swapped out to the host swap file. The current amount is stored in mem.swapped.

Thus the total memory of the VM is divided into the following areas:

total_memory_size = granted + vmmemctl + swapped + zipped + not_touched

Host level: in machine memory the following parts are stored on the account of the current VM:

  • Running a VM requires some extra memory to store auxiliary structures. This is mem.overhead, it’s size depends on the number of vCPUs, number of total VM memory and the number of the processes inside the guest (as a shadow page table has to be maintained for every guest page table) [1].
  • Some parts of the guest memory are actually stored in machine memory, this is reflected in mem.consumed.
    • “When multiple VMs are sharing a single region of machine memory, each VM is ‘charged’ for the memory proportionally based on the total references to that region of shared memory.” For calculating mem.consumed see [7].
    • (Note: we did not found any information whether consumed includes also the compression cache, but it seems logical. The actual size of the compression_cache is maybe mem.zipped – mem.zipSaved [3]??)

Thus at the host level the memory consumed by a virtual machine is computed as:

Fomrula for the memory.consumed metric in ESX

3. Tests with a simple VM

Next we did some tests to check, whether the above assumptions are correct. The VM was placed in certain situations to trigger the different memory overcommitment techniques, and the different memory metrics were collected using the Get-Stat cmdlet of PowerCLI.

Test VM: Windows Server 2003 with VMware Tools, 1024 MB RAM; running in an ESX 4.1 host, host is not overcommitted (more than 8 GB free RAM); no reservation or limit was initially set on the VM.

3.1 Startup of the VM

ESX memory metrics: VM startup

The following can be observed on the picture:

  • granted [purple on top] climbs quickly (Windows touches all memory during boot), tops at 1048540 KB and stays constant
  • no memory pressure on the host, thus swap/balloon/compression remains 0
  • active [light blue with steps] decreases after a few initial peaks as the VM does nothing after booting, and after each sampling ESX estimates this correctly.
  • overhead [yellow] is mostly constant at 53856 KB (small changes occur)
  • after the start, transparent page sharing (TPS) kicks in, detects zero pages [climbing red] and some shareable nonzero pages also [shared, climbing light blue] (difference between the two: 680568 KB vs. 693872 KB). In the meantime consumed [green] decreases, as zero pages gets unmapped.

The changes in the relevant performance metrics from VI API:

ESX memory metric values: VM startup

3.2 Using ballooning

To simulate memory pressure on the host, a limit of 700 MB was added to the VM (while its memory size is still 1024 MB).

With Sysinternal’s testlimit.exe  700 MB of memory was touched and leaked in the VM:

testlimit.exe -d 100 -c 7

The relevant performance metrics can be seen on the following figure:

ESX memory metrics: Ballooning

The legend for the above graph:

ESX memory metrics: Ballooning (legend)

But it can be better followed by looking at the numbers:

ESX memory metrics: Ballooning (values)

The following happens:

Description:

  • around line 8 memory is reserved in the VM, mem.consumed increases over the limit, thus ballooning kicks in [vmmemctltarget > vmmemctl, thus the  balloon inflates],
  • as the balloon increases, granted memory decreases. Consumed also decreases, because ballooned memory is not mapped to machine memory,
  • after TPS detects zero pages, those gets shared, thus balloon starts to deflate.

3.3. Memory compression

VMware Tools was uninstalled, thus ballooning cannot be used. In this way, first compression is used when the host runs out of memory.

ESX memory metrics: Compression (values)

It can be seen, that granted starts to decrease as memory is compressed.

3.4 Swapping & compression

Test: VMware Tools uninstalled + high memory activity inside the guest + 300 MB limit on the VM.

When ballooning is not active, and the memory pressure is even greater, ESX uses host level swapping:

ESX memory metrics: Swapping

The values of the performance metrics obtained through PowerCLI:

ESX memory metrics: Swapping (values)

What can be seen from the numbers:

  • If swaptarget > swapped, then ESX starts to swap. If pages are moved to the swap file, then swapout increases.
  • Pages are only moved back to the memory when they are needed, in this case swapin increases.
  • Both swapout and swapinare cumulative counters, which start when the VM is powered on.
    • swapped = swapout – swapin

Conclusion: we can relax, as the numbers (more or less) backed up the theoretical calculations of the different metrics. Thus the summary figure can help to answer our initial question of what metrics should be consulted about the VM’s memory consumption.

Update: You can find a version of the PowerShell script for collecting statistics here. This is a slightly newer version, I used it with vCenter 5, but probably it works also for vCenter 4. The metric names and the name of the  vCenter to query is hardcoded, but after adjusting these the script should work. However, I only tested it in a simple environment.

Kategória: Tech | Címke: , | 2 hozzászólás

Type I vs. Type II VMM

VMM-ek és/vagy hypervisorok csoportosításánál szokták használni a Type I és Type II felosztást. Úgy szoktak rájuk hivatkozni, hogy a Type I “ami közvetlen a hardveren fut”, a Type II meg “ami egy operációs rendszeren fut”. A Type I még általában OK, de a Type II akkor mit jelent pontosan? Azért nem szeretem, mert mindenki mást ért alatta, és van, aki a Type II csoportba sorolja a Java VM-et vagy a .NET CLR-t is. Ezért születtek meg az ehhez hasonló hibrid ábrák:

VMM arrangements

VMM típusok (forrás: Microsoft)

Most azonban végre megtaláltam, hogy mi volt az eredeti elnevezés:) Amennyire tudom, Goldberg vezette be a fogalmakat a disszertációjában (ami egyébként valami hadi R&D projektnek a jelentése, érdemes megnézni fedőlapokat): “Architectural Principles for Virtual Computer Systems“, Report number AD0772809.

A 22. oldalon van a Type I és Type II informális definíciója:

Type I — The  VMM runs on a bare machine*
Type  II — The VMM  runs  or  an  extended host  [53,75],  under  the  host operatinq  system.

Van egy nagyon jó ábra is a Type II-höz:

Type II VCS

Type II VCS (forrás: R. P. Goldberg)

Meg van egy formális modell VMM-ek leírásában, ahol azt foglalja össze, hogy a virtuális erőforrások hogyan képződnek le fizikai erőforrásokká, és ezt különböző függvényekkel definiálja. Ezekkel egy Tpye II rendszer így néz ki:

Type II VM

Type II VM (Forrás: R. P. Goldberg)

Így már világos, igaz?:)) A P_v a virtuális gép folyamatainak nevei, V a virtuális gép erőforrásainak a nevei, P_r a fizikai gép folyamatainak nevei, R a fizikai erőforrások nevei. A fí_v függvény jelöli azt, hogy futtatjuk a virtuális gépet, és annak a folyamatai valamilyen virtuális erőforrást kezelnek, az f’ pedig azt jelzi, hogy a virtuális erőforrásokat hogyan képezzük le. Ez egy kellően általános modell, amibe aztán később az akkori megoldásokat szépen be tudta sorolni (IBM CP-67 és System/360, HITAC  8400).

Na ettől megint nem lettünk okosabbak a kiindulási problémával kapcsolatban:), de ezek érdekes dolgok, és jó volt megnézni egy, a 70-es évekből származó munkát. Félelmetes, hogy mennyire könnyen elérhető az akkor még írógépen készült munka, és félelmetes, hogy ennek ellenére mennyire elfelejtette a világ ezt a témát, és majd 20 évvel később megint elkezdte feltalálni.

Függetlenül attól, hogy Goldberg mit értett anno a Type II rendszeren, ma már annyi mindenki használta mindenre a fogalmat, hogy szerintem a bare-metal és hosted felosztás használata egyértelműbb.

Kategória: Tech | Címke: , | Megjegyzés hozzáfűzése

Virtualizációs technológiák összehasonlítása

A héten két különböző helyen is előkerült a téma, úgyhogy gondoltam kicsit körüljárom azt a kérdést, hogy melyik virtualizációs megoldás milyen virtualizációs technológiát használ, és ezek közül melyik a “jobb”.

Jöjjön először egy pár alap fogalom (kicsit pongyola módon megfogalmazva, részletekért lásd a virttech tárgyunk anyagait)!

Platform virtualizáció: arról az esetről beszélünk, amikor egy fizikai számítógépen több “virtuális” számítógépet szeretnénk futtatni, potenciálisan akár teljesen különböző operációs rendszerrel. Viszont virtualizációt és nem emulációt szeretnénk, azaz megelégszünk azzal, hogy ugyanolyan processzor architektúrát lát a virtuális gép, mint a fizikai (tehát nem lehet ARM-os virtuális gép egy  x86 fizikai processzoron), viszont cserébe elvárjuk, hogy gyors legyen a megoldás. Ehhez kell majd nekünk egy komponens, aki a fizikai meg a virtuális gépeket kezeli, nevezzük ezt most VMM-nek (Virtual Machine Monitor). [Itt most egy nagyon hosszú fejtegetésbe lehetne belemenni, hogy pontosan mi a VMM feladata, ki hogyan hívja – de ezt most szántszándékkal kihagyom, ez szerencsére itt most nem tananyag, hanem csak egy blog bejegyzés:]

Egy ilyen virtualizációs környezet megvalósítása során egy csomó probléma fakad majd abból, hogy egy fizikai erőforrást szeretnénk majd több virtuális erőforrásként látni, és erre a fizikai erőforrásunk nem igen van felkészítve. Tipikusan három féle módon állhatunk neki megoldani az ilyen problémát:

  • Szoftveres: tisztán szoftveres úton próbálunk valamit varázsolni a VMM-ben.
  • Paravirtualizáció: a virtuális számítógépben futó operációs rendszer megfelelő részeit készítjük fel arra, hogy működjön együtt a VMM-mel.
  • Hardveres: a hardvert készítjük fel arra, hogy megosztható legyen, és több virtuális példány állapotát tudja tárolni.

[Megjegyzés: szokott olyan felosztás lenni, hogy full virtualization meg paravirtualization, én azt nem szeretem, mert szerintem félreértésre ad okot.]

Három féle alapvető erőforrást kell majd kezelni: CPU, memória, I/O eszközök. Ezek mindegyikéhez lehet használni bármelyik fenti három technológiát. Mindhárom technológia segítségével írtak már VMM-et, nézzük meg ki mit támogat.

1. Ki milyen virtualizációs technológiát használ?

[Itt most csak a VMware ESXi, Microsoft Hyper-V és a Xen kerül sorra. Kimaradnak a hosted architektúrájú megoldások (VirtualBox, KVM…), bár azokra is hasonlóan végig lehet játszani ezt. Meg nem kerülnek szóba a nem x86-os megoldások, pl. különböző mainframe-ek képességei. Azokat hajlamosak vagyunk elfelejteni mikor a virtualizáció szóba kerül, pedig már évtizedekkel korábban kitaláltak bennük sok mindent.]

1.1 CPU kezelése

Itt a feladat az, hogy a vendég virtuális gép szeretne mindenféle privilegizált utasítást végrehajtani, amit nem engedünk direktben neki (pl. HALT esetén leállna a teljes fizikai gép). Ezt lehet kezelni szoftveres úton bináris átírással (a vendég által kiadott bináris utasításokat vizsgáljuk, és cseréljük le benne menet közben a problémásakat), lehet paravirtualizációval (módosítjuk a vendég OS kódját, hogy ha problémás utasítás lenne, akkor a végrehajtása helyett hívja inkább a VMM megfelelő függvényét), és végül lehet hardveresen (a CPU adjon módot arra, hogy elkülönítsük a VMM-et és a virtuális gépekben futó OS-t, és tudjuk valahol tárolni a virtuális gépek állapotait).

VMware ESX/ESXi Microsoft Hyper-V Xen
Szoftveres (BT) +
Paravirtualizáció (+/-)* -** +
Hardveres (Intel VT-x, AMD-V) + + +

* Volt paravirtualizációs támogatás az ESXi-ben (VMI – Virtual Machine Interface néven futott), de megszüntették a vSphere 5-ben. Lásd itt: “Update: Support for guest OS paravirtualization using VMware VMI to be retired from new products in 2010-2011

** Itt utána olvasva kicsit elbizonytalanodtam:) A Hyper-V használatának előfeltétele a hardveres virtualizációs támogatás, azt mindig használja. Azonban van egy kellemesen homályos fogalom Hyper-V esetén, ez pedig az enlightenment (=felvilágosodás). Ez paravirtualizációs technológiákat takar, a Windows kernelt módosították, hogyha virtuális gépként fut, akkor máshogy viselkedjen. Az eszközöket biztos paravirtualizáltan kezeli, de itt van olyan utalás is, hogy más funkciónál is használ ilyesmit (lásd: Hyper-V: Integration Components and Enlightenments, alul az Operating System Enlightenments rész). Hogy ezek mik pontosan, arról nem találtam utalást. [A Hyper-V alacsony szintű működésének dokumentáltságát némiképp nehéz megtalálni a Techneten, elég csak annyit megjegyezni, hogy a legpöpecebb Hyper-V ábra és fogalommagyarázat a BizTalk 2009 függelékében van:)]

Összefoglalva akkor:

ESXi:

  • Megvan még a tisztán szoftveres megoldás, a bináris átírás (binary translation – BT) benne. Ehhez nem kell se hardveres támogatás, se a vendég kerneljének módosítása.
  • Klasszikus értelemben vett paravirtualizáció már az 5-ös verziótól kezdve nincs.
  • Hardveres virtualizációt tud használni, ha a hardver képes erre.

Hyper-V:

  • Kell neki a hardveres virtualizáció, különben nem lehet használni.
  • Azonban ha a vendég “felvilágosult”, akkor szerintem hypercall-okon keresztül biztos hívja néha a hypervisort, hogy jobb teljesítménye legyen.
  • Az újabb Windows kernelekben már benne van az enlightenment, de Linuxhoz is van valamennyi támogatás. Linux esetén Integration Componentsnek (IC) hívják azt a csomagot, ami paravirtualizált eszközkezelőket ad, ez most a 3.1-es verziónál jár. Ez Red Hat és CentOS 6.0-hoz támogatott, de az aktuális Linux kernel (3.0.8) forrásában a drivers/staging/hv alatt megtalálható a kód egy része. Volt az IC-nek egy érdekes része, a “hypercall adapter”, de a 3.1 readme-je szerint ez már nincs benne az új verzióban. Egyébként ez volt (forrás: RTM of Linux Integration Components for Hyper-V Now Available):

The hypercall adapter is basically a layer that translates between the Xen hypercall API and the Hyper-V hypercall API.  This allows you to install a Xen paravirtualized Linux kernel inside the virtual machine in order to get the best performance possible.

Xen:

  • Kezdetben paravirtualizációt használt, ezért csak módosított kernellel rendelkező virtuális OS-t tudott futtatni. Ezt a módszert továbbra is használják, manapság annyi könnyebbség van, hogy az ehhez szükséges OS módosításokat Linux esetén már nem kell külön patch-ként hozzáfordítani minden egyes új verzióhoz, hanem már része a kernelnek. Lásd: Linux mainline contains all the Xen code bits for Dom0 and DomU support.
  •  Ahol nem lehet kernelt módosítani, pl. virtuális Windows, ott hardveres virtualizációt használ a Xen (HVM a Xen szójárásában).

1.2 Memória kezelése

Itt a feladat az, hogy a szokásos 2 szintű fizikai – virtuális címtereket és címleképzést kiterjesszük 3 szintre: gazda fizikai – vendég “fizikai” – vendég virtuális. Szoftveres esetben árnyék laptáblákat (shadow page table) tartunk fent, és megpróbáljuk elkapni a vendég OS laptábla módosító utasításait mindenféle trükkel. Paravirtualizált esetben módosítjuk a vendég kernelt, hogy a VMM-et hívja, ha módosítani akar valamit a laptábláin. Hardveres esetben pedig a hardver biztosít még egy plusz szintet (nested page table, second level adrres translation bűvszavak).

VMware ESX/ESXi Microsoft Hyper-V Xen
Szoftveres + + +
Paravirtualizáció (+) +? +
Hardveres (Intel EPT, AMD RVI) + + (R2-től) +

Itt a melyiket használjam kérdés egyszerűbb. Alapból mindenki szoftveres technikákat használ. Ha tudják módosítani a vendég kernelt (Hyper-V esetén újabb Windowsok, Xen esetén Linux, ESXi esetén VMI-t használó Linux), akkor gondolom, hogy használnak valamiféle paravirtualizációs rásegítést.

De itt igazából a hardveres megoldások dobnak nagyon sokat a teljesítményen, úgyhogy kevés vita van, hogy mi a jó opció, lásd: (MMU) Paravirtualization is dead, VMware mérések (AMD RVI és Intel EPT hatása), vagy a “Virtualization performance: perspectives and challenges ahead” cikkből származó ábra.

Memória: szoftveres és hardveres megoldás összehasonlítása

Memória: szoftveres és hardveres megoldás összehasonlítása (forrás: VMware)

Ha van hardveres támogatás, akkor a legtöbbször azt használják.

1.3 I/O eszközök

Itt azt kell megoldani, hogy a virtuális gép tudja kezelni az I/O eszközöket, de mégis védjük azt tőle. Szoftveres esetben valami létező hardvert emulálunk. Paravirtualizált esetben egy speciális, direkt a virtualizált megoldáshoz létrehozott eszközt lát a virtuális gép (amit egyszerűbb megvalósítani, jobb a teljesítménye). Hardveres megoldások esetén vagy arra van támogatás, hogy közvetlenül odaadjunk egy eszközt egy virtuális gépnek (AMD-Vi vagy a régi nevén IOMMU, Intel VT-d), vagy a hardver képes több “virtuális példányt” kezelni magából (mindenféle PCI-SIG IOV szabványok) .

VMware ESX/ESXi Microsoft Hyper-V Xen
Szoftveres (emulált) + + +
Paravirtualizáció + + +
Hardveres (AMD-Vi, Intel VT-d, IOV stb. ) + – (v3-ban lesz) +

Itt is egyszerű a helyzet: amíg nincs jobb (pl. virtuális OS telepítése közben), addig emulált eszközöket kell használni. Utána érdemes felrakni a megfelelő csomagot (VMware Tools, Integration Components…), hogy paravirtualizált eszközeink legyenek. Hardveres támogatás meg bizonyos esetekben jó (videokártyát dedikáltan használjon a gép, sok hálókártyával rendelkező gép, 10 GB-es hálózati kártya), ez például egy érdekes kapcsolódó cikk: To VT-d or Not to VT-d?.

VMware esetén van VT-d/AMD-Vi támogatás (VMware VMDirectPath Tech Note), és az ESXi 5.0-ba bekerült valamiféle SR-IOV támogatás (vSphere 5.0 Features), de több részletet nem találtam erről.

Hyper-V esetén nem találtam hivatalos infot arról, hogy jelenleg nem támogatja, csak ennyit: Does 2008 R2 Hyper-V support PCI-SIG SR-IOV (2010-es, MSFT alkalmazott válaszolt, hogy nem); Does Windows Server 2008 R2 Hyper-V use Intel VT-d hardware features? (2011-es, a válasz, hogy nem). Viszont a következő verzióban (v3, Windows 8 Server-ben) lesz SR-IOV támogatás a BUILD fóliák szerint.

Xen esetén van VT-d támogatás (Xen Wiki VTdHowTo), és valamiféle SR-IOV támogatás is: SR – IOV and repeated enhancement for pass through device support és Xen 4.0 Relase Notes.

2. Melyik virtualizációs technológia a “jobb”?

(A memória és I/O eset szerintem viszonylag egyértelmű, marad a CPU).

A válasz könnyű, természetesen attól függ:-). Mitől is?

  • Milyen terhelést futtatunk a virtuális gépekben? Sok lesz-e a kontextusváltás, sok lesz-e a rendszerhívás? Mennyire kell majd beleavatkoznia a VMM-nek?
  • Milyen hardverünk van? Ha nincs benne hardveres virtualizációs támogatás, akkor az eléggé behatárolja a lehetőségeket:)
  • Milyen OS-t akarunk futtatni a virtuális gépen?

Arra vállalkozni, hogy általános esetben a különböző megoldások különböző módjait hasonlítjuk össze (gyorsabb-e a bináris átírás az ESXi-ben mint a paravirtualizált Xen), szerintem felesleges. Egy-egy konkrét alkalmazás esetén mindenki saját magának mérhet ilyet. Olyan mérések vannak, ahol Xen meg ESX vagy ESX meg Hyper-V kerül összehasonlításra mindenféle mikrobenchmarkkal vagy valósnak vélt terheléssel, de ennek az eredményét is sokkal inkább meghatározza az, hogy ki volt az, aki a mérést végezte, mint az, hogy mit tudnak a platformok:) (nem feltétlen rosszindulatból, csak nyilván a VMware Performance csapat az ESX-et ismeri jobban).

Azt érdekes inkább megnézni, hogy egy-egy megoldás mikor mit és miért használ.

ESXi: Igazából itt érdekes a kérdés, hisz a VMware tudja/tudta mindhárom módszert.

  • 2006: Amikor az első generációs hardveres megoldások megjelentek, csináltak jó pár mérést, és az eredmény az lett, hogy a bináris átírás – hardveres megoldás még akkor nem volt eldöntött. Lásd: “A Comparison of Software and Hardware Techniques for x86 Virtualization“. A fő ok, hogy a szoftveres megoldást már régóta tunningolták (fordítás gyorsítótárazása, több hívás összevonása stb.), míg a hardveres még csak az első verzió volt. Azóta azonban minden újabb processzorgenerációval javul a hardveres megoldás gyorsasága.
Bináris átírás és hardveres virtualizáció összehasonlítása

Bináris átírás és hardveres virtualizáció összehasonlítása (forrás: VMware)

  • 2007: Understanding Full Virtualization, Paravirtualization, and Hardware Assist. Itt már az szerepel, hogy bár még mindig a BT a legjobb, de már “Hardware Assist is the Future of Virtualization”. Itt még van paravirtualizáció.
  • 2009: Van egy ilyen leírás: Software and Hardware Techniques for x86 Virtualization. Ez egy nagyon jó technikai leírás azokról a fogalmakról, amik eddig szerepeltek, és utána egy lista, hogy milyen szempontok szerint dönt az ESX, hogy milyen módszert használ. [Ebben már nincs paravirtualizációról szó.]
  • 2009: Itt pedig a pontos lista, hogy mikor melyiket választja: Virtual Machine Monitor Execution Modes in VMware vSphere 4.0 Az itt lévő táblázatból az látszik, hogy próbálja használni a hardveres támogatást, ha van, kivéve, ha régi a vendég OS vagy egyéb körülmény miatt nem lehet (pl. a VMware Fault Tolerance nem támogatja az EPT/RVI-t).
  • De mit történt a paravirtualizációval?
    • 2008: Performance of VMware VMI. Itt még ez van: “concluding that VMI-style paravirtualization offers performance improvements for a wide variety of workloads, but that the actual performance gains depend on the nature of those workloads.
    • 2009: “Update: Support for guest OS paravirtualization using VMware VMI to be retired from new products in 2010-2011” Itt pedig már ez: “decided to retire support for VMI in 2010-2011 as a result of innovations in CPU hardware acceleration technologies from Intel and AMD which have surpassed the performance improvements provided by VMI
    • Gondolom már nem érte el az esetleges teljesítménynövekedés azt a szintet, amiért megérte volna vele nekik foglalkozni. Mivel a VMware nem OS gyártó, ezért neki különösen macerás ilyesmit karbantartani.
  • Összességében szerintem szépen lassan a hardveres megoldások felé terelődik az irány, a szoftveresek addig maradnak, amíg nem lesznek teljesen elterjedtek a hardveres támogatások minden gépben.

Hyper-V: itt igazából nincs választás, hardveres támogatást használ. A Windows kernelbe viszont gondolom, hogy mindig kerülnek majd olyan funkciók, amik segítenek a virtualizáció gyorsításán. A Linux támogatás azonban kérdéses, valamit gondolom adnak, de sosem fogja a linuxos IC kihasználni az összes lehetőséget.

Xen: Itt maradt meg ténylegesen a választási lehetőség, hogyan futassunk egy linuxos vendéget? Lehetőségek:

Xen futtatási módok

Xen futtatási módok (forrás: Stefano Stabellini)

A fő távlati kérdés, hogy gyorsabb tud-e lenni a paravirtualizáció, mint a második generációs hardveres támogatás? Egy kapcsolódó prezentációt találtam: Linux PV on HVM. Az itt lévő mérésekben sok helyen megelőzi a hardveres megoldás a paravirtualizáltat (már persze csak akkor, ha paravirtualizált eszközmeghajtókat használunk). Kíváncsi leszek, hogy hosszú távon mi lesz a Xen stratégiája.

Összességében akkor hova jutottunk?

1. Elment vele vagy két estém, de egy csomó érdekes dolgot összegyűjtöttem és olvastam, szóval nekem hasznos volt idáig eljutni;)

2. Előbb-utóbb már csak olyan processzorok lesznek, amikben van hardveres támogatás, az el fogja dönteni a kérdést. 64 bites vendégek futtatásához is szükséges a hardveres támogatás (Intel esetén). Hyper-V és KVM esetén pedig alapkövetelmény.

3. Addig is az átmeneti időszakban, aki Windowst akar futtatni és nincs hardveres támogatása, annak marad az ESXi. Ha Linuxot akarunk és nincs hardveres támogatás, akkor lehet ESXi vagy Xen. Ha AMD-V/Intel VT-x van a CPU-ban, de EPT/RVI nincs, akkor lehet érdekes kérdés, hogy VMware esetén BT vagy hardveres, Xen esetén PV vagy HVM, de ez meg nagyon alkalmazásfüggő.

Zárszó: remélem hasznos lesz másnak is:) Próbáltam mindennek utánajárni, de biztos van benne hiba, mert eléggé összetett (azt is mondhatnám, hogy néha zavaros) a téma. Ha valaki hibát talál, kérem jelezze megjegyzésben. Kösz:)

Kategória: Tech | Címke: , , , | 2 hozzászólás