vSphere 6.7u1 upgrade 2.

Miután sikeresen megtörtént a PSC frissítése, következő lépésben a vCenter szerver upgrade-et kell végrehajtani. Nem nagy meglepetés, de az upgrade folyamata szinte teljesen megegyezik a PSC frissítéssel. A következőkben csak az eltéréseket sorolom fel.

Mivel a forrás vCenter eléréséhez szükség van a PSC-re, ezért a Connect to source appliance oldalon több információt kell megadni.

A környezetünk nagyságától (illetve  jövőbeli méretétől) függően választhatunk néhány előre definiált VM méret közül. Ha utólag változtatni kell a mérteket, a memória és CPU egyszerű eset, de a diszkekkel kapcsolatban érdemes utána nézni a Neten. Ezek után megtörténik az appliance telepítése, majd megkezdődik a második fázis. Itt is csak a PSC-hez képest eltérő vagy új képernyőket mutatom meg.

A preupgrade check eredményeként itt olyan üzeneteket is kaphatunk, aminek a PSC esetében nem értelmezhető. Ilyen a csatolt képen látható warning is.

Végül még egy nagyon fontos dologra kérdezz rá a telepítő. Eldönthetjük, hogy az upgrade során a forrás vCenter adatbázisából milyen adatokat vegyen át az új appliance. Ennek hatása van a telepítés idejére, így a becsült állásidőre is. Nyilván a harmadik opció a legoptimálisabb választás (megmarad minden eddigi feladat, esemény és performancia adat.

Ha véget ér a folyamat, az eredmény a lekapcsolt forrás vCenter szerver és a működő új 6.7 U1-es szerver. Látható, hogy ha semmi rendkívüli probléma nem jön közbe, akkor az upgrade egy nagyon jól követhető, egyszerű folyamat.

Az új verzió egyik előnye, hogy közel teljes értékű HTML5 klienst kapunk.Erről majd egyszer később...

vExpert 2019

A VMware a napokban jelentette meg a 2019-ben  vExpert-nek választottak listáját. Immár negyedik alkalommal kaptam meg, aminek persze nagyon örülök. A teljes lista itt található: vExpert Directory

Magyarországról a következő nevek szerepelnek a listán, bár szerintem van egy kakukktojás :)

Gratulálok mindenkinek!

vSphere 6.7u1 upgrade 1.

A közeljövőben tervezem, hogy az általam üzemeltetett Vmware környezeteket egységesen 6.7 U1 verzióra hozom fel. Ez egy igen sok lépcsős feladat lesz, mivel jelenleg van 6.0-ás Windowsos vCenterem, 6.5U1-es vCenter appliance külső PSC-vel, és mindehhez még hozzájön egy Horizon környezet is, ami már nem alkalmas Windows 10-es linked clone gépek kezelésére. Tovább bonyolítja a dolgot, hogy a 6.7 U1-től a külső PSC használata már nem ajánlott. A 6.7 U1 megjelenés óta már eltelt 3 hónap, mire odajutok, hogy az éles rendszert frissítsem, az még további pár hónap lesz, így úgy hiszem, hogy elég "érett" verzióra fogok frissíteni. Azt, hogy érdemes-e átállni 6.5-ről 6.7 U1-re, azt mindenki eldöntheti a fellelhető információk alapján.
Én mindenesetre megteszem az első lépést azzal, hogy a 6.5 U1-es tesztkörnyezetemet megfrissítem a legújabb verzióra. A frissítés módja szerencsére olyan, hogy a végén az új verzió mellett megmarad a régi is kikapcsolt állapotban, így ha valami igen nagy gond lenne, a régi visszakapcsolásával semmissé tehetem az egészet.

Ebben az első részben a PSC upgrade folyamatát fogom leírni. Ehhez a VMware-VCSA-all-6.7.0-11726888 verziót fogom használtam. Letöltés és kicsomagolás után, a grafikus felületű upgrade a vcsa-ui-installer\win32 mappában érhető el. Indulás után egy elég tetszetős felületet kapunk, ahol nekikezdhetünk a frissítésnek.

Az egyes lehetőségek magukért beszélnek. Ebben a konkrét esetben a második, Upgrade opciót kell választani.

