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)

~ #

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!

VMware vCenter 5.1.0a - VMware View 5.1.1 Support!

Friday, 26 October 2012 09:52:06 (W. Europe Daylight Time, UTC+02:00)

VMware View 5.1 jetzt freigegeben für vSphere 5.1!



Bisher war die Installation von VMware View unter VMware vSphere 5.1 nicht supportet!
Das führte dazu, dass einige meiner Kunden das erwartete Update von vSphere verschieben mussten.
Jetzt wurden gestern eine neue Version des vCenters und des ESXi Servers veröffentlicht.




Kunden die schon auf VMware vSphere 5.1 sind sollten folgende KB Artikel beachten:

vSphere 5.1 compatible with View:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035268

ESXi Server Update VMware ESXi 5.1, Patch Release ESXi510-201210001:
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2034548



VMware Web Client - No UpdateManager

Wednesday, 24 October 2012 11:17:40 (W. Europe Daylight Time, UTC+02:00)

Der vSphere Client - Ein Speichermonster wird gezähmt!

VMware geht konsequent den Weg ins Web 2.0 und als Vorbote gibt es bereits für vSphere Version 5.1 einige Funktionen, die nur unter dem Web-Client funktionieren. Der vSphere Client von heute ist ein Auslaufmodell, aber es gibt noch liebgewonnene Plug-Ins, die den alten Client erfordern ;-) .



Für alle die bereits auf vSphere 5.1 setzen und bisher nur die Windows Variante einsetzen, gibt es im Web-Client keine UpdateManager Integration!
Also für diese Aufgaben noch den Standard vSphere Client benutzen mit dem Plug-In.
Warum ist das so?
Das ist kein Fehler, sondern by Design!
Der Hersteller VMware wechselt seine Adminkonsole hin zum Web-Client, als einzige Plattform. Damit sterben ALLE Plug-Ins die man bisher installiert und integriert hatte. Parallel dazu sollten alle, wirklich alle Kunden die Migration zur Linux Appliance planen, da VMware die Windows Variante einstellen wird. Es gibt genügend Hersteller, die ihre Plug-Ins bereits auf eine .OVA Appliance umgestellt haben, wie etwa DELL für die EqualLogic Integration.

vSphere 4.1 on the horizon

Thursday, 01 April 2010 17:37:28 (W. Europe Daylight Time, UTC+02:00)
Nein kein Aprilscherz!
Zur Zeit laufen die beta Tests zum neuen Maintenance Release vSphere 4.1, da wie immer alles unter dem Deckmantel der NDA Verschwiegenheit gehalten wird, werde ich hier nur einmal kurz auf den parallelen beta-Test für das Cisco Nexus 1000v zu sprechen kommen:

Hello:

Welcome to the Nexus 1000V Beta for VMware vSphere 4.1 Beta.

The new Nexus 1000V Beta has the following features.

  • New installer application that migrates Virtual Supervisor Module to its own Virtual Ethernet Module and create default system Port Profiles
  • For Layer 2 communication between Virtual Supervisor Module and Virtual Ethernet Module:  Only 1 VLAN
  • Option for Layer 3 communication between Virtual Supervisor Module and Virtual Ethernet Module

Please follow the procedures below to gain access to the Nexus 1000V Beta Program.
Invite others to our beta here https://www.myciscocommunity.com/docs/DOC-9459. They will be invited in a few days.  If you are not on the VMware vSphere 4.1 Beta, please reach out to your VMware account team.


Getting Started
To get started with the Cisco Nexus 1000V beta, you will need your Cisco.com account.  If you do not have a Cisco.com account, you can create one for free at the following URL:
https://tools.cisco.com/RPF/register/register.do <https://tools.cisco.com/RPF/register/register.do>

Please make sure that your Cisco.com credentials (CCO ID) has the e-mail address where you are are receiving this message listed as the business/primary email address. If you are not sure, please go to the following URL and make sure that your primary/business e-mail address is the e-mail address that you used when registering for the Nexus 1000V Beta program:
http://tools.cisco.com/RPF/profile/profile_management.do <http://tools.cisco.com/RPF/profile/profile_management.do>

To gain access the the Nexus 1000V Beta Test Community, please use your Cisco.com ID and login to:
https://www.myciscocommunity.com/community/products/nexus1000v/nexus1000vbeta
<blocked::http://www.myciscocommunity.com/community/products/nexus1000v/nexus1000vbeta>

Access to this private community requires you to accept a one time click-through Beta Agreement covering the terms and conditions of this beta program.

Confidentiality Rules
This is a private beta program and Cisco expects you to treat this beta program as strictly confidential. You are one of the select beta sites, and you are considered trusted advisors to Cisco for this program.  

You may:
       Speak to other participants of the beta program about this program.
       Speak to your Cisco and VMware account teams or representatives about this program.    
       Post questions and comments on the protected, private discussion forum inside the Nexus 1000V Beta Test Community

You may not:
       Discuss this program publicly.
       Discuss this program privately with any other people not listed above.

If you have any problems accessing either the beta website or private discussion forum, please email
nexus1000v-web-beta-reply@cisco.com
<mailto:nexus1000v-web-beta-reply@cisco.com>
.  Thank you very much for participating in the Cisco Nexus 1000V Beta program. We look forward to your feedback!

Thank you,
The Cisco Nexus 1000V Team



vCenter DB veraltete IP-Adresseinträge der Hosts löschen

