Már korábban is szó volt arról, hogy akik új vSphere license-et vásárolnak, ingyenesen megkapják hozzá a Suse Linux Enterprise Server license-eket.

Egy tegnapi hír szerint most már az összes VMware vSphere felhasználó számára ingyenessé tette a VMware a SLES-t, így akinek megfelel a zöld kaméleon, annak nem kell további összegeket fordítani a vSphere környezeten futtatott operációs rendszerre. További információk, részletes cikk az alábbi címen:

http://blogs.vmware.com/vsphere/2011/02/suse-linux-enterprise-server-for-vmware-now-available-to-many-more-vmware-vsphere-customers-.html

Nos, egy lelkes lengyel gyerek elkészítette a NAGIOS vSphere figyelésre konfigurált változatát egy virtual appliance formájában. Az eredeti lengyel cikk google fordítását becsatolom. Innen el lehet már indulni.

Nagios vsphere appliance

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.

A csomagok leírását itt lehet megtalálni.

Nos, ennek vége   Bár grafikus interfész egyelőre nincs (várható, hogy hamarosan ez is lesz 3rd party megoldásban), de a használat rémesen egyszerű még CLI-ből is.

Mi is a Linked Clone?

• Virtuális gépek többszörözése a egyik legegyszerűbb feladat. Történhet ez kikapcsolt vagy bekapcsolt gépeken és könnyedén testreszabhatjuk a klón-t más gépnévvel, ip címmel, sid-del stb. A probléma a hagyományos klónozás esetén, hogy többszörözi a helyfoglalást, és emiatt viszonlyag sokáig tart (1-15 perc a vmdk méretétől fűggően). Azaz ha az eredeti VM-ünk egy 15gb-s lemezzel működik, akkor az össze klón ennyi extra helyet igényel a storage-on. Ezen enyhíthetünk a thin diszkek használatával a vSphere4-ben, azonban ha az eredeti VM valóban elfoglal 15 GB-t, akkor ennél nem lehetnek kisebbek a thin diszkek sem.
• A LINKED CLONE óriási előnye, hogy az eredeti VM mellé úgy hozzuk létre a klónokat, hogy azok továbbra is a szülő diszkét (diszkjeit) használják read-only módon, így tehát nincs szükség többszörös tárhelyfoglalásra. Az összes változtatást, amelyet a klónok csinálnánk az eredeti diszken, pedig egy különbözeti állmányba kerülnek (snapshot delta).
• A klón szempontjából tehát a diszk egyrészt egy snapsthot-ból áll, másrész az eredeti VM diszkjéből. A változatlan blokk-ok olvasása mindig az eredeti diszkről történik, az összes megváltozott blokk pedig a deltából kerül kiolvasásra.

Mikor érdemes linked clone-okat használni?

• Ha sok VM-et létrehozni
  • PL: oktatáshoz 70 XP-t kell délutánra
• fejlesztési és tesztrendszerek
  • alap kiépítésből indulva számos fejlesztési variáns létrehozása
• nagyméretű VM-ek klónozása gyorsan
  • 200gb-s VM-ek klónozása minimális tárkapacitással másodpercek alatt
• szűkös tárkapacitás
  • nincs elegendő hely 10-20 új VM-hez

Mi kell hozzá?

• vSphere4, vCenter4
• vMA appliance vagy PERL kit vSphereCLI-vel (SDK)
• Eredeti VM kikapcsolt állapotban, snapshot-tal
• vGhettoLinkedClone.pl script

Tulajdonságok, limitációk

• A GuestOS szempontjából transzparens a klónozás. Számára ugyanaz a diszk látszik, mint az eredeti VM-ben
  
• Az eredeti VM-nek több diszkje is lehet, a diszkek nem lehetnek independent módban (snapshot-ra szükség van), nem lehet fizikai RDM diszk.
• Elvileg 8 klón hozható létre egy szülő VM-ról (de ezt sikerült megcáfolni a tesztek során..több is elkészíthető)
• A klónok nem lehetnek HA cluster tagjai (le kell tiltani)
• Support: érdekes kérdés, hogy milyen szintű támogatást ad hivatalosan a VMware a linked clone funkcióra. Elvileg ez nincs a hivatalos feature listában, de az SDK-nak része, azaz ebből következne, hogy erre is jár hivatalos támogatás (azért ennek még utánajárok…)
• Hivatalos dokumentáció (sdk): http://www.vmware.com/support/developer/vc-sdk/

