Datenfront

Mozilla Firefox ist neben Google Chrome einer der weitverbreitesten Multiplattform Browser, der auch Techniken wie HTML5 unterstützt. Da in vielen Unternehmen noch im Intranet Webanwendungen verwendet werden, die auf IE6 Techniken und Spezialitäten eingerichtet sind, bietet es sich an den Firefox als alternierenden Webbrowser einzusetzen. DAgegen spricht, dass es keinen GPO-Support durch Microsoft oder die Mozilla Foundation gibt, analog zum Chrome Browser. Allerdings lässt sich der Firefox Webbrowser hervorragend an einen Kiosk Modus wie etwa auf einem Terminalserver oder Thin Client anpassen. Dazu gibt es zwei verschiedene Ansätze, bei denen Mittels entweder einer Referenzdatei die Menüstruktur des Webbrowsers zentral vorgebenen wird, oder eben eine freie Erweiterung für die Unterstützung von GPOs / ADMx Templates. Mit GPO for Firefox kann man die Standardeinstellungen für die Startseite und Proxy festlegen und eben auch bestimmte Funktionen zentral und flexibel sperren.

Um GPO for Firefox zu verteilen sind im Wesentlichen drei Komponenten notwendig:

1. Ein ADM-Template für den Gruppenrichtlinieneditor, über den man die zentralen Einstellungen festlegt
2. Eine Firefox-Extension, damit Firefox abfragt, ob es zentrale Einstellungen per GPO erhalten soll
3. Ein Skript oder eine Alternativmethode, um die Extension automatisch an alle Clients zu verteilen (nicht zwangsläufig notwendig!!!)
   

Um die Extension als globale Erweiterung auf die Clients zu verteilen, wird die .XPI-Datei (Ordner mit den Extension-Dateien) aus “%ProgramFiles%\Firefox\Extensions\” kopiert und im NETLOGON-Verzeichnis eines DCs in einen Unterordner abgelegt. Per Startskript erhalten die Anwender anschließend den entsprechenden Ordner in ihr Programmverzeichnis kopiert, sofern dieser noch nicht (in der aktuellen Version) vorhanden ist. Wurde die Extension erfolgreich installiert, seht ihr auf Euren Clients folgendes Icon im rechten Bereich der Statusleiste:

Mit dem Standard-Gruppenrichtlinien-Editor können dann die Einstellungen gesetzt werden:

Neben dieser Option ist auch möglich den kompletten Browser selber anzupassen. Dazu müssen lediglich ein paar .JS Dateien angepasst werden:

user.js / prefs.js

In diesen beiden Dateien werden die einstellungen vom Firefox Browser abgelegt. Dazu gehören eben auch die Einstellungen, die Mittels GPO gesetzt werden können. Dabei ist es wichtig, dass die Datei user.js angelegt und angepasst wird und nicht die Datei prefs.js da diese durch den Anwender angepasst werden kann. Bei jedem Start einer neuen Instanz von Firefox überprüft die Browserengine, ob eine user.js Datei existiert und überschreibt dann die Werte in der prefs.js zum Start der Instanz.

userChrome.css

Mit Hilfe der Einstellungen in dieser Datei lässt sich der Browser limitieren, so dass Anwender nicht mehr in der Lage sind Erweiterungen personalisiert ablegen zu können, da diese evetuell nicht sicher sind, oder schlicht für den kommerziellen Betrieb nicht freigegeben sind und andernfalls lizenziert werden müssten. Danach startet der Browser im Kiosk Modus und ist sicher für den Tagesbetrieb. Ebenfalls ist dadurch die automatische Update-Funktion des Browsers deaktiviert!

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.

