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

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’

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

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

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!

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.

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

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

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.

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

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/

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

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.

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!

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.

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.

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

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.

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.

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)

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:

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.

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.

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.

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.

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.

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.

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.