vGhettpLinkedClone script – használat

Hála a VMware Community-nek nem kell az SDK-t bogarászni, hogy legyártásuk az első linked klónokat. William Lam vExpert már megtette ezt és publikálta a saját script-jét, amit bátran használhatunk. A script-et (sok más mellett) itt találhatjátok: http://communities.vmware.com/docs/DOC-9852

1, vMA

Mivel a vGettoLinkedClone egy perl script, ezért ezt a környezetet biztosítanunk kell számára. Ezt kétféle képpen is megtehetjük: vMA vagy Perl toolkit letöltése. A vMA egyszerűbb (lévén, hogy benne van minden és egy virtuáls appliance-ként fut) így indulujunk el ezzel.

Letöltés: http://www.vmware.com/support/developer/vima/

A letöltött ovf-t kényelemesen betolhatjuk majd vSphere alá két kattintással. Adni kell egy IP címet és egy admin jelszót számára és ezzel be is fejeztük az implementációt.

2, Sciprt betöltése vMA-ba

Winscp-vel csatlakozzunk a vMA appliance-be és töltsük fel a scriptet a /home/vi-admin folder-be (csak ide lesz írási jogunk) A script-en állísuk be futtatási jogot (winscp, jobb klikk, pipáljunk be mindent )

3, VM kiválasztása és snapshot

Válasszunk ki egy VM-et, amelyről linked klónokat szeretnénk csinálni. Állítsuk le a VM-et, ellenőrizzük a limitációkat és készítsünk egy snapshot-ot a gépről.
Ezek után a VM-et vissza is kapcsolhatjuk szabadon, azonban a snapshot-ot már ne töröljük le lehetőleg. További snapshot-ok természetesen létrehozhatóak, illetve a VM-et innentől már el is indíthatjuk.

4, Linked Clone-ok létrehozása

vMA konzolban a következő parancsot kiadva kezdhetjük el létrehozni a linked klónjainkat:

[vi-admin@xxx]$ ./vGhettoLinkedClone.pl –server <vcenter name> –username <administrator_for_vcenter> –vmhost <esxname> –vmname <name of parent vm> –vmname_destination <linked clone name> –snapname <name of snapshot on parent vm> –-datastore  <name of target datastore>

PL:

A parancs futása néhány másodperc, ami alatt el is készül a klónunk… Azaz egy perc alatt 6-8 VM-et is létrehozhatunk:)

A példa kedvéért 10 klónt hoztam létre a szülő VM-ből kevesebb, mint 2 perc alatt.

Hogy lássuk valóban mennyi helyet is foglalnak ezek:

Konzolból ugyanez (itt már látszik a delta is)

A létrejött klónok teljesen úgy működnek, mintha teljes VM-ek lennének. Természetesen snapshot-olni is tudjuk őket:

Testreszabás

Mivel klónokról beszélünk a létrejövő gépek minden szempontból megegyeznek a szülővel, ami név és IP ütközést okoz. A szenzációs, hogy a klónok létrehozásakor is kihasználhatjuk a Guest OS Customization lehetőségeit!!! Ehhez nincs másra szükség, minthogy a meglévő testreszabási xml-t feltöltjük a vMA-ba is majd a scriptet meghívjuk a következő paraméterekkel:

–customize_guest yes –filename /home/vi-admin/vGhetto/xml/w2k3r2sp2-32bit.xml

Tudnivalók a Parent VM-ről

A klónok kezelése során könnyen elfeledkezhetünk arról, hogy a háttérben ott a megosztott szülő diszk. Szerencsére nagy bajt azért nem okozhatunk.

Lecsatolás

Végül pedig érdemes megemléíteni, hogy a klónjainkat le is tudjuk választani a közös diszkről, azaz teljesértékű VM-et tudunk belőlük faragni bármikor a későbbiek során. (ehhez még nincs script)

