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...

Egy kis PowerCLI - VMware infrastruktúra KPI adatok lekérdezése

Lehet hogy túlzás KPI-nek nevezni, mi mindenesetre így hívjuk. A lényeg úgyis a tartalom. Arról van szó, hogy minden hónap elején kérnek tőlem bizonyos számszerűsíthető információt a VMware infrastruktúráról.

Mivel a mondás szerint ha már valamit kétszer meg kell csinálni, akkor arra írjunk scriptet, ezért én is így tettem.

Nem nagy dolgokról van szó, de ha valaki még esetleg most ismerkedik a PowerCLI használatával, akár még hasznos dolgot is találhat benne.

Az itt található kód egy kicsit egyszerűsített változata annak amit használok, mivel nálunk több datacenter van, és az adatokat megosztva kérik. A lenti viszont egyben kezeli a vCenteren lévő összes hostot, virtuális gépet valamint datastore-t. De a Location paraméter megadásával könnyen lehet szűkíteni a lekérdezéseket egy bizonyos csoportra.

Ha csak a Datacenter1-ben lévő dolgokkal akarunk foglalkozni, akkor egyszerűen ki kell bővíteni a parancsokat. Pl. 

$Host_ALL=Get-VMHost -Location DataCenter1|?{$_.ConnectionState -ne "Maintenance"}

Megjegyzések a scriptben, bár a nagy része nem szorul magyarázatra.

#Induló értékek meghatározása (dátum, hostok,virtuális gépek, datastore-ok)

#ha szükésges, akkor különböző szűréseket beállíthatunk, pl. csak bekapcsolt gépek,

#csak olyan datastore-ok, amikben nem szerepel az "internal" szó, stb

$Date=Get-Date

$Host_ALL=Get-VMHost |?{$_.ConnectionState -ne "Maintenance"}

$VM_ALL=get-vm |?{$_.Powerstate -eq "PoweredOn"}

$DS_ALL=get-datastore  |?{$_.Name -notlike "*internal*"}

#Host mennyiségi értékek számítása (összes mamória, CPU-k száma, és a hostok száma)

$Host_Mem_osszes_ALL=($Host_ALL|Measure-Object -Property MemoryTotalGB -sum).Sum

$Host_CPU_osszes_ALL=($Host_ALL|Measure-Object -Property NumCPU -sum).Sum

$Host_darab_ALL=($Host_ALL|measure-object).Count

#Datastore szabad és full kapacitások számítása

$DS_Free_Space_ALL=($DS_ALL|Measure-Object -Property FreespaceGB -sum).Sum

$DS_Full_Space_ALL=($DS_ALL|Measure-Object -Property CapacityGB -sum).Sum

#VM mennyiségi adatok (összes vCPU,számosság, abból mennyi a Windows és nem Windows gép)

$VM_CPU_ALL=($VM_ALL|Measure-Object -Property NumCPU -sum).sum

$VM_COUNT_ALL=($VM_ALL|Measure-Object).Count

$VM_COUNT_Windows_ALL=($VM_ALL|?{$_.GuestId -like "*win*"}|Measure-Object).Count

$VM_COUNT_NonWindows_ALL=($VM_ALL|?{$_.GuestId -notlike "*win*"}|Measure-Object).Count

#Provisioned Datastore számítás. Egy kicsit trükkös, mert ezt már csak az extensiondata #felhasználásával lehet lekérdezni, mivel a Get-DataStore ezt az értéket direktben nem
#tartalmazza

$ProvisionedSpace_ALL=(Get-Datastore | ?{$_.Name -notlike "*internal*"}|

Select-Object -Property Name,

CapacityGB,FreeSpaceGB,

@{ Name = "ProvisionedSpaceGB"

   Expression = {($_.ExtensionData.Summary.Capacity - $_.Extensiondata.Summary.FreeSpace + $_.ExtensionData.Summary.Uncommitted)/1GB}

 }|Measure-Object -Property ProvisionedSpaceGB -sum).sum

#Host memória és CPU szabad kapacitások számítása

#Nem bonyolítottam túl, egyszerűen az elmúlt egy hét értékeit lekértem, és abból az összes #hostra számoltam egy átlagot. Így utólag megnézve, lehetne egyszerűsíteni a következő pár
#sort (nem kéne számolgatni a hostokat, mivel tudom mennyi van...), de ez már így marad :)

$Host_ALL_CPU_Percent=0

$Host_ALL_MEM_Percent=0