Nachdem ich ja nun bekennender MAC Switcher bin und das Ganze auch seit zweieinhalb Jahren nicht bereue finde ich immer mehr zu einer nativen Nutzung unter OSX. Jetzt ersetzt bei mir Office 2008 auch das Office in meiner Windows VM vollständig, nachdem ich mich als zu "dumm" für OpenOffice bekenne bleibe ich dann doch wohl oder übel bei der Büro Suite aus Redmond.
findet man sich in Word und Co. recht schnell wieder zurecht, so ist der Umstieg von Outlook 2007 in Verbindung mit Exchange 2007 nach Entourage doch etwas härter, wenn auch abbildbar, man muss die Funktionen halt nur an der richtigen Stelle suchen und finden... .

So vermisste ich doch die Möglichkeit meine E-Mails nachzuverfolgen, beispielsweise in Form einer Empfangsbestätigung, oder besser einer Lesebestätigung, was unter der Windows Anwendung nur zwei Mausklicks sind ist dann doch etwas versteckter in der OSX Variante wieder zu finden und zu lieben / hassen:
Man wähle sein E-Mail Konto aus über das Menü "Extras | Konten..." aus und trage die beiden folgenden Zeilen, wie oben abgebildet als zusätzliche Kopfzeilen unter Optionen ein:

Return-Receipt-To               "<mein_name@meine_domain.tld>"
Disposition-Notification-To  "<mein_name@meine_domain.tld>"

Damit erreicht man zum Einen die Empfangsbestätigung "Return-Receipt" und auch die Lesebestätigung. Die <> Klammern dienen nicht zum Ärgern, sondern helfen strickten SMTP Servern reguläre Adressen zu übermitteln. Ein exemplarischer Internetheader sieht dann wie folgt aus:

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.

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.

Dieser Artikel ist eine kleine Anleitung zum Archivierungswerkzeug “Tar”. Hier werden die “Basisfunktionen” kurz erläutert und darüber hinaus einige Kniffe und sinnvolle Anwendungsbeispiele vorgeführt. Tar ist ein Archivierungswerkzeug, das heißt man kann beliebig viele Dateien zu einer Datei, einem Archiv, zusammenfügen. Tar an sich ist kein Komprimierungstool, aber mit der “Erweiterung”/Option gzip und anderen kann man ein Archiv auch komprimieren. Den folgenden Artikel habe ich auf einem Blog im Internet gefunden und fand diesen so gut, dass ich den direkt eingebaut habe, alles was in den Beispielen für ubuntu beschrieben wurde gilt, wenn man mal über die Pfadangaben hinweg sieht uneingeschränkt für VMware ESX Server, deren SC Betriebssystem entweder RHEL 5.0 (ESX Server 4.0.0) oder RHEL 3 Update 9 (ESX Server 3.x.0)

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 VCB wird oft unterschätzt, auch wenn das entsprechende Framework mit der Version 1.5 wohl den finalen Release erreicht hat und die Entwicklung von weiteren VCB Frameworks an die Hersteller von Wiederherstellungssoftware abgetreten wurde, eignet es sich hervorragend um komplette Exporte zur Desaster Recovery Vorsorge zu erstellen. Die Integration in die bestehende Datenwiederherstellungssoftware ist allerdings manchmal sehr holprig und die Ansätze zur Integration des VCB sind von Hersteller zu Hersteller stark unterschiedlich. Ein generalistischer Ansatz wäre da für alle etwas einfacher. Generell benötigt man für diese Methode der Datensicherung eigentlich nur einen einzelnen Befehl: vcbmounter.exe

Seit der Einführung Windows 2000 wurde das NLB Cluster als Loadbalancing Cluster von Microsoft für stateless Applications eingeführt. Was unter Windows 2000 nur den Kunden der Advanced Server Edition vorbehalten war, ist seit der Version Windows Server 2003 in allen Varianten verfügbar. Einziges Manko ist, dass diese preiswerte Clustermethode von Microsoft in den Handbüchern und technischen Referenzen etwas stiefmütterlich behandet wird und die wichtigsten Punkte nur über die Support Webseiten von Microsoft zu finden sind. Unter VMware möchten viele Kunden auf diese Option nicht verzichten, als Lösung innerhalb einer Virtualisierungsumgebung müssen allerdings zusätzlich zu den bestehenden Restriktionen weitere Punkte beachtet werden, damit ein NLB Cluster unter Windows stabil betrieben werden kann.