Wednesday, 31 March 2010 16:21:40 (W. Europe Daylight Time, UTC+02:00)
Bei einem meiner Kunden musste ein IP-Adressredesign stattfinden. Dazu mussten natürlich auch die IP-Adressen der ESX-Hosts und des vCenter Systems geändert werden.
Da direkt auch ein Upgrade des vCenter Servers auf die Version 4.0.x an stand hatten wir uns kurzfristig dazu entschieden das vCenter System komplett neu zu installieren auf einer neuen Plattform und nur die Datenbank zu übernehmen. Die ESX Server werden erst in der weiteren Folge auf die Version 4.0.0 aktualisiert, da es keinen funktionalen Grund gab dieses Upgrade zeitgleich umzusetzen. Gesagt getan, alle ESX Server wurden mit den neuen IP-Adressen "versorgt". Für eine Übergangszeit sollten beide IP-Adressbereiche erreichbar / erhalten werden, bis die endgültige Umstellung aller Servernetze abgeschlossen war. Soweit so gut. Alle Funktionen liefen vollkommen fehlerfrei und so sollte es auch während des Mischbetriebes bleiben.
Nachdem der endgültige Cut im Netzbereich vollzogen war liefen die ESX Systeme soweit auch fehlerfrei, allerdings informierte mich der Kunde darüber, dass er weder einen Klon-Prozess starten könne noch aus einem Template eine VM ausrollen konnte, immer mit der Fehlermeldung "failed to connect to host", obwohl der vCenter Agent aus dem vSphere Agent ansteuerbar war.
VMware KB Eintrag dazu: http://kb.vmware.com/kb/1010837

Ursache:

In der VPXDB waren nicht alle ESX Server IP-Adressen umgesetzt worden. Dort standen noch die alten IP-Adressen in der Datenbank!
Das reine ESX-Server aus dem vCenter herausnehmen und wieder hineinbringen brachte auch keine Lösung genauso wenig, wie das manuelle editieren der vpxa.cfg Datei
/etc/opt/vmware/vpxa/vpxa.cfg
, wie in manchen Foren beschrieben, da das vCenter immer Vorrang vor der lokalen Konfiguration hat, wird die falsche Einstellung mit dem Neustart des VPXA Agenten auf dem ESX Server erneut durch die falschen Parameter (IP-Adresse) aus der führenden Datenbank VPXDB ersetzt - per Push-Verfahren.

Lösung:

Die fehlerhaften Informationen finden sich in der SQl Datenbank wieder. Um diese Parameter ändern zu können muss das vCenter herutergefahren, sprich der Dienst beendet werden und die Datenbank darf nicht im Zugriff eines SQL Agenten sein. So dann kann man sich mit dem SQL Server Management Studio auf dem SQL Server anmelden, am besten mit dem VPXDB Benutzer, da dieser alle Berechtigungen für die Datenbank besitzt. Dann muss man die folgende Tabelle einmal aufrufen VPXDB.dbo.VPX_HOST und das folgende SQL Skript pro ESX Server ablaufen lassen:


UPDATE vcdb.dbo.VPX_HOST
SET IP_ADDRESS = ‘192.168.0.11’
WHERE DNS_NAME = ‘esxsrv011.domain.tld’


Im Anschluss kann das vCenter System neu gestartet werden (Dienst oder ganzer Server) und die VPXA Agenten ziehen sich die "richtige" Konfiguration aus der Datenbank. Danach funktionierte dann wieder alles wie gewohnt, klonen, Templates, svMotion etc.

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

EMC F.A.S.T. Das Storage DRS

Wednesday, 09 December 2009 11:03:24 (W. Europe Standard Time, UTC+01:00)

Dieser Bolgeintrag ist ein Excerpt aus dem Eintrag von "Virtual Geek"

Dieser Beitrag dreht sich um die technische Möglichkeit mittels von EMCs FAST so etwas wie VMware DRS auf den Massenspeicher zu übertragen, eine sehr coole Idee!
FAST steht dabei als Abkürzung für "Fully Automated Storage Tiering". Die Kernidee die dahinter steckt ist das automatische Verscheiebn von Laufwerken (LUNs) auf die richtigen Spindeln (RAIDgruppen) zu einem definierten Zeitpunkt.
FAST ist sofort für alle Plattformen von EMC verfügbar.

Auf Basis von EMC Clariion CX4-xxx Speichersystemen automatisiert diese Technik die Rekonfiguration von LUNs und deren Optimierung gegenüber einer definierten Richtlinie. Für eine V-Max Umgebung dies, dass zum Beispiel Swap LUNs automatisiert zwischen SSD, FC 15k, FC 10k und S-ATA Spindeln im Hintergrund diskret verschoben werden.

Warum kann es sinnvoll sein, eine solche Funktion / Technik einzukaufen (geschenkt bekommen wird man diese wohl eher nicht, wenn man EMC kennt...)?

  • Es geht um Effiziente Nutzung des Speichersystems, so kann der Lifecycle eines Systems nicht nur auf Ebene der Systemvirtualisierung verfolgt werden, sondern auch transparent auf dem Speichersystem, ohne dass man dazu eine weitere Virtualisierungsschicht im Speichernetz benötigt.
  • Im Rahmen der Cloud-Computing Initiative lassen sich so Laufwerke transparent an SLAs für externe Clouds oder interne Clouds anpassen.
Das soll nur ein Hinweis für die Möglichkeiten von FAST sein. Auf dem Originalblogeintrag werden noch weitere Überlegungen zum produktiven Einsatz erwähnt. Es lohnt sich wirklich diesen Eintrag zu lesen!

An dieser Stelle wird der Prozess einmal kurz beschrieben um eine Richtlinie für FAST zu konfigurieren und diese an ein V-Max Kunden-Szenario zu binden:

Soviel als Appetizer zu der neuen EMC Technik. Weiter Hinweise, Szenarien und Einstellmöglichkeiten finden Sie unter:

Den offiziellen EMC Produktwebsites (natürlich auch im Powerlink):

In den EMC Blogs:

Und auf den INoffiziellen EMC Nachrichtenkanälen:

Virtual Geek, vielen Dank für diese Hinweise und die einfache Erläuterung! :-)

APC PowerChute neue Version 2.2.4

