2017. december 10., vasárnap

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.

2017. november 8., szerda

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


2017. november 3., péntek

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



2017. szeptember 28., csütörtök

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!




2017. augusztus 31., csütörtök

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.

2017. július 7., péntek

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.

2017. március 2., csütörtök

Egy kis PowerCLI - HP hostok címkézése az ILO IP címével

Az egész úgy kezdődött, hogy letöltöttem a HP Scripting Tools for Windows Powershell alkalmazást, és elgondolkodtam rajta, hogy mire is tudnám használni. Jelenleg még ismerkedési fázisban vagyok a három modullal, de azért pár hasznos dolgot már elkövettem vele.

Előbb röviden, hogy miről is van szó. Itt elérhető a fent nevezett tool. Három, külön telepíthető modulból áll: HPBIOSCmdlets, HPiLOCmdlets valamint a HPOACmdlets.

Ha feltelepítjük őket, akkor attól kezdve mind a parancssoros Powershell, mind az ISE tartalmazni fogja a *HP* parancsokat. A későbbiekben szeretnék róluk írni egy-két cikket, de most csak annyit, amennyi a tárgyban szükséges művelet elvégzéséhez szükséges.

Előbb egy változóban elmenetem az ILO-hoz szükséges belépési adatokat, majd létrehozok két tömböt.

$AdminMol=Get-Credential
$DotNetHPIloArray=New-Object System.Collections.ArrayList

$DotNetHPIlo_servernameArray=New-Object System.Collections.ArrayList 

Van egy Find-HPiLO parancs, amivel egy vagy több IP tartományban meg lehet keresni az összes iLO eszközt. A visszakapott eredményt én szűrtem, mivel vannak régebbi HP szerverek is a környezetben, de nekem azokra nem volt szükségem.

$DotNetHPIloArray=Find-HPiLO -Range IPRange1,IPrange1,IPrange3|?{$_.SPN -like "*BL460c*"

Az IPRange1 formátuma pl. ilyen: 192.168.1.1-254

Ha megnézzük, hogy mit kaptunk, akkor ilyen az output:


Mint látható, ezekért az adatokért még nem kellett bejelentkezni.

Következő lépésben keresni kellett egy olyan Get-HPiILO kezdetű parancsot, amivel visszakapjuk a host nevet. Elég sok parancs van, de azért a parancs neve alapján könnyen megtalálható a Get-HPiLOServerName cmdlet.

De ha esetleg bizonytalanok vagyunk, akkor a legegyszerűbb az, hogy egy Start-Transcript parancs után (ami ugye file-ba írja a kiadott parancsokat és az eredményüket is) lefuttatjuk az összes Get-HPiLO* parancsot egy adott iLO kártya esetén, és utólag elemezzük, hogy melyik parancs milyen adatokat adott vissza. Persze nem egyesével, hanem pl. Excelben egy per alatt összedobható ehhez egy script.

Ha megnézzük, hogy mit ad vissza a fenti parancs, akkor láthatjuk, hogy benne van az ESXi hostunk neve.


Ezek után a fent definiált másik tömböt már könnyen fel tudjuk tölteni a szükséges adatokkal.

$DotNetHPIlo_servernameArray=$DotNetHPIloArray.IP|Get-HPiLOServerName -Credential $AdminMol -DisableCertificateAuthentication|Select IP,Server_name

Ha pedig ez megvan, akkor már könnyű dolgunk van. Ebben a cikkben már részletesen írtam a tag-ek kezeléséről, így most abba már nem megyek vele. A lényeg, hogy előbb létre kell hozni egy tag kategóriát. Erre is megvan a szükséges parancs:
(New-TagCategory -Name "ILO_IP" -Cardinality Single -EntityType VMHost)

De ha gondoljuk, akkor akár az új HTML5 klienst is használhatjuk erre a célra:

Ha tehát már létezik a kategória, akkor adjuk hozzá a hostokhoz a megfelelő címkét.

$hostok=get-vmhost
foreach ($h in $hostok)
    {
    $hely=$DotNetHPIlo_servernameArray.server_name.IndexOf($h.name)
 
    if ($hely -ne -1)
     {
     $NewTag=New-Tag -Name $DotNetHPIlo_servernameArray[$hely].Ip -Category "ILO_IP"
     New-TagAssignment -Tag $NewTag -Entity $h
     }

    } 

És kész is:)


Látható, hogy van egy másik címke is, de az is hasonló módon került oda, így azt már nem részletezem.



2017. február 2., csütörtök

Egy egyszerű "UNMAP" (VMFS5)