A következő ablakban kapunk egy rövid ismertetőt arról, hogy az upgrade gyakorlatilag egy kétlépcsős folyamat. Első lépésben létrejön egy új virtuális gép, amire a második lépésben átkerül minden beállítás a forrás applinace-ről.

Meg kell adni a forrás appliance nevét vagy IP címét, majd Connect to Source.

A kapcsolódáshoz szükséges az eredeti applinace root jelszava, és annak a környezetnek az elérhetősége, ahol az appliance fut.

Következő lépésben azokat az információkat kell megadni, hogy az új appliance milyen környezetbe kerüljön.

A fenti három ablakba a szokásos információkat kell megadni az appliance telepítéséhez (folder, cluster, datastore)

A következőkben az appliance ideiglenes hálózati beállításait kell megadni. Ideiglenes, mivel a második körben a forrás appliance beállításait lemásolja, és alkalmazza az újra.

Ezután egy összefoglaló képernyőn átnézhetjük az előzőekben megadott információkat, és ha mindent jónak találunk, akkor a Finish hatására megkezdődik a telepítés.

A környezetünk sebességétől függően 10-20 percet vesz igénybe a művelet.

Miután ez a fázis rendben lement, lehetőségünk van rá, hogy a második körös konfigurálást egy másik időpontban csináljuk meg. De ha már belekezdtünk, akkor inkább Continue.

A következő ablakban pár szóban leírja, hogy mi is fog következni. Gyakorlatilag lemásol minden fontos adatot, beállítást a forrás gépről, majd azt lekapcsolja. Utána alkalmazza az eredeti hálózati beállításokat az új appliance-re.

Első lépésben plusz információnak meg kell adnunk az SSO admin nevét és jelszavát. Nálam ez az administrator@vspehere.test. A többit kitölti előre, mivel azt már az előző fázisban bekérte tőlünk.

Azután végrehajt egy upgrade előtti ellenőrzést, és annak eredményét jeleníti meg. Ha nincs különösebb probléma, akkor mehetünk tovább.

Mielőtt megkezdődik az adatok másolása, konfigurálás, stb. még átnézhetjük a megadott adatokat, majd Finish.

Kapunk egy figyelmeztetést arról, hogy az eredeti applinace le lesz kapcsolva a konfigurálás során.

A telepítés befejezése előtt kapjuk még a fenti üzenetet. Ha lezártuk, rövidesen vége a folyamatnak.

Ez már egy kicsivel hosszabb folyamat, főleg ha egy nagyméretű vCenter-t frissítünk. De most nem ez volt a helyzet, így ez is lement kb. 20 perc alatt. Ez volt az utolsó lépés. A végeredmény az lett, hogy a régi appliance eredeti formájában lekapcsolva megmaradt, az új pedig fut. Ha belépünk az appliance management felületére, akkor egy megváltozott, a HTML5-ös kliens felületére emlékeztető oldalt kapunk.

Természetesen a 6.5 U1-es vCenter appliance gond nélkül működik az új 6.7 U1-es PSC-vel is, mint az várható volt. Így nem vagyunk rákényszerítve arra, hogy mindent egy lépésben csináljunk meg.

A következő bejegyzésben a vCenter frissítés folyamatát írom majd le, de nyilván az nagyrészt megegyezik a fentiekkel, így az már sokkal rövidebb lesz.

Egy kis PowerCLI - HBA driver és firmware verziók lekérdezése

A közelmúltban ellenőrizni kellett, hogy a HPE pengékben lévő HBA kártyák driver és firmware verziói elérnek-e egy bizonyos szintet. A driver verzió lekérdezése nem gond a PowerCLI segítségével, de a firmware-rel kapcsolatos infók kinyerése már problémás. Konkrétan én nem is találtam rá módot, hogy hogyan lehetne.
Viszont kapóra jön ilyenkor, ha a host gyártójának van valamilyen PowerShell modulja, amivel a hardware-ről lehet lekérdezni információkat. A HPE esetében pont ez a helyzet.
Egy korábbi bejegyzésben leírtam, hogy miként lehet a hostokat ellátni olyan címkékkel, amik az adott host iLO címét tartalmazzák. Ezt kihasználva viszont már igen könnyű dolgunk van, mivel a van egy Get-HPiLOFirmwareInfo parancs, amivel a hiányzó információt ki tudjuk nyerni.

