Unexpected.be

Telling stories for a living

Tag: VCenter

Als je regelmatig met VMware ESX (al dan niet vSphere) aan de slag gaat, heb je zonder twijfel al eens met “intranet” vSwitches gewerkt. Hiermee bedoel ik een vSwitch die niet gelinkt is aan een pNIC (een fysieke netwerkkaart).
Zelf gebruik ik zulke oplossing regelmatig als ik een sandbox omgeving wil maken waarbij een aantal virtuele machines enkel met elkaar mogen communiceren. Een serieus lastig probleem waar je mee geconfronteerd wordt in het geval je over een ESX cluster beschikt, is dat virtuele machines die op zo een “intranet” vSwitch geconnecteerd zijn niet met VMotion naar een andere ESX host gemoved kunnen worden.
Op zich niet zo een groot probleem hoor ik je denken: je kan de VM uitschakelen en daarna een “cold migration” doen. Klopt als een bus.
Maar hoe ga je DRS gebruiken op je cluster in bovenstaand geval? DRS maakt eveneens gebruik van VMotion en zal dus onmogelijk die machines kunnen moven tussen je ESX hosts.
Een ander probleem is dat wanneer je je ESX host in “maintenance mode” plaatst, de host zijn VM’s niet gaat kunnen moven naar een andere host, waardoor overgaan tot “maintenance mode” altijd manuele arbeid vereist. Als je tientallen VM’s in een sandbox hebt, ben je dus eventjes bezig om elke machine netjes uit te schakelen…
Gelukkig is er voor (bijna) elk probleem een oplossing! Je kan op je VCenter een wijziging van de configuratie doen zodat VMotion wel gaat lukken op machines die op een “intranet” vSwitch geconnecteerd zijn.
Opgelet: kijk goed na dat de “intranet” vSwitches op elke ESX host in je cluster aanwezig zijn, anders krijg je VM’s met een gedisconnecteerd netwerk.
En dan nu de oplossing: op je VCenter server in de folder “C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter” pas je het bestand “vpxd.cfg” aan door onderstaande parameters toe te voegen net voor de </config> lijn:
<migrate>
<test>
<CompatibleNetworks>
<VMOnVirtualIntranet>false</VMOnVirtualIntranet>
</CompatibleNetworks>
</test>
</migrate>
Daarna de VCenter Server service herstarten en als alles goed is, zou het nu allemaal netjes moeten werken.
PS: zorg dat je een backup maakt van het “vpxd.cfg” bestand, just to be safe.

Vandaag had ik problemen met mijn VMWare vSphere testlab, meer bepaald met mijn VCenter machine. Connecteren naar VCenter was niet mogelijk via de VIC en een reboot van de machine hielp niets. Op geregelde tijdstippen na het starten, vloog de VCenter Server service er telkens opnieuw uit. Hmmm.
Na de Windows eventviewer te raadplegen, vond ik volgende errors:

Bleek de MSSQL database tegen zijn limiet van 4096MB aan te lopen, waardoor VCenter er niet meer naar kon schrijven en waardoor gans de boel in faling ging. Een shrink op de database bracht geen soelaas (0,20MB om precies te zijn), maar na mijn trouwe vriend Google te raadplegen, wist ik wat gedaan.
Eerst en vooral was ik bij het opzetten van mijn VCenter een beperking vergeten in te stellen op het aantal “events” en “alarms” dat VCenter moet bijhouden in zijn database. Alles stond dus op “unlimited” en dat in samenwerking met “Verbose Logging” zorgde er dus voor dat mijn database na een paar maanden vol zat.
En de oplossing? VMWare heeft een scriptje ter beschikking (voor MSSQL en Oracle) waarmee je je database kan opschonen. Zeer simpel allemaal eigenlijk, en het werkt!

Hier het verslag van het script:

2010-06-21 19:32:51 starting…
2010-06-21 19:32:51 VPX_TASK: will attempt to delete 207 rows.
2010-06-21 19:32:52 VPX_TASK: deleted 207 total rows.
2010-06-21 19:33:11 VPX_EVENT_ARG: will attempt to delete 9544313 rows.

Serieuze opkuis nietwaar? Het scriptje is bijna halverwege en heeft er al 35 minuten opzitten, met een dual-core CPU die bijna constant op 100% loopt. Zware kost dus! En eenmaal het klaar is met cleanen, mag ik niet vergeten om de retention van al die zaken in te perken tot pakweg twintig dagen.

© 2018 Unexpected.be

Theme by Anders NorenUp ↑