Sysprep einer Template VM mit Windows Server 2008R2 schlägt fehl

Thursday, 23 October 2014 10:29:04 (W. Europe Daylight Time, UTC+02:00)
Während der Installation einer neuen VM kommt es in der Sysprep Phase zu folgendem Fehler:
"Die Antwortdatei [SYSPREP] konnte nicht analysiert werden..."
Diese Fehlermeldung bleibt auch nach dem Neustart der VM erhalten und die Installation scheitert.



Dieser Fehler beruht auf einer fehlerhaften Installations PID für die Windows Instanz. Das heisst der Server/ die VM wurde aus einem Template erzeugt, dass nicht aktiviert war.
Die Lösung ist also denkbar einfach:
1.Template in VM umwandeln
2. Template-VM starten
3. Windows aktivieren <-- Das ist der Punkt
4. VM wieder in ein Template verwandeln
VMware hat dazu einen Knowledgebase Artikel veröffentlicht, den findet man hier

TrendMicro DeepSecurity failed to prepare ESXi Host

Wednesday, 08 October 2014 17:33:16 (W. Europe Daylight Time, UTC+02:00)
Unter bestimmten Umständen kann es vorkommen, dass die Installation (Prepare) der ESXi Filtertreiber für TrendMicro DeepSecurity nicht erfolgreich abgeschlossen werden.

Der Fehler ist dann in etwa: "The installation transaction failed".Bei diesem Fehlerbild kann der ESXi Filtertrieber manuell auf den ESXi Server ausgebracht werden, dazu ist zunächst der SSH Zugang auf den ESXi Host zu gewähren und der Filtertreiber von TrendMicro auf eine angebundenes VMFS/NFS Repository zu kopieren. Im Anschluss daran wird dann der Filtertreiber über die Kommandozeile manuell installiert und die Installation kontrolliert:

esxi55 ~root# esxcli software vib install -d --maintenance-mode /vmfs/volumes/nfs_export/FilterDriver-ESX-5.0-9.5.2-1933.x86-64.zip

esxi55 ~root# esxcli software vib list

esxi55 ~root# vmkload_mod -l l grep dvfilter

Nachdem der Filtertreiber erfolgreich installaiert worden ist, muss noch überprüft werden, ob auf dem vSwitch für die vShield/vCN&S auch die Portgruppe vmservice-trend-pg angelegt worden ist.
Ist diese nicht vorhanden kann man diese über die GUI des vSphere (Web-)Client auf dem vSwitch als Standard Virtual Machine Network mit dem oben genannten Label ausbringen.

!!!WICHTIG!!! Dieser vSwitch hat keine physischen Uplink Ports gebunden und es existiert eine VMkernel Portgroup auf demselben vSwitch mit der APIPA IP-Adresse 169.254.1.1


  • Die Filtertreiber von TrendMicro findet man direkt hier



  • Eine Anleitung von TrendMicro gibt es hier



  • Eine Anleitung von VMware zur Umgehung des Bugs gibt es hier


Nach dem erforderlichen Systemreboot taucht der ESXi Host dann im DeepSecurity Manager (DSM) als prepared mit einem grünen Symbol auf und die DSVA kann über den DSM ausgebracht werden.

VMware vSphere Replication

Tuesday, 09 April 2013 13:38:35 (W. Europe Daylight Time, UTC+02:00)
Mit Vmware vSphere 5.1 wurde für alle Anwender der Standard Suites die neue Funktion Replication integriert. Diese Funktion wird ebenfalls von der kostenpflichtigen Erweiterung VMware SRM genutzt. Die Replikation funktioniert in dieser Version 1.0 nur Single-Site für eine VM. Sprich eine VM kann nur auf EINE weitere Site repliziert werden. Generell können aber unter vSphere mehrere remote Sites zur Replikation hinterlegt werden.

VMware vSphere Replication ist die erste Funktion / Anwendung, die man nur noch exklusiv über den vSphere WebClient konfigurieren und überwachen kann.
Daher, wer immer noch NUR mit dem vSphere Client arbeitet, umsteigen bitte, letzte Haltestelle vSphere 5.1 :-)



Teil 1 Einrichtung der Replizierung

Eine VM wird im vSphere WebClient über das Kontextmenü der rechten Maustaste ausgewählt und im Anschluss werden über den Assistenten die notwendigen Parameter, wie etwa die Zieldatenspeicherkonfiguration und die RPO Zeit hinterlegt.
Im Anschluss startet VMware automatisch mit der ersten vollständigen Replizierung der VM Daten. In der Version 1.0 kann man dabei leider nicht den Status abfragen - über die GUI... .





Teil 2 Überwachung der Replizierung

Die Überwachung der Replizierung läuft am besten über die Konsole des ESXi. In diesem Fall nutze ich den Zugriff über SSH:

~ # vim-cmd vmsvc/getallvms | grep view*
1      view1    [VM-HP-05] view1/view1.vmx     windows7Server64Guest   vmx-09    Testsystem Replication

~ # vim-cmd hbrsvc/vmreplica.queryReplicationState 1
Querying VM running replication state:
Current replication state:
        State: syncing
        Progress: 76% (checksum: 75161927680/75161927680; transfer: 27757535232/58507157504)

~ # vim-cmd hbrsvc/vmreplica.getState 1
Retrieve VM running replication state:
        The VM is configured for replication. Current replication state: Group: GID-a1ed9d80-4815-4528-8bf0-cc339a658b6b (generation=197268542349588)
        Group State: full sync (77% done: checksummed 70 GB of 70 GB, transferred 25.9 GB of 54.5 GB)
                DiskID RDID-9bcf4349-d81f-4530-87ab-0efd952d4f6a State: full sync (checksummed 50 GB of 50 GB, transferred 11.9 GB of 34.7 GB)
                DiskID RDID-b67702bf-b7a8-4ed9-b3f2-96e806d82349 State: full sync (checksummed 20 GB of 20 GB, transferred 13.9 GB of 19.8 GB)

~ #

VMware vCenter Certificate Automation Tool ist verfügbar

Monday, 08 April 2013 10:33:38 (W. Europe Daylight Time, UTC+02:00)
Seit langem existierte ein internen Werkzeug zum erstellen und Einbinden von CA SSL-Zertifikaten für den Einsatz unter VMware.
Leider war das Werkzeug nicht öffentlich verfügbar oder einfach schwer versteckt für die Öffentlichkeit.
Mit der Einführung von VMware vSphere 5.1 wurde die SSL Implemntierung zu einer wahren Odysee und so habe ich in vielen Projekten sehr viel länger mit der Implementierung gebraucht, als vorgesehen und gedacht (trotz Puffer ;-) ).



Das Werkzeug steht jetzt offiziell in der Download Seite bereit unter:
http://vmware.us2.list-manage2.com/track/click?u=6a06ad2174e3a4b4095b5f746&id=d65ec5760a&e=d3a2611a8d
Und trägt den Namen vCenter Certificate Automation Tool. Ob das Ganze auch sauber in den Appliances funktioniert muss sich zeigen.
Manuell ließen sich die Zertifikate dank einiger neuerer KB Artikel erstellen, allerdings gab / gibt es mit der SSL Implementierung auf der Appliance noch so manche Nuss zu knacken.
Das neue Werkzeug wird in der KB von VMware auch beschrieben unter:
http://kb.vmware.com/kb/2041600

Ich werde es in der nächsten Zeit auf Herz und Nieren testen :-D

How to: VMware Converter 5 Konvertierungsfehler

Friday, 16 November 2012 11:00:50 (W. Europe Standard Time, UTC+01:00)
Die Migration von virtuellen Maschinen über den Converter 5 schlägt fehl, wenn man die Version 5.0 verwendet wird und VMware vSphere 5.1 eingesetzt wird.
Man kann mittels VMware Converter Standalone laufende VMs konvertieren um eine "online" Sicherung des Systems an einem anderen Ort zu haben. Dazu muss man eigentlich nur im Converter Assistent die VM ale eingeschaltete physische Maschine mit DNS Name und Berechtigungskonto übergeben. Der Agent wird dann remote installiert und die betroffene VM kann online repliziert werden.
Leider klappt das nach dem Upgrade auf Version 5.1.0a von VMware vSphere mit dem Converter Standalone 5.0 nicht mehr, da hier der Converter Agent ständig unerwatet mit einem Dump abbricht!




Der Agenten Dienst wird innerhalb von Windows als beendet markiert. In den Anwendungs-Log-Dateien findet sich regelmäßig beim Versuch eine Konvertierung zu initiieren der Hinweis auf einen Dump der Anwendung unter:
Windows XP - Windows Server 2003R2: C:\Documents and Settings\All Users\ApplicationData\VMware\VMware vCenter Converter Standalone Agent\logs
Windows 7 - Windows Server 2008R2:   C:\Users\ApplicationData\VMware\VMware vCenter Converter Standalone Agent\logs



2012-11-20T10:46:09.348+01:00 [07852 info 'Ufa'] Plugin started
2012-11-20T10:46:09.348+01:00 [07852 info 'Default'] [,0] DiskLibProvider init - OK
2012-11-20T10:46:09.348+01:00 [07852 info 'Default'] [,0] Mntapi_Init Asked - 1.0 Served - 1.0 was successful,TempDirectory: C:\TEMP\vmware-temp\vmware-SYSTEM.
2012-11-20T10:46:09.348+01:00 [07852 info 'Default'] [serviceWin32,413] vmware-converter-agent service started
2012-11-20T10:46:19.879+01:00 [12192 info 'Default'] Impersonating user ssd\drysch.uwe in session 52248beb-7095-2c4f-538b-377506cd9809
2012-11-20T10:46:19.925+01:00 [12192 info 'Default'] Could not find the session object cache, will create a new one
2012-11-20T10:46:20.129+01:00 [12192 info 'Default'] CoreDump: Writing minidump
2012-11-20T10:46:20.332+01:00 [12192 panic 'Default']
-->
--> Panic: Win32 exception: Access Violation (0xc0000005)
-->    Read (0) at address 00000000
-->    rip: 7855734d rsp: 0643f67c rbp: 0643f67c
-->    rax: 00000000 rbx: 00000000 rcx: 0643f738
-->    rdx: 00000000 rdi: 029a07e8 rsi: 0643f738
-->

Die Lösung: Upgrade des Converter auf den Maintenance Release 5.0.1 VMware Converter (25.10.2012)

http://kb.vmware.com/kb/2033315

https://my.vmware.com/group/vmware/evalcenter?p=converter




Nach der Neuinstallation und dem Upgrade auf die Version steht der Converter - wie gewohnt - wieder zur Verfügung.

How To: VMs auf einem ESXi Server manuell mounten/starten