Amióta egy 3PAR 8440-es storage-on tároljuk a virtuális gépeinket, thick (eager zeroed) diszkeket használunk. Azaz a storage-ra bízzuk a hatékony tárhely kezelést. Ez többféle eljárás alapján történhet, pl. deduplikáció vagy zero detection. Az, hogy ezek mennyire hatékonyak, most nem kérdés, a lényeg az, hogy működnek. Pl. egy VMware oldaláról majdnem teleírt 5TB-os datastore esetében ez látszik a storage oldalon:

Ha VMware oldalon nézzük ugyanezt, akkor ez van:


Azaz az 5TB-ból csak 352GB szabad. Eléggé jól látszik a különbség.

Mi történik akkor, ha a fenti datastore-on lévő gépek közül törlünk néhányat? Természetesen a VMware oldalon rögtön látszik a különbség:


Tehát már majdnem 3TB szabad hely van a datastore-on. Viszont ha megnézzük a storage-on, hogy hogyan változik a kötet kihasználtsága, igazából semmit nem látunk. Mintha nem is töröltünk volna. 

Ha azt szeretnénk, hogy tükröződjön storage oldalon is a törlés, akkor az a legegyszerűbb, ha létrehozunk a datastore-on az üres hellyel nagyjából megegyező méretű thick eager zeroed diszket. Ezáltal megtörténik a teljes üres terület nullákkal való feltöltése, így a storage a különböző technikákat használva már tudja csökkenteni a tényleges helyfoglalást. Pl. hozzunk létre egy új gépet a fenti store-on:


Ha elkészült, akkor pedig töröljük. Hagyjunk időt a storage-nak, hogy feldolgozza az új helyzetet, majd nézzük meg úja az első ábrán lévő értékeket.


Több mint 2TB-tal csökkent a tényleges foglalás. Így már jobban néz ki:

VMFS6-os időkben ez talán már majd megtörténik automatikusan, de most még ez manuálisan kell megtennünk.

A fenti képek már az új vSphere kliensben készültek :)


2017. január 20., péntek

Egy kis PowerCLI - Címkék (Tags) használta a get-vm parancsban

Ha már a virtuális gépeinknek vannak címkéi, akkor érdekes lehet az is, hogy miként lehet ezeket használni PowerCLI lekérdezésékben. Címkéket gyárthatunk manuálisan, de ahogy itt olvashatjátok, akár egy meglévő CMDB adatbázisból is feltölthetjük.

Két módszer röviden.

Get-Vm parancs -Tag paraméterének használata

Ha a -Tag paraméter után megadunk egy szöveget, akkor azokat a virtuális gépeket fogja kilistázni, amelyeken valamelyik címke tartalmazza a megadott sztringet (* is használható). Ez is lehet hasznos, ha valamelyik címke jól meghatározott értékeket tartalmaz. Pl. nekünk van egy Patch fázisra vonatkozó címkénk, és ha arra vagyok kíváncsi, hogy melyik gépek tartoznak egy megadott fázisba, akkor csupán ennyi a dolgom:

get-vm -Tag "E1AA" 

Viszont ha az "E1AA" sztring véletlenül szerepel egy másfajta mezőben is, akkor már gond van.


Get-Vm és Get-TagAssignment együttes használata

Ez egy kicsit bonyolultabb, de itt már pontosabban szűkíthetjük a lekérdezéseket.

Get-VM | Select Name,@{N="PatchPhase";E={((Get-TagAssignment -Category PatchPhase -Entity $_ | select -ExpandProperty Tag).Name)}}|?{$_.PatchPhase -eq "E1AA"}


Előbb lekérdezzük az összes gépet, meghatározzuk a PatchPhase értékeket, majd végül szűrünk az "E1AA" értékre. A Select parancs második tagja egy ún. Calculated Property, amely a Property Name-ből (N=) ill. egy property expression-ből (E=) áll.

Ha több címkét is akarunk használni a lekérdezésben, akkor az előbbihez hasonlóan azokra is képezni kell egy-egy property-t. Pl. a következő lekérdezés (az egész egy sor) megadja az összes olyan gépet, aminek a Patch fázisa E1AA, és a szerver gazdája Kovács János.

Get-VM | Select Name,@{N="PatchPhase";E={((Get-TagAssignment -Category PatchPhase -Entity $_ | select -ExpandProperty Tag).Name)}},
@{N="Szervergazda";E={((Get-TagAssignment -Category Szervergazda -Entity $_ | select -ExpandProperty Tag).Name)}}|?{$_.PatchPhase -eq "E1AA" -and $_.Szervergazda -eq "Kovács János"}

Fura mód a Web kliensben a keresésben ezeket a címkéket még nem lehet normálisan használni.Vagy csak én nem találtam még meg.



