www.flickr.com

maandag 31 augustus 2009

Herstellen resource pools door middel van SQL server en PowerCLI

Ooit per ongeluk DRS uitgezet op een VMware cluster? Onlangs gebeurde dit bij mijn huidige opdrachtgever en als gevolg van deze actie waren alle resource pools verdwenen. Gelukkig waren er maar 20 pools en konden we deze met de hand weer aanmaken, echter de toewijzing van virtuele machines (> 200) aan deze pools was wel een uitdaging.

Gelukkig werd er van de vCenter database regelmatig een backup gemaakt, dus de informatie was beschikbaar. Hoe deze te herstellen was wel een uitdaging. Deze procedure omschrijft de stappen die we hebben uitgevoerd om weer tot de originele configuratie te komen.

  1. Herstellen vCenter database

    Localiseer de backup die je eerder maakte en voer een restore uit onder een andere naam dan de originele database. Zo kunnen beide databases naast elkaar draaien.
  2. Haal de lijst van resource pools uit de VPX_ENTITY tabel

    Voer de volgende query uit om een lijst van resource pools uit de herstelde database te halen:
    select * from VPX_ENTITY (nolock)
    where TYPE_ID = 4
    and name != 'Resources'

    Controleer de output en exporteer deze lijst vervolgens door middel van een export wizard naar een CSV bestand.
  3. Aanmaken resource pools

    Het aanmaken van resource pools gaat het eenvoudigst door het eerder gemaakte CSV bestand te importeren in PowerCLI met het Import-CSV CMDlet. Gebruik hiervoor de volgende code:
    Import-Csv –Path FileName | foreach {
    New-Resourcepool -Location (Get-ResourcePool -Location ( Get-Cluster ClusterName ) -Name Resources) -Name $_.ColumnName
    }

  4. Ophalen resource pool configuratie

    Naast de namen is het ook wenselijk om reserveringen, shares en dergelijke te configureren. Deze waarden zijn niet in aparte kolommen opgeslagen, maar samengevoegd in een XML bericht in de kolom CONFIG_SPEC. Haal deze informatie op met de volgende query:
    select ID.NAME, RP.CONFIG_SPEC
    from VPX_RESOURCE_POOL RP (nolock)
    join VPX_ENTITY ID (nolock)
    on RP.ID = ID.ID
    where ID.TYPE_ID = 4
    and ID.NAME != 'Resources'
    order by ID.NAME

    In mijn situatie was het minder werk om deze informatie handmatig over te nemen in plaats van de XML berichten te parsen. Voor complexere omgevingen is het handiger om dit te automatiseren. Dit zou vanaf SQL 2005 met XQuery moeten kunnen, maar hier heb ik helaas nog niet mee gewerkt. :-(
  5. Lijst virtuele machines en resource pools maken

    Om te zorgen dat alle virtuele machines weer in hun oorspronkelijke resource pool worden geplaatst moet de relatie tussen VMs en resource pools worden opgehaald uit de database. Gebruik hiervoor de volgende query:
    select ID2.NAME AS VM_NAME, ID1.NAME AS RP_NAME
    from VPX_VM VM (nolock)
    join VPX_ENTITY ID1 (nolock)
    on ID1.ID = VM.RESOURCE_GROUP_ID
    join VPX_ENTITY ID2 (nolock)
    on ID2.ID = VM.ID
    order by ID2.NAME

    Controleer de output en exporteer deze lijst vervolgens door middel van een export wizard naar een CSV bestand.
  6. Virtuele machines verplaatsen

    Het eerder gemaakte CSV bestand kan ten slotte gebruikt worden om alle virtuele machines in de juiste resource groups te zetten. Gebruik hiervoor de volgende powershell code:

    Import-Csv –Path FileName | foreach {
    Get-VM -Name $_.ColumnNameVM | Move-VM -Destination (Get-ResourcePool $_.ColumnNameRP) -RunAsync
    }


Voor omgevingen met namen die niet-ASCII bevatten is het misschien handiger om niet met VM namen, maar met ID's te werken. Dit omdat de gegevens in de database met een andere codering wordt opgeslagen dan in de vCenter GUI of PowerCLI.

Een ander alternatief is om de urlencode functie van System.Web .NET class te gebruiken. Zie voor meer informatie hierover de volgende link: http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/escape.mspx

vrijdag 17 juli 2009

Powershell troubleshooting

Voor het beheer van VMware gebruik ik steeds meer PowerShell en ook mijn Exchange admin collega's ontdekken de voordelen. Toch zijn bepaalde zaken weer nét even wat anders dan in een andere scripttaal. Een van die onderwerpen is troubleshooting.

Hiervoor heb ik 2 handige hulpmiddelen ontdekt, namelijk de standaard $error variabele en Start-Transcript, oftewel dit is min of meer de Powershell benadering van stderr en stdout.

De $error variabele is eigenlijk een array van errormeldingen die zich tijdens een Powershell sessie voordoen. Je kunt dus aan het eind van je script een controle doen of er iets in deze variabele staat en deze eventueel naar een bestand laten schrijven. Zie het onderstaande voorbeeldje om te zien hoe ik dit gebruik in mijn scripts:

#Print error messages - if any - to a file
if ($error.count -gt 0)
{
$error | Out-File stderr.log
}

Het Start-Transcript CMDlet is nog eenvoudiger. Gebruik dit commando aan het begin van je script en alle output van je script wordt naar een opgegeven bestand geschreven. Zet aan het eind van je script - of eerder indien gewenst - het Stop-Transcript commando en er wordt niet meer gelogd.

dinsdag 24 maart 2009

Diskruimte 'hot' uitbreiden voor een Linux VM

Onlangs reageerde ik op een artikeltje van ict-freak.nl en promootte hierin het gebruik van LVM.

Hoewel ik hier al wel het een en ander over gelezen had, had ik nog nooit in de praktijk uitgeprobeerd hoe eenvoudig (of ingewikkeld) het is om onder linux 'hot' diskruimte toe te voegen. Onder het credo 'meten is weten' heb ik hier een paar uurtjes tijd in gestoken om me in de mogelijkheden te verdiepen.

Ik begon een virtuele machine in te richten met Ubuntu server. Deze virtuele machine kreeg een enkele disk met een enkele volume group die - afgezien van een kleine ext3 partitie voor het /boot mountpoint - de volledige disk in beslag nam. De eerste uitdaging is nu om een extra schijf toe te voegen en deze in gebruik te nemen zonder deze down te brengen. Hiertoe doorliep ik de volgende stappen:

  1. Extra harddisk toevoegen aan configuratie VM
  2. Rescan uitvoeren op de SCSI controller:
    echo "- - -" > /sys/class/scsi_host/host/host0/scan
  3. Aanmaken LVM partitie (type 8e) op de nieuwe harddisk met commando fdisk
  4. Initialiseren van LVM partitie met commando pvcreate.
  5. Vergroten volume group met commando vgextend.
  6. Controleren beschikbare vrije ruimte met commando vgdisplay
  7. Vergroten logical volume met commando lvextend
  8. Vergroten filesystem met commando resize2fs

Het resultaat van deze procedure was dat ik de hoeveelheid beschikbare diskruimte had vergroot zonder de virtuele machine te herstarten. Helaas was dit niet helemaal de oplossing die ik zocht want ik moest zowel een nieuwe harddisk als een nieuwe partitie toevoegen. In dat opzicht het gebruik van 'extend' onder Windows toch wat eenvoudiger.

Toen ik op een later moment wat testen uitvoerde op een ESX server kwam ik nog een andere beperking tegen. Op ESX server kun je namelijk een harddisk uitbreiden terwijl de VM blijft draaien. Op het moment dat je dit voor een Linux VM doet, zal deze de extra ruimte niet direct opmerken. Hiervoor zul je een keer moeten herstarten. Als dat gebeurd is, is het alsnog noodzakelijk om een nieuwe fysieke partitie aan te maken en deze aan de volume group toe te voegen.

Mocht dit toch zonder reboot mogelijk zijn, meld dit dan svp. als een reactie op dit artikel! Mogelijk dat dit kan door gebruik te maken van partprobe. Deze utility is beschikbaar na installatie van GNU parted.

Na deze testen moet ik helaas concluderen dat 'hot' uitbreiden van een disk voor een Linux VM niet zo eenvoudig is als voor Windows VM. Het is onder beide besturingssystemen mogelijk, maar is misschien handiger om een Linux VM offline uitbreiden en dan met bijvoorbeeld een GParted live-cd de partitie op te rekken.

Bronnen:
http://kbase.redhat.com/faq/docs/DOC-3942
http://tldp.org/HOWTO/LVM-HOWTO/commontask.html
http://distrowatch.com/weekly.php?issue=20090309

maandag 2 februari 2009

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

maandag 5 januari 2009

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