Thursday, 15 November 2012 17:31:03 (W. Europe Standard Time, UTC+01:00)
Heute hatten wir einen Stromausfall im RZ, da leider die USV defekt gegangen ist. Neben dem normalen Ärger hatten wir dann noch das Problem, dass zunächst nur ein partieller Neustart der VMs durchgeführt werden sollte, dazu mussten die DCs auf einem dedizierten ESXi Knoten gestartet werden. Über die GUI (VMware vSphere Client) kann man sich einen Wolf suchen, wenn man aus über 40 Volumes eine bestimmte VM (*.VMX) sucht...

Also per SSH auf die Konsole und dann die VM mounten und starten:

~# find /vmfs/volumes/ -iname my-vm
~# vim-cmd solo/registervm /vmfs/volumes/4e087d42-17d5a77b-e9c4-14feb53c0a92/my-vm/my-vm.vmx
~# vim-cmd vmsvc/getallvms | grep my-vm

2832   my-vm    [V-ESX010] my-vm/my-vm.vmx  winNetStandardGuest       vmx-04    Domain Controller for .EU                                                    
~# vim-cmd vmsvc/power.getstate 2832
Retrieved runtime info
Powered off
~# vim-cmd vmsvc/power.on 2832
Retrieved runtime info
Powered on


Mehr Infos zu dem Thema in der VMware Knowledgebase:

http://kb.vmware.com/kb/1038043
http://kb.vmware.com/kb/1006160

Das Ganze geht auch per PowerCLI, dazu an dieser Stelle demnächst mehr [wenn hier wieder alles läuft];-)

Umstellen der MPIO Regeln für alle LUNs eines Clusters

Wednesday, 14 November 2012 11:49:06 (W. Europe Standard Time, UTC+01:00)
Unter Vmware vSphere gibt es seit der Version vSphere 4 einige neue Möglichkeiten zum Einbinden von LUNs für die Benutzung als VMFS Laufwerke.
Leider passt manchmal die eingebaute Variante der Path Selection Policy (PSP) nicht zum aktuellen Storage und dessen Konfiguration. Für die meisten älteren Systeme gab es da eh nur die Varianten VMW_PSP_FIXED_AP oder MostRecentlyUsed so dass im Zweifel eventuell der I/O Traffic von mehreren LUNs über einen Pfad abgewickelt wurde und dieser dann zum Flaschenhals wurde.

Heute können die meisten Systeme entweder vollständig active/active oder zumindest im ALUA Modus betrieben werden. Dadurch kann man erzilen, dass die LUN I/O leistung weiter Richtung konfigurierbares Maximum wächst. Die korrespondierende PSP für diesen Fall wäre Fixed (VMware) oder Round Robin (VMware). Die Umsetzung der PSP Regeln kann über die Shell des ESXi Servers oder den vSphere Client (ab Version 5.0 auch über den Web Client) erfolgen. Zusätzlich zu diesen GUI oder lokalen Möglichkeiten gibt es auch die Powershell, damit kann man diese Aufgaben einfach, schnell und reproduzierbar auf alle ESXi Server eines Clusters übertragen. Hat man in etwa mehr als fünf LUNs und mehr als drei Hosts, dann sollte man auf jeden Fall dem Skript den Vorzug geben, da die manuelle Interaktion zu fehleranfällig ist! Das Verfahren sollte man auch immer anwenden, wenn man neue LUNs in einem existierenden Cluster veröffentlichen!

Der Befehl unter Powershell sieht dann in etw so aus:
Zunächst verbindet man sich am besten zum vCenter Server mit einem administrativen Konto (VMware):
PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer vcenter.domain.suffix
Name                           Port  User
----                           ----  ----
vcenter.domain.suffix          443   DOMAIN\carsten

Jetzt listet man alle LUNs im Cluster auf, die eine Disk beschreiben, damit wir nicht noch die CD-/DVD-ROm Laufwerke der Hosts und die lokalen Platten(falls vorhanden) erwischen:

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Get-Cluster CL001 | Get-VMHost | Get-S
CSILun -LunType disk
CanonicalN ConsoleDeviceName              LunType         CapacityGB MultipathPolicy
ame
---------- -----------------              -------         ---------- ---------------
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 Fixed<--- Ist zu ändern!!!
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 Fixed <--- Ist zu ändern!!!
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 Fixed <--- Ist zu ändern!!!
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin

<<< Das ist nur ein Auszug aus der vollständigen Liste aller LUNs >>>

Mit fixed ist die neue LUN im Cluster noch im falschen Modus angesprochen. Diese PSP soll auf Round Robin (VMware) geändert werdenNachdem man jetzt den NAA String exzerptiert hat und damit alle beroffenen LUNS herausfiltern kann, kann in einem zweiten Step die Policy für alle Volumes im gesamten Cluster gesetzt werden:

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Get-Cluster CL001 | Get-VMHost | Get-S
CSILun -CanonicalName "naa.60a*" | Set-ScsiLUN -MultipathPolicy "roundrobin"
CanonicalN ConsoleDeviceName              LunType         CapacityGB MultipathPolicy
ame
---------- -----------------              -------         ---------- ---------------
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
<<< Das ist nur ein Auszug aus der vollständigen Liste aller LUNs >>>

Danach kann man das Ganze auf ein zweites Cluster erweitern, für das die LUN sichtbar sein soll. Die NAA IDs sind ja immer identisch auf allen Hosts.

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI> Get-Cluster CL002 | Get-VMHost | Get-S
CSILun -CanonicalName "naa.60a*" | Set-ScsiLUN -MultipathPolicy "roundrobin"
CanonicalN ConsoleDeviceName              LunType         CapacityGB MultipathPolicy
ame
---------- -----------------              -------         ---------- ---------------
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk               850,083 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.536,140 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin
naa.60a... /vmfs/devices/disks/naa.60a... disk             1.024,017 RoundRobin

<<< Das ist nur ein Auszug aus der vollständigen Liste aller LUNs >>>

PowerCLI C:\Programme\VMware\Infrastructure\vSphere PowerCLI>
Viel Erfolg!

VMware SSO 5.1.0a Update - Achtung!!!

Friday, 26 October 2012 10:58:38 (W. Europe Daylight Time, UTC+02:00)


Wer bisher bereits auf vSphere 5.1 setzen wollte kam um eine neue zentrale Komponente nicht herum,
den neuen VMware SSO Server. Dieses Produkt wurde entwickelt um MUlti-Tenant Umgebung an das vCenter zu binden,
da man ja den Windows Rechner nur in einen Forrest hängen kann :-D

Mit dem schnellen Release von Version 5.1.0a der Software muss zwingend das Update über die CMD gemacht werden, sonst kann es auf nicht englischen Windows Instanzen zu einem Problem, Abbruch der Installation kommen!

VMware hat dazu einen Knowledgebase Artikel bereitgestellt unter:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2037976




Der Update Prozess bleibt für den Anwender so lange unsichtbar, wie er ihn nicht mit einem Logfile Viewer beobachtet. Das geht hervorragend unter Windows mit der Freeware / Shareware mTAIL, die man auch mit mehreren Log-Files parallel füttern kann. mTAIL kann man hier herunterladen:
http://ophilipp.free.fr/op_tail.htm

Also keine Angst wenn der Cursor nach dem Abwurf der Befehlszeile direkt umspringt!

SQL Express Datenbank wächst auf über 4GB an!

Thursday, 25 March 2010 17:05:12 (W. Europe Standard Time, UTC+01:00)
In einem Projekt mit einem vCenter System und nur insgesamt vier ESX Servern hatten wir uns für die kostenfreie Variante des SQL Servers SQL 2008 Express Edition entschieden, da die gesamte zu erwartende Datenbankgröße vom vCenter auf unter 3,0GB angegeben wurde. Leider wuchs die SQL Datenbank schneller als berechnet und erwartet, so dass der vCenter Dienst nicht mehr startbar war und ein Purgen von Tasks und Events über das vCenter System selber nicht mehr möglich war.
Das Dilemma, eine Komprimierung der SQL Datenbank führte zwar zu dem gewünschten Ergebnis (DB < 2GB) aber die Express Variante startet keine komprimierten SQL DBs! Eine Einschränkung, die mir auch neu war. Daher half nur Folgendes:
  1. Neue Windows VM anlegen
  2. Testvariante SQL Server 2008 EE kostenfrei bei MS herunterladen
  3. SQL Server installieren
  4. VMDKs mit der SQL DB, TransAktLogs und Backup an den temporären SQL mounten
  5. SQL Benutzer und -berechtigungen anlegen
  6. VCDB_table_cleanup_MSSQL.sql Skript anpassen und ausführen
  7. VMDKs wieder zurückmounten
  8. DB starten, vCenter Dienst starten!

Das Skript beinhaltet einen konfigurierbaren Teil:
/*
    VCDB_table_cleanup_MSSQL.sql,v 3.0 2009/08/31

    This script will delete data from designated tables in the VirtualCenter DB
    for 2.0.x , 2.5.x and vc4.0 versions.

    You are strongly advised to shut down the VirtualCenter server and make
    a complete backup of your database before running this script.

    VirtualCenter Server must be stopped while this script is running.

    Please see USER CONFIGURABLE PARAMETERS section below for options.

    In particular, you must set @DELETE_DATA = 1 in order to actually delete rows;
    this is a safety precaution.

    Directions: open this file with one of the following and execute:
        SQL Query Analyzer (SQL Server 2000) or
        SQL Server Management Studio (SQL Server 2005)
        SQL Server Management Studio (SQL Server 2008)

    Connect using the same DB login that VirtualCenter uses.

    The transaction log may fill up during this procedure if sufficient space
    is not available.  Monitor the transaction log size and usage with this command:

    dbcc sqlperf (logspace)

*/


IF OBJECT_ID('tempdb..#CLEANUP_VCDB') IS NOT NULL
    DROP TABLE #CLEANUP_VCDB
GO

SET NOCOUNT ON

DECLARE @VCUSER NVARCHAR(60)
DECLARE @VCUSERID INT
DECLARE @BATCH_SIZE INT
DECLARE @CUTOFF_DATE SMALLDATETIME
DECLARE @CUTOFF_DATE_S NVARCHAR(60)
DECLARE @DELETE_DATA BIT
DECLARE @CNT INT
DECLARE @TOT INT
DECLARE @SQL NVARCHAR(900)
DECLARE @FROM_VAL NVARCHAR(60)
DECLARE @WHERE_VAL NVARCHAR(900)


-- ######### USER CONFIGURABLE PARAMETERS ########################
-- 0 = COUNT ONLY; 1 = DELETE ROWS
SET @DELETE_DATA = 0

-- Use one of these methods to specifiy the data cutoff date
SET @CUTOFF_DATE = GETUTCDATE()-180
--SET @CUTOFF_DATE = '2007/01/01'