$Host_Count=0

foreach ($h in $Host_ALL) {

  $HostCpuUsage = (get-stat -entity $h.Name -stat cpu.usagemhz.average -Start ($Date).adddays(-7) -Finish ($Date)|Measure-Object -Property Value -Average).Average

  $HostMemUsage = (get-stat -entity $h.Name -stat mem.consumed.average -Start ($Date).adddays(-7) -Finish ($Date)|Measure-Object -Property Value -Average).Average

  $HostallCPU=$h.CpuTotalMhz

  $HostallMem=$h.MemoryTotalMB

  $Host_ALL_CPU_Percent=$Host_ALL_CPU_Percent+(($HostCPUUsage/$HostallCPU)*100)

  $Host_ALL_MEM_Percent=$Host_ALL_MEM_Percent+((($HostMemUsage/1024)/$HostallMem)*100)

  $Host_Count=$Host_Count+1

  }

$Host_ALL_CPU_Percent=$Host_ALL_CPU_Percent/$Host_Count

$Host_ALL_MEM_Percent=$Host_ALL_MEM_Percent/$Host_Count

#Már csak az értékek kiíratása van hátra

Write-Host "összes CPU core" $Host_CPU_osszes_ALL

Write-Host "fizikia memória mérete" $Host_Mem_osszes_ALL

Write-Host "hostok szám" $Host_darab_ALL

Write-Host "provisioned tárhely" $ProvisionedSpace_ALL

Write-Host "szabad CPU kapacitás: " (100-$Host_ALL_CPU_Percent)

Write-Host "szabad datastore kapacitás" $DS_Free_Space_ALL

Write-Host "szabad Memória kapacitás: " (100-$Host_ALL_MEM_Percent)

Write-Host "teljes datastore kapacitás" $DS_Full_Space_ALL

Write-Host "vCPU szám" $VM_CPU_ALL

Write-Host "vCPU/core" ($VM_CPU_ALL/$Host_CPU_osszes_ALL)

Write-Host "vCPU/VM" ($VM_CPU_ALL/$VM_COUNT_ALL)

Write-Host "virtuális gépek száma" $VM_COUNT_ALL

Write-Host "Virtuális gépek száma (nem Windows)" $VM_COUNT_NonWindows_ALL

Write-Host "Virtuális gépek száma (Windows)" $VM_COUNT_Windows_ALL

A lista sok minden mással kiegészíthető, de pillanatnyilag nekem ennyi információra van szükségem.

Host és VM performancia értékek, statisztikák gyűjtése - Direkt SQL lekérdezések (2.rész)

Miután az adatainkat már egy ideje gyűjtögetjük, jó lenne abból olyan riportokat generálni, ami mindenki számára elérhetővé tehető. Ennek nagyon sok módja van, attól függően hogy milyen alkalmazás áll rendelkezésünkre.

Röviden azt szeretném veletek megosztani, hogy Microsoft SQL 2005 Reporting Service használatával én ezt hogy oldottam meg.
Emlékeztetőül, van három táblám, amiben különböző idő intervallumokból származó értékek vannak, van egy tábla ami tartalmazza, hogy milyen statisztikákat gyűjtök, illetve a hostokról és clusterekről vannak információim.

Mivel a táblák csak kódokat tartalmaznak, készítettem három view-t (nézetet), amiben már úgy szerepelnek az adatok, hogy a riportokban könnyen meg tudjam jeleníteni azokat.

Pl. a 30 perces adatok esetében így néz ki:


CREATE VIEW [dbo].[VIEW_STAT_30MIN]
AS
SELECT dbo.CLUSTER.NAME AS Cluster, dbo.HOST.NAME AS Host, dbo.STAT_30MIN.SAMPLE_TIME,
dbo.STAT_30MIN.STAT_VALUE, dbo.STAT_DEF.STAT_NAME,
dbo.STAT_DEF.STAT_UNIT
FROM dbo.CLUSTER ,dbo.HOST, dbo.STAT_30MIN,dbo.STAT_DEF
WHERE dbo.STAT_30MIN.HOST_ID=dbo.HOST.ID and
dbo.HOST.CLUSTER_ID=dbo.CLUSTER.ID and
dbo.STAT_30MIN.STAT_ID=dbo.STAT_DEF.STAT_ID

Ezután már át lehet térni a riport gyártásra. Ehhez az SQL Server Bussines Intelligence Development Studio-t használtam. Indulásként létrehoztam egy új Report Server projektet.

