afokkema VMware, Workstation

VMware Workstation 6 beta: Bin hack


In de Beta van VMware Workstation 6 staat standaard de debug feature aan. Deze opties staat aan om zo snel fouten op te sporen. Dat dedebug feature standaard aan staat komt de performance niet ten goede. Mijn VM’s waren zo traag als je weet wel, en eigenlijk niet werkbaar meer.

Deze performance problemen kun je oplossen met de volgende work around:

  1. Rename de bin-debug map in C:\Program Files\VMware\VMware Workstation
  2. kopieër de bin map
  3. hernoem de gekopieërde bin map naar bin-debug
  4. restart de pc

De VM’s zouden nu een stuk sneller moeten werken.

Let op! deze hack wordt niet ondersteund door VMware.

bron: http://4sysops.com/

afokkema VMware

VMware ESX Management Interface in IE7


Sinds de release van Internet Explorer 7 werkt de VMware Management Interface niet meer. Dit kun je oplossen door de volgende registry key te importeren:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-vmware-console]
“Extension”=”.xvm”

Nadat je dit hebt gedaan dien je de PC opnieuw op te starten en zou alles weer als vanouds moeten werken.

bron: http://blog.stevesinchak.com/

afokkema VMware, VMware Server, Workstation

Release: VMware Converter


Nadat ik de beta naar volle tevredenheid heb getest ben ik blij dat nu de final versie is gelanceerd.

De VMware Converter is een versterking in de wereld van VMware. De Servers die welke d.m.v P2V gevirtualiseerd moeten worden, kun je nu “live” migreren naar een VM (How to: Convert a Physical Server with VMware Converter). Dit betekent een minime downtime. De oude server moet uitgezet worden waarna de nieuwe live gaat.

Hoe het process in zijn werk gaat zie je in het onderstaande schema:

De gratis variant “De Starter Edition” kun je hier downloaden: www.vmware.com.

Voor meer informatie kun je hier terecht: www.vmware.com.

Voor de verschillen tussen de Starter en Enterprise versie klik je hier: www.vmware.com

afokkema VMware

How to: enable VMotion on different CPU’s


Om te kunnen beoordelen of de CPU’s in de ESX servers compatible zijn voor VMotion en DRS kun je de applicatie VMotion info gebruiken. Deze applicatie geschreven door Richard Garsthagen kun je hier downloaden: Run-virtual.com

Nadat je de zipfile hebt uitgepakt en de applicatie hebt geïnstalleerd start je deze op. Je logt in op de VirtualCenter 2 webport. In mijn geval was dit 4433 omdat ik op de VC server ook nog gebruik maak van een andere webserver met ssl.

Nadat je bent ingelogt krijg je de onderstaande informatie te zien:

vmotioninfo1.GIF

Zoals je kunt zien bij Unsupported Relaxations zijn er verschillen tussen mijn beide CPU’s. Dit houd in dat ik nu geen gebruik kan maken van VMotion en DRS. Zodra ik de Migrate job start krijg ik de volgende error:

vmotionerror.gif

De eerste foutmelding wordt veroorzaakt omdat ik mijn vmotion port nog niet op een gigabit gepatched had en de tweede foutmelding komt omdat mijn CPU’s niet compatible zijn zoals eerder gezien in de VMotion Info applicatie.

Mocht het nou zo zijn dat je in een migratie traject zit waarin je verschillende type servers en processoren hebt kun je de volgende workaround gebruiken om toch even de VM’s te VMotionen naar een andere server zodat je de huidige server kan migreren naar ESX3.

Deze manier van werken WORDT NIET ONDERSTEUND door VMware.

Open het C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg bestand op je VC2 server.

Voeg de onderstaande regels toe:

Onderaan het bestand boven de </config>

<migrate>
<test>
<CpuCompatible>false</CpuCompatible>
</test>
</migrate>

Sla het bestand op en herstart de VirtualCenter Service. Hierna kun je gebruik maken van VMotionen en DRS.

Deze oplossing wordt niet officieel ondersteund en kan problemen veroorzaken bij VM’s mochten de CPU’s dusdanig verschillen.

bron: VMTN Forum post van mcallistera VMTN Forum post van Joel Baxter

afokkema VMware

Excessive growth of the vmware.log files


Hoe komt het dat er zoveel gelogt wordt?

  1. Bij elke reboot van een VM wordt er een nieuwe log bestand aangemaakt
  2. Third-party agents op Service Console (IBM Director / HP Insight Manager / Dell OpenManage)

Om het vollopen van de /home voor te blijven kun je het volgende script aanmaken:

osde.info heeft een goede how to gemaakt op het vmtn forum: http://www.vmware.com/community

Maak een nieuw script aan in de map /root genaamd vmware-log-rotate.sh met de volgende inhoud:

vmware-log-rotate.sh

#
# watch vmware.log’s growing
#

lockfile=/tmp/$0.lock
testlock=”test -f $lockfile”
mklock=”touch $lockfile”
rmlock=”rm $lockfile”

if $testlock ; then exit ; fi

$mklock

vmware-cmd -l | while read -r vm;
do
d=$(dirname “$vm”)/vmware.log
tail “$d” | cat > “$d”
done

$rmlock

Daarna maak je een cronjob aan die een keer per maand het script uitvoerd:

Eerst maak je in de /root vmware-log-rotate-cron.sh aan:

vmware-log-rotate-cron.sh

#!/bin/bash
#copy on directory /etc/crond
1 1 1 * * /root/vmware-log-rotate.sh &> /dev/null

vervolgens doe je de volgende stappen:


# cp /root/vmware-log-rotate-cron.sh /etc/cron.d/vmware-log-rotate-cron.sh
# chmod 755 vmware-log-rotate-cron.sh
# touch vmware-log-rotate-cron.sh

Vanaf nu wordt dit script elke maand uitgevoerd zodat de /home drive niet vol kan lopen.

bron: VMTN Forum post (script) VMTN Forum post (vmware.log)

afokkema Backup, VMware

How to: Restore a backup with VMBK.pl


Login in als root op het Service Console van de ESX server waar je de backup op wilt restoren.

Vervolgens ga je een mount point maken naar de VMBK share:

ESX 2.5.x

# mkdir -p /mnt/esxbackup
# mount -t smbfs -o username=$user,password=$pass //$server/$share /mnt/esxbackup

ESX 3.0.x

# mkdir -p /mnt/esxbackup
# smbmount //$server/$share /mnt/esxbackup -o username=$domain\\$user,password=$password

Nadat je de mountpoint hebt gemaakt ga je naar de directory

# cd /mnt/esxbackup

en open je de map van de VM die je wilt restoren

# cd VMNAAM

In deze map vindt je de volgende bestanden

nvram.VMNAAM
VMNAAM.vmx
VMNAAM.vmdk
VMNAAM.restore
VMNAAM-s00x.vmdk
(Dit is een COW bestand. Een COW bestand wordt met de volgende formule gemaakt vmdk grootte / 2048MB heb je een VMDK van 10GB dan krijg je 5 COW files)

Om de restore job te starten voer je het volgende commando uit:
VMNAAM# ./VMNAAM.restore

De wizard start. Voer hier de juiste waarden in.

Enter directory where backup are present [/esxbackup/SE37BMC1]:
scsi0_0] Exported disk name (split disk) [VMNAAM.vmdk]:
scsi0_0] Imported disk name (monolithic) [VMNAAM.vmdk]:
scsi0_0] VMFS Volume where import disk [LUNNAAM]:
VMDK already exist do you want overwrite [NO]: yes
Do you want create a new guest configuration [YES]: no (Wil je de VM op een andere ESX host restoren dan dien je hier YES te antwoorden zodat er een nieuw VMX bestand gemaakt word)
Do you want restore vmdk file [YES]: yes

Nadat je YES gevolgd door {enter} hebt gedaan begint het restore process

Importing disk…..
Importing disk /esxbackup/VMNAAM/VMNAAM.vmdk:
Import: 46% done.

Import: 100% done.
Importing disk terminated
VMX file already exist, do you want overwrite [NO]?
no
restore complete

Nadat het restore process klaar is kun je de VM weer gebruiken.

afokkema VMware

VMware: Operation Timed out warning when cloning a VM


Wanneer ik een “Clone” of een andereÂopdracht gaf binnen VirtualCenter 2.0.1 patchÂin mijn testlab kreeg ik de onderstaande foutmelding.

failedtoclone.gif

Op de VMTN fora kwam ik de volgende topic tegen: www.vmware.com/community hierin worden een aantal tips gegeven.

De logfiles op de ESX 3.0.x server nakijken

Log in op het Service Console met Putty of zoals ik het altijd doe als ik logfiles moet lezen met WinSCP en blader naar de volgende directory: /var/log/vmware

En lees de volgende logfiles:

/var/log/vmware/vpx/vpxa.log
/var/log/vmware/hostd.log

Als laaste kun je ook nog de volgende logfile nakijken:

/var/log/vmkernel.log

Kijken of de template nog compleet is

Volgens de post van Jairam in de VMware fora: http://www.vmware.com/community is er een bug in VI3 dat er voor zorgt dat de bovenstaande foutmelding verschijnt. De bug treed op wanneer er een bestand van de template verwijderd of corrupt is.

Een template bestaat uit de volgende bestanden:

VMNAAM.nvram
VMNAAM.vmdk
VMNAAM.vmsd
VMNAAM.vmtx
VMNAAM.vmxf
VMNAAM-flat.vmdk
vmware.log

Mocht er nou een van de bovenstaande bestanden weg of corrupt zijn dan gaat de uitrol of clone van een template mis en treed de bovengenoemde foutmelding op.

Dit kun je dan oplossen door een copy te maken van een bestand dat wel werkt bij een andere VM. Daarna dien je het volgende commando op het Service Console uit te voeren:

# /etc/init.d/mgmt-vmware restart

DNS Settings

Open de volgende configuratie bestanden om te zien of de DNS settings goed zijn:

# cat /etc/hosts
# cat /etc/resolv.conf
# cat /etc/sysconfig/network

License file nakijken

Jamin maakte een post waarin hij vertelde dat het opnieuw aanmaken en inlezen van de vmware.lic de oplossing voor zijn probleem was.

Hostname

Ik kwam erachter dat toen ik de hostname had veranderd er een aantal foutmeldingen binnen het vpxd.log bestand van VirtualCenter 2.0.1.

De melding Name Mismatch.
de logfile post ik later.

bron: http://www.vmware.com/community