-- Number of rows to delete per transaction
SET @BATCH_SIZE = 10000


-- ######### END USER CONFIGURABLE PARAMETERS ####################
...
In diesem Fall dürfen es auch ein paar Nullen am Ende mehr sein, je nachdem wie viele Zeilen in dieser tabelle enthalten sind. Ferner ist die Variable zum Löschen auf den Wert "1" zu setzen.
Das Skript ruft man besten über die SQL Management Studio Anwendung auf. Da die Änderungen zunächst in den Transaktions-Logs abgelegt werden, sollte auf den entsprchenden VMDKs genügend (> 5GB) Speicherplatz zur Verfügung stehen.
Der Vorgang dauert allerdings ja nach Rechenleistung bis zu mehreren Stunden! Das muss man schon berücksichtigen, da das vCenter für diese Zeit nicht zur Verfügung steht.
Das Skript kann ich gerne per E-Mail weiterleiten, der Link auf der VMware Website ist leider verschwunden... .

VMware VCB ist tot, es lebe VADP

Thursday, 25 February 2010 11:37:34 (W. Europe Standard Time, UTC+01:00)
Die Nachricht ist nicht verwunderlich sondern eher ein großer Schritt hin zu einer neuen Technologie, die es dem Kunden erlaubt endlich flexibel innerhalb der Virtualisierungslösungen von VMware eine schnelle und effiziente Datensicherung und vor allen Dingen eine belastbare Wiederherstellung zu organisieren. Das versteht VMware unter dem VADP. Im Gegensatz zum VCB Ansatz benötigt der Kunde keinen dedizierten Proxy-Server mehr, allerdings handelt es sich bei dem "Produkt" lediglich um eine API, das heisst: Hier muss man selber Hand anlegen und coden, oder eben ein fertiges Produkt erwerben, wie etwa VMware DataRecovery, dass bereits dieses API seit dem Launch von VMware vSphere 4.0 vom 21.Juni 2009 nutzt.
Was aber bedeutet das für bestehende Kunden?

Zum einen benötigt der Kunde mit der kommenden Version 4.5 von VMware vSphere ab Sommer eine neue Version der verwendeten Datensicherungssoftware. Ferner ändern sich die Wege, wie denn die Datensicherung in der Virtualisierung durchzuführen ist. Spannende Themen sind hier der direkte Zugriff des Backup-Servers auf den Inhalt von vmfs Daten und dann direkter Zugriff auf einzelne Dateien innerhalb einer VMDK auf vmfs Dateisystemen. Da VMware zusammen mit den Storage / SCSI Anbietern eine Ergänzung zum SCSI Protokoll vereinbart hat ud eine SCSI-3 Implementierung noch nicht realisiert worden ist ergeben sich auch genau für den Anwendungsfall Datensicherung in der Virtualisierung Herausforderungen für den Massenspeicher, egal ob FC, FCoE, oder iSCSI. NFS glänzt hier mit seinen Fähigkeiten alles ohne "SAN" zu realisieren.



Anbei ein Auszug aus der VMware E-Mail:
Dear Valued Customer,

The purpose of this letter is to inform you of our vSphere backup
product strategy, ongoing enhancements, and end of availability plans
for VMware Consolidated Backup.

VMware Backup Product Strategy
VMware released vStorage APIs for Data Protection
<http://app.connect.vmware.com/e/er.aspx?s=524&lid=9503&elq=d3f96cc3a8af4a128080c3b505572f1d>
(VADP) with the vSphere 4.0 release in May, 2009. VADP is the next
generation of VMware’s backup framework. We have also been working with
several backup partners to integrate VADP into their solutions to make
backup of vSphere Virtual Machines fast, efficient and easy to deploy
compared to VCB and other backup solutions. Several of our major backup
partners have already released VADP integrated backup products and we
expect most of the major backup partners to have VADP integrated backup
software by the upcoming feature release of the vSphere platform in 2010.

Future Product Licensing
Given the strong interest and adoption of VADP by our backup eco-system
and the benefits offered by VADP compared to VMware Consolidated Backup
(VCB), we are announcing the End of Availability for VCB starting with
next vSphere feature release in 2010. Starting with the next vSphere
platform feature release, VCB will be removed from vSphere platform.
VADP integrated backup products (including VMware Data Recovery) will be
the recommended option for efficient backup and restoration of vSphere
Virtual Machines. This will allow us to focus new value added feature
development on VADP instead of two backup frameworks (VCB and VADP). You
can find more information about the use of vStorage APIs for Data
Protection in our Developer Community
<http://app.connect.vmware.com/e/er.aspx?s=524&lid=9504&elq=d3f96cc3a8af4a128080c3b505572f1d>.
For information on the availability of VADP integrated release of your
backup product please contact your backup vendor.

End of Availability
With the release of the next vSphere platform, we will continue to
provide the binaries for VCB, but they will not be compatible with the
next platform release. We will continue to provide support for VCB on
the current vSphere platform per the VMware support policy
<http://app.connect.vmware.com/e/er.aspx?s=524&lid=9505&elq=d3f96cc3a8af4a128080c3b505572f1d>.

If you need assistance in the migration from VMware Consolidated Backup
to the vStorage APIs for Data Protection, please contact your local
reseller
<http://app.connect.vmware.com/e/er.aspx?s=524&lid=9506&elq=d3f96cc3a8af4a128080c3b505572f1d>
or storage backup vendor.

Best regards,
VMware Product Management

vMotion Fehler unter vSphere 4.0

Thursday, 29 October 2009 09:43:49 (W. Europe Standard Time, UTC+01:00)
Gestern hatte ich zum ersten Mal ein Problem mit der vMotion Funktion in VMware, die ich mir technisch nicht erklären konnte:
Eine VM soll von einem Host auf einen anderen migriert werden. Die Pre-Tests, die VMware selber vor der Initialisierung des vMotion Prozesses durchführt, wurden alle mit "Validation succeded" im vSphere Client quittiert und der Prozess startete auch mit den Üblichen Meilensteinen:
  1. Validierung
  2. Start, Ruhigstellen (Dump von VM RAM und Kernelzustand) 10%
  3. Migration der Dumps zwischen den ESX Hosts 78%
  4. Stop "A generel system error occured..." 80% --> "A general system error occurred: Failed to write checkpoint data (offset 33558328, size 16384): Limit exceeded"
Weder die VMware Knowledgebase [Verknüpfung zum VMware Knowledgebase Artikel hier] noch mein Projektwissen haben mich in die Lage versetzt den Fehler näher zu spezifizieren. Einzig ein Blog Eintrag hatte eine Erklärung für mich parat:
Das Zielsystem ist ein Terminalserver, der auch Graphikananwendungen hostet, daher hatten wir den Mehrschirmbetrieb - auch in der Konsole - aktiviert und zum Test den vRAM der Graphikkarte angepasst auf 32MB.
Genau darin liegt der Fehler begründet, egal wieviel RAM man vergeben kann für den vRAM unter ESX 4.0, vMotion ist nur in der Lage maximal 30MB vRAM zu migrieren. vRAM Größe auf 16MB reduziert und vMotion funktioniert wieder, wie erwartet und bekannt.

Virtueller vCenter Server

Monday, 19 October 2009 12:43:55 (W. Europe Daylight Time, UTC+02:00)
Nachdem es in der Vergangenheit bei der Einführung von VI 3.0 lange offen war, ob tatsächlich das vCenter System als eine VM innerhalb der Virtualisierungslösung laufen kann und das ganze auch noch unterstützt wird, ist das Ganze heute gängige Praxis! Für alle Kundenumgebungen ohne spezielle Anforderungen im Bereich der zentralen Verwaltungssysteme kann ich diese "platzsparende" Option nur empfehlen.
Man muss sich zwar im Klaren darüber sein, dass man im Falle eines Ausfalls des vCenter Systems (inklusive SQL Server, AD, DNS, und UpdateManager) nu eine alternierende Methode für die Wiedererstellung oder den Wiederanlauf benötigt, sonst nichts! :-D

Duncan Epping hat dazu in den letzten Tagen einen neuen Eintrag auf seinem Blog <http://www.yellow-bricks.com> veröffentlicht, dem ich nur beipflichten kann:Das vCenter System als VM sollte generell mit einer optimierten virtuellen Hardware (in der Version 7) betrieben werden und zusätzlich sollten eigentlich alle bekannten "Best Practices" Verwendungen finden. Anbei also die "High-Lights" aus seinem Eintrag:
  1. Das vCenter System als VM mit W2K8 x64 nutzen um die neuen Treiber für die emulierten Geräte verwenden kann.
    Nicht zu vergessen: !!! Aktuelle VMware Tools Paket installieren !!!
  2. Die Clusterfunktion DRS ist für die VM vCenter auf "Disabled" (Änderung des Automationslevels / Change Automation Level) zu setzen. Halten Sie zusätzlich fest auf welchem Host das vCenter eingebunden ist!
  3. Die Clusterfunktion HA sollte für das vCenter System aktiviert / enabled sein und die Neustart Priorisierung sollte auf "hoch" / high stehen (Der Standardwert im Cluster ist "Medium".
  4. Es ist sicherzustellen, dass die VM für das vCenter immer genügend freie Ressourcen zur Verfügung hat. Das kann erreicht werden, indem die "Shares" für den Arbeitsspeicher und die CPU(s) auf "Hoch" gesetzt werden.
  5. Es ist sicherzustellen, dass die abhängigen Dienste vom und zum vCenter System im Falle von HA ebenfalls mit der Neustart Priorität auf "hoch" eingerichtet worden sind und das die VMs in der richtigen Reihenfolge starten, wie:
    • Verzeichnisdienste, wie Active Directory GC
    • Nameserver
    • SQL Datenbankserver auf dem die vCenter DBs betrieben werden.
  6. Erstellen Sie eine Skriptlogik, die Sie in die Lage versetzt die abhängigen Dienste vCenter System, AD, DNS und SQL im Falle eines Wiederanlaufs (nach Stromausfall, etc.) wieder in Betrieb zu setzen und dokumentiernen Sie die einzelnen Schritte zusätzlich, denn auch Skripte können mal versagen, wenn sich Parameter oder Werte ändern.
Wie man sieht sind die generellen Regeln garnicht so schwer einzuhalten, aber leider trifft man in der Realität immer wieder auf Umgebungen, in denen die Installation und Konfiguration doch noch Raum für Verbesserungen bieten.
Für alle experimentierfreudigen Adminkollegen:
Man kann das Ganze vCenter System mit dediziertem VUM Server, vCenter Server und SQL Server auch als eigenständige vApp konfigurieren und zumindest teilweise die VMs über den VMware Fault Tolerance Modus FT gegen Hostausfälle absichern, aber dazu später mehr an dieser Stelle :-o

911 - VMware ESX/ESXi 4.0 on Engeneering Hold

Saturday, 01 August 2009 13:47:10 (W. Europe Daylight Time, UTC+02:00)
Seit dem 21. Juli verdichten sich die Gerüchte um ein großes Treiberproblem innerhalb der Standardtreiber für VMware ESX 4.0.0. :-S
Dabei handelt es sich wohl um ein Problem mit lokal eingebauten und eingebundenen Bus Adaptern zur Massenspeicheranbindung, näher um LSI und Adaptec basierte Controller für SAS, (Parallel-) SCSI und S-ATA Festplatten. Werden diese in einem Host verwendet, so kann es unter Umständen dazu kommen, dass im Falle einer Abschaltung des Servers der Cache der Adapter nicht ordnungsgemäß auf die angeschlossenen Festplatten geschrieben wird. Das führt wiederum unweigerlich zu korrupten Daten, wenn die Batterie der RAID Controller leer läuft und im Fall von lokal angeschlossenen VMFS Laufwerken auf einem Host wahrscheinlich zu Datenverlust!
Da beim ESX 4.0 Server die SC als VMDK Datei auf dem lokalen VMFS Laufwerk vorgehalten wird, sollte der Patch unverzüglich auf alle ESX 4.0.0 Systeme gleich welcher Patch- / Buildstand ausgebracht werden. Der ESXi Server ist davon zur Zeit nicht betroffen.



Der Fehler wurde von VMware bereits veröffentlicht:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012794


Gestern habe ich dazu eine sehr wichtige E-Mail über meine DELL Kanäle erhalten.
DELL geht davon aus, dass in den nächsten Tagen (03.08.) ein ausserplanmäßiges Update bereitgestellt wird, das den Fehler im Treiber behebt.
Die Tests laufen wohl schon, dauern allerdings bis zu 2 x 48h, da der RAID Controller/Cache nur alle 48h eine vollständige Entladung der Batterie erfährt.

Man sollte jetzt nicht panisch reagieren und ein Downgrade auf die Version ESX 3.5.0U4 durchführen, sondern dafür sorgen, dass die Server am (Strom-)Netz bleiben und nicht längerfristig vom Strom getrennt werden. Dazu sollte man die DPM Funktion in vSphere 4.0 temporär auf manuell setzen oder komplett abschalten. ;-)