A script a következő:

$h=get-vmhost

$iLOIP=$h| Select Name,@{N="iLO";E={((Get-TagAssignment -Category ILO_IP -Entity $_ | select -ExpandProperty Tag).Name)}}

$adminmol=get-credential

$hbareport=@()

foreach ($h1 in $h)

{

$ilo=$iloip|?{$h1.name -eq $_.name}

if ($ilo.ilo -gt " ")

{

$report=""|select-object Host_Name,hba_driver,hba_firmware

$c=$h1|Get-EsxCli

$hba_driver=$c.software.vib.list()|?{$_.name -eq "lpfc"}|select version

$hba_firmwareinfo=Get-HPiLOFirmwareInfo -Server $ilo.ilo -Credential $adminmol

$hba_firmware=$hba_firmwareinfo.firmwareinfo|?{$_.firmware_name -like "*Flex*"}

$report.Host_name=$h1.name

$report.hba_driver=$hba_driver.Version

$report.hba_firmware=$hba_firmware.FIRMWARE_VERSION

$hbareport+=$report

}

} 

A kapott output pedig így néz ki:

Host_Name                hba_driver                      hba_firmware

---------                ----------                      ------------

xxxxxxxxxxxxxxxxxxxxxxxx 11.2.266.0-1OEM.650.0.0.4598673 11.2.1226.20

yyyyyyyyyyyyyyyyyyyyyyyy 11.2.266.0-1OEM.650.0.0.4598673 11.2.1226.20

zzzzzzzzzzzzzzzzzzzzzzzz 11.2.266.0-1OEM.650.0.0.4598673 11.2.1226.20

Mivel pl. az UCS szerverekhez is létezik PowerShell modul, ez a módszer ott is követhető.

VMware Tools 10.2.0 és Boldog Karácsonyt!!

A napokban jelent meg a VMware Tools újabb verziója. A Release Notes a szokásos dolgok mellett megemlíti, hogy létezik egy új Technical Paper, amiből megtudhatjuk, hogyan telepíthető, illetve terjeszthető a Vmware Tools a Microsoft SystemCenter Configuration Manager (SCCM) segítségével.

A leírás szerint csak Windows 2016-os szerver és SCCM 2016-os környezetben használhatjuk ezt a fajta telepítési módot, ami számunkra egyelőre még nem elérhető sajnos.

A leírás itt található: Deploying Vmware Tools Using SCCM

Végül pedig szeretnék mindenkinek Boldog Karácsonyt kívánni a következő képpel, amit öt nappal ezelőtt készítettem a Bükkben.

VMware Certified Advanced Professional 6 – Data Center Virtualization Deployment

Bár már hónapok óta a vCenter 6.5 és ESXi 6.5 a legújabb verziók, de még a tárgyban szereplő vizsgából a mai napig nincs 6.5-ös verzió. Igaz, hogy az áttérés sem történt még meg (csak a teszt rendszerben). Így mivel lehetőségem volt viszonylag kedvezményes áron (amit kivételesen nem is nekem kellett fizetnem) egy tanfolyamhoz csomagoltan megkapni a vizsgakupont, így belevágtam. Mivel a kedvezményes ajánlat az ArrowECS-től jött, így egyértelmű volt számomra, hogy a vizsgát is ott teszem le.

Néhány dolog a vizsgával kapcsolatban:

