afokkema Backup, Random, VMware, Windows

VMware: Redo files (Snapshots) and Active Directory


Om even een punt aan te wakkeren met betrekking tot de discussie over het virtualizeren van een Domain Controller (vanaf nu DC red.) de volgende post. Redo files / Snapshots en DC’s. Toevallig had ik gisteren de nare ervaring van een redo file die afgelopen vrijdag gecommit werd met oude data. Je raad het al de desbetreffende DC was corrupt.

Even de voorgeschiedenis over hoe dit ontstaan is.

VMBK zoals het hoort

VMBK.pl word gestart. Deze maakt een redo file aan zodat er een hot backup plaats kan vinden.

vmbkredo.gif

Nadat de backup klaar is, wordt de redo file gecommit en worden alle wijzigingen die op het moment dat de redo file actief is, samengevoegd met de data op de vmdk. De data uit de redo file krijgt voorang op de data die al op de vmdk staat.

vmbkredo1.gif

Redo file als het mis gaat

In mijn geval was de vmbk.pl job blijven hangen. Door gebrek aan tijd kon ik de log files niet nakijken en kwam ik er pas afgelopen vrijdag achter. Nadat ik de ESX server (2.5.4 patch 4) opnieuw opgestart had ging de back-up job gewoon weer aan de slag die nacht. Maar wat er volgens mij gebeurd is nadat de backup klaar was, heeft vmbk de redo file gecommit die al meer dan week oud was. Balen want het was mijn eerste DC welke alle FSMO roles had etc.

Zoals je in het volgende plaatje ziet wordt de oude redo file gecommit.

vmbkredo2.gif

En het gevolg is dat de DC corrupt raakt.

vmbkredo3.gif

EventID’s op de DC

Hier vindt je een overzicht van alle evenID’s die optraden nadat de DC corrupt raakte.

dcaftercommit.gif

dcaftercommit1.gif

dcaftercommit2.gif

dcaftercommit3.gif

dcaftercommit4.gif

Hoe deze ellende weer herstellen

Volgens KB875495 is de enige oplossing na zo’n voorval als deze het “demoten” van de DC en het daarna weer opnieuw aanmaken van de AD.

FSMO roles verplaatsen