vip-svmotion oder die Rückkehr eines Plug-Ins für VI 3.5

Thursday, 30 July 2009 18:50:00 (W. Europe Daylight Time, UTC+02:00)
Bereits vor über einem Jahr hatte der Entwickler Schley Andrew Kutz sein Plug-In veröffentlicht, mit dem Anwender ohne die sonst vorgesehene Kommandozeilenoperation, die schon sehr gewöhnungsbedürftig ist für GUI-verwöhnte Anwender.



Nachdem das Projekt mit der Version 1.0.0 dann irgendwann verschwunden war, tauchte es dann jetzt wieder bei SourceForge auf! Also für alle die Storage vMotion lieben, oder brauchen hier gehts zur Quelle: http://sourceforge.net/projects/vip-svmotion/

DELL OMSA Software Installation mit Hindernissen

Tuesday, 28 July 2009 07:41:34 (W. Europe Daylight Time, UTC+02:00)
Die neuen Pakete für DELL OMSA 6.1.0 erkennen bei einer ESX 4.0.0build164009 Basisinstallation fälschlicherweise eine bestehende OMSA 5.3.0 Installation, da der Installer die Abhängigkeiten in der RPM Datenbank abfragt.




Dazu habe ich einen Call bei DELL eröffnet und zusätzlich in den VMware Foren ein Workaround gefunden:

VMware Community vSphere 4.0 | ESX 4: http://communities.vmware.com/message/1321651#1321651
Alternativ hier als pdf Dokument: dell-omsa-6.1.0-on-esx-4.0.0-classic.pdf (71,51 KB)
Die interessante Passage habe ich mit einem gelben Textmarker markiert.

Der Installer denkt, es gäbe bereits eine alte Version von OMSA auf dem System und kommt aus dem Tritt. Abhilfe schafft hier das direkte installieren der RPM Pakete für "ESX40" und das manuelle öffnen der Firewall. ESX 3.5.0 Update 4 Systeme sind von dem Fehler nicht betroffen. Damit eine Installation des OMSA Clients auf den ESX 4.0.0build164009 reibungslos ablaufen kann muss man zuvor über folgende Befehlszeile als Administrator 'root' absetzen:

OSX-1057-XSTCGN:~ carsten$ ssh root@esx-400-xstcgn.xsteam.eu
root@esx-400-xstcgn.xsteam.eu's password:
Last login: Tue Jul 28 09:11:37 2009 from 10.2.110.121
[root@esx-400-xstcgn ~]# rpm -e --noscripts `rpm -qa | grep srvadmin`

Bei der neuen ESX 4.0.0 ISO Image Installation mit dem Build Stand: esx-DVD-4.0.0-171294.iso klappt die Installation auf Anhieb:

OSX-1057-XSTCGN:~ carsten$ ssh root@esx-400-xstcgn.xsteam.eu
root@esx-400-xstcgn.xsteam.eu's password:
Last login: Tue Jul 28 09:28:53 2009 from 10.2.110.121
[root@esx-400-xstcgn ~]# cd /tmp/
[root@esx-400-xstcgn tmp]# ls -alh
total 104M
drwxrwxrwt  5 root root  28K Jul 30 09:31 .
drwxr-xr-x 26 root root 4.0K Jun 25 12:54 ..
-rw-r--r--  1 root root 1.9K Jul 27 18:54 hostCompatList
drwxr-xr-x  2 root root 4.0K Jul 27 11:06 hsperfdata_root
drwxrwxrwt  2 root root 4.0K Jun 25 12:54 .ICE-unix
-rw-r--r--  1 root root 104M Jul 30 09:32 OM_6.1.0_ManNode_A00.tar.gz
drwxr-xr-x  3 root root 4.0K Jul 30 08:57 sfcb
[root@esx-400-xstcgn tmp]# tar -xvzf OM_6.1.0_ManNode_A00.tar.gz
[root@esx-400-xstcgn tmp]# .linux/supportscripts/srvadmin-install.sh -d -w -r -s <--- !!!Neu!!! Die Option 'd' (DELL agent) ersetzt die alte Option 'b' (base packages)

Installing the selected packages.

warning: srvadmin-cm-6.1.0-648.i386.rpm: Header V3 DSA signature: NOKEY, key ID 23b66a9d
Preparing...                ####################################### [100%]
   1:srvadmin-omilcore      ####################################### [  6%]
     To start all installed services without a reboot,
     enter the following command:  srvadmin-services.sh  start
   2:srvadmin-omcommon      ####################################### [ 12%]
   3:srvadmin-hapi          ####################################### [ 18%]
   4:srvadmin-syscheck      ####################################### [ 24%]
   5:srvadmin-deng          ####################################### [ 29%]
   6:srvadmin-omacore       ####################################### [ 35%]
   7:srvadmin-isvc          ####################################### [ 41%]
   8:srvadmin-omauth        ####################################### [ 47%]
   9:srvadmin-wsmanclient   ####################################### [ 53%]
  10:srvadmin-rac5-component####################################### [ 59%]
  11:srvadmin-jre           ####################################### [ 65%]
  12:srvadmin-cm            ####################################### [ 71%]
  13:srvadmin-iws           ####################################### [ 76%]
  14:srvadmin-omhip         ####################################### [ 82%]
  15:srvadmin-racadm5       ####################################### [ 88%]
  16:srvadmin-racdrsc5      ####################################### [ 94%]
  17:srvadmin-storage       ####################################### [100%]
[root@esx-400-xstcgn supportscripts]#
[root@esx-400-xstcgn supportscripts]# mv /vmfs/volumes/esx-400-xstcgn-local/DELL_OMSA.xml /etc/vmware/firewall/.
[root@esx-400-xstcgn supportscripts]# esxcfg-firewall -e 'DELL OpenManage Request'
[root@esx-400-xstcgn supportscripts]# service mgmt-vmware restart
Stopping VMware ESX Management services:
   VMware ESX Host Agent Watchdog                          [  OK  ]
   VMware ESX Host Agent                                   [  OK  ]
Starting VMware ESX Management services:
   VMware ESX Host Agent (background)                      [  OK  ]
   Availability report startup (background)                [  OK  ]
[root@esx-400-xstcgn supportscripts]# ./srvadmin-services.sh start
Starting Systems Management Device Drivers:
Starting dell_rbu:                                         [  OK  ]
Starting ipmi driver: Already started                      [  OK  ]
Starting snmpd:                                            [  OK  ]
Starting Systems Management Data Engine:
Starting dsm_sa_datamgr32d:                                [  OK  ]
Starting dsm_sa_eventmgr32d:                               [  OK  ]
Starting dsm_sa_snmp32d:                                   [  OK  ]
Starting DSM SA Shared Services:                           [  OK  ]
Starting DSM SA Connection Service:                        [  OK  ]
[root@esx-400-xstcgn supportscripts]#

Danach kann man wie gewohnt die lokale DELL OpenManage Installation über einen unterstützten Webbrowser aufrufen:
https://esx-400-xstcgn.xsteam.eu:1311

Das Neunundneunzig Prozent Dogma

Monday, 06 July 2009 11:24:50 (W. Europe Daylight Time, UTC+02:00)
Was es bedeuten kann, wenn man als Zuverlässigkeitskoeffizient mit den magischen Zahlen wie 99,9 Prozent von Anbietern "bombardiert" wird kann man sich hier einmal noch etwas genauer durchlesen und dann bestimmen, welche Ausfallzeit für eine Plattform, Anwendung oder Dienst akzeptabel ist, oder eben gerade nicht:

99% - Die Anwendung ist 3 Tage, 15 Stunden, 36 Minuten nicht verfügbar
99.9% - Die Anwendung ist 8 Stunden, 45 Minuten, 36 Sekunden nicht verfügbar
99.99% - Die Anwendung ist 52 Minuten und 33 Sekunden nicht verfügbar
99.999% - Die Anwendung ist 5 Minuten und 15 Sekunden nicht verfügbar
99.9999% - Die Anwendung ist 31 Sekunden nicht verfügbar

Dabei ist der Maßstab immer das Kalenderjahr!