Első lépésként egy Shared Data Source objektumot hoztam létre, ami tartalmazza az adatbázis szerver elérhetőségét, az adatbázisom nevét, és egy olyan accountot, amivel olvasási jogom van az adatbázishoz.

Amikor egy új riport tervezésébe kezdek, meg kell határozni, hogy milyen lekérdezések fogják majd szolgáltatni az adatokat akár a riportban megjelenő adatok számára, akár a riport paramétereinek meghatározásához. Ezeket a lekérdezéseket hívja a riport szerver dataseteknek.
Példként az 5 perces adatok lekérdezését megvalósító riportról írok.

A riport adatait a következő dataset határozza meg:

select * from view_stat_5min where host in (@HOST)
and sample_time>=dateadd("hh",CAST(@START_HOUR as integer),@START)
and sample_time<=dateadd("hh",CAST(@END_HOUR as integer),@END) and stat_name=@STAT order by host,sample_time


A riport paramétereihez pedig a következő kettőt használom:

select HOST.name as H_name from HOST,CLUSTER where HOST.cluster_id=CLUSTER.id
order by CLUSTER.name,HOST.name

select stat_name from stat_def

Az első datasetben a @név olyan változókat definiál, amiknek majd már a konkrét futtatáskor a felhasználó értéket tud adni, így azzal tudja testre szabni a riportot. Látható, hogy vannak @HOST,@START_HOUR,@START,@END_HOUR,@END,@STAT változóim, azaz futtatáskor meg tudjuk majd adni, hogy melyik hostokra, mikortól, meddig és milyen statisztikát szeretnénk megjeleníteni.

Ezeknek a változóknak tudunk kezdeti értéket adni, illetve megadhatjuk azt is, hogy melyik dataset legyen a forrása. Ebben a példában a @HOST változónak az első, míg a @STAT változónak a második dataset szolgáltatja az értékeket.
A kezdeti érték megadásával elérhetjük, hogy a riport indításakor a vélhetően leggyakrabban használatos értékek legyenek előre beállítva. A lenti képen látható, hogy ebben a konkrét esetben az előző nap 8 és 18 óra közti időszak, valamint a cpu.usage statisztika van beállítva.

A fél órás riportok esetén az előző teljes nap (0-24 óra), míg a két órás riportok esetében az előző teljes hét a default intervallum.
A vonal diagram az a típus, ami ebben az esetben a leginkább használható. A lenti képen látható egy konkrét riport, ami három host processzor kihasználtságát mutatja a fenti default idő intervallumban.

A következő képen azt lehet látni, hogy az egyik clusterben lévő hostok memória használatát éppen kiegyenlítette a DRS. Azt hiszem, ilyen ábrát nem is lehet kinyerni a vSphere kliensen keresztül. De javítsatok ki, ha tévednék.

Nagyon jól össze lehet fogni szinte az összes riportot úgy, hogy készítünk egy hagyományos táblázatos lekérdezést a clusterekről és a benne lévő hostokról úgy, hogy tartalmazzon processzor, memória, diszk és hálózati információkat, majd azokat link-ként használva direktben tudunk az egyes riportokra ugrálni.

Mint az elején említettem, eredetileg csak a hostokról készült ilyen módon adat gyűjtés, de azóta már a datastore-ok néhány paraméterét is letárolom, és alkalmas riportokon keresztül lehetőséget biztosítok, hogy akit érint információkat kapjon a VMware környezet ilyen tulajdonságairól is. A lenti példán jól látható, hogy volt storage bővítés, illetve hogyan viszonyul a provisioned kapacitás a ténylegesen használt kapacitáshoz képest egy adott Datacenterben.

Természetesen még mindenféle jópofa diagramot el lehet készíteni, ha van rá igény. Főleg úgy, hogy a kezdeti nagyobb energia és idő ráfordítás után a bővítés már sokkal egyszerűbb.

Végére még egy érdekesség. Természetesen Excelből is el lehet éni az adatokat, ott pedig a Pivot Chart funkciót használva nagyon tetszetős ábrákat lehet gyártani, mint ahogy a lenti ábra is bizonyítja.

Remélem van olyan köztetek, akinek hasznos volt ez a két bejegyzés. Ha mégsem, akkor legalább magamnak lejegyeztem, hogy hogyan is működik ez az egész:)

Host és VM performancia értékek, statisztikák gyűjtése - Direkt SQL lekérdezések (1.rész)