A nemrég megjelent VMware vSphere 4 (ESX 4.0) kapcsán talán az egyik legfontosabb dokumentum most a frissítési útmutató (ESX 3.5-ről), a napokban a legtöbb kérdés ezzel kapcsolatban ér utol. Az ünnepek alatt szakítottam egy kis időt, és megírtam a magyar nyelvű cikkemet (nemcsak a lusták kedvéért). Igyekeztem egy-két fontos tanácsot is elrejteni az amúgy dokumentációból is kiolvasható frissítéssel kapcsolatos tudnivalók közé. Jó frissítést mindenkinek!

Előkészületek: ESX3.5 szerverek és VI3 (2.5) felügyelet

A kiindulás alapom 2db ESX 3.5.0 (U3) szerverből álló fürt, a hozzávaló VI3 felülettel (ahol a VirtualCenter verziószáma 2.5). Gondolom, a legtöbb helyen ez a verzió van telepítve, hogy pontosan milyen liszenszel rendelkezünk (foundation-enterprise), a frissítés szempontjából ez most lényegtelen.

Frissítendő teszt környezet részletei (lényegtelen a frissítés szempontjából)

A VirtualCenter 2.5 szerver virtuális gépként fut (egy harmadik fizikai gépen), a frissítendő „szerverek”ez alkalommal fizikai gépek, a legkisebb Intel-VT-t már tartalmazó desktop processzorral szerelve (E6550), 4GB RAM-mal gépenként, valamint az ESX3 illetve ESX4 futtatására legalkalmasabb ASUS P5N-D alaplapot választottam (már nem nagyon lehet ilyesfélét kapni). Effélét bárki össze tud guberálni, aki a frissítést szeretné elpróbálni otthon, mielőtt, nekiesne az éles rendszernek. Persze bármilyen valódi szervernek látszó tárgy jobb kiindulási alap ennél (úgy látszik még mindig nem tudtam elszakadni az otthoni gagyi gépektől, amikor cikket írok J). Természetesen VMware Workstation 6.5 alatt is el lehet játszani a frissítést csupán virtuális gépekkel, itt arra kell csak figyelni, hogy az ESX-ek a 4.0-ás változattal már 2GB RAM-ot igényelnek.

Maradék zsebpénzemet ismét brand Intel NIC-ekre költöttem, vettem Intel Pro 1000-ből új PCI-E 1X-es változatot (PT), illetve a régi PCI-os változatot (GT). Illetve volt egy korábbi Intel Pro 100-am (ez 3.5 alatt még ment, de 4.0 alatt már le kell mondanom róla – hacsak nem teszek fel drivert hozzá – erről majd később még írok). Az alaplapra integráltan csak NForce Chipset-et használok, így az ASUS P5N-D alaplapi gigabit hálózat prímán működik mindenféle ESX/ESXi verziók alatt. Mondanom sem kell a teszt környezet (frissítésének) költségvetése így 300E forint alatt tudott maradni a végére, melynek jelentős része a hálózati kártyákra ment el.

Ami a memóriát illeti a szerviz konzol a szokásos alapértelmezett 272MB-ot eszi meg a kiszolgálón. A maradék 3.5GB-ot lehet szétosztani a virtuális gépek közt.

Storage hálózat szinten még mindig OpenFiler a barátom, lassan jön össze a zsebpénzemből egy EMC vagy NetApp FC storage+a hozzávaló HBA-k. Jó alternatíva lehet pl. a HP LeftHand VSA megoldása, amint lesz egy kis időm, utána nézek. Éles szeműek észrevehetik, hogy a VMFS 3.31-es változatot az ESX 3.5-tel formáztam, egy 3.33-ra fog változni, amikor majd 4.0-val formázok. Minden irányban kompatibilis, nem kell aggódni.

A hálózat a lehető legegyszerűbb hármas (Szerviz konzol, VMKernel – iSCSI és VMotion miatt, Virtuális gépek hálózata), és sajnos még nem redundáns (ezért a kis felkiáltójel a DRS_Cluster-en).

Liszensz szempontjából minden földi jó be van állítva teszt célból, az ENTERPRISE változatot fogom frissíteni (host liszensz fájl alapján).

Új szerverek minimum követelménye

Az ESX 4.0 fizikai kiszolgálókkal szemben elvárásrok

· 64 bites szerver

· minimum 2GB RAM

VirtualCenter 4.0 számára támogatott operációs rendszerek

