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

Posts Tagged ‘esx’

Upgrading ESX 4.0 to 4.0 U1 using Update Manager fails or times out and rebooting the host results in a purple diagnostic screen

A hiba azon vsphere ESX telepítéseknél jön elő, ahová valamilyen management agent-et már feltettetek. U1 telepítés és újraindítás után ezek a box-ok lila halálba mennek.

Workaround-ként a a mgmt agent-eket le kell szedni a gépről majd U1 telepítés után visszatenni.

KB cikk

A nemrég megjelent VMware vSphere 4 (ESX 4.0) kapcsán talán az egyik legfontosabb dokumentum most a frissítési útmutató (ESX 3.5-ről), a napokban a legtöbb kérdés ezzel kapcsolatban ér utol. Az ünnepek alatt szakítottam egy kis időt, és megírtam a magyar nyelvű cikkemet (nemcsak a lusták kedvéért). Igyekeztem egy-két fontos tanácsot is elrejteni az amúgy dokumentációból is kiolvasható frissítéssel kapcsolatos tudnivalók közé. Jó frissítést mindenkinek!

Read the rest of this entry »

Eredetileg egy cikkben akartam bemutatni mindent, amit az ESX VI3 környezet kapcsán célszerű megismerni, de aztán túl hosszú lett, így inkább 2 részre vágtam szét. Az előző részben beállítottuk a hálózatot, létrehoztunk egy fürtöt és átnéztük annak beállításait. Ez alkalommal a közös storage beállításával ismerkedünk meg, illetve létrehozzuk az első ESX VI3 alatti virtuális gépünket is, egy Windows XP lesz. Végezetül egy VMotion-t is végrehajtunk, azaz az egyik fizikai vasról a másik fizikai vasra helyezzük át a futó XP virtuális gépet, leállás nélkül. Az iSCSI közös storage és a notebook teljesítménye miatt 2 „ping” maradt ki, de a múlt heti szerver környezeti tesztjeim alatt (FC+BLADE) mindössze egyetlen „ping” marad ki a VMotion alatt (ARP flush miatt). A migráció alatt egy rajzot készítettem „mspaint”-ben (RDP kapcsolat közben). A kapcsolat nem bont le, sőt, a Paint-ben a ceruzám csak egy pillanatra „nem fog”. Kb. ennyit vettem észre abból, hogy a gépem fizikai gépek határát átlépte. A felhasználó ezt észre sem veszi (egy pillanatra nem működik az egér a távoli asztal kapcsolatban).

Minden alapja, egy közös hálózati tároló (iSCSI SAN konfigurációja)

Ahogy már korábban is említettem, a VMware a SAN-okon elhelyezett virtuális gépeket támogatja. Nem véletlen, hiszen csak megosztott lemezeken lehet szó HA vagy VMotion szolgáltatásokról.

Read the rest of this entry »

