2011. november 21., hétfő

vCloud Director Appliance

Talán a VMware-nél is érezték, hogy egy vCloud Director teszt környezet felállítása nem egy egyszerű feladat. Ezért készítettek egy aplliance-t, amiben előre feltelepítettek mindent (Red Hat, Oracle, vCloud Director). Így az egész leegyszerűsödik egy OVF deploy-ra.
További segítségként készítettek egy Evaluation Guide-ot, ami lépésenként végigvisz a telepítéseken (kezdve a vCenter szerverrel), és a konfiguráción. Bejelentkezés után egy 60 napos licencet kapunk, ami a bejelentkezéstől számítva él (nem a telepítéstől)

Bevallom, nekem egyelőre a vCloud Director eléggé homályos terület, igazából nem is tudtam, hol kezdjek hozzá. Így viszont azt hiszem, a kezdetei lépéseket magam is megteszem.

Mindez megtalálható: https://www.vmware.com/tryvmware/index.php

Ha lesz értékelhető információm a tesztelésről, szintén megosztom.

2011. november 14., hétfő

Linked Clone Pool és a replika vm

Az általam használt View környezetben feltünt, hogy a replika vm-ek száma jelentősen nagyobb,  mint a rendszerben lévő linked clone típusú pool-ok száma. Miközben az elmélet szerint minden pool-hoz egy darab replika tartozik.
A nagy számú replikának valószínűleg az az oka, hogy elég sokszor futott hibára a recompose folyamat, mivel szűkében voltam mindig is a storage területnek. Bár azt nem értem, hogy ha a hibás pool tagokra elindítok egy recompose folyamatot, és az alap virtuális gép, valamint a felhasznált snapshot ugyanaz, akkor miért nem használja a már meglévő replikát?
Mivel ezek a replikák elég sok helyet foglalnak el, ezért szerettem volna tudni, hogy az egyes gépekhez mely replika tartozik. Így ha van olyan replika, amelyik valami hiba folytán maradt a rendszerben, azt bátran törölhetném. Mivel ez a rendszerből könnyen nem olvasható ki, ezért a VMUG közösséghez fordultam segítségért. CZW-től jött a gyors válasz: a descriptor vmdk file-ban megtalálom a szükséges infót. A ParentFileNameHint sor tartalmazta az adott vm-hez tartozó replika vm nevét. Ha pl. a virtuális gép neve V400212, akkor a V400212.vmdk file-ban található az információ.
Most már csak az a kérdés, hogy ha 100 gép esetében kell kinyernem azt az infót, akkor mit tegyek. Mivel a PowerCLI elég közel áll hozzám, és pont erre találták ki, azért azt kezdtem el nézegetni. Hogy egy kicsit felgyorsítsam a dolgokat, a PowerCLI fórumon is feltettem egy kérdést, amire Luc Dekens rövidesen válaszolt is. A továbbiakban az ő útmutatására is támaszkodok.

Legyen a kiválasztott gép a fent is említett V400212:

$vmName = "V400212"

Kérdezzük le, hogy milyen diszkek tartoznak a géphez:

Get-VM -Name $vmName | Get-HardDisk

CapacityKB Persistence Filename
---------- ----------- --------
15728640 Persistent ...FS20_VDI_SYS] V400212MOL/V400212-000001.vmdk
2097152 IndependentPersis... ...isk-D-e61dac41-43c4-499f-8334-40c495ce04c9.vmdk
20480 IndependentPersis... ...0_VDI_SYS] V400212/V4002121-internal.vmdk

A vSphere kilensben leellenőrizve látható, hogy a -00001 végű vmdk a virtuális gép C: meghajtója. Meglepő módon, pont a V400212.VMDK nem szerepel a lekérdezés eredményében. Viszont, ha megnézzük a V400212-000001.vmdk descriptor file tartalmát akkor látható benne a következő bejegyzés:

parentFileNameHint="V400212.vmdk"

Azaz, a virtuális gépet alkotó file-ok között van egy V4000212.VMDK nevű is, ami valószínűleg pont a linked clone technológia miatt szükséges.

Tételezzük fel, hogy a fenti diszkek valamelyikének szeretnénk beleolvasni a descriptor file-jába. Legyen ez az első a fenti három közül. Ha a Get-Datastore paranccsal lekérdezzük, akkor a Name paraméter érték "Hard disk 1" lesz.

$hdName = "Hard disk 1"
$hd = Get-VM -Name $vmName | Get-HardDisk | where {$_.Name -eq $hdName}