Der VMware UpdateManager (VUM) ist eine der Neuerungen in VI 3.5. Neben der Herausforderung der Installation und Konfigration des VUM kommt es immer wieder im Kundenumfeld zu Problemen mit dem Internetzugang für den VUM. Viele Firmen verwenden einen Proxyserver mit Authentifizierung für den Zugang zum Internet. Erschwerend für den VUM kann hinzukommen, dass der Kunde eine Proxykaskade einsetzt um einen mehrfach abgesicherten Zugang zum Internet zu bieten und / oder Zusätzlich Inhaltsfilter einsetzt, die das Herunterladen von EXE Dateien oder TAR Archiven unterbindet. Diese Konfigurationen lassen sich noch handhaben aber dazu mehr in einem separaten Blogeintrag später.

Seit der Version 3.5 können mehr als 16 GB RAM einer einzelnen VM zugeordnet werden. In den VMware Foren kann man dazu einige Einträge finden. Was steckt dahinter? Ist die Aussage einer VM bis zu 64 GB RAM zuweisen zu können nur eine Markting Aussage (als Ausblick in Zukunft kann man dynamisch bis zu 256 GB RAM zuordnen)?

Weder noch, es gibt de facto eine signifikante Änderung wenn man VMs mit mehr als 10 GB RAM ausstattet. Fehlerbilder sind eindeutig, der Boot des Systems dauert über eine halbe Stunde, oder bricht sogar ab, nimmt man der VM wieder diese Summe an RAM weg, so dass diese nur noch zwei bis vier GB RAM hält, dann startet dieses System ohne das Fehlerbild schnell und konsistent.

Als Lösung ist folgende Vorgehensweise meistens von Erfolg gekrönt:

1. Einer VM nicht einfach so mehr als vier GB RAM zuweisen! Planen Sie den Einsatz von "großen" VMs.
2. Soll eine VM sehr viel RAM und / oder zusätzlich vCPU Ressourcen erhalten, so sollte das Pagefile auf eine dedizierte VMDK verlagert werden.
3. Als Faustformel sollte man bei 16 GB RAM eine 20 GB Pagefile Date auf eine dedizierte 30 GB VMDK verlegen.
4. Wird die RAM-Größe deutlich überschritten, so muss auch das Pagefile mitwachsen, aber nicht dynamisch! Die Größe sollte fix eingestellt sein und
   immer größer als der physische RAM sein. Als Anhaltspunkt kann der Vorschlag des OS dienen.
   

Die Konvertierung von produktiven Systemen sollte man keinem Zufall überlassen, daher nutze ich für die Konvertierung von Systemen ausschließlich (wenn möglich) die Boot-CD (coldclone.iso) von VMware um in Projekten Systeme P2V zu migrieren. Obwohl diese Variante für beste Ergebnisse im Rahmen der Virtualisierung bürgt, kann es in der Praxis immer wieder zu Problemen kommen. Neben der Herausforderung alle Treiber für HBAs und NICs zu integrieren ergeben sich immer wieder Probleme im Bereich des Kopiervorgangs während der Migration. Generell ist zwischen zwei Methoden zur Datenübertragung mit Converter zu unterscheiden. Die schnellste variate ist die Migration der Daten im Block-Leseverfahren. dabei werden die Inhalte der Festplatte einfach Block für Block ausgelesen und in die VMDK Datei geschrieben. Eine Alternative bietet die Option des Transfers auf Dateiebene, der automatisch immer dann genutzt wird, wenn die Größe der Quellpartitionen im Verhältnis zur Ziel VMDK Datei geändert werden. Dabei spielt es keine Rolle, ob die Ziel VMDK Datei größer oder kleiner ist, als die Quelle. Je älter das Quellsystem ist, desto eher finden wir vor Ort langsame Plattensubsysteme mit einer starken Fragmentierung und / oder fehlerhaften Blöcken vor, die immer wieder zu Problemen führen können.

