www.flickr.com

dinsdag 23 september 2008

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

dinsdag 16 september 2008

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/

maandag 15 september 2008

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.

donderdag 28 augustus 2008

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.

woensdag 7 mei 2008

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.

donderdag 24 april 2008

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.

dinsdag 1 april 2008

Virtual Center session count

Virtual Center kent veel mogelijkheden om het beheer van het virtuele machinepark te automatiseren. Dit is onder andere mogelijk met de VI Perl Toolkit. Deze interface bied de mogelijkheid om door middel van Perl scripts de VI API te gebruiken.

Tijdens het gebruik van deze toolkit is mij (wederom) gebleken dat het automatiseren door middel van eigen geschreven scripts de nodige risico's met zich meebrengt.

Een van de gebruikte scripten op de server van mijn opdrachtgever voerde een beschikbaarheids controle uit door simpelweg in te loggen op de Virtual Center web interface. Echter de routine om uit te loggen stond niet op de juiste plek in het script en werd nooit aangeroepen.

Het gevolg hiervan was dat na enkele momenten het limiet was bereikt van het maximaal aantal gelijktijdige sessies. Proefondervindelijk is vastgesteld dat dit maximum op de huidige versie van Virtual Center - versie 2.5 - op 100 is ingesteld. Indien deze situatie zich voordoet zal de volgende melding in de vpxd log bestanden worden weggeschreven:

"SOAP session count limit reached".

Gelukkig kan ook het aantal sessies door middel van de VI Perl toolkit worden bewaakt. Zie hiervoor de VMware Infrastructure SDK reference guide en zoek hier naar het UserSession Data Object.

Hopelijk ben je door het bewaken van het aantal gelijktijdige sessies het moment dat het écht fout gaat voor.

woensdag 12 maart 2008

Eerste ervaringen met de VMware Infrastructure Remote CLI

Met de komst van VMware ESX Server 3i lijkt VMware de weg naar 'thin virtualization' gevonden te hebben. Hoewel er een aantal voordelen te verzinnen zijn bij het gebruik van een thin hypervisor zoals minder vereiste diskruimte, een verminderde noodzaak voor patching en het niet meer hoeven beheren van een compleet linux-like systeem (de serviceconsole van ESX is gebaseerd op RedHat Enterprise Linux), zijn er ook nadelen.

Zo zullen veel bedrijven het configureren van hun ESX hosts voor een deel hebben geautomatiseerd door middel van scripting. Aangezien de tools die door deze scripten worden aangeroepen niet meer aanwezig zijn in ESX Server 3i heeft VMware een nieuwe management tool in het leven geroepen: VMware Infrastructure Remote CLI (versie 1.1.0 met experimentele ondersteuning voor ESX 3.5).

Deze software lijkt gebruik te maken van de VI Perl Toolkit en emuleert de werking van ESX configuratie commando's. Hierbij kan gelukkig wel voornamelijk dezelfde syntax worden gehanteerd. En doordat de commando's aan Virtual Center kunnen worden doorgegeven worden de wijzigingen als 'task' getoond in de Virtual Center client met de gebruikersnaam van de uitvoerende operator erbij.

Hoewel je een eind zult komen met de Remote CLI zijn er ook wat beperkingen. Het is bijvoorbeeld niet mogelijk om users te beheren op de ESX server, of de in ESX 3.5 geïntroduceerde instellingen voor CDP (Cisco Discovery Protocol) te wijzigen.

Verder was het in een ESX service console mogelijk om waar de esxcfg-* commando's tekort schoten, gebruik te maken van vimsh. Deze shell kon bijvoorbeeld het aantal poorten op een reeds aanwezige vSwitch aanpassen, een machine in maintenance mode zetten, of de Vmotion functie aanzetten op een VMkernel poort.

Kortom, het lijkt erop dat VMware iets te haastig is geweest bij het introduceren van de Remote CLI. Het is begrijpelijk dat ze ter compensatie voor het wegvallen van de service console in ESX 3i een nieuwe management interface wilden aanbieden. Maar deze schiet in de huidige vorm helaas tekort.

Het wachten is op een nieuwe, uitgebreidere versie. VMware werkt inmiddels ook aan een interface die kan worden aangeroepen via Windows PowerShell. Ontwikkelingen op dit gebied zijn te volgen op het VI PowerShell Blog.

maandag 25 februari 2008

Wijzigen password aging op ESX server

