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

VMware katasztrófatűrő megoldások élesben a Japánoknál

attila.macskasy — Thu, 07 Apr 2011 04:25:09 +0000

Szomorú, de igaz: a Japánok élesben használták a VMware Site Recovery Manager-t. A termék segítségével (sajnos, nem először a világon) a tartalék telephelyen sikerült helyre állítaniuk üzleti kritikus folyamataikat.

A történetről bővebben itt lehet olvasni, nagyon tanulságos írás, mindenképpen érdemes átnézni:

http://blog.christopherwells.com/english/2011/3/23/real-life-dr-bc-with-vmware-srm.html

Mai tanulság: vCenter 4.1 – csak 64bit OS

balazs.lovas — Thu, 22 Jul 2010 08:05:39 +0000

Így jár az ember ha nem olvassa el a friss KB cikkeket.

A vCenter 4.1 csak 64-bit OS-re telepíthető.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1019144

Linux VM-ek kezelése

attila.sarandi — Tue, 30 Mar 2010 06:44:21 +0000

Legutóbbi találkozónkon elhangzott előadásom letölthető változatához adok némi magyarázatot azok számára, akik nem tudtak eljönni.
Először is miről lesz szó: VMware Tools install, fizikai-virtuális konverzió, HotAdd Disk, HotAdd CPU, HotAdd RAM, vCenter Template, időszinkron, kernelbe integrált driver-ek.

Sokan elfelejtik a VMware Tools-t felrakni a VM telepítése után, talán azért mert a linux-os telepítés egyszerűsége nem ismert számukra, ezért bemelegítésként álljon itt egy rövid kis összefoglaló a telepítési lépésekről:

$ mount /dev/cdrom /mnt/cdrom

$ cp /mnt/cdrom/VMwareTools-.tar.gz /tmp/

$ cd /tmp

$ tar -zxvf VMwareTools-.tar.gz

$ cd vmware-tools-distrib

$ ./vmware-install.pl

–vagy–         $ rpm -ivh /mnt/cdrom/VMwareTools-.rpm

$ vmware-config-tools.pl

$ umount /mnt/cdrom

$ /usr/bin/vmware-toolbox &

$ rm /tmp/VMwareTools-.tar.gz

$ rm -rf /tmp/vmware-tools-distrib

P2V (Physical To Virtual)

A 4-es verzió óta nem kell mindenféle trükközésekhez folyamodnunk, a VMware Converter Standalone kiválóan használható fizikai gépeink online (működés közbeni) konvertálására. A termék ingyenesen letölthető és használható, akár Linux vagy Windows gépre is feltelepíthető. A vCenter Server-be integrált változathoz képest két hátránya van nem tud P2V folyamatot beütemezni és ColdCloning-ra (CD-ről boot-olós offline konvertálás) nem használható. Viszont egy előnye is van, ugyanis a vCenter-es változat nem tud Linux gépet konvertálni. Az előadás dia azt mutatja be, hogy amennyiben a forrás gépen LVM-et használtunk, azt a konvertálás során szétszedi; viszont – ha szükséges – az IDE-SCSI átalakítást megteszi, kijavítja az fstab-ot is. Hasznájátok!

Lemez növelése, hozzáadása működés közben

A VM meglévő lemezeit tudjuk ugyan növelni, de nem találtam olyan módszert, amivel működés közben egy meglévő partíciót és a fájlrendszert ki lehetett volna húzni. Persze, persze ha umount-tal lecsatolom, akkor igen, de a létfontosságú fájlrendszerek (/var, stb.) lecsatolása alatt nemigen várható el a VM-ben futó alkalmazások futása, ezért nekem innentől az nem működés közbeni, online lemez növelés. Teljes funckionalitású működés közben csak akkor van lehetőségünk, ha LVM-et használunk és fájlrendszer növelési igénykor új lemezet csatolunk a VM-hez, majd azt az LVM-en keresztül hozzácsapjuk a meglévő fájlrendszerhez. Ennek a lépéseit írja le az alábbi parancs sor (a fontos parancsok előtti és utáni ellenőrzések, megjelenítések csak azt a célt szolgálják, hogy tudjuk ellenőrízni a munkafolyamatot):

#0.lépés: diszk hozzáadása VMware-ben
lsscsi
rescan-scsi-bus.sh                             #új diszk felismertetése
lsscsi

fdisk /dev/sdb (n – primary with defaults; t- type 8e; w – write)

pvcreate /dev/sdb1                                  #physical volume létrehozása

vgdisplay
vgextend rootvg /dev/sdb1          #volume group kiterjesztése az új partícióval
vgdisplay

lvdisplay /dev/rootvg/rootlv
lvextend -L +1G /dev/rootvg/rootlv /dev/sdb1       #logical volume kiterjesztése
lvdisplay /dev/rootvg/rootlv