Das will niemand sehen, aber es passiert! Der PSOD schlägt zu und der ESX Server steht, wie einst das gute alte Windows NT 4.0.
Im Gegensatz zu Windows NT damals, tritt der PSOD (Purple Screen Of Death) zum Glück sehr selten beim ESX Server auf, aber wir wollen es nicht verheimlichen, es gibt ihn diesen Albtraum eines Systemadministrators! Leider gibt es einen echten Bug in VMware ESX Sever Version 3.5.x.

Dieser Fehler tritt in folgender Hardwarekonfiguration auf:
DELL PE 29x0 III Server mit PERC/6i S-AS Controller.

Von VMware gibt es dazu keinen Knowledgebase Eintrag, lediglich ein Eintrag im VMware Forum deutet auf das Problem hin.

Scannt man unter dem VI Client unter Configuration / Hardware / Storage Adapters die HBAs nach neuen VMFS Volumes oder LUNs, so stoppt der ESX Server mit einem PSOD!
Dieser Fehler ist bereits bei VMware bekannt und adressiert. Laut VMware wird dieser Fehler mit dem anstehenden Update 3 für VMware ESX 3.5.0 behoben. Bis dahin gibt es einige obskure Anleitungen in den VMware Communities für dieses Problem, die soweit gehen in Systemdateien des ESX Servers einzugreifen, dass ist unnötig und hilft in Abhängigkeit zur verwendeten BIOS Version der Servr auch überhaupt nicht.

Lösung:

Im BIOS der DELL Server ist nach der Basisinstallation der integrierte S-ATA Controller auszuschalten. Dadurch verliere ich zwar den Zugriff auf das lokale CD-ROM Laufwerk (S-ATA seit Version III der PE 29x0 Server), aber dafür kann man im laufenden Betrieb nach neuen SAN LUNs suchen und diese gefahrlos mounten. Diese Lösung funktioniert mit den genannten DELL PE Servern mit den BIOS Versionen 2.1.0, 2.2.6 und 2.3.1.

Alternative:

Wer unbedingt auf das integrierte CD-ROM Laufwerk nicht verzichten kann, der muss zur SAN Erweiterung jeden Host einmal neu starten. Beim Systemstart scannt der Server die SAN auf verfügbare / konfigurierte LUNs ab und kann in dieser Prozedur ohne Absturz auch neue LUNs persistent mounten.

As many of You suffer from the pain of the most boring part of VMware VI 3.5 - the installation of the hosts - I'm tryig to bring up a version of a kickstart script I wrote to install DELL PowerEdge Servers. In the early future I will adopt this for the unattended installation of FSC Primergy Servers as well. Let's have a closer look at it, but in German.

In den meisten Projekten werde ich immer wieder mit Fragen zum Thema Netzkonfiguration in virtuellen Umgebungen konfrontiert. Aus den Projekten hat sich im Laufe der Zeit eine Art Best Practise entwickelt, den ich gerne in der Reihe "Mein Netzwerksenf!" an dieser Stelle veröffentlichen möchte.

As we now have the patch, how to install the patch in the Enterprise with a minimum of downtime?

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

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

VMotion to this host is now again possible!!!
After the first host is considered as working "normal" You can go ahead with patching the rest one-by-one. Good luck, I'm with You!

As I mentioned yesterday there is a very big influence on how You set and change time information on an ESX host and the impact on VMs.
What I hardly learned was, that changing the ESX time information within the VI Client has direct impact on ALL running VMs on the particular host.

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

In the VMware communities, there is a solution that might work:
The real trick is to use the direct ssh access and change time information within the COS:
Be sure You are root

service ntpd stop
date -s 08/10/2008
esxcfg-firewall -d ntpClient

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

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

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

vmware-cmd /vmfs/volumes/[LUN]/[VM folder]/VM.vmx start --trysoft
wait for result = 1 (success)
esxcfg-firewall -e ntpClient
service ntpd star

Now You can set back the sdate within the VMs BIOS and start your VM; reenable DRS

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