Egy régebbi postban írtam arról, hogy milyen lehetőségeink vannak (természetesen vannak más módszerek is), ha szeretnénk hosszabb távon performancia adatokat tárolni illetve megjeleníteni úgy, hogy ez ne függjön a vCenter szerveren beállított megőrzési időktől, illetve csak az adatok egy számunkra fontos részhalmazát tartalmazzák.

Most a direkt SQL lekérdezésekről szeretnék írni. Esetemben a vCenter szerver adatbázisa egy SQL 2005-ös adatbázis szerveren fut (a neve legyen VPX). Mivel az volt a célom, hogy a lekérdezéseket majd SQL Reporting Service segítségével oldjam meg, így természetesen a kigyűjtött adatok is egy SQL adatbázisba kerülnek (a neve legyen VMware_stat). Ebben a bejegyzésben csak az adatok gyűjtéséről lesz szó, később valamikor a lekérdezésekről is írok. (talán)

A feladat behatárolása

Nem akartam egyszerre mindenre kiterjedő lekérdezéseket létrehozni, ezért a következő feltételeket szabtam magamnak.

• Csak a hostok adataira vagyok kíváncsi
• Nem bántom a vCenter beállításai között a Statistics Level értékét (marad 1)
• Külön gyűjtöm az 5 perces, félórás és 2 órás értékeket
• Az öt perces adatokat 40 napig gyűjtöm, a többinél egyelőre nem szabtam korlátot
• Mivel a Statistics Level 1 maradt, így eléggé beszűkültek a lehetőségek, így én négy különböző értéket választottam: cpu.usage(%), mem.usage(%),disk.usage(kiloBytesPerSec),net.usage(kiloBytesPerSec)
• A mért értékek köre viszonylag könnyen módosítható legyen
• Az adatbázis hasonlítson egy normálisan felépített relációs adatbázisra

A VPX adatbázis feltérképezése

Mivel nagyjából tudtam mit akarok, ezért elkezdtem böngészni a vCenter adatbázisát, hogy melyik táblát vagy nézetet tudnám legkönnyebben felhasználni. Ehhez előbb kitaláltam, hogy az én kis adatbázisom kb. hogy fog kinézni. Így:

A lekérdezéseknél szeretném, ha különálló hostokat is lehetne választani, de akár cluster-enként is indíthatóak legyenek. Ehhez a host táblámban szerepeltetni kell a cluster azonosítót is. Mivel a host-cluster összerendelés kiolvasható a vpx.dbo.vpx_entity táblából, valamint mindent megtudhatunk a hostokról a vpx.dbo.vpx_host táblából, így a kettőt felhasználva könnyen írhatunk egy query-t, ami pont azt az információt adja meg, amivel a host táblámat fel akarom tölteni.

INSERT INTO dbo.host

SELECT h.id,dns_name,

(SELECT id FROM vpx.dbo.vpx_entity p WHERE e.parent_id=p.id) p,

ip_address,product_version,product_build,host_model,cpu_model,

cpu_count,cpu_core_count,cpu_thread_count,

cast(round((cast(cpu_hz as numeric)/1000000000),1) as numeric(3,1)),

ceiling(round(cast(mem_size as numeric(13,0))/(1024*1024*1024),0)),boot_time

FROM vpx.dbo.vpx_host h,vpx.dbo.vpx_entity e WHERE h.id=e.id

Mint láthatjátok, egy al-lekérdezéssel olvastam ki a cluster azonosítóját (parent_id), illetve a memória méretének és a processzor sebességének a mértékegységét egy kicsit átalakítottam. Természetesen a cluster táblámat is feltöltöttem a megfelelő értékekkel.


insert into dbo.cluster

select id,name from vpx.dbo.vpx_entity where type_id=3

Következő lépésben azokat a statisztikákat kellett kigyűjtenem, amelyeket használni szeretnék. Ezt egyszerűen lekérdeztem a megfelelő táblákból, nézetekből, megnéztem, milyen azonosító érdekel engem, és annak megfelelő feltöltöttem a stat_def táblámat.


insert into dbo.stat_def
select id,cast(group_name+'.'+name as nvarchar(50)),cast(unit as nvarchar(15))

from vpx.dbo.vpx_stat_def

where id in (2,98,16,110)

Az elején említett négy statisztikának az azonosítója 2, 98, 16 és 110, ezért szerepelnek ezek az értékek a where feltételben.