· Windows XP Professional

· Windows 2003

· Windows 2008 (újdonság, eddig nem volt támogatott)

Támogatott adatbázis hátterek a VirtualCenter mögé, amennyiben nem a beépítettet akarjuk használni (MSDE avagy SQL 2005 Express Edition)

· IBM DB2

· Microsoft SQL Server 2005

· Microsoft SQL Server 2008

· Oracle 10g

· Oracle 11g (újdonság)

Az ESX/VI környezet frissítési folyamatának lépései

Az alábbi rajzon láthatóak a frissítés lépései, célszerű ezeket követni:

Az izgalom a 3-as pontnál kezdődik. Mivel nekem a VirtualCenter 2.5 is egy VM, ezért nyomtam róla egy mentést a folyamat előtt. Természetesen nagyobb rendszerek esetén célszerű követni a frissítési útmutatóban bemutatott forgatókönyveket:

(vsp_40_upgrade_guide.pdf)

Még egyszer összefoglalásképpen tehát:

To complete the upgrade, you will perform the following tasks:

· Upgrade VirtualCenter Server 2.5 to vCenter Server 4.0.

· Upgrade VMware Update Manager 1.0 to vCenter Update Manager 4.0.

· Use Update Manager to upgrade the ESX 3.5 server to ESX 4.0.

· Use Update Manager to upgrade the virtual machines on the ESX host to the latest version of VMware Tools and Hardware Version 7.

A VirtualCenter Server 2.5 – vCenter Server 4.0-re frissítése

Első feladat tehát a VirtualCenter Server frissítése. Nem kell aggódni, a frissítés után természetesen látni fogja a VC4 a korábbi 3.5-ös ESX szervereket is és az új 4.0-ás ESX-eket is egyaránt  (ez szokott lenni az első kérdés).

A frissítést megelőzendő lépjünk be a VirtualCenter-t futtató jellemzően Windows 2003 szerverre, és állítsuk le a „VMware VirtualCenter” Server szervizt.

Ezt követően a letölthető ZIP vagy ISO állományban indítsuk el az autorun.exe-t! Én a ZIP-et töltöttem le, mert az kisebb (VMware-VIMSetup-all-4.0.0-162902.zip).

Egyből figyelmeztet is, hogy egy korábbi verzió már telepítve lett a gépen, és az frissítve lesz.

A telepítés során az alábbi lépések érdekesek:

A korábbi liszensz fájlok helyett a 4.0-ás változatnál egyszerű sorozatszámokat lehet majd használni. Így van ez a Virtual Center esetén is, illetve az ESX hosztok esetén is. Én nem adok meg sorozatszámot, így EVAL módban fog futni a termék. Akinek van korábbi 3.5 érvényes S&S-e, azaz verziókövetése, azok megkapták a VMware-től e-mailben az új termék használatához szükséges kulcsokat. Erről még a későbbiekben írok.

Az adatbázis beállításokon most nem módosítok:

A megjelenő figyelmeztetés teljesen normális, ezeket a komponenseket majd később fogjuk frissíteni.

Érdekességképpen, ha a telepítőt újraindítjuk, akkor ez a rész tér csak el és akkor így jelenik meg:

Normál esetben a fenti képpel nem találkozunk.

Igen, frissíteni akarom az adatbázist. Legyen akár helyi MS SQL Express vagy távoli Oracle.

Célszerűen ezen nem változtatok, hogy milyen felhasználó alatt fusson a Virtual Center szervert szervize.

Az alapértelmezett portokat sem érdemes babrálni, hacsak nincs valami különös oka annak:

Ha tűzfalas környezetbe telepítjük a rendszert, akkor ezeket érdemes felírni a telepítés során, később nagyon hasznos lehet.

Nem árt, ha van Internet kapcsolata a gépnek, miközben a MS.NET keretrendszer újabb változatát telepíti a telepítő J

A telepítés ekkor van készen:

A START menüben kotorászva új ikonokat találunk:

A telepítés befejeztével indítsuk újra a gépet!

Virtual Center kliens frissítése (Virtual Center helyett vSphere 4.0 kliensre)