Monday, 07 December 2009 12:43:41 (W. Europe Standard Time, UTC+01:00)

Heimlich, still und leise hat der USV Hersteller eine neue Version von PCNS heraugebracht. Neben der Unterstützung von Windows & Co. gibt es das neue Paket auch für Linux.
In der Knowledgebase von APC befinden sich zudem einige PDF Dokumente zum Gebrauch der Software in Verbindung mit VMware ESX(i) Systemen. Insbesondere die Verwendung mit ESXi ist etwas neues, wobei diese Variante auch schon für die Hypervisor der Generation VMware ESX(i) 3.5.x verfügbar war.
Wir schauen dem Paket mal unter die Haube... .
Das Paket kann nicht direkt auf dem ESX(i) Server installiert werden, dazu benötigt man nachwievor die Vorgängerversion 2.2.3 Neu ist, dass man zur USV Steuerung einfach eine vMA Appliance verwendet und die Software einfach in das Linux dieser speziellen VM installiert und konfiguriert. Neben dieser vom Hersteller propagierten Version bevorzuge ich allerdings die parallele Installation auf mehrere Systeme:

  • Installation Version PCNS 2.2.3 auf alle ESX Server
  • Installation Version PCNS 2.2.4 in eine vMA Appliance pro Cluster (Redundanzgründe) bei ESXi Umgebungen
  • Installation Version PCNS 2.2.4 in die vCenter VM und dann Hinterlegung von PowerShell Skripten zum gesteuerten Herunterfahren von allen VMs, ja allen VMs auch vom SQL Server und dem vCenter Systems, wie das funktioniert erläutere ich in einem separaten Blogeintrag (später) :-)

Die Installationsquellen befinden sich auf einem gesicherten FTP Server, der Einstigespunkt für den Downlaod erreicht man über:
https://www.apc.com/tools/download/index.cfm

Voraussetzung für den Zugriff auf den Download ist eine Registrierung unter der Website apc.com.

Aktualisierung VMware vCenter Systrem auf 4.0.0 Update 1 Probleme & Lösungen

Friday, 27 November 2009 09:54:25 (W. Europe Standard Time, UTC+01:00)
Die Aktualisierung eines verteilten vCenter Server Systems von der Version 4.0 auf die Variante Update 1 birgt einige Risiken!
Zunächst sollte man seine Umgebung - wie immer - gründlich auf Fehler überprüfen, bevor man die gesamte Installerroutine aufruft.
In meinem Fall besteht die Umgebung aus drei Systemen, dem SQL Server, dem vCenter Server und dem UpdateManager Server.
Zunächst sollte im ersten Schritt der neue vSphere 4.0 Client installiert werden, der abwärts kompatibel zu den alten vCenter Versionen ist.
Im zweiten Schritt sollte man dann zuerst das vCenter aktualisieren.
Die Aktualisierung kann fehlschlagen, wenn zum Beispiel die TomCat Server Konfigurationsanwendung als Autostart hinterlegt worden ist und in der "System-Tray" liegt, da dann der TomCat Server nicht deinstalliert werden kann, bricht der Vorgang ab und die Installationsroutine macht einen Rollback!
Drittanbieter Plug-Ins in vCenter System können auch Probleme schaffen.
Kollegen aus den USA berichteten von Problemen mit der aktivierten VMware Orchestrator Komponente, diese sollte man besser vor der Aktualisierung anhalten (über die Dienste Steuerung).
Ebenso betroffen soll der UpdateManager sein, der nach der Aktualisierung nicht mehr alle ESX Server aktualisieren kann, bzw. nicht mehr mit allen ESX Servern kommuniziert.
Ich konnte lediglich noch beobachten dass es zum Fehler 25089 während der Installation des Converter Enterprise Edition und UpdateManager kommt, der eigentlich falschen Benutzernamen oder Passwort als Ursache hat. Der Fehler tritt allerdings im Zusammenhang mit angehaltenen Diensten auf! und nicht wegen falscher Benutzernamen oder -passwörter.

Zusammenfassung:
  1. Fehler in der Umgebung vor dem Update finden und beheben!
  2. Drittanbieter Software anhalten / analog zum ESX(i) Update
  3. vSphere Client aktualisieren
  4. Alle vCenter Tools anhalten / stoppen, zum Beispiel TomCat5w.exe
  5. Orchestrator Dienste anhalten (nur bei Update von 4.0 auf U1)
  6. vCenter Server aktualisieren (SQL DB aktualisieren, Kern Komponenten erneuern)
  7. vCenter Add-Ons aktualisieren (Converter EE, Guided Consolidaten) <--- Dienste müssen vor dem Beginn der Aktualisierung gestartet sein
  8. UpdateManager aktualisieren <--- Dienste müssen vor dem Beginn der Aktualisierung gestartet sein
  9. Plug-Ins im vSphere Client aktualisieren

Es bleibt also spannend.... .

PSOD nach Update auf VMware ESX 4.0.0 Update1

Wednesday, 25 November 2009 12:54:20 (W. Europe Standard Time, UTC+01:00)
Gestern erhielt ich eine E-Mail von Kollegen aus den Staaten, dass es derzeit zu Problemen mit dem Einspielen des Update1 Paketes über den VMware Update Manager für den ESX Server kommen kann.
Die Probleme können genau dann entstehen, wenn auf der Service Console eines ESX 4.0 Systems Drittanbieter Agenten installiert worden sind und diese im Status "laufend" sich befinden.
Inwiefern auch ein Upgrade der Version ESX 3.x auf ESX 4.0.0U1 betroffen ist oder die manuelle Installation in der SC selber oder über das "Host Update Utility" des vSphere 4.0 Clients betroffen ist, kann ich und konnten meine Kollegen weder bestätigen noch ausschließen. Generell empfehle ich mit dem Update auf Version ESX 4.0.0 U1 und auf ESXi 4.0.0 U1 zu warten.
Als Workaround bietet der Hersteller Vmware untwer dem folgenden KB Artikel eine Lösung für das Problem an:

http://kb.vmware.com/kb/1016070

Will man also ein System aktualisieren, auf dem zum Beispiel eine Hardwareüberwachung wie DELL OMSA oder HP Insight Manager installiert worden ist, so sollten diese Dienste vor dem Start der Aktualisierung in der SC deaktiviert werden. Nach der Installation und dem Neustart des Hosts können die Agenten wieder gestartet werden.
Hat ein Kunde bereits die Installation ausgelöst, so ist umgehend ein Support Call bei VMware zu eröffnen, da es ansonsten zu Datenverlust kommen kann. Betroffen davon sind insbesondere Systeme mit lokal angeschlossenem Storage. iSCSI und FC Laufwerke sollen allerdings nicht dieses Fehlerbild aufweisen. Wir bleiben dran...

VMware View 4.0 ist da!

Friday, 20 November 2009 13:11:15 (W. Europe Standard Time, UTC+01:00)


Lange erwartet und endlich fertig geworden ist die Desktop Virtualisierungslösung von VMware ab jetzt verfügbar. Zu den Vorzügen gehört die (zunächst experimentelle) Unterstützung von Windows 7 Gästen als Zielsystem und die Möglichkeit vSphere 4.0 als PLattform für die Virtualisierung zu nutzen. Wichtig in in diesem Zusammenhang ist, dass mindestens VMware vSphere 4.0.0U1 als Plattform installiert sein muss. Dazu prüft die Installationsroutine zunächst die Rahmenparameter der virtuellen Infrastruktur und verweigert die Installation der Pakete, wenn U1 fehlt.

Alle Informationen rund um View und eine sechzig Tage Testlizenz findet man auf der Hersteller Website unter:

http://www.vmware.com/products/view/overview.html

In den kommenden Wochen habe ich eine Referenzumgebung für VMware View zur Verfügung und werde über alle Neuigkeiten rund um View hier berichten.

VMware vSphere 4.0 und das HA Cluster

Friday, 31 July 2009 08:31:27 (W. Europe Daylight Time, UTC+02:00)
Mit VMware vSphere 4.0 hat VMware auch die HA (High Availability) Funktion überarbeitet.
Neben der neuen Version des HA Agenten wurden neue Funktionen in das HA Cluster integriert. Neben der nützlichen Funktion, dass man einen Standard Failover Host über die GUI setzen kann, kann man nun auch die Überhang Ressourcen in Prozentwerten definieren, um zum Beispiel nur 15% der Ressourcen für HA zu reservieren. Unter der Haube hat sich einiges geändert, die Berechnung der HA Cluster Failover Quoten und der Cluster-Health (grün ist schön :-D) erfolgt jetzt auf Basis von so genannten Slots. Dabei werden die Cluster-Ressourcen in kleinere Einheiten, den Slots, eingeteilt auf Basis eines Algorithmus, die Slotgröße definiert. Danach wird die Slot Gesamtanzahl umgelegt auf das Cluster und die Slots werden "verteilt". Wie das Ganze abläuft und welche Optionen neu sind demnächst hier...

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 OpenManage OMSA Security Profile

Friday, 24 July 2009 17:37:47 (W. Europe Daylight Time, UTC+02:00)
Ein kleines Goodie am Rande:
Wer Anwendungenn in die SC installieren muss der weiß, dass die Firewall zumeist auch angepasst werden muss. Dabei kann man über das Kommandozeilenwerkzeug von VMware esxcfg-firewall die eingebaute Firewall manipulieren.
Leider sieht man im vSphere Client nicht, dass es ein weiteres Sicherheitsprofil gibt und ahnt, wenn man nur auf der GUI agiert nicht, dass im System weitere Änderungen an der Firewall vollzogen worden sind.

Auf der Kommandozeile würde man wie folgt den einzelnen OMSA Port freigeben können:
esxcfg-firewall -o 1311,tcp,in,OpenManageRequest

Wer gerne auch "sieht" was er einrichtet kann gerne ein Sicherheitsprofil anlegen und über dieses dann die Portkontrolle ausüben:
<!-- Firewall configuration information for DELL OpenManage SystemAdaministrator -->
<ConfigRoot>
    <service>
    <id>DELL OpenManage Request</id>
        <rule id='0000'>
            <direction>inbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>443</port>
            <flags>-m state --state NEW</flags>
        </rule>
        <rule id='0001'>
            <direction>inbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>1311</port>
            <flags>-m state --state NEW</flags>
        </rule>
        <rule id='0002'>
            <direction>outbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>443</port>
            <flags>-m state --state NEW</flags>
        </rule>
        <rule id='0003'>
            <direction>outbound</direction>
            <protocol>tcp</protocol>
            <port type='dst'>1311</port>
            <flags>-m state --state NEW</flags>
        </rule>
    </service>
</ConfigRoot>

Und wer will kann auch die fertige Datei direkt hier herunterladen: DELL_OMSA.xml (,80 KB)
Das fertige Profil muss dann nur noch in der SC abgelegt werden und mit der Firewall geladen werden:
root@esx40 #cp ./DELL_OMSA.xml /etc/vmware/firewall/.
root@esx40 #esxcfg-firewall -e "DELL OpenManage Request"
root@esx40 #service firewall restart
root@esx40 #service mgmt-vmware restart <-- sorgt dafür, dass der vSphere Client das neue Profil auch anzeigt! (!!!Achtung, bei direkten Connect auf den ESX wird vSphere Client Sitzung getrennt!!!)

Viel Erfolg beim umsetzen

Hostprofiles oder "was geht konkret" (nicht)?