2017. január 17., kedd

NMON Visualizer

Többször előfordult már, hogy az esxtop által gyűjtött adatokat jó lett volna megjeleníteni grafikus módon. Erre persze a perfmon.exe is használható, de azért sok tekintetben eléggé körülményes, és nem túl felhasználóbarát.

A címben említett NMON Visualizer az IBM egyik belső fejlesztése, amit 2013-ban nyilvánossá tettek. Nem kifejezetten ilyen adatok megjelenítésére fejlesztették, de erre is jó. A támogatott formátumokat megtaláljátok a linken.

A használata nagyon egyszerű. Le kell tölteni a fenti linkről a  NMONVisualizer_2016-02-29.jar file-t, és futtatni. Az esxtop használatával kapott .csv file-t be kell tölteni, és utána már lehet is nézegetni az adatokat.

Előbb pár szó az esxtop használatáról. Csupán egyetlen dolog, hiszen mindenki ismeri. Ha elindítjuk a default beállításokkal batch módban, akkor látható módon igen rövid idő alatt igen sok adat képződik. Ha szeretnénk egy kicsit csökkenti az adatmennyiséget, akkor két dolgot tehetünk. Egyrészt növelhetjük a mintavételek közti időt (-d kapcsoló), vagy pedig az esxtop-ot elindítva interaktív módban, az egyes kategóriáknál az "F" használatával elvesszük a nem szükséges mezőket. Ha összeállt úgy, ahogy nekünk elégséges, azaz minden felesleges adat megjelenítését kikapcsoltuk, akkor az aktuális beállításból készíteni kell egy új konfig file-t (W), és a batch módú futtatásnál ezt a konfig file-t is megadjuk. Pl.

esxtop  -b  -n infinity -c ./alap1 > /vmfs/volumes/57fe4a2e-21a0072a-c0dc-e41f132e8b64/CD_IMAGES/55_alap1.csv

A fenti parancs az alap1 nevű konfig file-t használja, és addig fut, amíg manuálisan le nem állítjuk. A nagy méretű keletkező file miatt érdemes egy datastore-ra irányítani az output-ot.

Ha a fenti módon előálltak az adatok (akár több hostról is), akkor indítsuk el az NMON Visualizer-t, és töltsük be a .csv file-t, vagy file-okat (mivel akár többet is tud kezelni egy időben)


Ezután egy kevés időt eltöltve fel lehet fedezni, mit is tud ez az alkalmazás. De azért röviden a legfontosabbak:

A baloldalon a fában le tudunk menni az egyes értékekig, de a legalsó "csomópontra" kattintva egyszerre megjeleníti az alatta lévő értékeket. Pl.


Képes .png formátumban lementeni az aktuális képet, illetve a képet alkotó adatsorokat is kinyerhetjük.

Automatikusan meghatározza az adatpontok sűrűségét (mérések száma alapján), de fixen meg is adhatjuk (View/Set Granurality...)

A teljes mérési intervallumot felszabdalhatjuk kisebb időszakokra, így azokat külön is meg tudjuk nézni. Sőt, ezek az intervallumokat le tudjuk menteni, így később egyszerűen betölthető, nem kell újra létrehozni. Pl.



Akár táblázatos formában is megjeleníthetjük az adatokat.


És persze a diagram megjelenítési módját is szabályozhatjuk.

Összefoglalva, egy telepítést sem igénylő pár megabyte-os alkalmazásról van szó, amivel egyszerűen megjeleníthetjük az esxtop eredményét.





2017. január 12., csütörtök

vmware tools 10.1 és 10.0.12

2015 őszétől kezdve a VMware külön letölthetővé tette a VMware Tools-t. Ezáltal az ESXi verziók és a VMware Tools verziók külön életet kezdtek el élni. Azaz anélkül, hogy ESXi patch jönne ki, ha szükséges, új VMware Tools csomagok jelenhetnek. Ennek persze van előnye , de van hátránya is. Hátrány pl. az, hogy ezentúl hiába tartjuk az ESXi-t a legfrissebb állapotban, egyáltalán nem biztos, hogy a róla elérhető Tools is a legújabb. Sőt, inkább az a biztos, hogy nem.