Ha megvagyunk a szerver frissítésével, akkor jöhet a kliens frissítése. Ez új telepítés esetén nem jár a VC-vel, de utólag fel lehet tenni. Illetve természetesen lehet frissíteni. Célszerűen most a VC szerverre telepítem, de természetesen lehet külön gépre is tenni.

A kliens új nevet kapott: vSphere Client.

A Host Update Utility-t NE tegyük fel! Ez majd később kerül fel, frissítve.

A telepítő a Visual J# 2.0 keretrendszer után pár fájlt még a helyére tesz.

Első belépéskor az SSL (self-signed) tanúsítvány miatt figyelmeztetés jelenik meg.

A belépés során új üzenetek jelennek meg, mint pl. „Discovering Plugins…”

Belépve a „Home” rész fogad. A korábbi 3.5-ös kliensben megszokott nézethez kattintsunk a „Host and Clusters” ikonra!

A képen jól látható, hogy a korábbi 2.5-ös VirtualCenter-t sikeresen megfrissítettem 4.0-ra, és minden objektum, ami az ESX szervereken volt megmaradt és használható.

Update Manager frissítése

Folytassuk a munkát az Update Manager frissítésével! Ezt szintén a telepítőkészlettel lehet indítani (autorun.exe).

Ne ijedjünk meg a felugró figyelmeztetéstől, ez teljesen normális, ha korábban volt 2.5-höz Update Manager telepítve.

Első feladat a belépés:

Használjuk a VC-hez használt felhasználónevet és jelszót!

Az adatbázist is frissítsük!

A frissítés után indítsuk el a klienst újra, majd frissítsük a kapcsolódó Plug-in-t!

ESX hosztok frissítése az Update Manager segítségével

Remediate an ESX Host

Now that Update Manager is installed, you can configure it so that compliance equates to an installed hypervisor running ESX 4.0. Then when you remediate against that baseline, Update Manager performs the upgrade.

ESX hosztok frissítése, első lépés – update csomag elkészítése

Az új VI4 klienssel az „Update Manager” ikont válasszuk!

Majd kattintsunk a „Baselines and Groups” fülre!

A „Baselines and Groups” fület választva a „Hosts” legyen benyomva, és válasszuk a „Create…” lehetőséget!

Ekkor az új „Baseline” varázsló fogad:

Adjuk meg neki az ESX4 telepítő ISO-t!

Várjuk meg, míg feltölti!

Fogadjuk el az alapértelmezettet!

Fogadjuk el az alapértelmezettet!

Eredmény:

ESX hosztok frissítése, második lépés – update csomag hozzárendelése

Válasszuk ki a frissítendő ESX szervert a „Host and Clusters” nézetet használva. Kattintsunk az „Update Manager” fülre. Most nyomjuk meg az „Attach…” gombot!

Adjuk hozzá a korábban létrehozott ESX 4.0 csomagot!

Most nyomjunk a választott host-on „Scan For Updates”-t!

Ne felejtsük el benyomni az „Upgrades” részt!

A hozzárendelést követően lehetséges, hogy nem fog megfelelni a host a HCL listának (Non-Compliant) de ettől még a frissítést el lehet végezni rajta. Sajnos a „zsuga-home-desktop” gépek nem mentek át a HCL listán, de ez várható volt!

Korábban egy tanfolyamon HP szervereket használva nem volt semmi gond. Ha esetleg a szerver nem felel nem, akkor sem kell kétségbe esni, ettől még nyugodtan mehet neki a frissítés, nagy valószínűséggel sikeres lesz a művelet végére.

Mi van, ha mégsem sikerülne? Semmi különös, a CD-ről még bármikor újra lehet húzni a host-ot, bár akkor sajnos az összes beállítást újra el kell majd végezni rajta, tehát ez amennyire lehet elkerülendő. Persze ezen (új host beállítsának automatizálása) is segíthet a „Host profiles” nevű újdonság!

ESX hosztok frissítése, harmadik lépés – update csomag hozzárendelése után futtatása (a host tényleges frissítése)

Ezt a lépést „Remediate” –nek hívják. Én először az 1-es szervert fogom frissíteni. Ilyenkor le kell állítani vagy át kell migrálni a virtuális gépeket róla egy másik hosztra a frissítés ideje alatt. Én az egyszerűség kedvéért most leállítottam a 2 VM-et, természetesen éles környezetben ezeket át kell migrálni másik hosztra!