Aus meiner Sicht sind Zahlen die eine Verfügbarkeit von mehr als 98,5% suggerieren komplett am Thema vorbei, denn wann immer auch ein Hersteller seine Verfügbarkeit als five-nine bezeichnet (99,999% Verfügbarkeit), so kann das immer nur isoliert für sein einzelnes Gerät gemessen sein. Werden also mehrere von diesen Systemen mit anderen Komponenten, Anwendungen Systemen und Verbindungsmitteln zu einer "Anwendung" verschaltet, so ergeben sich auf einmal ganz andere Verfügbarkeiten, da man die Verfügbarkeiten in Relation zueinander setzen muss um eine Verfügbarkeit zu ermitteln.

Microsoft selber gibt für zum Beispiel Exchange 2007 "In the Enterprise" eine Gesamtverfügbarkeit von maximal 98,5% an, gemessen am Client, denn Verfügbarkeit einer Anwendung kann man objektiv nur dann ermitteln, wenn man das Ganze aus Anwendersicht betrachtet, oder eben als Kunde! Denn der Anwender ruft beim Helpdesk an wenn seine Anwendung nicht funktioniert und eben nicht wenn ein SAN Switch ausgefallen ist.

Zusätzlich gebe ich zu bedenken, dass es in etwa zwölf geplante Ausfallzeitfenster im Jahr pro System gibt (Windows, VMware) oder sogar öfter (Linux Distributionen (Ja in Abhängigkeit zu den Paketen; nicht gleich hauen...), Anwendungen). Dann denken wir mal an SAN Systeme, schon mal ein Firmwareupdate auf einer SAN(-Farm) durchgeführt, man wird sehen die erwarteten Ausfallzeiten schmelzen einem dahin wie Eis in der Frühjahrssonne.

VMDK Festplattendateien Optionen unter vSphere 4.0

Friday, 12 June 2009 07:31:56 (W. Europe Daylight Time, UTC+02:00)

VMDK Dateien bilden den Standard bei der Konfiguration von VMs. Egal mit welchem Hypervisor von VMware ein Anwender eine VMDK erstellt, kann diese auch auf einem anderen Hypervisor genutzt werden. Dazu gibt es einige Einschränkungen.

Bisher konnte man nur mit den Desktop-Versionen so genannte "Thin-Provisioned" VMDKs also wachsende VMDK Dateien erstellen. Das funktioniert jetzt auch unter VMware vSphere 4.0 mit ESX 4.0. Im Prinzip konnte das der ESX Server ja schon immer, wenn man daran denkt, wie die Snapshotfunktion unter ESX funktioniert.

Was steckt aber hinter den einzelnen Optionen zum Anlegen einer neuen VMDK, insbesondere auf der Kommandozeile:

Thick:

Diese "dicken" Festplatten bezeichnen alle Formatierungsoptionen, bei denen die definierte Festplattengröße beim Anlegen der VMDK direkt auf dem Laufwerk allokiert wird.

Ist der Speicherplatz auf der LUN voll wird es nicht mehr möglich weitere VMDK Dateien zu erstellen. Eine Fragmentierung der Datendatei auf Ebene des VMFS Dateisystems ist nahezu ausgeschlossen. Nachteilig ist, dass der teure SAN-Speicherplatz direkt verloren geht.

Zerodthick:

Der Speicherplatz der VMDK wird komplett belegt beim erstellen der VMDK. Eventuell vorhandene Daten werden erst beim ersten Lesezugriff überschrieben. Dies ist der Standardmodus beim Anlegen einer VMDK. Der Vorteil ist die schnelle Bereitstellung der neuen VMDK, allerdings mit dem Nachteil, dass ein „data leaking“ möglich ist.

Eagerzeroedthick:

In diesem er wird ebenfalls der gesamte Speicherplatz direkt beim erstellen der VMDK belegt und direkt alles mit Nullen vollgeschrieben. So ist sichergestellt das keine Daten mehr vorhanden sind und auch nicht ausgelesen werden können. Das lesen solcher Daten wird auch „data leaking“ genannt, allerdings kann das Erstellen der VMDK sehr lange dauern.Diese VMDK Dateien werden auch benötigt, um etwa den FT "Fault Tolerance" Modus für eine VM zu nutzen.

Thin:
Nur der wirklich verwendete Speicherplatz wird belegt. Je nach Blockgröße wird dann bei Bedarf mehr Speicherplatz hinzugefügt. Der Speicherplatz auf dem VMFS Laufwerk wird dabei sehr effektiv genutzt, allerdings muss der Speicherplatz überwacht werden, da er plötzlich, schnell volllaufen kann. Zusätzlich benötigt man für die Vergrößerung der VMDK Datei eine SCSI Reservierung, das kann auf großen VMFS Laufwerken zu Problemen führen, da das Laufwerk für dieses Metadaten-Update "angehalten" werden muss.

Über die VMKFSTOOLS lassen sich die VMDK Dateien jederzeit in ein anderes Format klonen, über den vSphere 4.0 Client kann mit "Migrate" nicht nur der Speicherplatz der VMDK Datei verlagert werden, sondern jetzt auch der Festplattenmodus von Thin auf Thick gesetzt werden. Allerdings benötigt man dafür genügend Platz auf dem Ziellaufwerk.

vCPUs Multikern CPUs in einer VM

Monday, 25 May 2009 06:52:13 (W. Europe Daylight Time, UTC+02:00)
Seit dem es VMware Infrastructure gibt, kann man einer VM auch mehrere vCPUs präsentieren. Dabei war es bisher so, als gäbe es für die VMs keine Multi-Kern Optionen. Innerhalb der Beta Tests zu vSphere 4.0 hat dann einer der Entwickler Sean Borman einen Hinweis zur Multi-Kern Option in ESX 4.0 gegeben, der seitdem auch eingesetzt werden kann.
Diese Anforderung resultiert aus der Notwendigkeit, dass bestimmte Betriebssysteme eine harte Limitierung bei der Anzahl der unterstützten, genutzten CPUs haben. Beispielsweise kann Windows Server 2003 Standard Edition nur mit maximal 4 CPUs genutzt werden. Moderne Server haben allerdings schon mal gerne 12 bis 24 Kerne, eine VM ann davon allerdings nur vier nutzen!
Mit Hilfe der Option zur Multi-Kern Unterstützung kann man nun einer VM mit Windows Server 2003 Standard Edition acht vCPUs geben und diese über Multi-Kern auf entweder vier oder zwei Sockel zusammenschließen. Bei Anwendungen innerhalb der VM kann es zu erhöhten Kosten kommen, wenn diese per Sockel lizenziert werden muß.

So kann man diese Option nutzen:

  1. Herunterfahren / Ausschalten der VM
  2. Über das Kontextmenü der VM mit "Edit Settings" die Konfiguration der VM öffnen
  3. "Options" Karteikartenreiter auswählen
  4. Auf General unter den Advanced Options gehen
  5. Den "Configuration Parameter" auswählen
  6. Mit "Add Row" eine neue Zeile in der KOnfigurationsdatei erstellen
  7. In der Spalte "Name" folgende Option „cpuid.coresPerSocket“ hinzufügen
  8. In der Spalte "Value" einen Wert von 2, 4 oder 8 eintragen <-- !!! Achtung !!! Auch bei Hexacore Systemen kann der Wert von sechs nicht eingetragen werden !!! Achtung !!!
  9. Mit "OK" Die Änderungen an der VM Konfiguration abspeichern
  10. Starten der VM und das Betriebssystem erkennt nun zwar im Gerätemanager weiterhin zum Beispiel acht CPUs, allerdings findet man unter Systemeigenschaften nun den Eintrag, das es ein Zweisockelsystem ist mit vier Kernen.
Ob das ganze auch so von VMware unterstützt wird muss noch geklärt werden. Duncan Epping von yellowbricks.com will dazu bald ein Update bringen.

Originalthread aus dem Beta Tester Forum:

esx4-multicore.pdf (63,04 KB)

VMware HA Konfiguration und Fehlermeldungen

Saturday, 07 February 2009 11:42:17 (W. Europe Standard Time, UTC+01:00)
Hier ist er der zweite Teil zum Thema HA Konfigurationen. Immer wieder melden sich Kunden bei mir, dass die HA Konfiguration ihrer Cluster nicht konsistent funktioniert, ESX Server einen Fehler in der HA Agentenkonfiguration melden oder das HA Cluster anscheinend Warnungen ausgeben, da nicht genügend "FailOver"-Kapazitäten vorhanden sind. Im ersten Teil des Berichts bin ich näher auf die einzelnen Parameter der HA Konfiguration zu sprechen gekommen. In diesem zweiten Teil dreht sich alles rund um die Fehleranalyse und Behebung.

VMware View Client als Open Source Projekt gestartet

Friday, 06 February 2009 12:10:51 (W. Europe Standard Time, UTC+01:00)



Der VMware View Open Client ist unter der GNU Lesser Public License Version 2.1 (LGPL v 2.1) der breiten Öffentlichkeit vorgestellt worden und verfügbar über:
http://code.google.com/p/vmware-view-open-client/

Einige diese Veröffentlichung umfassende Eigenschaften sind sicheres Tunneln mit SSL, zwei Faktor-Authentifizierung mit RSA SecurID, Novell SUSE Linux Enterprise Thin Client Add-On, RPM Paketinstallation und eine volle Kommandozeilen-Schnittstelle.
Der Support für den Quellcode-Vertrieb ist durch die VMware-View Open Client Gemeinschaft verfügbar über:
http://code.google.com/p/vmware-view-open-client/

Ich teste den Client gerade unter CentOS, und werde an dieser Stelle über meine ersten Einfdrücke berichten. Neben SLETC werden Debian 4.0r3 und RHEL als Plattformen erwähnt, mal sehen wie schnell ich meine ThinClient Installation aus 2006 wieder reaktiviert bekomme, die ich damals für meine Terminalserver Projekte genutzt habe... ;-)

vMotion zwischen ESX 3.0.x und ESX 3.5.0 Servern

Tuesday, 03 February 2009 09:36:40 (W. Europe Standard Time, UTC+01:00)
In der Vergangenheit hatten einige Kunden bei der Aktualisierung der bestehenden ESX Server auf einen aktuellen Ausgabe-Stand Probleme mit der Übernahme der bestehenden virtuellen Systeme auf die aktualisierten ESX Server. Der VMotion-Prozess bricht in der Regel immer nach 10 Prozent in der Anzeige des VI-Clients mit einem unbekannten Fehler ab. So ließen sich alte Umgebungen schwer aktualisieren, da die fließende Übernahme der VMs nicht möglich war.

Einige Knowledgebase Artikel zu dem Thema und Beiträge im VMware Anwenderforum ließen offen, warum genau dieses Phänomen auftritt und vor allen Dingen, wie man das Problem umschiffen kann.

