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.