A varázsló megjelenik:

Adjuk hozzá a Baseline-t, amit frissíteni kell majd.

Fogadjuk el a liszensz-t!

Tovább…

Illetve azonnal mehet a frissítés!

A Finish-re kattintva már indul is a hoszt gép frissítése!

Először szépen Maintenance mode-ba teszi a gépet, majd újraindítja és megkezdi a frissítését!

A host-on a háttérben ilyenkor ez történik (itt csaltam, mert ez ILO-val egy másik szerver – egy korábbi tanfolyam alapján) J

Betöltődnek a szükséges meghajtók.

Települnek a csomagok, természetesen minden karakteres módban, felhasználói beavatkozás nélkül, hiszen távolról kerül rá a frissítés!

Végezetül egy kis post config, majd készen is van a host! Amikor a host újraindul, multiboot-os lesz – mindenki nagy örömére J

Ha esetleg valami oknál fogva a 3.5-ös verziót szeretnék kipróbálni, a host indításakor erre is van lehetőség!

A host frissítése sikeresen végbement! Jól látszik, hogy a frissítés után az 1-es host-ban megjelent a másik hálózati kártya is! Hurrá, nem lesz végre amatőr „No redundant service console” figyelmeztetésem!

Ez eddig a 3.5 alatt nem látszott!

Most, hogy van 2-2 NIC mindkét hosztban, ideje létrehozni egy distributed switch-et!

Erről a következő cikkemben fogok írni!

Virtuális gépek frissítése az új Virtuális Hardverre (VMHW7) és VMware Tools frissítés

Nincs más tennivaló, mint a virtuális gépeket megfrissíteni! Majd a virtuális gépeken belül a VMware Tools-t is frissíteni az aktuális verzióra. Ezt célszerűen kötegelten kell elvégezni!

Célszerűen előbb a VMware Tools-t frissítsük majd utána módosítsuk a Virtuális Hardvert 4-ről 7-re!

A virtuális hardver frissítését itt lehet kérni (csak kikapcsolt VM-nél lehetséges!):

A figyelmezetést érdemes átnézni, visszafelé már nem lesz kompatibilis a gép innentől ESX3.5-tel!

VM Version: 7! J Természetesen nem egyenként, hanem ezt is tömegesen kell elvégezni a host-okra. Ehhez szintén az Update Manager-t hívhatjuk segítségül, csak ezúttal nem host, hanem VM-ek kötelgelt frissítésére használva.

Különálló (nem VC által felügyelt) hosztok frissítése

Megemlíteném, hogy kapunk egy Host Update Utility-t is, mely segítségével különálló ESX szervereket lehet megfrissíteni.

A tool segítéségével gyerekjáték különálló hosztokat frissíteni!

Liszensz kulcsokkal kapcsolatos tudnivalók meglévő ügyfeleknek

A VMware.com –on belépve a saját felhasználónévvel lehet letölteni a korábbi ESX3.5 felhasználóknak az ESX4.0-hoz tartozó liszensz kulcsokat! Ha több szerverre volt liszensz, akkor a kulcsokat össze is lehet konszolidálni, és egy sorozatszám fogja reprezentálni a korábbi sok szerverre érvényes CPU liszenszt. Erről majd még később részletesebben írok!

Összegzés

Ahogy látható, a frissítés ESX 3.5-ről 4.0-ra viszonylag egyszerű feladat, kb. egy fél napos munka (nagyobb rendszerek esetén valamivel tovább is eltarthat). A frissítés során az éles üzemet nem kell leállítani, amennyiben több fizikai gépünkből álló fürtön a virtuális gépeket az éppen frissítendő host-ról mindig elköltöztetjük, majd vissza).

A frissítés csak az első lépés, első feladatunk a korábbi virtual switch-ek helyett a „Distributed Switch” megismerése. Következő cikkemben az erre történő migrációt fogom bemutatni. Célszerűen, akik az elosztott hálózatos változatú ESX környezetre ruháznak be (Enterprise Plus), számukra célszerű a Cisco Nexus 1000V virtuális switch beszerzése is, így a legjobban kihasználva a rendszer lehetőségeit.

Jó frissítést kívánok mindenkinek!