A $hd objektum Filename paamétere tartalmazza a vmdk file teljes elérési útját. Ezt egy kis bűvészkedéssel szét tudjuk szedni a Datastore nevére és a file névre.

$ds = Get-Datastore -Name $hd.Filename.Split(']')[0].TrimStart('[')
$vmdkPath = $hd.Filename.Split(']')[1].TrimStart(' ')

Ahhoz, hogy a szokásos Powershell parancsokkal hozzá tudjunk férni a datastore elemihez, hozzunk létre egy új PSDrive objektumot.

New-PSDrive -Location $ds -Name ds -PSProvider VimDatastore -Root '\'

Ettől kezdve, a ds: megadásával tudunk hivatkozni a a virtuális gépet tartalmazó Datastore root mappájára. Ha pedig ez így van, akkor egyszerűen olvassuk el az ott lévő file-ok tartalmát.

$source = ("ds:\" + $vmdkPath).Replace('/','\')
Get-Content -Path $source

Sajnos a várt eredmény helyett a következő üzenetet kapjuk:

Get-Content : Cannot use interface. The IContentCmdletProvider interface is not implemented by this provider.
At line:21 char:12
+ Get-Content <<<< -Path $source
+ CategoryInfo : NotImplemented: (:) [Get-Content], PSNotSupportedException
+ FullyQualifiedErrorId : NotSupported,Microsoft.PowerShell.Commands.GetContentCommand

Azaz, a VimDatastore PSProvider-ben nincs implementálva a Get-Content cmdlet. Akkor most hogyan tovább? Nincs más hátra, mint hogy megpróbáljuk átmásolni a .vmdk file-t a lokális gépre. Legyen ez a temp folder.

$temp = (Get-ChildItem Env:TEMP).Value
$destination = $temp + '\' + $vmdkPath.Split('/')[1]

Ezek után a $source értéke: ds:\V400212\V400212-000001.vmdk
A $destination pedig: D:\DOCUME~1\ZSoltesz\LOCALS~1\Temp\V400212-000001.vmdk
Maga a másolás:

Copy-DatastoreItem -Item $source -Destination $destination

Remélhetőleg, most már meg tudjuk nézni a fuile tartalmát.

Get-Content -Path $destination

És az eredmény:

# Disk DescriptorFile
version=1
CID=df51c9e2
parentCID=86745223
createType="vmfsSparse"
parentFileNameHint="V400212.vmdk"
# Extent description
RW 31457280 VMFSSPARSE "V400212-000001-delta.vmdk"
# The Disk Data Base
#DDB
ddb.longContentID = "2b70c5743a0fbfed935a57b5df51c9e2"
ddb.encoding = "UTF-8"


Hurrá! Győzelem! Illetve mégsem:( Ez, mint az elején írtam, nem annak a diszknek a leíró file-ja, amelyet szeretnénk, de ebben találunk rá hivatkozást, nevezetesen a parentFileNameHint="V400212.vmdk sorban.

Ezek után viszont már nagyon gyorsan eljuthatunk a kívánt információig. A fenti módszerrel másoljuk át a temp mappába a V400212.vmdk-t, majd nézzük meg annak a tartalmát.

Az eredmény:

# Disk DescriptorFile
version=1
CID=86745223
parentCID=3260994c
createType="vmfsSparse"
parentFileNameHint="/vmfs/volumes/4b9776cc-9ad21a92-391f-00215e4cb38d/replica-2d2fdc7f-5e15-4b9d-89be-/replica-2d2fdc7f-5e15-4b9d-89be-.vmdk"
# Extent description
RW 31457280 VMFSSPARSE "V400212-delta.vmdk"

# The Disk Data Base
#DDB

ddb.encoding = "UTF-8"
ddb.longContentID = "2b6a3f59ef1ff403a0c2983786745223"

Innen pedig egy kis bűvészkedés a file tartalmával, nevezetesen:

$replica=Get-Content -Path $destination|?{$_ -like 'Parentfile*'}
$replica.split('/')[5].trim('"')

És meg is kaptuk a replika nevét: replica-2d2fdc7f-5e15-4b9d-89be-.vmdk

Ezek után már csak azt a kódot kell megírni, amelyikkel sorra tudjuk venni az érintett virtuális gépeket, és megtudjuk mi az igazság.

Nem tudom, hogy a fenitől létezik-e sokkal egyszerűbb megoldás, de ez működik. Köszönet még egyszer CZW-nek, valamint Luc Dekens-nek.