Die Lösung zu dem Problem ist dabei denkbar einfach, nur Schade, dass genau solche wichtigen Fragen in einem offiziellen Migrationshandbuch leider vom Hersteller nicht beantwortet werden.
Da der komplette VMware Kernel zwischen den Versionen 3.0 und 3.5 eine größere Überarbeitung erfuhr und die entsprechenden Komponenten und Software-Module eine Anpassung erfuhren ergeben sich prinzipiell kleinere Inkompatibilitäten zwischen den Versionen. Generell funktioniert VMotion zwischen 3.0 und 3.5 Systemen ohne Abstürze von VMs oder Datenverlust.



Durchläuft man den Assistenten für die manuelle Initiierung von VMotion, dann muss lediglich in der Priorität des Prozesses das Auswahlfeld "Low Priority / Niedrige Priorität" ausgewählt werden. Durch diese Auswahl wird erreicht, dass Ziel- und Quell-ESX-Server eine längere Time-Out Wartephase zur Erstellung des Arbeitsspeicherabbildes erhalten und der Handshake Prozess bei der Initiierung des Prozesses nicht frühzeitig terminiert.

EVC - Oder wie man vMotion über verschiedene Host CPU Typen nutzen kann

Monday, 02 February 2009 11:58:16 (W. Europe Standard Time, UTC+01:00)
EVC - Enhanced vMotion Compatibility ist eine der Funktionen die im Laufe der ESX 3.5.0 und VC 2.5.0 Pflege in das vCenter gewandert sind. Eigentlich sollte diese Funktion erst mit der Version 4, also dem großen neuen System ausgerollt werden, aber da war die Marketing Abteilung wohl vor der Technik schon unterwegs und hat den großen und ganz großen Kunden den Mund so wässrig gemacht, dass es schon jetzt integriert wurde und auch supportet wird, was nicht zwangsläufig bei VMware der Fall ist, man erinnere sich nur an das "Green IT" - Debakel mit DPM - Distributed Power Management von VMware, was im jetzigen RC für vSphere schon etwas besser funktioniert, aber dann doch nicht ganz soviel Strom spart; dazu aber später mehr.

Die EVC Einrichtung
Eigentlich eine einfach Clusterkonfiguration, die als Punkt einfach über den VI-Client aktiviert werden kann; aber in der Regel nicht läuft, da dazu alle VMs aus sein müssen. Warum? Und wie soll ich diese Funktion dann wieder einschalten, wenn mein vCenter Server auch eine VM ist?
Dieser Frage habe ich mich auch in der jüngeren Vergangenheit auch gestellt und bin auf eine interessante Lösung zu dieser Herausforderung gestoßen.
In der Regel werden zunächst die ESX Server installiert und konfiguriert und danach als erste VM das VC installiert und im Anschluss konfiguriert. Genau dann haben wir den Salat, es gibt ein Cluster und das VC läuft, jetzt kann EVC eben nicht eingeschaltet werden, daher die

Lösung auf Umwegen
Man benötigt dazu einen einzelnen Host. Dieser Host wird einem neuen Cluster zugeordnet und im Anschluss wird das Cluster konfiguriert - mit EVC!!!
Das klappt natürlich jetzt einwandfrei, da keine VM auf dem ESX Server eingeschaltet oder registriert ist. Im Anschluss fährt man das VC einfach herunter, registriert diese VM an dem neuen Host in dem neuen Cluster und startet diese VM. Dabei kann der ESX Server die fehlenden Zeilen in der VMX Datei anhängen und die EVC Funktion wird anschließend genutzt.
Ist das vCenter einmal gestartet, werden die anderen Hosts aus dem alten Cluster dem neuen Cluster zugeordnet und voila unser Cluster nutzt ab sofort für alle Hosts die EVC Konfiguration.
 

VMware vSphere - Der Release Candidate 1 ist geschlüpft

Monday, 19 January 2009 13:16:35 (W. Europe Standard Time, UTC+01:00)
Nachdem die letzten Telefonkonferenzen zur Beta 2 abgeschlossen und auch sonst keine neuen Themen in der beta Community aufgetaucht waren, haben die Entwickler wohl einen kleinen Zwischenspurt eingelegt und pünktlich zum Ende der Weihnachtsferien in den USA den ersten Release Candidate (RC 1) an die Beta-Tester verteilt. Der eigentliche Veröffentlichungstermin 16. Januar 2009 wurde von mir wegen Urlaub zwar verschlafen, dafür hatte ich dann in dieser Woche keinerlei Probleme mit überlasteten Download Servern.



Interessant ist, dass die Linux Appliance zur Verwaltung anscheinend tatsächlich kommen soll, diesen Download habe ich dann mal getätigt und werde sobald die Freigaben dazu vorliegen im Detail über diese interessante Neuerung berichten.

VMware ESX / ESXi Virtual Hardware Memory Corruption Vulnerability

Thursday, 04 December 2008 11:44:28 (W. Europe Standard Time, UTC+01:00)
Heute Nacht hat VMware einen Fehler in der Hauptspeicherverwaltung für virtualisierte / emulierte Treiber veröffentlicht, der auf den ersten Blick nur nicht gepatchte Systeme der aktuellen Versionen von ESX(i) betreffen.


Bei secunia wurde der Fehler als weniger kritisch eingestuft. Ich unterstütze diese Ansicht in Teilen. Für virtualisierte Serverumgebungen ergibt sich ein deutlich geringeres Gefährdungspotential, als für virtualisierte Arbeitsplatzumgebungen unter VMware View alias VDI.

http://secunia.com/advisories/32965/

http://lists.vmware.com/pipermail/security-announce/2008/000046.html

Update der VMware Tools notwendig!
Liest man sich die entsprechenden Knowledgebase Artikel durch, fällt direkt auf, dass die VMware Tools geupdatet werden und das neue Paket in alle Gäste ausgerollt werden muss, damit die Systemintegrität wieder hergestellt werden kann.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007501

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007504

Administratoren der Umgebungen sollten zeitnah das Update testen und verproben und gegebenfalls ausrollen.

Lizenzierung von Oracle unter VMware

Wednesday, 03 December 2008 10:35:41 (W. Europe Standard Time, UTC+01:00)
Nachdem in der Vergangenheit so gut wie alle Softwarehersteller etwas zurückhaltend waren, was die Unterstützung der / ihrer Kunden in Virtualisierungsumgebungen betraf, so verfolgten in der jüngeren Zeit alle Hersteller eigene Wege, sprich: Unterstützungs-Frust "(...)Generell verbieten wir es ihnen die Anwendung auf einer Virtualisierungslösung zu installieren und in Betrieb zu nehmen, oder wenn Sie ein Problem haben unterstützen wir Sie NICHT!(...)" So oder so ähnlich ergeht es vielen Kunden, die ohne eine belastbare Aussage der Anwendungshersteller in ein Virtualisierungsprojekt gestartet sind.

VDI ist tot! Es lebe VMware View oder doch VDI

Tuesday, 02 December 2008 09:50:10 (W. Europe Standard Time, UTC+01:00)
Wie bereits angekündigt ist seit heute das neue Produkt VMware View alias VDI 3.0 verfügbar!


Ich habe bereits mit der Version 3.0 beta erste Erfahrungen gesammelt und werde in den nächsten Tagen ausführlich über die neuen Möglichkeiten an dieser Stelle veröffentlichen.
Für alle die es kaum abwarten können hier der Link zur offiziellen Download Seite von VMware; hier


VMware HA Konfiguration und Fehlermeldungen

Wednesday, 26 November 2008 21:55:25 (W. Europe Standard Time, UTC+01:00)
Ich dachte zu dem Thema sei alles erklärt und die Karten lägen offen auf dem Tisch, aber weit gefehlt! In meinen Dokumenten habe ich zwar meine Erfahrungen und Empfehlungen zum Thema HA und Fehlermeldungen mit meinem Team ausgetauscht, aber leider hatte ich bis jetzt noch nicht die Gelegenheit alle Funktionsweisen, Parameter und Tipps zu veröffentlichen, ich gelobe Besserung und fange direkt mal mit den "un-"dokumentierten Parametern für VMware an. Parameter für VMware HA Auf der Website von der Niederländischen VMUG bin ich fündig geworden

Schon wieder Pegasus Fehler - trotz Update 2

Tuesday, 18 November 2008 11:04:50 (W. Europe Standard Time, UTC+01:00)
Nachdem das Update 2 für ESX Server 3.5.0 verfügbar war, hatte ich den alten Pegaus Fehler wieder verdrängt, oder war der damit nicht behoben?
Bei den Neuinstallationen trat der Fehler auch nicht mehr auf, dies habe ich in mehreren Projekten verifiziert.

Bei einem meiner Kunden hatte ich Probleme in der snmp Überwachung, Ergebnis der alte Pegasus Fehler war nach dem Update auf U2wieder da!!!! und noch andere, ohne dass der UM meldete, das ein Modul oder Paket nicht in Ordnung sei.
Jetzt die Horrornachricht für alle, die niemals auf die direkte Konsole ihres ESX Server gucken und diesem beim Booten zuschauen, okay beobachten und analysieren:
Der Fehler bleibt auch nach dem Update von 3.5.0U1 auf 3.5.0U2 erhalten. Damit sollte jeder seinem Kunden empfehlen:
  1. UpdateManager nur für security und major fixes bei Problemen verwenden
  2. Updatebundles von VMware immer von Hand als komplettes System ausrollen!!!!
    Keine Updates (Pierre hat das schon immer gewusst, ich ziehe meinen Hut) von laufenden Systemen machen!
Fazit, das Patchen von ESX ist nach wie vor ein Drama und die Installationsanleitungen müssen selbst innerhalb eines Releases überarbeitet werden, aufgrund der schlechten Informationspolitik von VMware!
Mal schauen ob das Ganze in Version 4.0 besser wird. :'(

ESX Server reagiert nicht COS - VMs laufen weiter

Monday, 17 November 2008 10:55:30 (W. Europe Standard Time, UTC+01:00)
Ich hatte gerade einen schönen Support Call, einer meiner Kunden berichtete, dass ein ESX Server "steht", sich nicht mehr richtig steuern lässt, die VMs liefen aber wie die Hölle weiter.
Wie immer hat der Kunde nichts geändert - bei diesem Kunden glaube ich das auch - und dem war anscheinend auch so. Ein kleiner Blick in das Dateisystem offenbarte, dass die /VAR Partition, die ich als paranoider Admin schon mit 8GB angelegt hatte vollgelaufen war. Lustiges Detail, es gab dort ein Unterverzeichnis ./core, in dem hunderte 35 MB große 12345.core Dateien lagen, die anscheinend alle innerhalb von einer Minute angelegt worden waren.