A másik változás, hogy különválasztotta a mostani operációs rendszerekhez és a régi, már nem támogatott operációs rendszerekhez tartozó Tools verziókat a VMware. Ez elég friss dolog, októberben vált elérhetővé ez a fajta konstrukció. Ennek megint csak lehet értelme, de a számozást egy kicsit átgondolhatták volna. Az lenne a logikus, hogy pl. a 10.0.6-nak a 10.0.12 a frissítése lenne. Pedig nem. Pontosabban régi operációs rendszerek esetében igen, újak esetében nem. A 10.0.12 annak a Tools-nak a verziója, amit a régi operációs rendszerekhez használhatunk. A 10.1 viszont frissíti a 10.0.6-ot újabb rendszerek esetében. . Lehet, hogy csak nekem tűnik zavarosnak? Persze meg lehet magyarázni. A 10.0.x a továbbiakban mindig a régi rendszerekhez lesz használható (bár itt nagy fejlesztésekre nyilván nem kell gondolni), A 10.1.x  pedig az aktuális operációs rendszerekre lesz telepíthető.

A harmadik változás, hogy most már külön Release Notes készül mindkét féle kiadáshoz. Ha máshonnan nem, onnan lehet tudni, hogy mihez mi való. Release Notes 10.0.12 és Release Notes 10.1.0. Az előző bekezdésben emlegetett régebbi és új operációs rendszerek fogalma is értelmet nyer, ha elolvassuk a két dokumentumot.

A fentiek miatt borul a szokásos Tools telepítés is.  Mivel alapállapotban a Tools aktuális verzióját az ESXi-n lévő productLocker linken lévő verzióhoz hasonlítja a rendszer. Természetesen megtehetjük, hogy minden ESXi szerveren a megfelelő helyre felmásoljuk a letöltött és kicsomagolt Tools-t, de ez sok host esetében igen macerás lenne, és minden egyes újabb verzió esetében újra végig kellene csinálni.

E helyett a következő módon járhatunk el.

  • Hozzunk létre egy minden host által látható datastore-on egy mappa struktúrát. (ha követni akarjuk az eddigi felállást, akkor packages/6.0.0
  • Ebbe másoljuk bele a kicsomagolt Tools-t (floppies és vmtools almappák)
  • A vsphere kliensben minden hoston módosítsuk a UserVars.ProductLockerLocation beállítást úgy, hogy az új, közös elérésű helyre mutasson
  • SSH-ne belépve a hostokra a productLocker linket szintén változtassuk meg úgy, hogy az új helyre mutasson. (vagy egy host restart is megteszi)

Persze ha fentieket 100 hoston kell megcsinálni, akkor megint csak nem egyszerű a feladat. Viszont erre találták ki a PowerCLI-t :)

Szokásomhoz híven nem egy szépen kidolgozott scriptet mutatok, hanem csak egyszerűen azt, hogy mit kell tartalmaznia ahhoz, hogy a fenti beállításokat számunka megcsinálja.

$command="c:\powershell\pL.txt" #pL.txt tartalmazza a hoston futattandó parancsokat
$user = "root"
$pw="tikosjelszo"

$host1=get-vmhost host1

$remoteserver=$user+"@"+$host1.Name

get-advancedsetting -Entity $host1 -Name "UserVars.ProductLockerLocation"|set-advancedsetting -Value "/vmfs/volumes/57fe4a2e-21a0072a-c0dc-e41f132e8b64/packages/6.0.0" -Confirm:$false #megváltoztatjuk, hogy az új helyre mutasson

$host1|get-vmhostservice| Where { $_.Key -eq "TSM-SSH"}|start-vmhostservice #engedélyezzük az SSH-t


write-output "yes"|c:\powershell\plink.exe -ssh $remoteserver -pw $pw -m $command #lefuttajuk a pL.txt-ben lévő parancsokat. 

A pL.txt-ben a következő két parancs van:

rm /productLocker
ln -s /vmfs/volumes/57fe4a2e-21a0072a-c0dc-e41f132e8b64/packages/6.0.0 /productLocker

Azaz töröljük a meglévő linket, majd újra létrehozzuk úgy, hogy a megosztott helyre mutasson. Mindezt pedig a plink.exe parancssori alkalmazással használatával érjük el.

Ha a fenti script köré írunk valamilyen ciklust, ami végigmegy a hostokon, akkor már készen is vagyunk.

Ha ezek után megnézzük a virtuális gépeink állapotát, akkor semmilyen változást nem fogunk észrevenni, mivel az ellenőrzés akkor történik meg, amikor bekapcsolunk egy gépet, vMotion-nel elmozgatunk egy gépet, vagy pedig a gépen belül a vmtools szervizt újraindítjuk. Ekkor már az adott gép esetében csak akkor fogjuk azt látni, hogy a legfrissebb tools van rajta, ha valóban az van rajta, ami a közös elérésű datastore-on van. (Ez egyébként a 10.1-es esetében a 10272-őt jelenti)

És persze ezek után már a szokásos módokon mehet a vmwere tools frissítés (kliensből, PowerCLI segítségével, stb)

Remélem segítettem a fentiekkel!