Wednesday, 22 July 2009 07:12:34 (W. Europe Daylight Time, UTC+02:00)
Mit VMware vSphere 4.0 wurde zum ersten Mal ein Werkzeug eingeführt, mit dessen Hilfe ein Anwender überprüfen kann, ob alle Hosts eines Clusters die identische Konfiguration halten. Bisher musst man entweder auf der Kommandozeile im VI Toolkit oder über die BASH skripten, um eine einheitliche Konfiguration zu erzielen.
Jetzt ist alles anders, wirklich Alles?

Die VMware Host Profiles sind ein ideales Überwachungswerkzeug, dass man direkt aus der GUI des vSphere Clients starten kann. Allerdings ist diese Funktion nur für Kunden verfügbar, die die Version Enterprise Plus lizenziert haben.
Leider werden nicht alle Einstellungen eines Referenz ESX Servers von den Host Profiles übernommen und dann auf andere Hosts übertragen.
Die nachfolgende Auflistung gibt Punkte wieder, die nicht über diese Funktion ausgerollt werden können:
Netzwerkkonfiguration:
  • Statische Routen für IPv4 und IPv6 Netzkonfigurationen
  • Zuordnung der vmnics (physische Netzadapter) zu vSwitches auf Basis der PCI Slotordnung
Speicheranbindung:
  • iSCSI HBA and targets
  • LUN Multipathing Richtlinie (PSP)
    • Fixed
    • Round-Robin
    • MRU
  • PSA Konfigurationen außerhalb der automatischen Konfiguration (NMP)
Sicherheitsprofile:
  • Administrative Passwörter
  • Host UUID (Unwichtig, eher besser)
  • selbst generierte Sicherheits Profile

An dieser Stelle sollte man die Hostprofiles als "Richtschnur" nutzen und die Feinkonfiguration über Skripte organisieren, damit eine einheitliche Konfiguration aller Hosts möglich ist.

Erste Updates für vSphere 4.0

Friday, 17 July 2009 22:10:15 (W. Europe Daylight Time, UTC+02:00)
Nachdem die RTM / GA Version von VMware vSphere 4.0 seit dem 22. Mai verfügbar ist wurden die ersten Updates für den ESX(i) Server 4.0.0 veröffentlicht. Das Updatepaket beinhaltet dabei einige wichtige Sicherheitsupdates für Linux Module innerhalb der aktuellen SC mit dem modifizierten RHEL 5.1 für x86-64.

Das Updatepaket von VMware für die einzelnen Varianten von VMware ESX 4.0.0 wurde mit Größen zwischen 163,4MB und 377,9MB nicht gerade klein.
Parallel dazu wurden die ISO Dateien auf der Downloadseite angepasst und tragen nun den folgenden Build-Stand:
VMware ESXi installable VMware-VMvisor-Installer-4.0.0-171294.x86_64.iso
VMware ESX "Classic"    esx-DVD-4.0.0-171294.iso

Ich bin gespannt wann das vCenter geupdatet wird, da es zur Zeit zwei kleinere Probleme gibt:
  1. Reboot der vCenter VM an einem dvSwitch schlägt fehl, genau wie das Clonen / Deploy an eine dvSwitch Portgruppe
  2. Memory-Leak in der Tomcat Server Engine
Es bleibt also spannend!

DELL OpenManage 6.1 für VMware ESX Server 4.0.0

Friday, 17 July 2009 16:18:20 (W. Europe Daylight Time, UTC+02:00)
Nachdem ein paar Wochen ins Land gegangen sind, ohne dass man seine DELL Server mit OMSA ausstatten konnte, hat DELL mit der Version 6.1 eine unterstütze Version von OpenManage veröffentlicht, die VMware ESX(i) Server 4.0.0 unterstützt.
Dabei kann das Paket als einzelnes Installationspaket über die DELL Website heruntergeladen werden.



Die Installation erfolgt aus der SC heraus und bedarf keines Neustarts des Servers. Nach der Installation ist die ESX Server Firewall noch zu konfigurieren. Die Installation erfolgte über das Installationspaket „OM_6.1.0_ManNode_ A00.tar.gz“ Die Software kann wie gewohnt kostenlos über die DELL Website heruntergeladen werden.

Download Link OMSA Installationsquelle:
ftp://ftp.us.dell.com/sysman/OM_6.1.0_ManNode_ A00.tar.gz

Download Link OMSA Installationsanleitung:
Für ESX Server Version 3.0: http://www.dell.com/downloads/global/solutions/Installing_Dell_OpenManage_50_on_ESX_3.pdf
Für ESX Server Version 3.5 und 4.0 "Classic": http://support.dell.com/support/edocs/software/smsom/6.1/en/ug/html/instlx.htm#wp1054425

Für die ESXi Varianten bietet DELL mittlerweile eine eigene Kompilierung des Paketes für ESXi embedded an, bei der die OM Ageneten bereits integriert sind. Damit hat DELL mit HP gleichgezogen, die diese Verknüpfung für OpenView bereits seit einiger Zeit über die HP und VMware Website anbietet.
Neben der embedded Variante von DELL gibt es noch ein weiteres Paket für die Variante ESXi "installable". Dazu wird ein Frontend auf einem entferneten System installiert, das dann wiederum die ESXi OpenIPMI Schnittstelle DELL spezifisch abfragt und so den konkreten Maschinenzustand an OM weiterleiten kann. Der Anwender kann über diese Webschnittstelle zentral alle ESXi Systeme mit DELL Hardware abfragen. Es bleibt abzuwarten, wann die neuen Funktionen von vSphere 4.0 in der neuen DELL Management Console zusammengeführt werden.

vSphere 4.0 Client unter Windows 7

Thursday, 16 July 2009 16:28:03 (W. Europe Daylight Time, UTC+02:00)
Leider funktioniert der vSphere 4.0 Client nicht mit der Version des .NET Frameworks unter Windows 7. Aber natürlich gibt es dafür einen eleganten Workaround, daß dem vSphere Client auf die Sprünge hilft.