Analyse
Auf der VAR Partition wurden innerhalb von einigen Minuten zirka 6,5 GB Daten angelegt, deren Muster in etwa 12345.core war. Diese lagen alle in einem von mir niemals zuvor gesehenen Verzeichnis /var/core
Die Dateien konnten sofort gelöscht werden und ein Neustart der Dienste
service mgmt-vmware restart
service vmware-vpxa restart
führte dazu, dass der ESX Server ohne Neustart einfach weiter lief und in der Folge wieder über das VC verwaltet werden konnte.

Das Handbuch (google) ergab:
http://communities.vmware.com/message/1080791;jsessionid=1D9C8527320ADDA1891D81FB1F3E3C95
http://communities.vmware.com/thread/55607

Treffer!!!!
laut dem Support kann es passieren, dass der hostd in diesem Verzeichnis seine App daemon crash infos pumpt und der esx danach zwar noch läuft aber die COS nicht mehr mit anderen ESX oder dem VPX reden wollte. Das Update 3 soll das fixen, da bin ich mal gespannt, viel interessanter finde ich allerdings, dass mal wieder ohne Dokumentation (ich hasse sowas) eine Info nach außen drang, die mich veranlasst sieht die Aussage über Partitionsgößen zu revidieren:

Ab sofort sollte man eine /var/core Partition anlegen. Größe 8 GB

VMware EVC einschalten

Thursday, 30 October 2008 18:41:25 (W. Europe Standard Time, UTC+01:00)
Mit der Version VMware Infrastructure 3.5 Update 2 wurde die erweiterte VMotion Kompatibilität eingeführt.
Dahinter verbirgt sich eine sehr interessante Funktion, die es ermöglicht in mixed INTEL Clustern oder mixed AMD Clustern VMs von einem Host zum anderen zu migrieren.
Diese Funktion ist alt bekannt, hat aber ihre Tücken im Detail.

Anforderungen für vMotion:
Neben der Erfordernis, dass lediglich CPUs eines Herstellers in einem Cluster verwendet werden, kommt erschwerend hinzu, dass die CPUs aller Hosts eines Clusters aus der selben Familie / Serie stammen müssen, damit vMotion und damit auch DRS funktionieren können.
In der Version ESX Server 3.0.x konnte man die CPU Maske pro Host manipulieren, damit nur gemeinsame CPU Funktionen allen VMs präsentiert werden.
Da das Anlegen einer CPU Map nicht trivial ist, hat wohl kaum jemand von dieser Option Gebrauch gemacht.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1993

Der EVC Ansatz:
EVC ist eine Clusterfunktion und wird daher direkt über das VC gesteuert. Neu ist die Änderung in der Art und Weise der Festlegung der möglichen gemeinsamen CPU Funktionen. Wurde das bisher pro Host gesetzt, so wird jetzt die Konfiguration pro VM in der .VMX Datei gesetzt. Damit diese Option gesetzt werden kann, muss die betreffende VM, bzw. alle VMs des Clsuters ausgeschaltet sein.

hostCPUID.0 = "0000000a756e65476c65746e49656e69"
guestCPUID.0 = "0000000a756e65476c65746e49656e69"
userCPUID.0 = "0000000a756e65476c65746e49656e69"
hostCPUID.1 = "0001067600040800000ce3bdbfebfbff"
guestCPUID.1 = "000006f800010800000022010febbbff"
userCPUID.1 = "0001067600040800000022010febbbff"
hostCPUID.80000001 = "00000000000000000000000120100000"
guestCPUID.80000001 = "00000000000000000000000120100000"
userCPUID.80000001 = "00000000000000000000000120100000"
evcCompatibilityMode = "TRUE"


Je nachdem wie viele vCPUs in der Vm gebunden sind - im vorliegenden Fall sind es zwei vCPUs - werden Zeilen am unteren Ende der .VMX-Datei hinzugefügt.

VCB Exporte nach Datum / Ablauf automatisiert löschen

Tuesday, 28 October 2008 18:28:39 (W. Europe Standard Time, UTC+01:00)
Nachdem im letzten Post gezeigt wurde, wie man mit einer einzelnen Batchdatei einfach alle VMs als DRV sichern kann, kommt natürlich die Frage auf, was tun, wenn die Datensicherungsfestplatte droht vollzulaufen? In der Regel würde man versuchen manuell die älteren Exporte einfach von der Platte zulöschen, das geht aber auch einfacher per VBScript und einer Batch. Leider kennt Windows keinen Befehl, der einfach Verzeichnisse samt Inhalt löscht, wenn deren Inhalt älter als ein bestimmtes Datum oder Anzahl an Tagen ist. In dem folgenden Beispiel sollen alles Exporte, die älter als 44 Tage sind von der Festplatte gelöscht werden. Das VBScript wird über eine Batch oder einfach eine Kommandozeile ausgeführt.

VCB Datensicherung per Skript

Monday, 27 October 2008 17:23:09 (W. Europe Standard Time, UTC+01:00)
VMware VCB wird oft unterschätzt, auch wenn das entsprechende Framework mit der Version 1.5 wohl den finalen Release erreicht hat und die Entwicklung von weiteren VCB Frameworks an die Hersteller von Wiederherstellungssoftware abgetreten wurde, eignet es sich hervorragend um komplette Exporte zur Desaster Recovery Vorsorge zu erstellen. Die Integration in die bestehende Datenwiederherstellungssoftware ist allerdings manchmal sehr holprig und die Ansätze zur Integration des VCB sind von Hersteller zu Hersteller stark unterschiedlich. Ein generalistischer Ansatz wäre da für alle etwas einfacher. Generell benötigt man für diese Methode der Datensicherung eigentlich nur einen einzelnen Befehl: vcbmounter.exe

VMware Virtual Center 2.5.0 Update 3 ist da!

Saturday, 04 October 2008 07:46:08 (W. Europe Daylight Time, UTC+02:00)
Das jüngste Update Paket für das VirtualCenter beseitigt unter anderem Probleme mit dem Wartungsmodus & dem UpdateManager!



Wie immer im Verborgenen erblickte das neueste Kind von VMware das Licht der Welt. Das Update 3 ist da!
Da es in der bisherigen Version erhebliche Probleme mit der Berechnung der HA Kapazitäten in Verbindung mit dem UpdateManager und der benötigten vMotion Technologie gab, hat VMware diesen Schritt vorgezogen. Aber erstmal alles Schritt für Schritt:

Problem:
Insbesondere in kleineren Umgebungen mit zwei oder drei ESX Servern kann man einen produktiven ESX Server nicht mehr so einfach in den Wartungsmodus versetzen, insbesondere dann, wenn auch noch VMware HA auf Clusterebene eingestellt worden ist. Der Server startet mit dem Wartungsmodus und bleibt bei genau 2% stehen, bricht mit Fehler ab.
Betrachtet man af der Zusammenfassungseite die Clusterkonfiguration stellt man fest, dass die konfigurierte Failover Quote für HA auf ein Host eingestellt ist und die verfügbare Clusterkapazität den Ausfall von "NULL" Hosts erlaubt?!
Der kluge Administrator baut vor und hat extra für das kleine Cluster eingestellt, dass auch dann im HA Fall VMs neu gestartet werden, wenn die Kapazitätsgarantien für die VMs auf "erlaubt" gestellt.
Zusätzlich wurden die das.VmMemoryMinMB und das.VmCpuMinMHz gesetzt und trotzdem nix Wartungsmodus!?

Workaround:
Temporär die Clusterfunktion HA ausschalten. Die Konfiguration des Clusters geht dabei NICHT verloren (liegt in der VCDB) und im Anschluss an die Updateeinspielung wieder einschalten. Dabei wierden zunächst die Konfiguration und Pakete vom ESX Server deinstalliert und entfernt und im Anschluss wieder neu installiert.

Lösung:
Das Update 3 für VMware VirtualCenter behebt dieses Problem, auch in kleinen Clustern mit zwei bis drei Hosts klappt das einstellen des Wartungsmodus jetzt wieder problemlos und man kann auch über den UpdateManager wieder Patches einspielen.

demnächst mehr zum Thema VI 3.5 Update 3 hier!

VMware Tools Best Practise

Friday, 26 September 2008 13:57:05 (W. Europe Daylight Time, UTC+02:00)
Wenn man mit virtuellen Systemen arbeitet, dann werden in der Regel auf allen VMs die VMware Tools installiert. In diesem Beitrag wollen wir darauf eingehen, was sich überhaupt hinter den VMware Tools verbirgt und welche Bestandteile auf welcher Plattform sinnvoll zum Einsatz kommen sollten oder gerade nicht. Seit dem es VMware gibt, werden die Tools verwendet, um die VM mit optimierten treibern für die emulierte ardware auszustatten und zusätzlich über die VMware Tools Dienste die VM steuern zu können. Genauso wie der Hypervisor unterligen die VMware Tools einer ständigen Überarbeitung seitens VMware und so kommt es sehr oft vor, dass eine VM im Laufe ihres "Lebens" eine aktualisierte Version der Treiber und der Dienste erhalten sollte. Das Installationspaket für VMware Tools wird pro Betriebssystemgruppe eingesetzt, so dass es ein Paket für Windows, Linux, Netware und BSD standardmäßig von VMware gibt. Die Betrachtung der einzelnen bestandteile dieser Pakete werden wir im Folgenden anhand des Paketes für Windows Gastbetriebssysteme erläutern. Gibt es bestimmte Unterschiede zu en anderen Paketen, so werden diese als Zusatzoption genannt.

VMware Infrastructure Beta: VirtualCenter Ask the Expert Session

Wednesday, 24 September 2008 12:19:08 (W. Europe Daylight Time, UTC+02:00)
Heute am späten Nachmittag findet die erste WebEx Sitzung mit dem Entwicklerteam von VMware statt.
Ich bin sehr gespannt auf eine gute Stunde Plausch mit den Leuten, die das Produkt entwickeln.
Alles weitere dazu an dieser Stelle zu späterer Zeit.


VMware Fusion Netzwerkkonfiguration ändern

Wednesday, 24 September 2008 08:13:14 (W. Europe Daylight Time, UTC+02:00)
Unter Windows war ist es relativ einfach die einzelnen Netzkonfigurationen zu ändern und gezielt über die Dienste von Windows zu steuern. Nachdem ich ja nun seit über einem Jahr bekennender MacBook Pro Besitzer und OSX Lover bin gestaltet sich die Umstellung manchmal als schwieriger / anders. Das Umstellen der von VMware vorgeschlagenen vNetworks ist durchaus sinnvoll, da zu erwarten ist, dass es doch mehr als einen VMware User in einem Unternehmensnetz geben wird oder bereits gibt. Im konkreten Beispiel wollte ich, dass die DHCP Adressen aus dem Subnetz 172.16.191.0 stammen, aber oberhalb von .127 genutzt werden, da ich in dem unteren Segment Server betreiben will mit festen IP-Adressen. Die Umstellung dieser Konfiguration erfolgt anders als unter VMware Workstation nicht über die GUI, sondern über das Terminal und einen Editor.

