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.
Tag: vMotion
Eind vorige week een VMware vSphere 4.0 Update 2 omgeving geupgrade naar vSphere 4.1:
- Upgrade package downloaden van de VMware website
- Package importeren in de Update Manager
- Host in “maintenance mode” zetten
- Upgrade laten lopen
- Reboot
- Upgrade Manager laten scannen voor extra updates, bugfixes,…
- Upgrades toepassen
- Klaar
- Host uit “maintenance mode” halen en aan de volgende host beginnen…
Op zich allemaal goed gelukt zonder problemen, ware het niet dat mijn HA (High Availability) configuratie voor problemen zorgde na de upgrade. De eerste host gaf geen noemenswaardige problemen aan, maar op de tweede kwam er de melding dat er een probleem was met de HA Agent op de host.
In zo een geval migreer ik meestal de VM’s naar de andere host en reboot ik de machine. Probleem nummer 2: vMotion wou ook niet meewerken waardoor de taken om de VM’s te migreren bleven “hangen”.
Enfin. De time-out’s uitgezeten en daarna gewoon de VM’s afgezet (gelukkig was er geen issue voor productie) en daarna de host een reboot gegeven. En ja, ik had eerst de VMware service herstart, zonder soelaas.
Spijtig genoeg gaf een reboot geen oplossing. Het probleem van de HA agent was er nog steeds en vMotion ging ook nog niet zoals het moest (en dus faalde DRS eveneens).
Oplossing: host uit de cluster verwijderen waarop de HA agent verwijderd wordt van de ESX host. Daarna terug toevoegen zodat de agent opnieuw geïnstalleerd wordt en klaar is kees. Probleem opgelost, HA up & running, DRS in de pocket en vMotion deed ook weer wat van hem / haar verwacht werd.
Recente Comments