Ezzel tulajdonképpen készen van az a három tábla, ami az alap adatokat tárolja. Ezután jön az érdekesebb rész. Mint mondtam, én az öt perces, félórás és két órás értékeket szeretném tárolni. Ezeknek létrehoztam három táblát, teljesen azonos szerkezettel. Ezek neve rendre dbo.stat_5min, dbo.stat_30min és dbo.stat_120min.

Már csak azt kellett kitalálnom, hogy honnan tudnám legegyszerűbben kinyerni az értékeket. Nyílván a táblák közt is meg lehetne találni, de biztos voltam benne, hogy ők is inkább nézeteket használnak, amikor pl. a vSphere kliensben valamilyen performance diagramot megnézünk.
Sikerült is ezekre rálelni. Ezek a nézetek a következők: vpx.dbo.vpxv.hist_stat_daily, vpx.dbo.vpxv.hist_stat_weekly, vpx.dbo.vpxv.hist_stat_monthly. Létezik egy negyedik is, amiben napi összesített értékeket tárol (azaz egy nap, egy érték), de én azt nem akartam használni.

Három olyan tárolt eljárást kellett megírnom, ami a megfelelő nézetből feltölti az én tábláimat. Elsőre egyszerűnek tűnik a dolog, de azért van benne néhány dolog, amire figyelemmel kell lenni.

• A vCenter UTC idő szerint tárolja le az adatokat, így ezt bele kell kalkulálni. Ezt megtehetnénk a riportok írásánál is, de egyszerűbb már ezt figyelembe véve áttölteni az adatokat.
• Figyelembe kell venni azt is, hogy a vCenter mikorra időzíti a saját SQL job-jait, hogy ne ütközzünk.
• A következő fontos dolog, hogy ugye ezt az egészet azért csinálom, mert a vCenter csak egy bizonyos ideig őriz meg értékeket, így nekem még azelőtt át kell vennem, mielőtt azokat automatikusan törli.
• A negyedik pedig az, hogy meg kell határoznom, hogy egyszerre mekkora idő intervallum értékeit vegyem át. Minél gyakrabban töltöm át az értékeket, annál hamarabb rendelkezésre áll a riportok számára.

Az intervallumok esetében én úgy döntöttem, hogy az öt perces adatokat kétóránként, a félórás adatokat naponta, a két órásakat pedig hetente frissítem. Úgy tűnik, ez viszonylag jó választás volt a visszajelzések szerint.

Nézzük, hogy néz ki egy tárolt eljárás. A három közül azt láthatjátok, ami a félórás adatokat tölti át, és naponta egyszer fut. Azaz egy napnyi értéket másol be egyszerre az én táblámba. Az egyszerűség kedvéért a teljes eljárást bemásolom.


CREATE PROCEDURE [dbo].[felora]
AS

BEGIN

DECLARE @STARTD datetime

DECLARE @ENDD datetime

DECLARE @TIMESHIFT int

SET @TIMESHIFT=datediff(hh, getdate(), getutcdate())

SET @STARTD=DATEADD(d, -1, DATEDIFF(d, 0, GETDATE()))

SET @ENDD=DATEADD(d, 0, DATEDIFF(d, 0, GETDATE()))

SET @STARTD=dateadd(hour,@TIMESHIFT,@STARTD)

SET @ENDD=dateadd(hour,@TIMESHIFT,@ENDD)

SET NOCOUNT ON;

insert into stat_30min

select right(sw.entity,len(sw.entity)-5),stat_id,dateadd(hour,(-1*@TIMESHIFT),sample_time),

CASE

WHEN stat_id=2 or stat_id=16 THEN stat_value/100.0

ELSE stat_value

END

from [VPX].[dbo].[VPXV_HIST_STAT_WEEKLY] sw

where

entity like '%host%' and sw.stat_id in(2,98,16,110)

and sample_time >=@STARTD

and sample_time <@ENDD

END

Néhány megjegyzés a fenti eljáráshoz:

• A @TIMESHIFT tartalmazza az UTC időhöz képest mennyi az eltolódás (nyílván más a nyári és más a téli időszámításban)
• Az előző teljes napot fedik le a @STARD és @ENDD változók
• A %-os statisztikáknál (2 és 16) százszoros értékek vannak, így azt osztom százzal
• A vCenter szerver a hostok azonosítóit 'host-hostid' formában tárolja (pl. host-382), de nekem ebből csak a hostid a fontos, ezért van a lekérdezésben string manipuláció.