Voordat je dit gaat doen dien je de FSMO roles te verplaatsen (informatie over FSMO roles vindt je hier: http://www.petri.co.il/ en hier: KB197132). In KB324801 lees je hoe je na kunt gaan welke FSMO roles er actief zijn op de DC die verwijderd moet worden. Nadat je bent nagegaan welke FSMO roles er actief zijn dien je deze te verplaatsen. Hier http://www.windowsdevcenter.com/ vindt je meer informatie over het plaatsen van FSMO roles.

Het kan zijn dat de DC dermate beschadigd is, dat het verplaatsen niet meer mogelijk is. In dit geval moet je de FSMO roles “seizen”. Meer informatie over hoe dit in zijn werk gaat lees je hier: http://www.petri.co.il en KB255504.

DC demoten

Nadat je de FSMO roles hebt overgezet kun je de DC demoten. Dit kun je doen via start | Run | dcpromo {enter}.

In mijn geval lukt dit niet en moest ik het volgende commando gebruiken: start | Run | dcpromo /forceremoval {enter}. meer informatie over deze actie lees je in KB332199.

Mocht je gebruik moeten maken van de /forceremoval dan dien je nadat de DC gedemote is ook de oude data van de DC uit de werkende AD te halen. Hoe dit in zijn werk gaat kun je hier lezen: http://www.petri.co.il/

AD weer installeren

Nadat de AD geschoond is en de DC welke kapot was weer een stand alone server is, moet deze weer geconfigureerd worden als DC. Dit heb ik als volgt gedaan. De DC heb ik lid gemaakt van het domain. Daarna heb ik dcpromo (start | Run | dcpromo {enter}.) uitgevoerd en geconfigureerd als additionele domain controller.

Na dit alles kwam de replicatie weer op gang en werkte alles weer naar behoren.

afokkema VMware

VMware: Patch Recall


Patch 6 (build #41630) voor ESX 2.5.4 en patch 9 (build #41618) zijn terug geroepen door VMware. Dit hebben ze gedaan omdat er nogal wat problemen waren met de vmxnet netwerk driver.

Binnenkort moet er een nieuwe patch uitkomen die de problemen definitief oplost.

Bron: http://blogs.vmware.com

afokkema Backup, Random, VMware

VMBK: Backup with different session names


De VMBK backup duurt helaas iets te lang om elke dag een een full backup te maken. Nu heb ik voor gekozen om twee backup scenario’s te gaan gebruiken.

  1. Daily: de VM’s waar de data veel veranderd. Bijvoorbeeld DC’s, fileserver en mailserver
  2. Full: Alle VM’s. Deze job draait in het weekend. Dit zijn VM’s die vrij statisch zijn.

Dit kun je als volgt configureren. Maak twee vmbk-config.conf files aan (vmbk-daily.conf en vmbk-full.conf). Maak vervolgens een lijst van VM’s die met de daily backup meegenomen moeten worden. Pas het VMX bestand aan van de VM’s door BACKUP.SESSION=daily toe te voegen. Als laatste stap maak je de cronjob aan.

Deel van de vmbk-daily.conf file. Het enige wat je veranderd is de BackupSession value, zodat alleen de VM’s met BACKUP.SESSION=daily in het vmx bestand, worden meegenomen in de backup.

Daily

Configfile VMBK:


#Version 1.01.2
#set timeout
#Timeout=60000
Timeout=180000
#minimum space required for add RedoLOG
minspaceforRedo=1024
# backup esx host configuration
backupESX=true BackupSession=”daily”
#directory where file
destination=/mnt/esxbackup/

Deel van de vmbk-full.conf file. Dit bestand is default gebleven met betrekken tot de BackupSession value.

Full

Configfile VMBK:


#Version 1.01.2
#set timeout
#Timeout=60000
Timeout=180000
#minimum space required for add RedoLOG
minspaceforRedo=1024
# backup esx host configuration
backupESX=true BackupSession=”default”
#directory where file
destination=/mnt/esxbackup/

VMX bestand

Voor de dagelijkse backup voeg je de onderstaande regel toe aan het VMX bestand:
BACKUP.SESSION=daily

Cronjob

De volgende stappen moeten worden gedaan om de cronjob aan te maken.

Open /etc/cron.d/vmbk-cron.sh en voeg de onderstaande regels toe of pas deze aan naar jouw situatie.



#!/bin/bash
#copy on directory /etc/crond and configure /usr/local/etc/vmbk-default.conf
30 23 * * 1 root /usr/local/bin/vmbk.pl -C /usr/local/bin/vmbk-daily.conf > /dev/null 2>&1
30 23 * * 2 root /usr/local/bin/vmbk.pl -C /usr/local/bin/vmbk-daily.conf > /dev/null 2>&1
30 23 * * 3 root /usr/local/bin/vmbk.pl -C /usr/local/bin/vmbk-daily.conf > /dev/null 2>&1
30 23 * * 4 root /usr/local/bin/vmbk.pl -C /usr/local/bin/vmbk-daily.conf > /dev/null 2>&1
30 23 * * 5 root /usr/local/bin/vmbk.pl -C /usr/local/bin/vmbk-daily.conf > /dev/null 2>&1
30 5 * * 0 root /usr/local/bin/vmbk.pl -C /usr/local/bin/vmbk-full.conf > /dev/null 2>&1

30 23 * * 1 staat voor Maandag om 23:00 uur wordt de backup gestart.

Door de onderstaande commando’s uit te voeren wordt de cronjob geïnstalleerd:
cp /usr/local/bin/vmbk-cron.sh /etc/cron.d/vmbk-cron.sh

chmod 755 /etc/cron.d/vmbk-cron.sh
touch /etc/cron.d/vmbk-cron.sh

Met het volgende commando herstart je de cron service:
/sbin/service crond restart

Zie deze post over het aanpassen van vmx bestanden.

afokkema VMware

VM: Cold Migration between ESX 2.5.x and ESX 3.0.x


Voor de upgrade van VMware ESX 2.5.x naar VI3 zijn er een aantal mogelijkheden voor het upgraden van de VM zijn hardware versie.

Cold Migration

In deze post behandel ik de migratie door middel van Cold Migration. De methode heeft als nadeel dat de VM uit moet staan. In de omgeving waar ik nu zit staan twee ESX servers gekoppeld aan een SAN. De ESX versie is 2.5.4 patch4. Een test server is voorzien van ESX 3.0.1. met de laatste patches. Omdat er geen HBA beschikbaar is in de test server kan ik helaas geen gebruik maken van DMotion, daarom maak ik gebruik van Cold Migration.

In het onderstaande plaatje zie je de inhoud van het VMX bestand zoals deze nu is op ESX 2.5.x.

coldmigrationesx25xtovi3_1.gif

En dan gaan we nu beginnen met het migreren. Sluit de VM af. Klik vervolgens met de rechtermuis op de VM gevolgt door Migrate. Het onderstaande scherm verschijnt.

coldmigrationesx25xtovi3_2.gif

Zoals je in de melding ziet “Migration will cause the virtual machine’s configuration to be modified, to preserve the CPU feature requirements fort its guest OS.”

Selecteer vervolgens de Resource Pool en de Datastore waar de nieuwe VM moet komen te staan.
coldmigrationesx25xtovi3_3.gif

De VM wordt gemigreerd.
coldmigrationesx25xtovi3_4.gif

Nadat dit proces klaar is zul je zien dat het VMX bestand er nu heel anders uit ziet. Zo valt bijvoorbeeld de nieuwe regel virtualHW.version = “3” op.
coldmigrationesx25xtovi3_5.gif

VMware-Tools

Na de migratie zul je zien dat de VMware-Tools niet worden bijgewerkt. Dit is nog een actie die je handmatig moet uitvoeren.

coldmigrationesx25xtovi3_6.gif

De nieuwe versie van VMware-Tools is geïnstalleerd.

coldmigrationesx25xtovi3_7a.gif

Upgrade Hardware

Na deze actie is de Hardware wel geschikt gemaakt voor ESX 3.0.x alleen is de hardware nog niet bijgwerkt naar de nieuwste versie. Dit kun je doen door de VM weer af te sluiten. Vervolgens in VirtualCenter 2.0.x de VM te selecteren, rechtermuis knop en dan upgrade hardware.

Dit is een actie die maar een kant op werkt. Na deze actie kun je VM niet meer terugplaatsen op ESX 2.5.x.

Zodra je de actie visaversa wilt gaan uitvoeren krijg je de volgende foutmelding: coldmigrationesx25xtovi3_8.gif

Vervolgens ziet het VMX bestand er zo uit:

#!/usr/bin/vmware
config.version = “8”
virtualHW.version = “4”
floppy0.present = “true”
powerType.powerOff = “default”
powerType.powerOn = “default”
powerType.suspend = “default”
powerType.reset = “default”

afokkema Random, VMware

Tool: Veeam FastSCP 2.0


De tool bevat de volgende features:

  • Multiple ESX server management from a single console
  • File management and Windows integration
  • ESX to ESX copy
  • Supports ESX 2.5.x and ESX 3.0.x

De tool belooft ons ook super hoge snelheden en dat kan hij deels waarmaken. De tool is super snel mits je een goed netwerk tot je beschikking hebt.

Zie het onderstaande plaatje als bewijs:

fastscp2.gif

Download de tool hier: http://www.veeam.com/

bron: http://www.veeam.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

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.