Im VMware Forum habe ich die folgende Anleitung gefunden, die ein Mitstreiter veröffentlicht hat:

An dieser Stelle erst einmal Danke an die aktiven Mitstreiter in den Foren. Leider kommt es auf der deutschen Community offensichtlich nicht zu einer so großen Nutzerzahl, die auch regelmäßig Neues kundtun, so dass es leider an den Bloggern bleibt technische Tricks und Raffinessen zu veröffentlichen. Schade eigentlich! Nun zum Thema:

Von einem Nicht-Windows-7 Rechner (am Besten Windows Vista oder Windows XP) wird folgende Datei benötigt:
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\System.dll



Hier am Beispiel eines Windows 2008 Servers x64 Edition mit SP2 und .NET 3.5 SP1.

System.dll zum Herunterladen: System.dll.zip (1,01 MB)

Hierbei handelt es sich um eine .Net 3.5 SP1 Datei, die zum Ausführen des vSphere 4 Clients unter Windows 7 RC benötigt wird. Als nächstes muss ein neuer Ordner im Installationsverzeichnis des VMware vSphere Clients mit der Bezeichnung „Lib“ erstellt werden. Je nach Version (x64 oder x86) liegt dieser unter:
32 Bit Version
%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib

64 Bit Version
%ProgramFiles(x86)%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib

Nachdem der Ordner erstellt wurde, die System.dll Datei hierher kopieren. Anschließend muss folgende Datei in einem Texteditor geladen werden:
<VMware Client Installationsverzeichnis>\Launcher\VpxClient.exe.config

Es muss ein zusätzliches Runtime Element hinzugefügt werden:
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>

Die fertige Datei sollte ungefähr so aussehen:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.net>
<connectionManagement>
<clear/>
<add address="*" maxconnection="8" />
</connectionManagement>
</system.net>
<appSettings>
<add key = "protocolports" value = "https:443"/>
</appSettings>
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
</configuration>

Um den Client zu starten ist ein kleines Batchskript notwendig.
<VMware Client Installationsverzeichnis>\Launcher\VpxClient.cmd

Der Inhalt ist wieder je nach Windows 7 RC Edition unterschiedlich

32 Bit Version
SET DEVPATH=%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib
"%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe"

64 Bit Version
SET DEVPATH=%ProgramFiles(x86)%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\lib
"%ProgramFiles(x86)%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe"

Mit der Batch Datei lässt sich nun der Client ohne Fehler starten.





Als Alternative kann man auch die "DEVPATH" Variable als neue Systemvariable oder Benutzervariable hinterlegen, dass erspart einem dann die Batchdatei. Wichtig ist, dass die DEVPATH Variable ohne Anführungszeichen für den String Wert hinterlegt wird, sonst klappt es nicht und Windows 7 meldet, dass die Anwendung nicht mehr funktioniert.
Nachtrag:
Der Workaround funktioniert nur dann, wenn beim Startaufruf für den Client keine weiteren Parameter mitgegeben werden wie etwa:
  • Sprachpaketfixierung: -locale en-us
  • Fixer Anmeldeserver: -s "vcserver.domain.tld"
  • SSO: -passThroughAuth (in vSphere 4.0, obsolete; einfach den Checkbox setzen)

Neuinstallation eines ESX Servers mit FC-SAN Anschluss

Thursday, 09 July 2009 14:31:00 (W. Europe Daylight Time, UTC+02:00)
Bisher war es immer sehr mühselig einen Host neu zu installieren, wenn dieser Host komplett gezont war und noch Zugriff auf die SAN hatte. Früher musste man am besten den Host entweder ohne verbundene FC Kabel starten, oder aus der Zone nehmen (FC-Fabric) oder eben auf der SAN selber den Zugriff für den Host auf die LUNs verhindern.

Dieser Prozess bedarf immer der Zusammenarbeit über Abteilungen hinweg, da in der Regel die Serveradministratoren keinen Zugriff auf die SAN Verwaltung besitzen und umgekehrt. Im Web gabe es Anleitungen, wie man von der ESX Server CD die SAN Treiber Optionen beim Installationsstart  entfernt, aber dass war natürlich mit jedem Versionswechsel erneut durchzuführen und damit sehr Pflege intensiv.

Mit vSphere 4.0 wird alles besser!
Wie ich in den vergangenen Wochen erfreulich feststellen konnte, erkennt der ESX Server jetzt alle LUNs, auch die lokale LUN (vmfs) und ändert die Reihenfolge der Laufwerke nicht mehr, denn mit ESX 4.0 wurde die Identifizierung der LUNs / Laufwerke auf NAA-Format umgestellt und die LUN / Laufwerkszuordnung ist und bleibt persistent!

Damit kann man nun ohne Eingriff in die SAN Verwaltung ESX Server installieren, sehr cool :-)

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.

Fault Tolerance Checkliste für den Einsatz

Thursday, 11 June 2009 08:10:08 (W. Europe Daylight Time, UTC+02:00)

VMware Fault Tolerance bietet kontinuierliche Verfügbarkeit bei Hardwareausfällen – ohne Datenverlust oder Ausfallzeit für alle Anwendungen. Folgende Punkte müssen erfüllt sein damit eine VM im Fault-Tolerance Modus betrieben werden kann:

Allgemein:

  • Shared Storage (NFS, iSCSI, FC)