A fenti eljárást (és a másik kettőt) megfelelő módon beidőzítve futtatom, így már jelenleg kb. 40-50 napnyi információm van, aminek jó része már a vCenter adatbázisában nincs is meg. (De az öt perces adatok közül én is törlöm a 40 napnál régebbieket, hogy az adatbázisom mérete ne szaladjon el, illetve 40 napnál régebbi adatok esetében valószínűleg elegendő a fél vagy két órás adat is.

Röviden ennyi. Természetesen ez további statisztikákkal bővíthető, illetve a hostok mellett más dolgok (virtuális gépek, datastore-ok,stb) különböző statisztikáit is gyűjtögethetjük. A datastore-okkal kapcsolatban már elkészítettem egy hasonló rendszert, mint amit itt olvashattok, de az a fentiek alapján már mindenki számára könnyen elképzelhető.

Szívesen meghallgatnám a véleményeteket a fentiekről.

vCenter Multi-Hypervisor Manager

Csak idő kérdése volt, hogy a VMware mikor jelenik meg valamilyen vCenter kiegészítéssel, amellyel lehetővé válik más virtualizációs környezetek menedzselése is. Ha jól tudom, a System Center már lehetővé teszi, hogy vCenter megléte mellett bizonyos feladatokat elvégezzünk a a VMware környezetünkben is. Úgy tűnik, egyre több cég használ egynél több virtualizációs megoldást. A lenti ábra egy mostani amerikai felmérésből való, amiből az előző állítás is következik.

 

Ha valakit érdekel a felmérés teljes eredménye, akkor innen letöltheti.

 

Egy nagyon új termékről van szó, ami kb. 10 napja jelent meg. Minden információ, ami ezzel kapcsolatban elérhető, itt található: http://www.vmware.com/support/pubs/vcenter-multihypervisor-manager-pubs.html

Enyhén szólva elég korlátozott tudású a kiegészítő. Bár az én véleményem szerint nem is kellene ebbe túl sok energiát fektetni, de biztosan nincs igazam.

 

Nézzük egy kicsit közelebbről meg a terméket. Két külön telepítendő komponense van. Ezt nem részletezem, nem nagy dolog. A dokumentációból kimásolt ábrán látszik a lényeg.

 

 

 

Egy kicsit ellentmond annak a törekvésnek, hogy az új dolgokat már csak a Web kliensen keresztül lehet használni, mert ez egy hagyományos plug-in a régi kliensben. Ha feltelepítettük a vCenter szerverre, majd a kliensben is telepítettük a plug-int, akkor nézzük, mi is változik.

 

 

Az Inventory részre új lakó költözött, a vCenter Multi Hypervisor Manager. Ha elindítjuk, akkor a vCenter nevére kattintva felvehetjük az inventory-ba az első nem ESX szerverünket. Meg kell adni a Hyper-V szerver nevét vagy IP címét, és egy olyan accountot, amivel csatlakozni tudunk a hosthoz. Ez a verzió csak Windows 2008 és 2008 R2-n futó Hyper-V szervereket képes kezelni. Ha sikeresek voltunk, akkor a valami ilyesmit kapunk.

 

 

Látható, hogy kinézetben igyekeztek mindenben követni azt amit megszoktunk, de azért a "fülek" és lehetőségek száma lényegesen kevesebb.

Nézzünk egy listát a lehetőségeinkről:

• Hostokat tudunk felvenni, törölni, valamint meg tudjuk nézni a konfigurációjukat
• Virtuális gépeket tudunk létrehozni a Hyper-V hostokon
• Meglévő virtuális gépek tulajdonságait tudjuk szerkeszteni
• Tudunk CD-t,DVD-t, floppy-t csatolni a virtuális géphez, így pl. az op. rendszer telepítését is el tudjuk végezni.
• A szokásos "power" műveleteket el tudjuk végezni hostok és virtuális gépek esetén

Nézzünk meg néhány képet. A következő egy host Summary ablak.

 

 

Ez pedig egy virtuális gép tulajdonságainak módosításaira szolgáló ablak.

 

 

 

Végül pedig nézzük, hogy kell új diszket adni egy meglévő géphez.

 

 

Kíváncsi lennék a véleményetekre, hogy szerintetek szükséges-e ilyen irányba fejleszteni a vCenter környezetet, vagy pedig mindenhez használjuk az ahhoz leginkább megfelelő alkalmazást. Jelenleg elég kevés tudást pakoltak az MHM plug-inbe, de a kényszer miatt gondolom gyors fejlődés előtt áll.