Hostname aanpassen in ESX 3.x

Onlangs las ik op de VMUG site een artikel over het aanpassen van de hostname in ESX 3.x.

Nu had ik vorige week toevallig ook een systeem waarvan ik de hostname moest wijzigen (ESX 3.5 update 2), maar heb dit gedaan door via de VI client naar de DNS en Routing configuratie te gaan en daar de hostname aan te passen.

Ik heb alle stappen gecontroleerd uit het VMUG artikel en daar stond netjes de nieuwe naam:

• hostname -f geeft nieuwe naam weer
  
• /etc/hosts bevat de nieuwe naam
  
• /etc/sysconfig/network bevat de nieuwe naam
  
• sysctl kernel.hostname geeft de nieuwe naam weer
  
• esxcfg-advcfg -g /Misc/Hostname geeft de nieuwe naam weer
  

Het enige wat volgens mij niet is aangepast, is het SSL certificaat dat oa. voor communicatie met Virtual Center wordt gebruikt. Gelukkig is dit ook eenvoudig te verhelpen door de volgende procedure uit te voeren:

• Maak een backup van de directory /etc/vmware/ssl/
  
• Verwijder alle bestanden uit de bovengenoemde directory met het volgende commando: rm /etc/vmware/ssl/*
  
• Herstart de VMware management services met het volgende commando: service mgmt-vmware restart
  

Bij het herstarten van de VMware management services zal de volgende melding worden getoond: Generating VMware ESX Server SSL certificate

ESX maintenance mode via de service console

Mocht je via de service console een ESX host in maintenance mode willen zetten, bijvoorbeeld via een script dan kan dit door gebruik te maken van het volgende commando:

vimsh -n -e /hostsvc/maintenance_mode_enter

Het uit maintenance mode halen gaat als volgt:

vimsh -n -e /hostsvc/maintenance_mode_exit

P2V server wijzigen van multi naar single CPU

Indien je een server virtualiseert door middel van P2V is soms het wenselijk om de HAL (hardware abstraction layer) aan te passen. Bijvoorbeeld in het geval als je een multiprocessor fysieke server migreert naar een uniprocessor virtuele server.

Voor Windows 2000 was de procedure bekend. Je gaat naar de device manager en wijzigt de driver van het apparaat dat onder de container 'computer' staat. Zie voor meer informatie de knowledge base van Microsoft op het volgende URL: http://support.microsoft.com/kb/237556

Echter in Windows 2003 schijnt dit niet zo gemakkelijk te gaan. Een downgrade via dezelfde procedure als Windows 2000 zou niet mogelijk zijn, tenzij er een hotfix wordt geïstalleerd. Hier is het volgende knowledge base artikel aan gewijd: http://support.microsoft.com/kb/923425

Heb je geen zin om deze hotfix te installeren is het ook mogelijk om door middel van de command-line utility devcon (Device Console) een wijziging door te voeren. Het werd mij na het lezen van wederom een knowledge base artikel - http://support.microsoft.com/kb/311272 - niet duidelijk of deze utility standaard in Windows 2003 aanwezig is. Maar op mijn server was dit wel het geval. Het gebruik van devcon is verre van gebruiksvriendelijk te noemen, dus heb ik de volgende batch file op het internet gevonden die de omzetting van multi- naar uniprocessor volautomatisch uitvoert.

HAL_UPDATE.CMD

@echo off

:DRIVER_HAL_UPDATE
SET HAL=

IF %NUMBER_OF_PROCESSORS%==1 (
devcon.exe /find @ROOT\ACPI_HAL\0000 | find /i "Multiprocessor" > NUL && SET HAL=ACPIAPIC_UP
devcon.exe /find @ROOT\PCI_HAL\0000 | find /i "Multiprocessor" > NUL && SET HAL=MPS_UP
) ELSE (
devcon.exe /find @ROOT\ACPI_HAL\0000 | find /i "Uniprocessor" > NUL && SET HAL=ACPIAPIC_MP
devcon.exe /find @ROOT\PCI_HAL\0000 | find /i "Uniprocessor" > NUL && SET HAL=MPS_MP
)

IF NOT "%HAL%"=="" (
ECHO.
ECHO ----------------------------------------
ECHO Installing %HAL% HAL
ECHO ----------------------------------------
ECHO.

devcon.exe sethwid @ROOT\PCI_HAL\0000 := !E_ISA_UP !ACPIPIC_UP !ACPIAPIC_UP !ACPIAPIC_MP !MPS_UP !MPS_MP !SGI_MPS_MP !SYSPRO_MP !SGI_MPS_MP
devcon.exe sethwid @ROOT\ACPI_HAL\0000 := !E_ISA_UP !ACPIPIC_UP !ACPIAPIC_UP !ACPIAPIC_MP !MPS_UP !MPS_MP !SGI_MPS_MP !SYSPRO_MP !SGI_MPS_MP
devcon.exe sethwid @ROOT\PCI_HAL\0000 := +%HAL%
devcon.exe sethwid @ROOT\ACPI_HAL\0000 := +%HAL%
devcon.exe update %windir%\inf\hal.inf %HAL%
devcon.exe ReScan

ECHO.
ECHO ----------------------------------------
ECHO Rebooting
ECHO ----------------------------------------
ECHO.
devcon.exe Reboot
) ELSE (
ECHO.
ECHO ----------------------------------------
ECHO Correct HAL Detected
ECHO ----------------------------------------
ECHO.
)
GOTO :EOF


SVMotion VI plugin

Als ESX beheerder zul je ongetwijfeld bekend zijn met Storage vMotion dat sinds versie 3.5 beschikbaar is. Zo niet, zoals de naam doet vermoeden is het met deze functionaliteit mogelijk om zonder een virtuele machine down te brengen de onderliggende opslag te verplaatsen.

Het aansturen van Storage vMotion was tot nu toe echter niet echt gebruiksvriendelijk te noemen. Hiervoor had je namelijk de VMware remote CLI nodig en was flinke lijst aan argumenten nodig om VI/ESX aan het werk te zetten.

Gelukkig kwam een collega onlangs een plugin voor de VI client tegen die dit een stuk eenvoudiger maakt. Door middel van deze plugin kun je grafisch aangeven waar je je bestandjes wilt bewaren.

Bekijk voor meer informatie de website van het project op Sourceforge: http://vip-svmotion.wiki.sourceforge.net/

ESX host wordt als 'not responding' getoond

Vandaag (maandag, hoe kan het ook anders) signaleerde ik een probleem op het VMware cluster van mijn opdrachtgever. Verschillende ESX hosts werden als 'not responding' getoond in de VI client.

Nu is dit gedrag mij niet helemaal onbekend. De oplossing is in zo'n geval vaak het herstarten van de mgmt-vmware service vanuit de service console. Deze keer bleef het opstartscript echter hangen op de eerste regel van de output.

Om de ESX host in kwestie weer netjes in het cluster zichtbaar te krijgen heb ik het volgende commando opgegeven:

service mgmt-vmware status

Dit commando geeft zoals de naam doet vermoeden de status weer van een service en als deze draait ook een program ID. Gebruik nu dit program ID als argument voor het beruchte kill commando en na enige tijd is de ESX host weer gezond.

Mocht dit niet zo zijn, voer dan het volgende commando uit:

service mgmt-vmware start

En controleer met hetzelfde commando, maar nu met het agument status of er daadwerkelijk iets gestart is. Mocht je de status voor langere duur willen monitoren, overweeg dan om dit commando aan watch te voeren.

VMware Virtual Center database cleanup

Tijdens de upgrade van Virtual Center krijg je de keuze om historische data zoals tasks, events en performance data wel of niet te bewaren. Ik had het echter fijn gevonden als een deel van de data bewaard kon blijven. Zo maak je namelijk wel weer opslagcapaciteit beschikbaar, maar heb je toch nog een deel van je historische gegevens.

Wellicht komt dit ooit nog eens in een volgende versie van Virtual Center, maar voor nu is er ook een andere oplossing in de vorm van een SQL script. Dit script en de werking ervan is te vinden op de knowledge base van VMware op het volgende url: http://kb.vmware.com/kb/1000125. Er is een versie beschikbaar voor zowel SQL server als Oracle.

Het komt er in het kort op neer dat je door middel van een zogeheten 'cutoff date' kunt instellen hoeveel dagen historie je wilt bewaren. Met het instellen van de variabele DELETE_DATA (waarde 0 of 1) kun je bepalen of je alleen een rapport wilt krijgen, of ook de data daadwerkelijk wilt verwijderen.

Mijn suggestie is om periodiek, of tenminste vóór iedere update van Virtual Center even een cleanup uit te voeren.

Customization mislukt bij uitrollen template Virtual Center 2.5

Sinds de upgrade naar Virtual Center versie 2.5 functioneerde het uitrollen van templates niet meer volledig. De customization wilde niet meer starten waardoor de hostnaam en andere instellingen van een nieuwe virtuele machine niet werden aangepast.

Bij controle van een log bestand van het customization proces - %TEMP%\vmware-imc\guestcust.log - vond ik een 'access denied' melding bij het verplaatsen van tijdelijke bestanden naar C:\SYSPREP. De locatie van deze bestanden werd bepaald door de %TEMP% systeemvariabele welke in onze template naar E:\TEMP was gewijzigd. Tot aan Virtual Center 2.0.x was dit geen probleem, maar kennelijk is er in versie 2.5 het nodige gewijzigd.

Als workaround heb ik de %TEMP% en %TMP% variabelen weer naar de standaard locatie gezet in de template. En vervolgens heb ik in de 'Run Once' sectie van een customization specification de volgende commando's opgenomen:

setx /M TEMP E:\Temp
setx /M TMP E:\Temp

Het gebruikte setx commando is standaard aanwezig in Windows 2003. Ook Windows 2000 gebruikers kunnen dit commando gebruiken, maar moeten dit nog wel eerst even downloaden van de Windows Support site.

Bij contact met de support afdeling van HP (onze support partner) wist men mij te vertellen dat dit een bekende bug is in Virtual Center. Ze moesten hiervoor wel eerst een VMware support engineer benaderen, want ze hadden dit probleem zelf nog niet eerder behandeld. De workaround die ik heb verzonnen zal totdat de bug is opgelost door VMware ook aan andere HP klanten worden aanbevolen.

• Update 8 mei 2008: Volgens HP is de bug ondertussen aangemeld bij VMware onder ID 263317.


• Update 6 februari 2008: Via een berichtje op vmguru.nl kwam ik tot de ontdekking dat VMware in een knowledgebase artikel heeft beschreven dat het wijzigen van de TEMP en TMP variabelen niet ondersteund wordt.