ESX Host:

  • Minimal drei ESX 4.0 Server mit gleichen Prozessorfunktionen
  • Der Build-Stand des VMware Kernels muss auf den ESX Servern installiert sein
  • Hyperthreading im BIOS der physischen Server muss deaktiviert sein
  • Eine Netzschnittstelle für FT (aktivierte VMkernel Port Group) muss auf jedem ESX Host konfigueriert sein. Die Bandbreite muss zwei Gigabit-Ethernet betragen!
  • Eine Netzschnittstelle für vMotion (aktivierte VMkernel Port Group) muss vorhanden sein
  • Power Management (Power-Capping) im BIOS der Server sollte deaktiviert sein
  • Hardware Virtualisierung muss im BIOS des ESX Server aktiviert sein

Cluster:

  • Der HA Modus muss aktiviert sein
  • Server Zertifikate müssen verwendet werden
  • Der Anwender, der den FT Modus einstellen will, muss die Berechtigung / Benutzerrolle "Cluster Administrator" konfiguriert haben

VM:

  • Die einzelne VM darf maximal 1 vCPU konfiguriert haben
  • Die Port Group der VM braucht einen Uplink analog zu vMotion
  • Die VMDK Dateien (alle!!!) müssen im Eagerzeroedthick Modus angelegt worden sein
  • Es können keine RDMs im Modus "Physical RDM" genutzt werden
  • Die VM muss nicht ausgeschaltet sein, wenn man den FT-Modus aktivieren möchte
Beim Anlegen einer VM über den vSphere Client wird direkt abgefragt, ob die VM im Kompatibilitätsmodus für FT erstellt werden soll. Diese Option verhindert allerdings, dass die Option Thin Provisioned genutzt werden kann. Ist man sich nicht hundertprozent sicher, ob man die neue VM im FT Modus nutzen möchte, so sollte man den FT Kompatibilitätsmodus immer auswählen. Dabei sollte man immer bedenken, dass es neben FT und geclusterten VMs auch die Option zur redundanten Vorhaltung von Diensten und Anwendungen gibt, der die Hostkonfiguration erheblich erleichtert, denn realistisch betrachtet bindet man mit FT immer gleich zwei Hosts! Wichtig ist, dass FT eine Clusterfunktion ist und so nicht über Clustergrenzen funktioniert. Ferner ist ein Spiegeln von VMs über eine Weitverkehrsstrecke weder von VMware unterstützt noch ratsam.

ssh Zugriff für ESXi 4.0.0 Releasebuild-164009

Saturday, 30 May 2009 10:43:55 (W. Europe Daylight Time, UTC+02:00)

Installiert man den ESXi Server, so hat man zur Administration normalerweise keine vollwertige Konsole mehr zur Verfügung. Die Administration erfolgt dabei exklusiv über die GUI des vSphere 4.0 Clients oder über die direkte Konsolenausgabe des ESXi Hypervisors. Für den VMware Support gibt es allerdings die Möglichkeit den ssh Zugriff auf den ESXi Host zuzulassen.

Dieser Modus kann wie folgt freigeschaltet werden:

1. Zunächst muss man einmal an die Originalkonsole kommen:

An der Originalkonsole des ESXi Hosts mit der Tastenkombination ALT-F1 drücken um in die reguläre Konsole zu kommen.

2. Nun muß man blind das Wort unsupported eingeben und danach enter drücken.

Die Aufforderung zur Eingabe des root Passworts erfolgt, hier geben Sie dass vormals konfigurierte root Passwort ein, wichtig ist dabei, dass das Original Tastaturlayout verwendet wird! Wenn nun German Keyboard bei der Basiskonfiguration ausgewählt worden ist, dann finden sich leider die Tasten auf einer anderen Position wieder, wie etwa Y = Z etc. :-)


3. Wenn man sich beim root Passwort nicht vertippt hat, sollte man nun die Kommandozeile des Hosts sehen ~ #. An dieser gibt man nun den Befehl vi /etc/inetd.conf ein.

4. In der Datei initd.conf muß man nun die Zeile finden, die mit #ssh beginnt. Wenn der Kursor auf dem Raute Zeichen steht kann man dieses durch drücken der “x” Taste auf der Tastatur entfernen und die gemachte Änderung danach durch drücken der ESC - Taste und dem Befehl :wq speichern.

5. Man kann die Änderung nun einfach durch einen Neustart aktivieren, oder man arbeitet noch etwas mit der Komandozeile weiter um mit dem Befehl ps | grep inetd die Prozessnummer des inetd raus zu bekommen. Hat man diese kann man diesen mit dem Befehl kill -HUP [Prozessnummer] terminieren und automatisch neustarten. Der SSH-Zugang ist jetzt freigeschaltet.


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 Converter 4.0.1 Standalone

Friday, 22 May 2009 12:04:58 (W. Europe Daylight Time, UTC+02:00)
Mit dem Erscheinen von vSphere 4.0 kommt auch eine neue Version des Converters raus, der Versionssprung ist zwar relativ gering, aber ein paar interessante Änderungen kann man in den Release Notes nachlesen:


Leider sind die "Release Notes" mal wieder nur auf Englisch verfügbar.

VMware vCenter Converter Standalone 4.0.1 Release Notes

VMware vCenter Converter Standalone 4.0.1 | 5/21/2009 | Build 161434

Last Document Update: 5/21/2009

Introduction to VMware vCenter Converter Standalone 4.0.1

VMware vCenter Converter Standalone provides an easy-to-use solution to automate the process of creating VMware virtual machines from physical machines (running Windows and Linux), other virtual machine formats, and third-party image formats. Through an intuitive wizard-driven interface and a centralized management console, Converter Standalone can quickly and reliably convert multiple local and remote physical machines without any disruptions or downtime.

Benefits

  • Convert physical machines running Windows and Linux operating systems to VMware virtual machines quickly, reliably, and without any disruption or downtime.
  • Convert third-party formats such as Parallels Desktop, Symantec Backup Exec System Recovery, Norton Ghost, Acronis, StorageCraft, and Microsoft Virtual Server or Virtual PC to VMware virtual machines.
  • Enable centralized management of remote conversions of multiple physical servers or virtual machines simultaneously.
  • Populate new virtual machine environments from a large directory of virtual machine appliances.
  • Ensure conversion reliability through quiesced snapshots of the guest operating system on the source machine before data migration.
  • Enable non-disruptive conversions through hot cloning, with no source server downtime or reboot.

