vmware felhasználói közösség » virtualcenter

VM jogosultság automatikusan

attila.sarandi — Mon, 22 Mar 2010 09:48:44 +0000

Néhány bejegyzéssel korábban igértem, hogy bemutatom egy cikkben, miként lehet a vCenter Server adatbázisán keresztül automatikusan VI hozzáférést adni Kollégáknak az általuk felügyelt virtuális szerverekhez.

Feladat a következő: egy adatbázisban már egyébként is nyilván tartom szervereimet, azok funkciójával, illetve gazdájával. Az a cél, hogy az itt tárolt szervergazda automatikusan kapjon a VMware infrastruktúrában jogot a szerveréhez, amivel a VMware adminisztrátor munkáját is csökkentettük, illetve a VI klienssel bejelentkező szervergazda menedzselni tudja virtuális szervereit is.

Először is nézzük milyen formában tárolom a szervereket és gazdáikat:

select Host, Szervergazda, SAMAccName
from ServerInfo.dbo.ServerAdmins
where Szervergazda = ‘Sárándi Attila’

Keressük ki a VPX_ROLE táblából a “VirtualMachineAdministrator” jogosultsághoz tartozó ID-t, ez fog kelleni a későbbiekben:

select ID, NAME from dbo.VPX_ROLE

where NAME = ‘VirtualMachineAdministrator’

Megnézhetjük jelenleg melyik szerverhez, melyik Kollégának van meg a keresett joga:

select dbo.VPX_ENTITY.NAME, dbo.VPX_ACCESS.PRINCIPAL
from dbo.VPX_ENTITY
left outer join dbo.VPX_ACCESS
on dbo.VPX_ENTITY.ID = dbo.VPX_ACCESS.ENTITY_ID
where dbo.VPX_ACCESS.ROLE_ID = 1 — role_id
and dbo.VPX_ENTITY.”TYPE_ID” = 0 –virt.gépek típusa

A következő lépésben már összekapcsoljuk a ServerAdmins táblát a vCenter megfelelő tábláival, hogy ellenőrízhessük a megfelelő embernek megvan-e a joga:

select A.Host, A.Szervergazda_Login,

VPX.dbo.VPX_ACCESS.PRINCIPAL as Admin_in_VMware

from (select VPX.dbo.VPX_ENTITY.ID, VPX.dbo.VPX_ENTITY.NAME as Host,

‘MOL\’ + ServerInfo.dbo.ServerAdmins.SAMAccName as Szervergazda_Login

from VPX.dbo.VPX_ENTITY, ServerInfo.dbo.ServerAdmins

where VPX.dbo.VPX_ENTITY.NAME = ServerInfo.dbo.ServerAdmins.Host

and VPX.dbo.VPX_ENTITY.”TYPE_ID” = 0) A left outer join VPX.dbo.VPX_ACCESS

on (A.ID = VPX.dbo.VPX_ACCESS.ENTITY_ID) and (A.Szervergazda_Login = VPX.dbo.VPX_ACCESS.PRINCIPAL)

Sok a NULL a jobb szélső oszlopban, azaz sok szervergazdának nincs meg a szükséges VMware-es joga, ami ellen tennünk kell. Jogosultságot nemes egyszerűséggel úgy tudunk adni, hogy a VPX_ACCESS táblába be kell szúrni egy sort. Az alábbi értékekkel:

ENTITY_ID: a vCenter központi táblájának (VPX_ENTITY) ID mezője, az adott virt.gép sorában
ROLE_ID: VPX_ROLE táblából az adni kívánt jog ID-ja, esetünkben 1
PRINCIPAL: a jogosultság kedvezményezettjének login-ja
FLAG: ha a PRINCIPAL felhasználói account, akkor 1, ha csoport account, akkor 3

insert into VPX.dbo.VPX_ACCESS (ID, PRINCIPAL, ROLE_ID, ENTITY_ID, FLAG)
select C.NEXT_ID,
‘MOL\’ + B.SAMAccName,
1,
A.ID,
1
from VPX.dbo.VPX_ENTITY A, ServerInfo.dbo.ServerAdmins B,
(select max(ID)+1 as NEXT_ID from VPX.dbo.VPX_ACCESS) C
where A.NAME = B.Host
and A.”TYPE_ID” = 0