• 27 feladat, amit egy elő környezetben kell megoldani
• HOL szerű környezet, amiben a billentyűkezelésre vonatkozóan van néhány megszorítás, de nem annyira fájdalmas, mint amilyennek elsőre tűnt
• Bő 3 óra, beleszámítva már a pluszba kapott 15 percet is
• A feladatok kb. fele simán megoldható a napi adminisztráció során felszedett ismeretek alapján
• Az 5-ös vizsgához képest gyorsabb környezet, de még mindig lassú, így akár "segíthet" abban, hogy ne sikerüljön a vizsga
• Néhány esetben egy kicsit "trükkös" a feladat. Konkrét feladatot nem írhatok ide le, de pl. olyanra gondoljatok, hogy a leírás szerint meg kell határozni, hogy ki hajtott végre egy konkrét művelet a környezetben, és ha már rájöttünk hogy melyik log-ban kell nézni, akkor kiderül, hogy több felhasználó is kiadta a kérdéses parancsot, vagy ahhoz hasonlót. 
• A legfőbb nehézséget az adja, hogy általában egy bizonyos technológiával dolgozunk napi szinten, viszont a vizsgán a többi is jelen van. Pl. én SAN-t használok, de ettől az iSCSI vagy NAS kezeléssel is tisztában kell lenni
• Ha valaki ódzkodik a scriptektől, de ezt a vizsgát le szeretné tenni, érdemes mégis nekiesnie, mert biztosan jelent jó pár pontot a végső elszámolásnál
• Kiértékelés is scripttel történhet, mert a vizsga után egy órán belül meg is küldik az eredményt. Az ötös vizsgánál erre még kellett két hét, mivel ott valaki ténylegesen átnézte mit is csináltam, és az alapján értékelt. Ennek viszont szerintem van egy nagyon pozitív következménye. Nevezetesen a feladatokat nagyon pontosan kell megfogalmazni, ha azt szeretnék, hogy az eredmény scripttel ellenőrizhető legyen. Pl. az kevés, hogy hozz létre mondjuk egy vDS-t, ettől konkrétabbnak kell lenniük. És minél konkrétabbak, nekünk annál könnyebb dolgunk van.

És végül az eredmény :) Acclaim Badge

vDocumentation - PowerCLI modul

Kb. három hónapja hallottam erről először, de miután megnéztem, úgy gondoltam, hogy nem olyan nagy durranás, hogy erről írni kelljen akár röviden is. De mivel ezt is elvileg a "közösség" fejleszti, ezért várhatóan sokat fog fejlődni az elkövetkezendő időben. Ezt vetíti előre az is, hogy már azóta is sokat változott, bővült a modul. Illetve mivel az idei VMworld-ön ennek külön előadást szenteltek, ezért is várható hogy a tartalom, funkcionalitás még jelentősen bővülni fog.
Tulajdonképen arra való, hogy egy egységes dokumentációs lehetőséget biztosítson az adminisztrátorok számára, egyelőre a hostok vonatkozásában.

Persze erre ott van az rvtools, de abba kód szinten nem tudunk belenézni, esetleg módosítani.

A terjesztés már úgy van megoldva mint a komplett PowerCLI csomag, azaz a Powershell Gallery-n keresztül.
Lekérdezhetjük,

Find-Module -name vDoc*

majd telepíthetjük a modult a szokásos módon:

Install-Module -Name vDocumentation  

Telepítés után ha megnézzük, hogy milyen új parancsok kerültek be a PowerShell rendszerünkben, akkor ezt kapjuk:

Get-Command -Module vDocumentation|select name,version 

Name              Version
----              -------
Get-ESXInventory  2.1.0  
Get-ESXIODevice   2.1.0  
Get-ESXNetworking 2.1.0  
Get-ESXPatching   2.1.0  
Get-ESXStorage    2.1.0  

A nevek alapján már mindenki következtetni tud a tartalomra.

Ami fontos kényelmi szolgáltatás, hogy az eredményeket közvetlenül Excel file-ba is megkaphatjuk még úgy is, ha nincs telepített Excel a gépünkön (ami persze manapság már elég ritkán fordul elő). Ehhez természetesen egy újabb modul szükséges, nevezetesen az ImportExcel modul, amit szintén a most már szokásos módon telepíthetünk, frissíthetünk.
Megjegyzendő az is, hogy host, cluster és datacenter szinten is futtathatjuk a scriptet, ilyenkor Excel-t megadva mint formátumot, hostonként egy sort kapunk.

Mint az elején már említettem, ettől sokkal összetettebb scriptek is vannak hasonló célra (a vCheck is idetartozik), de mint mindenből, ebből is lehet tanulni. Nem csak azt, hogy hogyan tudunk bizonyos értékeket lekérdezni, hanem azt is, hogy hogyan kell modul-t írni, és ez ami miatt én is elkezdtem ismerkedni vele.

vSphere 6.5 Host Resources Deep Dive Ingyen!!

A szerzők, a Rubrik és a VMUG támogatásával ingyenesen letölthető a névben szereplő könyv. Pont a napokban írtam róla, hogy érdemes beszerezni.

A könyv letölthető innen: http://pages.rubrik.com/host-resources-deep-dive_request.html?utm_campaign=Authors