What's New

The VMware vCenter Converter Standalone 4.0.1 release is an update to Converter Standalone 4.0, and includes the following new features:

  • Support for vSphere 4.0 as source and destination targets:
    • Support for configuring target disks as thin provisioned disks
    • Support creation of IDE disks on vSphere 4.0
    • Support for backup products to restore vSphere 4.0 virtual machines backed up using VCB
    • Support for creation of virtual hardware version 7.0 virtual machines on vSphere 4.0. targets as well as migration of hardware version 7.0 virtual machines from Workstation and Server platforms to vSphere 4.0
  • Support for importing OVF 1.0 single virtual machine images.
  • Support for customization of Windows Server 2008 guests.

Der Upgradepfad zu vSphere 4.0

Friday, 22 May 2009 10:35:01 (W. Europe Daylight Time, UTC+02:00)
Nachdem die Katze aus dem Sack ist und nun alle wissen, dass die Subscription von VMware VI 3.5 nur zur "Enterprise Edition" langt, kommt hier der offizielle Lizenz-Upgrade-Pfad für alle, denen "Enterprise" nicht genug ist. Bis zum 15. Dezember 2009 hat man die Möglichkeit sich für eine Gebühr pro Sockel auf die neue "Enterprise Plus" Suite zu entscheiden und damit alle Funktionen aus vSphere 4.0.



Die neuen Editionen bieten einige Änderungen gegenüber den früheren Versionen von VMware VI 3.x. So kann man bereits ab der "Advanced Edition" mit vMotion seine Gäste durch das Rechenzentrum "jagen" und FT ist auch schon bereits integriert, was bis vor kurzem ein Alleinstellungsmerkmal unter XEN mit der hervorragenden Technik von Marathon VM war. In der nächsten Version wird VMware diese FT Funktion dann auch für vSMP Gäste unterstützen, aber dazu später mehr.



Was fällt auf? Nichts? Na dann schauen wir mal auf die Details, denn was Einigen nicht klar sein dürfte ist die Tatsache, dass zum einen die "Enterprise Edition" vom Aussterben bedroht ist und durch die Plus Varienate ersetzt wird und in den meisten kleinen Umgebeungen bereits mit der "Advanced Edition" die richtige Variante verfügbar ist, zu deutlich geringeren Konditionen als zuvor. In diesem Zusammenhang sei erwähnt, dass die Lizenzierung umgestellt worden ist. Es werden jetzt keine 2xCPU Lizenzen mehr angeboten, sondern man kann jeden Sockel einzeln als für jede CPU eine Lizenz erwerben. Das macht auf den ersten Blick zwar villeicht nicht sofort einen Sinn machen, allerdings möchte ich darauf hinweisen, dass für Single Sockel Systeme jetzt eine bessere Flexibilität besteht.

vSphere 4.0 startet

Thursday, 21 May 2009 10:22:12 (W. Europe Daylight Time, UTC+02:00)
Seit heute Morgen ist der Download der lange erwarteten Version 4.0 von VMwares Virtualisierungslösung zum Download freigegeben.
Neben den registrierten Benutzern, die auf die aktuelle Version aktualisieren können, kann jedermann nach einer Registrierung bei VMware die komplette Suite, allerdings ohne den CISCO Nexus 1000v kostenfrei herunterladen und 60 Tage testen.


Unter der bekannten Adresse kann das Produkt und die Dokumentation gefunden werden.
Für alle die es kaum abwarten können loszulegen hier noch ein kleiner Tipp:

Abwarten kann das Leben des IT-Verantwortlichen dramatisch verlängern!

Damit apeliere ich an alle Bestandskunden, die neben dem ESX Server und dem vCenter Server noch andere Rechenzentrumsanwendungen oder die VMware View Komponenten nutzen! Denn diese werden allesamt nicht mit vSphere 4.0.0 unterstützt. An alle Kunden die "nur" VI 3.5 einsetzen sei gesagt, dass der vollständige Funktionsumfang der Version 4.0 Komponenten nur über die Edition Enterprise Plus zur Verfügung stehen. Hier müssen Bestandskunden von VMware eine kleine Upgrade Gebühr leisten um alle Funktionen inklusive
  • 8 x vCPU SMP Unterstützung
  • Host Profiles
  • dVSwitches und den Cisco Nexus 1000v
nutzen zu "dürfen".

vSphere 4.0 Die offizielle Vorstellung

Tuesday, 21 April 2009 11:09:18 (W. Europe Daylight Time, UTC+02:00)
Heute ist dann wohl Dooms-Day für Microsoft und Citrix, die beiden großen Gegenspieler von VMware im Bereich der Virtualisierung von x86/x64 Windows Systemen und allem anderen was auf dieser Plattform so lauffähig ist.



Die Ankündigung von VMware ist schonmal so verschickt worden:

Sehr geehrte Damen und Herren,
VMware ist aufgrund seiner innovativen Technologie und beispiellosen langjährigen Erfahrung führend in der Virtualisierungsbranche. Jetzt stellen wir unsere neueste bahnbrechende Entwicklung vor – VMware vSphere™ 4.
Nutzen Sie das VMware vSphere Kit und erfahren Sie, wie Cloud Computing mit VMware vSphere Ihre IT-Abläufe optimiert und folgende Vorteile ermöglicht:
•    Senkung der Investitions- und Betriebskosten um über 50 Prozent
•    Automatisierung der Servicequalität für höhere Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit und Sicherheit
•    Freie Wahl bei Hardware, Betriebssystemen, Anwendungs-Stacks und Serviceanbietern

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 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.


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.