Előző cikkeimben „szigetszerűen” telepítettem ESX 3.5 vagy ESXi 3.5 kiszolgálókat. Felügyeletükhöz a szerverre kapcsolódva letölthető VI klienst használtuk. Természetesen ez csak a kezdet, az ESX VI környezet előnyeit több fizikai gépből álló fürt (clusa ter) estén tudjuk kamatoztatni. Ehhez azonban egy központi felügyeleti szerver kell telepítenünk, melynek neve Virtual Center. Ez egy Windows 2003 szerverre épülő szoftver, mely egy MS SQL (vagy Oracle) adatbázis háttérrel támogatva az összes ESX/ESXi kiszolgáló együttes felügyeletét ellátja. Ilyenkor a VI kliens nem a fizikai kiszolgálóhoz, hanem a Virtual Center szerverhez kapcsolódik. Ebben a formában már definiálhatunk szerverek közötti kapcsolatokat, úgymint „Adatközpontok/DataCenter” vagy „Fürtök/Cluster”. Az így definiált gépcsoportokon már elérhetőek olyan szolgáltatások is, melyek a folyamatos üzemet támogatják (COS). Ide tartozik a virtuális gépek fizikai kiszolgálók közt történő tervezett mozgatása (VMotion) illetve az erre épülő szolgáltatások úgymint DRS vagy DPM. A magas rendelkezésre állást a 3.5-ös ESX szerverek esetén a HA agent biztosítja, mely nem tervezett esetekben valamely kiszolgáló kiesése esetén a leállt virtuális gépeket a fürtben elérhető szabad kapacitású kiszolgálókon újraindítja. A kiesés ilyenkor az észrevételi idő (15 mp, de állítható) plusz a virtuális gépek újraindítási idejével arányos. Akinek ez nem volna elég, és katasztrófatűrő telephelyek építésén gondolkoznak, ők a VMware SRM-et nézegessék. Egy másik irány a hibatűrő rendszerek világa, vagyis az FT (Fault Tolerance). Jelenleg az ESX 3.5-ben ilyen jellegű támogatás még nem elérhető. Termszetesen továbbra is lehet szoftveres clustering-et alkalmazni a különböző fizikai gépek azonos virtuális hálózatára kapcsolódó virtuális gépei között (DNS, MS Clustering, Linux Clusterek, stb. Lehet próbálkozni Oracle RAC-cal is, működik, de a támogatást ekkor inkább valamely szolgáltató partnertől kérjük, mint közvetlen a RAC gyártójától).

Read the rest of this entry »

Az elmúlt héten a VMworld Europe rendezvényen elhangzott, hogy „VMware vSphere 4” lesz a hamarosan megjelenő új ESX 4.0 termék neve. Ezzel a cikkel nagyon elkéstem (2007. októberben jelent meg a 3.5), de hiánypótlásként mindenképpen tartoztam még vele. Legutóbb az ESXi telepítését néztük át, most nézzük meg újra a „hagyományos” ESX szerver telepítésének lépéseit. Igyekeztem az unalmas telepítési leírás mellett jó pár hasznos tippet is megosztani a kedves olvasóimmal.

Magyar nyelvű ESX Server 3.5 telepítési útmutató

Ez a rövid bemutató képekben átfutja, hogyan lehet az ESX 3.5-öt telepíteni. A napokban még mindig találkozom olyanokkal, akiknek a telepítéssel kapcsolatos kérdési vannak. A cikk további célja, hogy egy helyen legyen megtalálható az ESX3 és ESX4 telepítése, így a különbségeket/változásokat jól lehet majd látni. Amúgy nem bonyolult a telepítés, a lépések nagyon hasonlítanak egy sima RHEL telepítésre. Ez nem véletlen, hiszen az ESX szerver konzol operációs rendszere ebből származik.

A telepítés első lépéseként tesztelhetjük a CD lemezt, de nem ajánlott, csak az időt húzzuk vele. Én egy virtuális gépként teszteltem, ez ne zavarjon meg senkit (így lehet a legegyszerűbben képernyőképeket készíteni szerverek nélkül), normál esetben fizikai gépre ugyanígy történik a telepítés. Legközelebb, ha minden terveim szerint alakul már pl. az IBM BladeCenter Management webes felületén fogok mutogatni, amint a VI4-et telepítem, remélhetőleg hamarosan.

A kezdő képernyőn a logó megcsodálása után a Next az egyetlen lehetőség.

Read the rest of this entry »

Találtam egy rövid checklist-et, amit elő lehet venni ha gond van a HA konfigurálással:

• Check the HOSTNAME entry in /etc/sysconfig/network to the short name
• Check if your FQDN is greater than 30 characters, in which case HA will not configure properly. This is a known bug in VC20 (see KB article 2259).
• Check IP, routing, and DNS for each host.
• Make sure that storage and network are available across the cluster – Ensure that the hosts are not managed directly: perform all host management through VC.
• May want to add nodes to /etc/hosts on ESX Server AND hosts file on VC Server. A better plan would be to use primary and secondary DNS servers.
• Check if Service Console has default gateway defined.
• Verify logs: /opt/LGTOaam512/* and /opt/LGTOaam512/vmsupport/*.
• Check /etc/hosts and /etc/resolv.conf.
• In ESX 3.x the memory reservation is zero, and the limit is “unlimited.” To see this, edit the settings of a virtual machine, click on the Resources tab, and select Memory on the left. To conform to the ESX 3.x defaults, change the settings to a reservation of 0, and check the Unlimited box under limit. After doing this for all virtual machines, edit the settings for the cluster. Disable HA, and then edit the cluser settings again to reenable HA. The current failover capacity should now match the configured capacity.

Gyakori probléma, hogy HA-hoz szükséges Service Console redundancia nincs biztosítva. Azonban még nagyobb gond, ha a redundáns SC hálózat kialakítása nem megfelelő. Sajnos meglehetősen félrevezető és nem túl bőbeszédű a dokumentáció ezzel kapcsolatban.
Hogyan is kell tehát a Service Console redundanciát kialakítani?

Alapvetően két megoldás létezik

1. A meglévő Service Console-hoz tartozó vSwitch-hez adunk legalább két NIC-et
2. Dedikálunk egy kölünálló NIC-et egy új vSwitch-hez, amihez aztán egy második SC hálózatot rendelünk

Látszólag egyszerű a dolog, de mindkét megoldásnak vannak erős követelményei.

Teaming

Az első megoldás tűnik a legegyszerűbbnek, azonban ez a felállás magában foglal egy lehetséges Single-Point-of-Failure, nevezetesen a mögöttes fizikai switch-et. Nyilvánvaló, ha mindkét NIC-et ugyanabba a fizikai switch-be kötjük, akkor az adott switch meghibásodása esetén az egész HA redundacia bedől. Emiatt mindenképpen külön-külön switch-be kell kábeleznünk a két Service Console-t. Azonban! Ez a kettőzés megköveteli, hogy a két fizikai port-on FastPort (Etherchannel) legyen konfigurálva, amely két fizikai switch esetében csak akkor lehetséges, ha a switch-ek STACK-elve vannak, erre pedig nem minden switch képes!!

Még egy SC

A második lehetőségünk, hogy használunk egy meglévő vSwitch-et és ezen alakítunk ki a második Service Console-t. A VMware ajánlása, hogy erre nyugodtan használjuk a meglévő VMotion-VMKernel vswitch-et, ami valóban a legegyszerűbb megoldás. Sajna ezzel is van egy kis bibi… A VMotion hálózattal szemben követelmény, hogy ez egy teljesen izolált fizikai hálózat legyen; a HA-ról pedig tudjuk, hogy erősen kötődik a DNS-hez, így rögtön felmerül a kérdés: az a Service Console hálózat, amely a VMotion hálózatot használja hogy az ördögbe fog tudni a DNS-hez csatlakozni? Szerencsére van megoldás: /etc/hosts.

Tehát ha a VMotion hálózathoz szeretnénk kötni a redundáns SC-t ezt így tehetjük meg:

1. alakítsuk ki a VMotion vSwitch-en a második SC-t és adjunk neki IP a vmotion subnet-ből
2. szerkesszük meg az /etc/hosts állomány és kézzel vegyük fel a HA cluster minden tagjának a VMotion subnet beli IP-címét
3. Bizonyosojunk meg arról, hogy az elsődleges SC-nél konfiguráltunk DNS-t és ellenőrizzük, hogy létezik-e DNS host rekord minden node-hoz (itt terménszetesen a management LAN beli IP címet kell használni)
4. szerkesszük meg az /etc/nsswitch.conf állományt, hogy ez legyen benne.
   hosts: files dns

Ennek hatására a HA cluster mindkét SC irányba képes lesz név szerint elérni a node-okat. Az nsswitch beállítása miatt előszőr a hosts file-ból fog pingelni (ekkor használja a VMotion-re kötött SC-t), és ha ez nem megy, akkor fordul a DNS-hez (mikor is a mgmt lan-hoz kötött SC-t használ).

Gondoltam, ideje belenézni a „nagyok” dolgába is, ezúttal készítek egy bemutatót a VMware fizetős, elsősorban nagyvállalati felhasználóknak szánt „enterprise” ESX környezetéről.
Az ötletet az adta, hogy kb. egy hónapja találtam híreket arról, hogy a nemrég megjelent, ingyenesen hozzáférhető VMware Workstation 6.5 beta képes futtatni vendég gépként az ESX 3.5 szervert.
Segítségével otthon is össze lehet rakni egy virtuális ESX homokozót, tehát nem kell 2-3 fizikai gépet vásárolni (komoly SAN diszkrendszerekkel), akár a notebook-omon is játszhatok vele, miközben a Balatoni strandra (északi part) utazunk a gyors(?)vonattal. Figyelembe véve a vonat sebességét, mire leér a vonat, épp felhúzok egy ESX cluser-t 2 virtuális gépből (meg a páromat is, hogy már megint a gépet nyomkodom). Így is történt, íme a bemutatóm. Természetesen, ez itt még csak a kezdet, ami arról szól, hogyan lehet beüzemelni az ESX környezetet otthoni, relatív olcsó hardver (Intel-VT vagy AMD-V kell „csak”) segítségével. Legközelebb a megszerzett tapasztalatokról és ESX lehetőségekről fogok írni.

Azt csiripelik a madarak…

hogy az ESX 3.5 szerver (és VI3 infrastruktúra) akár virtuális gépként is működik a nemrég megjelent VMware Workstation 6.5 alatt. Ez magában is érdekesen hangzik, hiszen a virtuális gépek nem mindig használhatóak további virtualizációs környezet létrehozására. Ez amolyan virtuális gép a virtuális gépben kérdést vet fel. Lehet próbálkozni, bizonyos korlátozásokkal ez-az összejöhet (VMware alatt Xen?) bár nem sok értelme van, és a performancia igencsak elúszik. Azonban oktatási vagy érdeklődési céllal nyerő lehet egy gépen működtetni egy komplett virtualizációs rendszert (pl. VI3).

Kezdeti nehézségek: Windows 2008 (x64) host + VMware Workstation 6.5 beta (91182) nem nyert

Dual boot-os gépem WinXP/Win2008 (x64)-at tartalmazó fizikai partícióin próbálgattam a VMware Workstation 6.5-öt. Win2008 x64 alatt elég pocsékul szerepelt: simán kiakad a VMware 6.5 konzol, ha véletlen magyar billentyűzetről nyomok be neki egy karaktert. Read the rest of this entry »

Pár héttel ezelőtt még gondolkodnom kellett, hogyan mutassuk be a „desktop virtualizáció” témában az energia megtakarítást. A napokban a VMware honlapján erre a célra egy remek kis kalkulátor jelent meg, ahol a jelenlegi gépparkod paramétereit megadva (gépek száma) megbecsülhető a virtualizáció általi energia-megtakarítás mértéke. Bár a cikk elsősorban az USA állapotát mutatja be, állításuk szerint akár 80-90 százalékkal is csökkenthető a villamos energia kiadás, meggondolandó, hogy hazánkban mikor kap majd esetleg állami támogatást a virtualizáció (környezetvédelmi okok miatt).

Gondoljuk csak végig, milyen előnyökkel járna, ha egy vállalkozás (adó-, villamos energia- vagy virtualizációs támogatás formájában) kedvezményt kaphatna, amennyiben csökkentené villamos energia felhasználását, ezzel együtt hozzájárulna környezetünk védelméhez. Kíváncsian várom, mikor lesz esetleg valamilyen visszhangja a tőlünk nyugatra már régóta megfigyelhető szerver konszolidációnak, és energiacsökkentéseknek.

Részletek itt: http://www.vmware.com/solutions/consolidation/green/