Könyvajánló - VMware vSphere 6.5 Host Resources Deep Dive

Ilyen még úgysem volt :)

A nyár közepén jelent meg Frank Denneman és Niels Hagoort szerzőpáros fenti könyve, amit már a kiadást megelőző hónapokban is figyelemmel kísértem, mivel már régen szerettem volna egy olyan könyvet beszerezni, ami megfelelő mélységgel, de mégis érthetően tárgyalja a mai modern x86 alapú szerverek működését.
Ezen ismeretek beszerzésére a mostani, egyre nagyobb és nagyobb kapacitású szerverek esetében fokozottan szükség van, hiszen egy-egy szerveren ma már akár 50-60, de még több virtuális gépet is futtathatunk (a szerverekben lévő nyers erőforrások lehetővé teszik), így minden apró részlet komoly hatással lehet a performanciára.
Így amikor megjelent, az elsők közt rendeltem meg. Mivel szeretem a papír alapú könyveket, így egyáltalán nem volt gond, hogy az első hónapokban csak ilyen formátumban volt elérhető.

Mint a képen is láthatjátok, négy téma köré szerveződnek a fejezetek, mint ahogy a VMware üzemeltetés során is ezen erőforrások mentén kezeljük a környezetünket.
Azok számára is hasznos lehet, akik nem VMware-t üzemeltetnek, de 100%-ban mi tudjuk igazán kihasználni az innen felszedett tudást.

A VSAN-t tárgyaló fejezet kivételével mindent elolvastam, és ha majd az időm engedi, akkor következik a második olvasás, amikor is már olyan szempontból is nézem majd, hogy az én környezetemben milyen módosításokat érdemes végrehajtani ahhoz, hogy még jobb legyen minden.

Csak egy példa. A Host Power Management témában leírtakat alkalmazva egy teszt hoston kb. 20%-kal nagyobb CPU teljesítményt sikerült elérni (benchmark programmal mérve).

Az aktuális dolgokon kívül néhány, a következő években mindennapossá váló technológiáról is esik szó (pl. 3D Xpoint)

Akit érdekel, az Amazon oldalán megtalálja.

PowerCLI upgrade

Mióta a PowerCLI fejlesztői áttértek a modul alapú terjesztésre, azóta már két frissítés is kijött. És pontosan ez az egyik legnagyobb előnye a rendszernek. Nem kell várni, amíg összejön egy olyan "csomag", amiért már érdemes új telepítő készletet készíteni, hanem ha az egyik modulban történik valami komolyabb javítás/új parancs létrehozás, akkor egyszerűn ráhúzhatjuk az új verziót a gépünkre.
Ha nem akarjuk nézegetni, hogy mikor jön ki módosítás, akkor akár egy scriptet is írhatunk, ami mondjuk hetente egyszer leellenőrzi a powershellgallery oldalon, hogy van-e valami változás, és ha igen, akkor telepíti is azt.

Ahhoz hogy tűzfal mögül is rendben is működjön az update, előbb a következő pár sor futtatásával ezt lehetővé kell tenni a PowerShell-ben is.

$webclient=New-Object System.Net.WebClient

$creds=Get-Credential

$webclient.Proxy.Credentials=$creds

Feltétel még, hogy a PowerShell-t, vagy az ISE fejlesztői környezetet admin módban indítsuk el.

Természetesen szemre is meg lehet állapítani, hogy van-e változás a telepítetthez képest, de egy pár soros scripttel biztosíthatjuk, hogy nem néztünk el valamit.

$installed=get-installedmodule VMware*|select name,version|Sort-Object name

$newest=find-module vmware*|select name,version|Sort-Object name

foreach ($module in $newest)

{

if ($module.name -notin $installed.name)

    {

    $module.name +"***New module***"

    }

else

    {

    $existing=$installed|?{$_.name -eq $module.name}

    if ($existing.version -ne $module.version)

        {

        $module.name +"***Updated Module***" + $module.version

        }

    }

} 

A fenti pár sor összehasonlítja a telepített és a Powershell Gallery-ben megtalálható modulokat, és kilistázza ha újat vagy módosítottat talál. (Szokás szerint nem a kód szépségére törekedtem :) )

Az eredmény:

VMware.PowerCLI***Updated Module***6.5.3.6870460
VMware.VimAutomation.Cis.Core***Updated Module***6.5.3.6870462
VMware.VimAutomation.Core***Updated Module***6.5.2.6234650
VMware.VimAutomation.Nsxt***New module***

Látható, hogy egy új (Nsxt) és három frissített modul van az eredeti telepítéshez képest (mivel ezen a gépen még nem frissítettem a kezdeti állapotot)

Hasonlóan a telepítéshez, itt is elegendő a VMware.PowerCLI modult frissíteni, mert az alapján tudja, hogy mely más modul módosult, és a telepítést az alapján elvégzi.

Update-Module VMware.PowerCLI 

Ha ezek után újra lefuttatjuk a fenti scriptet, akkor nem meglepő módon nem lesz eredmény, hiszen minden új és változott modul telepítésre került.

Ha megnézzük, hogy mink is van pontosan, akkor a

get-installedmodule VMware*|select name,version

parancs megadja a listát:

Name                                Version      
----                                -------      
VMware.DeployAutomation             6.5.1.5299608
VMware.ImageBuilder                 6.5.1.5299608
VMware.PowerCLI                     6.5.3.6870460
VMware.VimAutomation.Cis.Core       6.5.3.6870462
VMware.VimAutomation.Cloud          6.5.1.5375799
VMware.VimAutomation.Common         6.5.1.5335010
VMware.VimAutomation.Core           6.5.2.6234650
VMware.VimAutomation.HA             6.0.0.5314477
VMware.VimAutomation.HorizonView    7.1.0.5307191
VMware.VimAutomation.License        6.5.1.5375648
VMware.VimAutomation.Nsxt           2.0.0.6870461
VMware.VimAutomation.PCloud         6.5.1.5376282
VMware.VimAutomation.Sdk            1.0.0.5334677
VMware.VimAutomation.Srm            6.5.1.5374694
VMware.VimAutomation.Storage        6.5.1.5374001
VMware.VimAutomation.StorageUtility 1.0          
VMware.VimAutomation.Vds            6.5.1.5374428
VMware.VimAutomation.vROps          6.5.1.5375723
VMware.VumAutomation                6.5.1.5301639


A lényeg tehát az, hogy akár a legkisebb módosítások esetében is pillanatok alatt frissíthetjük a PowerCLI környezetünket.

Az egyes verziók változását itt is követhetjük: VMware PowerCLI Change Log

VMworld 2007 session videók

A VMware már az előző évben is viszonylag hamar elérhetővé tette az előadások videóit mindenki számára, és ez most sincs másképp. Pár éve még ezért fizetni kellet egy éves díjat, hogy a legutolsó év előadásait meg lehessen nézni azoknak is, akik nem tudtak elmenni.

Hogy még egyszerűbb legyen a dolgunk, William Lam létrehozott egy oldalt, ahol direkt linkek segítségével érhetjük az előadásokat. Biztosan mindenki ismeri a virtuallyGhetto nevű oldalát, ahol az erről szól bejegyzését is megtalálhatjátok.

Ha esetleg az európai előadások közt találtok olyat, amihez nem tartozik videó, akkor érdemes megnézni az amerikai szekciót is, és fordítva.

Jó videózást!

VMUG előadás anyaga (30 perc PowerCLI)

Már jó régen volt, de talán még most sem késő megosztani az előadás anyagát. Aki ott volt, az biztosan emlékszik, hogy nem volt teljesen zökkenőmentes a dolog, mivel csak kézi mikrofon volt, így egy kézzel kellett volna demózni, ami ebben a témában elég nehéz dolog, még ha a kódok nagyrészt előre el is voltak készítve.

Remélem azért arra jó volt, hogy ha eddig valaki még nem használta, esetleg kedvet kapott hozzá, aki meg meg aktív használó, az az új telepítési módról kapott némi infót.

Innen tölthetitek le: 30 perc PowerCLI

De hogy valami plusz infó is legyen... Említettem az előadáson, hogy a közösség vegyesen fogadta a telepítési mód megváltozását. Általában céges környezetben nem feltétlenül lett egyszerűbb, mivel addig letöltöttük az MSI csomagot, és lokálisan telepítettünk. Most meg az lenne a jó, ha a PowerCLI direktben elérné az Internetet, akkor is ha egy proxy-n kell keresztül menni.
Szerencsére ez általában igen egyszerűen elérhető a következő kis kód segítségével:

$webclient=New-Object System.Net.WebClient

$creds=Get-Credential

$webclient.Proxy.Credentials=$creds 

Ezután a PowerCLI úgy fogja elérni az Internetet, mint a böngészőnkből is elérjük.

Egy kis PowerCLI - ki készítette a snapshotot?

Első ránézésre ez nem tűnik túl bonyolult kérdésnek. Viszont ha lekérdezünk egy snapshotot, nem lesz benne a készítőjének a neve. Ha a description vagy név mezőbe nem írta bele, akkor bizony utólag ebből megállapítani nem lehet.

$snap=Get-VM molszhbsigma01|Get-Snapshot

$snap|fl * 

Az eredmény:

Viszont mint általában mindenről, erről is készül bejegyzés az események közé. Csak annyi a dolgunk, hogy valahogy párba állítsuk a snapshotot a hozzá tartozó eseménnyel. Ez már így járhatónak tűnik, de van több probléma. Az egyik az, hogy az események is kipörögnek egy idő után (vCenter beállítás, ha igaz, akkor 30 nap a default). Ha ez már megtörtént, akkor sajnos ez az információ nem kinyerhető. A másik probléma, hogy ha megnézzük az eseményben és a snapshotban szereplő időket, akkor azok nem pontosan egyeznek. Lehet, hogy csak egy-két másodpercről van szó, de akkor is eltérhetnek. Az is gondot okozhat, hogy aznap készülhetett több snapshot egymáshoz közeli időkben, de mondjuk egy kivételével a többit már törölték.

Erre a problémára a lenti script készült. A lényege, hogy sorra veszem a snapshotokat, és mindegyiknél megkeresem az adott virtuális géphez tartozó azon eseményeket, amik aznap keletkeztek, és snapshot készítésről szólnak.
Ha egyáltalán nincs ilyen bejegyzés, akkor már kipörgött az adatbázisból. Ha pontosan egy darab van, akkor szerencsénk van, megtaláltuk a pontos egyezést. Ha viszont több esemény is van, azzal valamit kezdeni kell.
Erre azt találtam ki, hogy összehasonlítom az eseményekben szereplő időt a snapshotban található idővel, és azt az eseményt választom ki, ami a legközelebb van hozzá. Ennek már szinte 100%-os pontosságúnak kell lennie.

$Snapshotok=Get-VM|Get-Snapshot

$osszes=@()

foreach ($snap in $snapshotok)

{

$egysor=""|select-object vm,sh_name,sh_created,sh_createdby

$tol=$snap.Created.toshortdatestring()

$ig=$snap.Created.AddDays(1).toshortdatestring()

$egysor.vm=$snap.vm.Name

$egysor.sh_name=$snap.name

$egysor.sh_created=$snap.Created

$esemeny=Get-VIEvent -Entity $egysor.vm -Start $tol -Finish $ig|?{$_.fullformattedmessage -like '*Create virtual machine snapshot*'}

if ($esemeny.count -eq 0)

{

$egysor.sh_createdby="Már nem elérhető" #nincs meg az események közt

}

elseIf ($esemeny.count -eq 1) #pontosan egy esemény történt aznap

{

$egysor.sh_createdby=$esemeny.UserName

}

else #legalább két esemény volt aznap (adott gépre snapshot készítés)

{

$legjobb_index=0

$event_sanpshot_diff_time=[math]::abs(($snap.Created-$esemeny[0].CreatedTime).Seconds)

    for ($i=1;$i -lt $esemeny.count;$i++)

    {

        $d_time=[math]::abs(($snap.Created-$esemeny[$i].CreatedTime).Seconds)

        if ($d_time -lt $event_sanpshot_diff_time)

        {

        $event_sanpshot_diff_time=$d_time

        $legjobb_index=$i

        }

    }

$egysor.sh_createdby=$esemeny[$legjobb_index].UserName

}

$osszes +=$egysor

} 

Ha a futtatás végén kiírjuk az $osszes változó tartalmát, akkor pont azt kapjuk, amit szerettünk volna.

Abban az esetben ha már nincs meg az esemény, a "Már nem elérhető" szöveg jelenik meg.