Már készen is lennénk, de tekintettel kell lennünk arra, hogy ha másodjára akarjuk a fenti SQL-t futtatni hibaüzenetet fogunk kapni vagy dupla bejegyzést hozunk létre, mert már meglévő rekordok lesznek a VPX_ACCESS táblában – ezért gondoskodni kell a meglévő rekordok törléséről. Ha adatbáziskezelőnk támogatja az “INSERT or UPDATE” SQL szintaxist, akkor nem kell a törléssel foglalkoznunk, nekem sajnos kell, mert az itt alkalmazott MS SQL – ha jól tudom – nem támogatja ezt:(

delete from VPX.dbo.VPX_ACCESS
where ROLE_ID = 1
and FLAG = 1
and convert(varchar, ENTITY_ID) + ‘—’ + PRINCIPAL in
(select convert(varchar, A.ID) + ‘—’ + VPX.dbo.VPX_ACCESS.PRINCIPAL
from
(select VPX.dbo.VPX_ENTITY.ID,
VPX.dbo.VPX_ENTITY.NAME,
‘MOL\’ + ServerInfo.dbo.ServerAdmins.SAMAccName as ServerInfo_SAMAccName
from VPX.dbo.VPX_ENTITY, ServerInfo.dbo.ServerAdmins
where VPX.dbo.VPX_ENTITY.NAME = ServerInfo.dbo.ServerAdmins.Host
and VPX.dbo.VPX_ENTITY.”TYPE_ID” = 0) A
left outer join VPX.dbo.VPX_ACCESS
on A.ID = VPX.dbo.VPX_ACCESS.ENTITY_ID
where A.ServerInfo_SAMAccName = VPX.dbo.VPX_ACCESS.PRINCIPAL

Nincs más dolgunk, mint beütemezni a két utolsó DELETE és INSERT SQL parancsot (fontos a sorrend;) ), az adatforrás ServerInfo tábla töltési idejét és gyakoriságát figyelmbe véve. Fontos, hogy a vCenter adatbázis külső módosítása csak akkor jut érvényre, ha újraindítjuk a vCenter Server szolgáltatást! Ha a fenti SQL-ekben hangolható részt találtok, kérem a comment-be adjátok közre.

…és persze csak a vCenter adatbázis mentése után adjuk ki az INSERT/DELETE parancsokat!!!

Remélem hasznosnak találtátok a cikket, a következőben azt használjuk fel, hogy a ServerAdmins tábla a szerverről egyéb információt is tárol (pl. a rajta futó alkalmazás nevét), amit a fentiekhez hasonló egyszerűséggel lehet betölteni a vCenter adatbázisába pl. custom tag-ként.

vCenter Server adatbázis beállítások

attila.sarandi — Tue, 23 Feb 2010 13:45:00 +0000

Apró, de talán annál hasznosabb tapasztalatot szeretnék megosztani Veletek. Leggyakrabban talán MS SQL adatbázist tolunk a vCenter Server és az UpdateManager alá. Az adatbázishoz két módon csatlakozhatunk:
A) Windows authentikáció
B) SQL Server authentikáció

A) esetben pl. ActiveDirectory szerviz account-ot hozunk létre, célszerűen nem lejáró jelszóval. Ehhez az account-hoz adunk az adott adatbázishoz jogot az SQL szerverben.

B) esetben az SQL Server-ben hozunk létre egy account-ot, amihez megadjuk a szükséges adatbázis jogokat.

A) vCenter Server-en az ODBC kapcsolat létrehozásnál Windows authentikációt állítunk be, majd a vCenter Server telepítésekor az ODBC kapcsolat kiválasztása után beadjuk a létrehozott AD-s account-ot. Ez esetben a vCenter Server szolgáltatás az adott AD account nevében fog futni, így ennek az account-nak a megfelelően magas jogosultsággal kell rendelkeznie a helyi gépen.

B) A vCenter Server-en az ODBC kapcsolat létrehozásánál SQL Server authentikációt állítunk be, sőt a felhasználónevet és jelszót már az ODBC kapcsolatban rögzítjük. Így a vCenter Server telepítésekor csak ki kell választani az ODBC kapcsolatot, majd a szolgáltatások helyi system account nevében futnak, így helyi jogosultság problémákba nem futhatunk bele.

Itt az idő, válasszatok!

Vigyázzatok – vCenter 4.0 Update 1

attila.sarandi — Tue, 15 Dec 2009 10:50:06 +0000

vCenter 4.0 Update1 Alert (Affecting ESXi 4.0/4.0U1): After upgrading vCenter Server 4.0 to 4.0U1, the following error message might result while reconnecting ESXi hosts to vCenter Server, “Cannot install the vCenter agent service. Unknown Installer error”. If you have ESXi hosts connected to vCenter Server 4.0, do not upgrade vCenter Server to Update 1 at this time. For more details, read KB article 1016262.

Virtual Center upgrade után nem működik a customization

admin — Sun, 30 Nov 2008 11:44:00 +0000

VC 2.5 U2 vagy U3-ra való upgrade-je után nem működik a template deploy utáni customization, aminek az az oka, hogy a template-ben régi VMware Tools van, ami nem működök együtt a VC ezen verzióival.

Megoldás:

- Template konverzió VM-é, Tools upgrade, majd vissza template formátumba. Ennek az a hátránya, hogy munkás és ha korábbi ESX verziód van (pl. 3.0.x), akkor azokra nem működik a customization.

- VC2.5U3-ban javították ezt a hibát, így U3-ra menjünk, majd csináljunk egy új customization-t, akár egy meglévő lemásolásával. Ez után megy az összes (a korábban létrehozottak is) customization. EZ A TUTTI!

Részletesebben itt

VirtualCenter DB migráció

admin — Mon, 30 Jun 2008 12:35:00 +0000

Akik esetleg most állnak VC sql 2000>2005 migráció előtt, azok bizonyára hasznosnak fogják találni a következő guide-ot:

VC DB upgrade