Einladung zum Beta Programm von VMware

Saturday, 13 September 2008 21:42:58 (W. Europe Daylight Time, UTC+02:00)
Völlig frustriert darüber, dass ich dieses Jahr nicht zur VMworld fahren kann (Pierre, ich beneide dich!) hatte ich bereits beschlossen meinen Frust darüber in Migrationsprojekten zu ertränken.
Als ich heute mein Postfach durchstöbert habe fand ich eine sehr interessante E-Mail von VMware mit dem Kontext "You are invited to participate(...)the VI BETA Program".
Obwohl ich am Wochenende gearbeitet habe konnte ich mir das Grinsen im Gesicht nicht verkneifen und irgendwie kam zeitgleich die Sonne raus, schöööön!

Gefolgt vom Ausfüllen des VMware Beta Tester Antragsformular folgte dann das lange Warten und heute war es soweit, die Links zum VI 4.0 Beta Programm wurden von VMware an mich übermittelt,
da fiel mir nur ein Filmzitat ein "(...) Now I have a machine gun! Hoh, hoh, hoh! (...)" Auf geht's! Seit heute Abend bin ich dabei die neuesten Versionen herunterzuladen und ausgiebig zu testen. Ich freue mich schon an dieser Stelle über alle neuen Fuktionen berichten zu können, sobald die Freigabe dazu von VMware erfolgt ist.


 

Mein Netzwerksenf! - virtual networking in VMware VI 3.5

Sunday, 17 August 2008 16:34:51 (W. Europe Daylight Time, UTC+02:00)
In den meisten Projekten werde ich immer wieder mit Fragen zum Thema Netzkonfiguration in virtuellen Umgebungen konfrontiert. Aus den Projekten hat sich im Laufe der Zeit eine Art Best Practise entwickelt, den ich gerne in der Reihe "Mein Netzwerksenf!" an dieser Stelle veröffentlichen möchte.

Installing ESX Server 3.5, Patch ESX350-200806812-BG

Wednesday, 13 August 2008 21:26:27 (W. Europe Daylight Time, UTC+02:00)
As we now have the patch, how to install the patch in the Enterprise with a minimum of downtime?

It's possible to do it as followed with a minimum of downtime for your VMs.

  1. Set your DRS cluster in "Manual" Mode to ensure, that VMs are not moved to other hosts!
  2. shutdown all VMs on the chosen ESX(i) host and set the host into maintenance mode!
    A very cool small script can be seen at Duncans blog
  3. copy the patch into the /tmp directory or any other ext3 filesystem location on the host with appropriate free disk space!
  4. install the patch and reboot your host.
    [root@esx]#unzip ESX350-200806812-BG.zip
    Archive:  ESX350-200806812-BG.zip
       creating: ESX350-200806812-BG/
      inflating: ESX350-200806812-BG/VMware-esx-vmx-3.5.0-110181.i386.rpm
      inflating: ESX350-200806812-BG/VMware-hostd-esx-3.5.0-110181.i386.rpm
      inflating: ESX350-200806812-BG/descriptor.xml
       creating: ESX350-200806812-BG/headers/
     extracting: ESX350-200806812-BG/headers/VMware-esx-vmx-0-3.5.0-110181.i386.hdr
     extracting: ESX350-200806812-BG/headers/VMware-hostd-esx-0-3.5.0-110181.i386.hdr
      inflating: ESX350-200806812-BG/headers/header.info
      inflating: ESX350-200806812-BG/headers/contents.xml
      inflating: ESX350-200806812-BG/headers/contents.xml.sig
      inflating: ESX350-200806812-BG/contents.xml
      inflating: ESX350-200806812-BG/contents.xml.sig

    [root@esx]#cd ESX350-200806812-BG
    [root@esx]#esxupdate --noreboot -v 6 update

    Wait for the entire process to end & if "FinalState: SuccessState" reboot the host

    [root@esx]#reboot
  5. After the successfull reboot, end the maintenance mode.
    [root@esx]#vmware-vim-cmd hostsvc/maintenance_mode_exit
VMotion to this host is now again possible!!!
After the first host is considered as working "normal" You can go ahead with patching the rest one-by-one. Good luck, I'm with You!

Changing time on ESX hosts

Wednesday, 13 August 2008 14:18:06 (W. Europe Daylight Time, UTC+02:00)
As I mentioned yesterday there is a very big influence on how You set and change time information on an ESX host and the impact on VMs.
What I hardly learned was, that changing the ESX time information within the VI Client has direct impact on ALL running VMs on the particular host.

Whether or not You checked "sync time with host" feature in VMware Tools, the time information is directly submitted into the VM, when the VMware tools service is running within the VM. This behavior is NOT as expected and described in the VMware Guides, so don't change time information on any running ESX(i) in a productive environment.

In the VMware communities, there is a solution that might work:
The real trick is to use the direct ssh access and change time information within the COS:
Be sure You are root
service ntpd stop
date -s 08/10/2008
esxcfg-firewall -d ntpClient

This changes also the time on the host, but has in the end the same effect on running machines!!!

The best solution is (if you cannot install the patches) to move all running VMs of the host and change the time on this particular host temporary:
Be sure to disable VMware DRS, so that no VM is being scheduled back on this host and that You are again root.

service ntpd stop
service ntpd status
esxcfg-firewall -d ntpClient
date -s 08/10/2008
----> break, switch to VI Client
right click VM | Edit Setting | Options | Boot Options | check "Force BIOS Setup"
wait untill the task completed successfully
break, switch back to ssh session<---

vmware-cmd /vmfs/volumes/[LUN]/[VM folder]/VM.vmx start --trysoft
wait for result = 1 (success)
esxcfg-firewall -e ntpClient
service ntpd star
Now You can set back the sdate within the VMs BIOS and start your VM; reenable DRS

OKay, I know VMotion will not work also, so DRS settings are not really necessary to be changed. :-)

ESX Server 3.5, Patch ESX350-200806812-BG

Wednesday, 13 August 2008 13:40:05 (W. Europe Daylight Time, UTC+02:00)
Early this morning I noticed, that the patches for ESX(i) are available for download and I did it!

I installed the patch on three new hosts in a running customer environment and from my point of view everything works as expected, but let's wait for a while...
The new build version is ESX 3.5.0.110181

Timebomb in VMware VI 3.5 Update2 (1st solution)

Wednesday, 13 August 2008 07:01:21 (W. Europe Daylight Time, UTC+02:00)
Yesterday was one of those days I will not forget very soon. so what happened exactly, I don't know, but a lot of glass is being broken on that VMware "Dooms-Day".
But they worked hard to fix it up:

  1. Make sure You don't turn back time in your environment!!!
    Some customers reported, although having NO time sync within the VMs running towards the hosts, time is being set back! One of my customers ran in this nightmare :'(.
    I don't know what really happened exactly and I'm still wondering about this and this is still under investigation with the DELL Pro Support EMEA team.

  2. Be patient and install the fixes as needed. But please test these patches carefully, because it seems that the complete kernel of VMware is being superseeded by these patches!
    Nobody knows (outside VMware) what was the real issue of this bug and from what point of kernel-build they fixed and recompiled the kernel sources. I'm looking forward to getting any information about this special issue from my sources at VMware.
    I'm testing this patch today in the morning and will give a fast feedback on my first impressions.

    Fix for ESX 3.5 Update 2 can be found here.
    The description of the patch is here.

    Fix for ESXi 3.5 Update 2 can be found here.
    The description of the patch is here.

  3. Follow the guidelines from VMware to installing these very critical patches!
    Instructions can be found here.

Unable to connect to Converter Enterprise Server

Tuesday, 12 August 2008 10:50:19 (W. Europe Daylight Time, UTC+02:00)
Some customers reported, that the Converter Enterprise Client Plugin (Version 4.0.0) doesn't start as expected and throws an error message similar to this.
To workaround this issue:

  1. Check whether the Converter Enterprise Server Service is started on the VC Server.
  2. In the VI Client disable the Converter EE Client plugin and reenable it again.
This should help.

Timebomb in VMware VI 3.5 Update2 (with workaround)

Tuesday, 12 August 2008 10:29:02 (W. Europe Daylight Time, UTC+02:00)
As several news services report, there is a timebomb within the licencing System of VMware Infrastructure.
VMware has not found the source for the bug and claims for using an earlier time period within VMware ESX(i) Hosts and VC Server as well.

Be very careful in doing so, because of the logging of the VC database can be corrupt, or lose data because of rewriting the "real" old data with the new ones.
I'm trying to figure out how far you can go back (or may be into the future!)

The link to the knowledge base article is here

To workaround do as followed:

  1. stop ntpd service on each ESX host with version mentioned above (ESX 3.5.0.103908). service ntpd stop
  2. check that the service isn't running anymore. service ntpd status
  3. set a date in the past maybe something like june 12th 2008, same time!

Then please go to your updatemanager to prevent systemes to install ESX 3.5.0 Update 2!

  1. Open VI Client and install and enable the update manager client.
  2. Navigate to the update manager (click the button!).
  3. Change the default baseline for non critical host updates and exclude the esx 3.5.0 Update 2 patch.
  4. the baseline should now show the annex "modified" in brackets behind the baseline type.

That's it for the very first time, so stay tuned on any broadcasting service for updates :-)

VMware closed download section for Update 2 installable Versions

Tuesday, 12 August 2008 07:06:01 (W. Europe Daylight Time, UTC+02:00)
From yesterday in the morning until now the Update 2 sources on the VMware website are still disabled!

VMware launched VI 3.5 Update 2

Saturday, 26 July 2008 12:26:50 (W. Europe Daylight Time, UTC+02:00)
Ooops! Here it is: Update2!
Along some hotfixing of already implemented functions there are a lot of features that are pretty new in VMware. But again to late for me and all the guys from Europe.

You can download this new release from here

During the next days I will have a closer look to the new features and report them here, so stay tuned for "Good News"!

VMware Infrastructure and me

Sunday, 22 June 2008 12:24:21 (W. Europe Daylight Time, UTC+02:00)
This blog is dedicated to all topics along virtualization and all the great things you can do with a hypervisor.
For the last two years I am working with DELL to help their customers to get the best of virtualization. During this period I've seen a lot of customers, datacenters and indeed problems and of cause solutions. As I participated from other guys blogging around virtualization solutions and topics, I would like to give some knowledge back to you all and say thank you for making this community that big!
So give me a little bit of time to give anyone a closer look to virtualization and VMware in depth.