df -h
resize2fs /dev/rootvg/rootlv                           #filesystem kiterjesztése
[ext2online /dev/rootvg/rootlv vagy resize_reiserfs /dev/rootvg/rootlv]
df -h

SWAP növelése esetén a következőképpen néz ki:

#0. lépés: diszk hozzáadása VMware-ben
lsscsi
rescan-scsi-bus.sh                             #új diszk felismertetése
lsscsi

fdisk /dev/sdb (n – primary with defaults; t- type 8e; w – write)

pvcreate /dev/sdb1                                  #physical volume létrehozása

vgdisplay
vgextend rootvg /dev/sdb1          #volume group kiterjesztése az új partícióval
vgdisplay

lvdisplay /dev/rootvg/swaplv
free
swapoff /dev/rootvg/swaplv
lvextend -L +1G /dev/rootvg/swaplv /dev/sdb1
mkswap /dev/rootvg/swaplv
swapon /dev/rootvg/swaplv
free

Hot-Plug CPU

Alapfeltételek: vSphere4 (ESX4/ESXi4); VM version 7; kernel min. 2.6.14. VM FaultTolerance-al nem működik együtt és talán a legfontosabb, hogy alapból nincs bekapcsolva és csak álló VM esetén állítható, így VM indítás előtt az opcióknál kapcsoljuk be ezt a képességet. A VMware publikát egy kis script-et, amivel manuális munka nélkül a Linux-unkban is láthatóvá tehetjük a hozzáadott CPU-(ka)t. Ezt töltsük le, másoljuk fel az összes linux-os VM-ünkbe vagy persze az is elég, ha elkérhetővé tesszük a hálózaton pl. egy NFS megosztáson keresztül:

http://communities.vmware.com/servlet/JiveServlet/download/10493-2-26560/online_hotplug_cpu.sh

Ha hozzáadtuk a VI (ez nem a unix/linux vi editor! ) kliensben az új CPU-t, akkor már csak le kell futtatni – természetesen root jogosultsággal – a fenti script-et.

Hot-Add RAM
Ugyanaz mint a processzornál, csak itt még a Linux-ban aktív SUSPEND és hibernációs képesség is bekavar, ezért azokat mind ki kell kapcsolni – mert még több szerver disztribúcióban is alapból aktív! A script elérhető:

http://communities.vmware.com/servlet/JiveServlet/download/10492-7-26611/online_hotplug_memory.sh

vCenter Template
Igazából semmi különbség nincs a Windows és Linux alapú template-ek között, mindkettő használható és működik: hozzunk létre egy egy új VM-et; telepítsük fel a linuxunkat, konfiguráljuk be, rakjuk fel rá a VMware Tools-t, illetve minden corporate standard alkalmazást; állítsuk le; konvertáljuk át template-té; hozzunk létre egy ‘customization specification’-t és mehet is a deploy! A testreszabásban (customiation) lehetőség van az új gép gép nevének, hálózati beállításainak konfigurálására. Hasznájunk a template-ben LVM-et, így kellően kicsi template-et tudunk létrehozni és garantáljuk a későbbi fájlrendszer növelési igények teljesíthetőségét is.

Időszinkron
Két lehetőségünk van – és persze az egyszerűbbet fogom választani:

a) guest-ben NTP-n keresztül: itt a VMware Tools-os időszinkront a hoszthoz le kell tiltani, DE ha az alábbi műveletek bármelyikét csináljuk (tools startup, taking a snapshot, resuming from a snapshot, resuming from suspend, VMotion), a Tools MINDENKÉPPEN fog egy ad-hoc időszinkront csinálni a hoszthoz, tehát a hoszton mindenképpen be kell állítani az NTP alapú szinkront. Ha pedig már úgyis beállítjuk, akkor használjuk a kövekzető lehetőséget.

b) VMware Tools szinkron a hoszthoz: guest-ben nem kell NTP-t, sőt a Tools-t sem konfigurálni, mert ez a fajta időszinkron a VI kliensben a VM paramétereknél beállítható. Viszont attól függően, hogy milyen disztribúciónk és boot loader-ünk van, szükség lehet a /etc/lilo.conf vagy /boot/grub/grub.conf paraméterezése. Disztribúciónkénti részletes listát itt olvashattok: http://kb.vmware.com/kb/1006427

Nekem ez bevált!

Kernelben integrált VMware driver-ek
Ebből egy részeltesebb cikket tervezek írni, ezért most csak annyi, hogy 2.6.33-as verzió óta már a kernel része néhány VMware driver.

A teljes előadás anyag elérhető a letöltések szekcióban, sőt a videón is dolgozunk!

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