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.

Verplaatsen opslag virtuele machines met Storage Vmotion

Onlangs heb ik één van de nieuwe features van ESX3.5 gebruikt, namelijk Storage Vmotion. Hiermee is het mogelijk om zonder downtime de opslag van een virtuele machine te verplaatsen.

Helaas kun je Storage Vmotion niet aanroepen met de VI client, maar is de Remote CLI vereist. Deze bevat een commando 'svmotion' die een Storage Vmotion opdracht kan uitvoeren. De syntax van svmotion is als volgt:

svmotion [Standard remote CLI options]
--datacenter=<datacenter name>
--vm="<VM config datastore path>:<new datastore>"
[--disks "<virtual disk datastore path>:<new datastore>, <virtual disk datastore path>:<new datastore>]"

Met dit commando is het mogelijk om (afhankelijk van de opgegeven argumenten) een complete virtuele machine te verhuizen naar een andere datastore, of slechts enkele schijven. Een belangrijke kanttekening hierbij is dat de VM config datastore path die bij het vm argument wordt opgegeven niet hetzelfde mag zijn als de new datastore. Anders gezegd de configuratie, log en andere bestanden die in een directory van een virtuele machine staan moeten verhuizen. Met het disks argument kan eventueel per VMDK bestand worden opgegeven welke schijven moeten verhuizen of moeten blijven staan op de originele locatie. Ook mag de virtuele machine waarvan de opslag verplaatst gaat worden geen snapshots bevatten.

Zie voor meer informatie de Virtual Infrastructure documentatie op het volgende URL: http://pubs.vmware.com/vi35/ (via de index: Basic System Administration/Migrating Virtual Machines/Migration with Storage VMotion).

Mocht je de Remote CLI willen uitproberen, pas dan op aangezien deze een complete ActiveState perl distributie bevat. Mocht je al perl op je machine hebben staan dan kan dit mogelijk voor ongewenste bijeffecten zorgen.