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.

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.

Neuer Patch von VMware: ESX(i) 4.0.0U1a

Friday, 11 December 2009 18:07:42 (W. Europe Standard Time, UTC+01:00)


Nachdem es doch einige Probleme mit dem neusten Updatepaket von VMware gibt, hat der Softwarehersteller eine zweite Auflage des Update1 Paketes für ESX(i) 4.0.0 herausgebracht. Der Patch ist vornehmlich an alle Kunden gedacht, die zum Einen Hardwareagenten in der Service Console oder modifizierte ESX(i) Varianten einsetzten und zum Zweiten die Updatepakete per Updatemanager installieren.
Neben dem ersetzenden Update1 Paket kommt direkt noch ein weiterer Patch für das GLIBC Paket mit, das auch außer der Reihe publiziert worden ist.
Kunden die bereits Update1 auf den ESX(i) ausgebracht haben erhalten lediglich ein Update der GLIC Bibliothek und eine Änderung in der Paketverwaltung von RedHat (RPMD).
Das Updatepaket kann jetzt, wie gewohnt über den UpdatemNager auf die Hosts ausgebracht werden.

Alle Knowledgebase Artikel zum Patch:

KB1016070

Due to a possible dead lock on rpmdb, upgrading ESX 4.0 to 4.0 Update 1 can fail or time out and leave the host in an unusable state

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

KB1016262

vCenter agent service does not install or upgrade on ESXi 4.0 hosts

http://kb.vmware.com/kb/1016262

KB1014842

VMware ESX 4.0, Patch ESX400-Update01a

http://kb.vmware.com/kb/1014842

KB1014797

VMware ESX 4.0, Patch ESX400-200912101-UG: Updates Service Console glibc

http://kb.vmware.com/kb/1014797


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

Virtueller vCenter Server

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

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

Umbennen des vCenter Servers

Wednesday, 12 August 2009 09:58:50 (W. Europe Daylight Time, UTC+02:00)
Seit der Version 2.5 bietet VMware offiziell Unterstützung an zur Umbenennung der Windows Instanz.
Mit der Einführung von vSphere 4.0 und dem vCenter Server 4.0 sollte der Prozess sehr einfach werden, schlicht den Server umbenennen und anschließend neu starten.
Danach sollte der vCenter Server einfach funktionieren. Das funktioniert auch mit den Basiskomponenten ohne Probleme!

Allerdings steckt der Teufel mal wieder im Detail und so muss doch noch etwas mehr getan werden als einem Recht sein kann:
Alle Plug-Ins und Zusatzkomponenten müssen zusätzlich doch noch angefasst werden.
In den Vorgängerversionen gab is zumindest die Reparaturoption über den Einstiegsdialog zum Installieren von Anwendungen in der Systemsteuerung, leider ist diese Option gänzlich aus dem Installer für den vCenter Updatemanager entfernt worden und so muss man, wenn man nicht die XML Dateien editieren will immer die komplette Komponente deinstallieren und anschließend wieder neu installieren, was einen weiteren Change Request zur Folge haben kann.

Manuell können die Eerweiterungen über die Konfigurationsdateien auf dem vCenter System konfiguriert werden:
Für jedes Plug-In / Extension muss im entsprechenden Verzeichnis die extension.xml Datei modifiziert werden, da hier der FQDN der vCenter Servers enthalten ist. Im Anschluss daran muss dann die Systemregistrierung überprüft werden. Unter HKLM\Software\VMware Inc. befinden sich mehrere hinterlegte Einträge mit dem FQDN des vCenter Systems.
Danach ist das vCenter System komplett funktionsbereit. :-)

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/

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

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

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

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

VMware vSphere - Der Release Candidate 1 ist geschlüpft

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



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

VMware HA Konfiguration und Fehlermeldungen

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

VMware EVC einschalten

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

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

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

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

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


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