Standaard is password aging ingesteld op ESX server. Dit is niet altijd wenselijk, dus hierbij 2 commando's om dit weer uit te schakelen:

Het eerste commando past de aging aan van een enkele gebruiker:
passwd -x -1 -w 7 -n 0 gebruikersnaam

Het tweede commando zorgt dat de password policy wordt gewijzigd zodat er voor nieuwe gebruikers geen aging meer wordt toegepast:
esxcfg-auth --passmaxdays=0

woensdag 13 februari 2008

Hoe stop ik een hangende virtuele machine?

Soms komt het voor dat een opdracht voor het stoppen of herstarten van een virtuele machine niet goed doorkomt op de ESX server die deze virtuele machine 'host'. Als deze opdracht meermalig wordt gegeven zal de volgende foutmelding worden getoond: "Operation failed since another task is in progress". Er zijn 2 methoden om de virtuele machine weer operationeel te krijgen.

ESX 3.0 methode
- Login in op de service console
- Het is mogelijk om de status van de VM te controlerem met het volgende commando: "vmware-cmd /<pad naar VM directory>/server.vmx getstate"
- Typ "ps xww | grep <virtualmachinename>". De tweede kolom is het PID van het vmkload_app proces van de virtuele machine.
- Typ "kill -9 "
- Controleer nogmaals de status van de VM. Deze zou nu uit moeten staan.
- Typ "vmware-cmd /<pad naar VM directory>/server.vmx start" om de VM weer aan te zetten.

ESX 3.0 Alternatieve methode
- Login in op de service console
- Vraag het VMID op van de virtuele machine met het commando "vm-support -x"
- Kill de virtuele machine en genereer core dumps en log bestanden door het commando "vm-support –X <vmid>" te gebruiken.
- Er zal gevraagd worden of je een screenshot van de Virtuele machine wilt bijsluiten en een NMI en een ABORT opdracht naar de VM wilt sturen. Antwoord "YES" op het verzoek de ABORT opdracht uit te voeren om de VM te stoppen. Dit proces zal 5 tot 10 minuten in beslag nemen en zal een tar archief aanmaken.
- Typ "vmware-cmd /<path to VM directory>/server.vmx start" om de VM weer aan te zetten.

woensdag 23 januari 2008

Grootte VMDK bestand met bestaande snapshots aanpassen

Het is niet mogelijk om in VMware ESX de grootte van een VMDK bestand aan te passen zo lang er snapshots aanwezig zijn van de virtuele machine. Mocht je dit toch doen, dan zal de machine niet meer opstarten.

Gelukkig is er een manier om ESX te laten denken dat de aangepaste VMDK nog de oude grootte heeft. Controleer de originele grootte van een virtuele disk door het volgende commando uit te voeren op de command prompt van ESX:

grep -i rw test-000001.vmdk

De output van dit commando zal lijken op de volgende regel:

RW 2097152 VMFSSPARSE "test-000001-delta.vmdk"

Neem de waarde (in dit geval 2097152) over in de originele VMDK file, die hier test.vmdk heet.

Voer nu het volgende commando uit om de bestaande snapshots te verwijderen:

vmware-cmd /pathtovmx/test.vmx removesnapshots

Nu dient het commando voor het vergroten van de virtuele disk opnieuw uitgevoerd te worden:

vmkfstools -X 8G test.vmdk

Vanwege het verschil in grootte tussen de configuratie in test.vmdk en de ware grootte van het test-flat.vmdk bestand zal de volgende waarschuwing worden getoond:

DISKLIB-VMFS :Create: unexpected size diff: 0

Desondanks zal het nu mogelijk zijn om de virtuele machine weer op te starten met een vergrootte disk.

Update 06-01-2009: VMware heeft een soortgelijke procedure op hun knowledgebase gezet: http://kb.vmware.com/kb/1646892

maandag 7 januari 2008

Verwijderen van een vastgelopen DLT tape

Voor degenen die wel eens een DLT drive hebben weggegooid omdat er een tape in vast zat, heb ik vervelend nieuws. Op de website van HP staat namelijk een handig support document die beschrijft hoe je een vastgelopen DLT tape uit de drive kunt verwijderen. Voor een collega bij mijn huidige opdrachtgever bleek dit document zeer waardevol nadat een gemodde DLT cleaningtape vast kwam te zitten in de drive.

De vreugde was echter van korte duur aangezien de drive na het verwijderen van de cleaning tape niet meer functioneerde.