A Dynamic Memory gyakolatilag a Hyper-V 1.0 kripli memória-kezelését orvosolja. Anno ugyanis, amennyi RAM-ot odaatál egy VM-nek, azt a VM a  fizikai memóriából rögtön ki is harapta. Ennek köszönhetően aztán, hibába szerettél volna 10VM-et futtatni mindet 1-1gb ram-mal, ha a host-ban csak 8Gb ram volt, akkor a 7. VM után vége volt a konszolidációnak.

A DM most már megengedi, hogy a VM-ek dinamikusan használják fel a gépi memóriát, előre meghatározott méretek között. Szerencsére az MS nem a guestOS-re bízta az újabb ram területek allokációját, hanem az enlightenment-en keresztül végzi el. Ennek köszönhetően azon guestOS-ek is használhatják ezt a funkciót, amelyek egyébként hot-add funkciót nem tudnak.

Nos, ez a feature ESX-nél még a 2.0 soroztban megjelent (2003). Az ESX-nél alap kialakítás, hogy a VM-ekszinte soha nem kapják meg a számukra konfigurált ram-ot. Az esx van annyira okos, hogy csak akkor áldoz fizikai ram-ot egy VM-re ha annak valóban szüksége van rá. Emiatt aztán a konszolidációs ráta is sokkal-sokkal magasabb, mint egy hyper-v esetben.

A DM szépséghibája, hogy nem minden guestOS támogatott. Szerencsére a legnépszerűbb OS-ek hasznáhatják, de pl. linux VM-ek egyelőre nem. A VMware-nél ilyen limitáció természetesen nincs, a funkció teljesen OS agnostic.

A DM gyakorlatilag az ESX-ekben lévő Share funkciónak feleltethető meg. Persze ESX-ben share-ekkel a CPU-t és a disk IO-t is tudjuk szabályozni a ram mellett, továbbá ezen értékek futás közben is, sőt időzítve is változtathatóak. Számomra nem derült ki, hogy a DM prioritása bekapcsolt gépnél vajon változtható vagy sem…

Mi van még hátra? Nos ha az MS be akarja fogni az ESX ram kezelését, még van mit csinálni:

• nincs page sharing
• nincs kernel swap
• az ESX 4.1-ben lévő Memory Compression újabb elképsztő megoldást hozott, ami szerintem egy újabb mérföldkő ram kezelés terén.

  Bár nem VMware közeli a hír, mégiscsak érdekes Szóval a mostani frissítőkedd hozta magával az első Hyper-V javítást. A patch egy “apróbb” hibát javít: guest OS-ben futtatot rosszindulatú kód használatával DoS támadás indítható a Guest-et futtató hypervisor ellen. Magyarul a Hyper-V-t (és ezzel az összes rajta futó VM-et is) megfektetheti a saját virtuális gépe. A sérülékenység csak hely  támadást tesz lehetővé (távolról nem indítható).  Ezek szerint a Hyper-V nem biztosít 100%-os izolációt Kernel, Server Core és Guest között.

A patch telepítése természetesen újraindítást igényel.

Nem tudok nem emlékezni arra az óriási hype-ra, amelyben az MS hangoztatta a microkernel előnyeit az ESX-szel szemben: 31x több potenciális hiba lehet az ESXi-ben, mint a Hyper-V-ben,  PUSZTÁN a footprint méretéből következően.

Idézet1

A footpint kapcsán, melyben egy korábbi ESX javításra hivatkoznak (arra utalván, hogy az ESXi mennyivel támadhatóbb a monolitikus kernel miatt)

Erre tessék, itt a frissítőkedd… Ezek után elég ciki odaállni az ügyfélhez, hogy “Bocs, de mégsem volt igazunk…”

Idézet2

(Azure design principles): “Small footprint: any features not applicable to our specific … scenarios are removed. (azaz a Windows code nem illeszkedik az design elvárásokhoz, hogy el kell távolítani?)  This guarantees that we do not have to worry about updating or fixing unnecessary code, meaning less churning or required reboots for the host.  All critical code paths are also highly optimized for our … scenarios.”

Eddigi öngólok :

• 1) MS:“A footprint mérete rettentő fontos a potenciális hibák miatt. Ezért a Hyper-V biztonságosabb”  Látjuk
• 2) MS: “You don’t really need that live migration stuff.  It’s overkill and nobody really uses VMotion anyway.”. Aztán mégiscsak lett Live Migration.
• 3) “A Memory overcommitment potenciálisan veszélyes, éles környezetben nagyon kockázatos” A minap olvastam, hogy mégiscsak lesz Hyper-V 2-ben hasonó feature… Most már nem kockázatos???

Gondolom a Storage VMotion és az FT is csak a geek-ek játéka és totál felesleges addig amíg….