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.
donderdag 28 augustus 2008
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:
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.
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:\TempHet 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:
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.
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.
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.
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:
Het tweede commando zorgt dat de password policy wordt gewijzigd zodat er voor nieuwe gebruikers geen aging meer wordt toegepast:
Het eerste commando past de aging aan van een enkele gebruiker:
passwd -x -1 -w 7 -n 0 gebruikersnaamHet 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.
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.
Abonneren op:
Posts (Atom)