VOSICHT UPDATE: vSphere 4.0 Update 1

Auf Update 1 von VMware vSphere ESX 4.0 upzugraden, ist momentan riskant: Es kann passieren, dass der geupdatete ESX Host nicht mehr gebootet werden kann - Purple Screen Of Death (PSOD):

Feherdarstellung:

• Upgrade schlägt fehl oder bleibt "hängen", mit der Folge, dass das Update nicht vollständig abgeschlossen werden kann und zu einer fehlerhaften Installation führt
• Nach Rebooten ist der geupdatete Host in einem "inkonsistenten Zustand" (PSOD) und zeigt folgende diagnostische Fehlermeldung an:
  
  COS Panic: Int3 @ mp_register_ioapic

Aktuell: Wer heute auf die VMware Downloadseite geht, erhält folgende Warnung: "VMware has discovered an issue with upgrading to Update 1 described in KB article 1016070. A new build will be uploaded as soon as it is available."

Umgehung des Problems: Das Problem lässt sich umgehen, wenn man Hardware-Monitoring-Software und Management-Agenten von Drittherstellern vor der Installation des Upgrades z.B. durch VUM deaktiviert (nach dem Update kann man diese dann wieder aktivieren).

Wer ist betroffen

Alle, die von VMware vSphere 4 auf ESX 4.0 U1 upgraden und einen Management wie z.B. den  HP Insight Management Agent auf dem Host zu laufen haben

Dies bezieht sich auf folgende Update-Möglichkeiten:

• Upgrade mit dem  Update Manager
• Upgrade mit esxupdate
• Upgrade durch das vSphere Host Update Utility

Bemerkung: ESXi ist nicht betroffen!

Lösung (am Beispiel des HP Insight Management Agents)

Um einem möglichen PSOD zuvorzukommen, sind vor dem Update die HP Insight Management Agents, die auf dem ESX 4.0.0 Server laufen, zu beenden.

HP Insight Management Agenten kann man beispielsweise durch folgende Befehlszeilen deaktivieren:

• service hpsmhd stop
• service hp-snmp-agents stop
• service hp-health stop

Die Management Agents können nach dem Update wieder gestartet werden!

Wer bereits den ESX Host geupdated hat, sollte diesen nicht neu booten! VMware hilft betroffenen Kunden, das Problem zu lösung und ggf. Ihre Daten zu retten!

Wer ganz sicher gehen möchte, sollte sich noch ein paar Tage gedulden mit dem Update.

Wer bereits geupdatet hat,  riskiert im schlimmsten Fall nach dem Booten den Verlust der VMs auf lokalem Host-Speicher (DAS), da der Host u.U. nicht mehr wiederbelebt werden kann!

Status Update 19.12.09:  Mit dem gerade eben veröffentlichten neuen Build 208167 wurde das oben genannte Problem gelöst! Es müssen nicht mehr manuell - wie oben beschrieben - die Dienste vor der Installation des Updates gestoppt werden. Natürlich wurden auch eine Menge anderer Probleme und Bugs behoben, siehe hier: VMware ESX 4.0 Update 1 Release Notes 19th December 2009, Build 208167

vSphere 4.0 Update 1 - VORSICHT!!!

Das Update 1 ist halb zurückgezogen worden, also bitte nur installieren, wenn Sie sich des Riskios bewusst sind! Details: siehe nächster Post!

Seit dem 19.11. gibt es das Update 1 verschiedener Komponenten der vSphere-Software: Eine der  Neuerungen ist  die Windows 7 Unterstützung des Clients. Wer den Workaraound mit der Anpassung der Konfigdatei und Kopieren der System.dll zum Start des vSphere Client 4.0 unter Win7 eingerichtet hat, muss diese Änderungen rückgängig machen, damit der neue Client gestartet werden kann.

Ein wichtiges Feature des Update 1 ist die View 4 Unterstützung. View 4 ist wenige Stunden später auf den Servern von VMware und Akamai zum Download zur Verfügung gestellt worden:

Download des Update 1 für vSphere.

Hier die Release-Notes-Zusammenfassung auf Deutsch:


Release Notes vCenter 4 U1:

• View 4 Support
• Windows 7 und Windows 2008 R2 Support
• HA Cluster Maximum auf 160 VMs bei 8 Hosts und weniger im Cluster erhöht

Release Notes ESX 4 U1:

• View 4 Support
• Windows 7 und Windows 2008 R2 Support
• Erweiterungen für Microsoft Cluster
• VMware Paravirtualized SCSI wird nun auch für Boot Platten und nicht nur Datenplatten unterstützt
• Distributed vSwitches Performancesteigerung
• vCPU per Core Limit von 20 auf 25 erhöht
  

Release Notes VMware Data Recovery 1.1:

• File Level Restore Support
• verbesserte Integritätschecks
• erweiterter CIFS Share Support

Hinzu kommen noch unzählihge Features sowie auch zahlreiche Bug-Fixes. Darunter folgdende Highlights: FCoE/10Gb Unterstützung: 

1. 
   
   • Wir haben viele Anfragen bezüglich  der Unterstützung neuer CNA (converged network adapter) durch VMware: Kurz: Die Unterstützung wird immer besser, nachzulesen hier
   • The Qlogic CNA Treiber der 2. Generation (8100 series)  für vSphere sind nun endlich auch verfügbar: FCoE und Network
   
   
   
   
2. NMP (Änderung des Wertes des Parameters "IOoperationlimit" ):
   
   
   
   • Das Ändern des Wertes dieses Parameters von 1000 (Standard) auf 1 führt nach Reboot des ESX-Hosts zu sehr merkwürdigem Verhalten! Dieser Parameter steuert das Verhalten, wie viele I/Os erfolgen, bevor ein neuer Pfad gewählt wird wenn NMP Round Robin benutzt wird.
   • Kurzfassung: Am besten, nicht die Standard-Einstellung ändern, da das Verhalten dann momentan unvorhersagbar wird.
   • Obiges betrifft nicht PowerPath/VE-Anwender.
   
   

Nachzulesen: Hier und auch hier!

UPDATE: Schwachstelle in VMware Virtual Center vor Version 2.5 Update 4 - VMSA-2009-0002.2

Folgende Information möchten wir an dieser Stelle weitergeben:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Kolleginnen und Kollegen,

soeben erreichte uns nachfolgende Warnung des VMware-Teams. Wir geben
diese Informationen unveraendert an Sie weiter.

Bitte beachten Sie, dass dies ein Update des Advisories ist, das die
folgenden Aenderungen betrifft:

Mit diesem Update verweist VMware fuer Updates von vCenter 4.0 und ESX
4.0 auf das Advisory VMSA-2009-0016.


CVE-2008-2370 - Cross-site Scripting Schwachstelle in Tomcat ermoeglicht
Zugriff auf Vertrauliche Daten

Wird Tomcat fuer die Verwendung eines RequestDispatchers konfiguriert,
werden eingehende Anfragen vor der Weiterverarbeitung auf ein
einheitliches Format normiert. Ein Angreifer kann eine Schwachstelle
im Normierungsvorgang ausnutzen um Anfragen zu manipulieren und
Zugriff auf vertrauliche Daten zu erhalten.

CVE-2008-1232 - Cross-Site Scripting Schwachstelle im Apache Tomcat

Tomcat beinhaltet eine Cross Site Scripting Schwachstelle bei der
Fehlerbehandlung. Ein der Funktion 'HttpServletResponse.sendError()'
uebergebenes Argument wird nicht nur im Error-Log angezeigt sondern
auch im HTTP-Response Header auf die fehlerhafte Anfrage verwendet.
Ein Angreifer kann diese Schwachstelle ausnutzen um HTTP-Header zu
manipulieren und so Cross-Site Scripting Angriffe durchfuehren.

CVE-2008-1947 - Cross-Site Scripting Schwachstellen im Apache Tomcat

Die Host Manager Anwendung in Apache Tomcat filtert die uebergebenen
Parameter 'name' in den Skript 'host-manager/html/add' ungenuegend auf
enthaltenen Skript- oder HTML-Code und kann so fuer Cross-site
Scripting Angriffe missbraucht werden. Entfernte Angreifer, die sich
in der Anwendung authentifiziert haben, koennen dadurch Scriptcode im
Browser anderer Benutzer ausfuehren.

Betroffen sind die folgenden Software Pakete und Plattformen:

Virtual-Center 2.5 fuer Windows ohne Update 4
Virtual-Center 2.0.2 fuer Windows
VMWare Server 2.x
VMWare ESX 3.5 ohne Patch ESX350-200910403-SG
VMWare ESX 3.0.3
VMWare ESX 3.0.2

Alle Plattformen fuer die das VMware Virtual Center verfuegbar ist.

Vom Hersteller werden ueberarbeitete Pakete zur Verfuegung gestellt.

Hersteller Advisory:
http://www.vmware.com/security/advisories/VMSA-2009-0002.1
http://www.vmware.com/security/advisories/VMSA-2009-0002.2


(c) der deutschen Zusammenfassung bei DFN-CERT Services GmbH; die
Verbreitung, auch auszugsweise, ist nur unter Hinweis auf den Urheber,
DFN-CERT Services GmbH, und nur zu nicht kommerziellen Zwecken
gestattet.

Mit freundlichen Gruessen,
Torsten Voss

- --

Dipl.-Ing.(FH) Torsten Voss (Incident Response Team)

DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

Automatische Warnmeldungen https://www.cert.dfn.de/autowarn

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- - ------------------------------------------------------------------------
VMware Security Advisory

Advisory ID: VMSA-2009-0002.2
Synopsis: VirtualCenter Update 4 and ESX patch update Tomcat
to version 5.5.27
Issue date: 2009-02-23
Updated on: 2009-11-20
CVE numbers: CVE-2008-1232 CVE-2008-1947 CVE-2008-2370
- - ------------------------------------------------------------------------

1. Summary

Updated VMware VirtualCenter Update 4 and ESX patch update Tomcat
packages.

2. Relevant releases

VirtualCenter 2.5 before Update 4
ESX 3.5 without patch ESX350-200910403-SG

3. Problem Description

a. Update for VirtualCenter and ESX patch update Apache Tomcat version
to 5.5.27

Update for VirtualCenter and ESX patch update the Tomcat package to
version 5.5.27 which addresses multiple security issues that existed
in the previous version of Apache Tomcat.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the names CVE-2008-1232, CVE-2008-1947 and
CVE-2008-2370 to these issues.

The following table lists what action remediates the vulnerability
(column 4) if a solution is available.

VMware Product Running Replace with/
Product Version on Apply Patch
======== ======== ======= =======================
vCenter 4.0 Windows see VMSA-2009-0016
VirtualCenter 2.5 Windows VirtualCenter 2.5 Update 4
VirtualCenter 2.0.2 Windows affected, patch pending

Workstation any any not affected

Player any any not affected

ACE any Windows not affected

Server 2.x any affected, patch pending
Server 1.x any not affected

Fusion any Mac OS/X not affected

ESXi any ESXi not affected

ESX 4.0 ESX see VMSA-2009-0016
ESX 3.5 ESX ESX350-200910403-SG
ESX 3.0.3 ESX affected, patch pending
ESX 3.0.2 ESX affected, end of life
ESX 2.5.5 ESX not affected

** Tomcat will be updated to version 6.0.20 in the next update release

Note: These vulnerabilities can be exploited remotely only if the
attacker has access to the Service Console network.

Security best practices provided by VMware recommend that the
Service Console be isolated from the VM network. Please see
http://www.vmware.com/resources/techresources/726 for more
information on VMware security best practices.

The currently installed version of Tomcat depends on your patch
deployment history.

4. Solution

Please review the patch/release notes for your product and version
and verify the md5sum of your downloaded file.

VirtualCenter
-------------
VMware VirtualCenter 2.5 Update 4
http://www.vmware.com/download/download.do?downloadGroup=VC250U4
DVD iso image
md5sum: 4304334ed7662b6a43646e6dde0956d2
Zip file
md5sum: 1306cb9b25e28a06bab84257d7cbf38f
Release Notes
http://www.vmware.com/support/vi3/doc/vi3_vc25u4_rel_notes.html

ESX 3.5
-------
ESX350-200910403-SG
http://download3.vmware.com/software/vi/ESX350-200910403-SG.zip
md5sum: 0e90be5bd6aa986dc2356563e809a54f
sha1sum: a5968cf6db78e28d79a4fd0b4df172cadf0f7129
http://kb.vmware.com/kb/1013126

5. References

Tomcat release notes
http://tomcat.apache.org/security-5.html

CVE numbers
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1232
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1947
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2370

- - ------------------------------------------------------------------------
6. Change log

2009-02-23 VMSA-2009-0002
Initial security advisory after release of VirtualCenter 2.5 Update 4
on 2009-02-23.
2009-10-16 VMSA-2009-0002.1
Updated after release of ESX 3.5 patch 18 on 2009-10-16.
2009-11-20 VMSA-2009-0002.2
Updated after release of vCenter and ESX Update 1 on 2009-11-19.

- - -----------------------------------------------------------------------
7. Contact

E-mail list for product security notifications and announcements:
http://lists.vmware.com/cgi-bin/mailman/listinfo/security-announce

This Security Advisory is posted to the following lists:

* security-announce at lists.vmware.com
* bugtraq at securityfocus.com
* full-disclosure at lists.grok.org.uk

E-mail: security at vmware.com
PGP key at: http://kb.vmware.com/kb/1055

VMware Security Center
http://www.vmware.com/security

VMware security response policy
http://www.vmware.com/support/policies/security_response.html

General support life cycle policy
http://www.vmware.com/support/policies/eos.html

VMware Infrastructure support life cycle policy
http://www.vmware.com/support/policies/eos_vi.html

Copyright 2009 VMware Inc. All rights reserved.

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksHBIIACgkQS2KysvBH1xnEAgCeLC12nVbvwYPj1Wabqaeq1DM/
36AAnRm96ANHl2FF/8FJiP9oxiuZrqnv
=owAk
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFLCrVAk0kIxZMiiQ8RAiAWAKCSRR3hzH1v5SnFqDi1hCMW8fbs1ACgs5Xx
N4QDXHoa/dFskF4y7tvcw4A=
=NX2Q
-----END PGP SIGNATURE-----

vSphere ESX 4.0 auf Intel S5000PAL-Serverboard Systemen wie z.B. SR2500, z.B. Thomas Krenn AG SR2500

Einige unserer Kunden haben mit einiger Verärgerung festfestellt, dass ein Update von ESX 3.x auf ESX 4.0 (vSphere) nicht möglich war:

Betroffene Systeme:

Mainboard: Intel S5000PAL
Storage-Controller: Adaptec 5xxx, z.B. 5405, etc. Zur Zeit können wir nicht ausschließen, dass auch andere Controller betroffen sind.

Screenshot des Fehlers (hier bleibt das System hängen):

Status:  (Dienstag, 13:09 Uhr): Problem gelöst! Wir möchten uns an dieser Stelle für die Zuammenarbeit mit  der Thomas Krenn AG, Intel und Adaptec bedanken, die mit Ihren Tipps zur Lösung beigetragen haben!

Bemerkung: Leider ist die Fehlerbehebung ein wenig komplexer, da verschiedene Schritte zur Lösung notwendig sind, und die Fehler leider alles andere als reproduzierbar sind: Einige identischen Systeme sind nämlich nicht betroffen, andere schon.
Betroffene Kunden wenden sich bitte zwecks Lösung direkt an uns, wir helfen Ihnen gerne weiter!

Vor dem vSphere-Update ist ein Aktualisieren sämtlicher MB-Firmware sowie eine Update der Adaptec-Controllerfirmware zu empfehlen.

VMware workstation 7 angetestet

Wir haben für Sie die neue Version von VMware am 27.10. veröffentlichten Workstation 7 für Windows und Linux getestet und sind sehr angetan von den neuen Funktionen. Diese sind nicht nur die viel beworbenen Funktionen wie offizielle Unterstützung für Windows 7 und 3D-Grafik sowie neue Funktionen für Entwickler.

Nett ist zum Besipiel  "Easy Install", mit welchem die Installation der 32-Bit- und 64-Bit-Versionen von Windows 7 auf einer virtuellen Maschine sogar einfacher als auf einem physischem PC gelingen. VMware Workstation 7 arbeitet mit Flip 3D, und Aero Peek zeigt den Fortschritt der virtuellen Maschinen in Echtzeit an.

Die Webeaussage, dass mit VMware Workstation mehr Betriebssysteme als bei jedem anderen Produkt zur "Desktop-Virtualisierung" unterstützt werden, nämlich über 200 Betriebssysteme von Windows 3.1 und Windows 7 bis hin zu Red Hat Enterprise Linux 1 und Red Hat Enterprise Linux 5. Unterstützung von über 20 neuen Betriebssystemen wie Windows 7, Windows Server 2008 R2, Debian 5, Ubuntu 9.04 und von über 20 Windows-Versionen sowie 26 Linux-Versionen. VMware vSphere 4 - ESX und ESXi - lassen sich jetzt auf einer virtuellen Maschine installieren und ausführen! Sicher, mit einigen Tricks und Kniffen haben wir das natürlich schon lange vorher zum Laufen gebracht, aber eine quasi offizielle Unterstützung ist - sehr leistungsfähige Hardware vorausgesetzt - wirklich ein nettes Feature, wenn man vSphere oder ESX(i) so auf einem gut ausgestatten Notebook für Demos, Tesst und Schulungszwecke wirklich ultramobil machen kann!

Unser Test: Auf einem Dell Precision 6400 Covet mit 16 GB RAM kann man durchaus auch die andere Bedeutung von Desktop-Virtualisierung demonstrieren: Es liefen innerhalb von VMware Workstation 7 eine komplette vSphere Infrastrukur für 10 komplettvirtualisierte Arbeitsplätze, so dass zumindest einfache Officefunktionalität an allen 10 Arbeitsplatzgeräten, die mit Pano Zero-Clients ausgestattet waren, gut demonstrieren konnte. Unsere Kunden sind von einer solchen Demo so begeistert, dass wir ernsthaft überlegen, unsere Testvorführungen künftig mit Notebooks statt mit kleinen Servern durchzuführen! Die Gewichtsersparnis ist immerhin mehr als 60 % :-)

Speziell die Softwareentwicklung profitiert von den neuen Funktionen von VMware Workstation 7: IDE-Integration der SpringSource Tools Suite und Eclipse IDE für C/C++ sind hier die Stichwörter.

Einen ausführlicheren Test werden wir an dieser Stelle in Kürze veröffentlichen!

Wer Paritätsbasierende RAID-Levels nutzt, ist selber schuld...

Warum ein altes Thema ausgraben, denn dass paritätsbasierende RAID-Levels wie RAID5 und RAID6 zu Problemen führen können, sollte hinlänglich bekannt sein.

Aber es scheint sich noch immer nicht herumgesprochen zu haben, dass diese Probleme keine reinen "Statistik-Rechenübungen" sind, sondern in der Praxis leider immer häufiger auftreten.
Bei uns häufen sich die Probleme mit RAID5 (und vereinzelt sogar RAID6) massiv, obwohl wir unseren Kunden so ein RAID-Level wirklich niemals mit SATA-Platten >500 GB einrichten, aber einige Hersteller von Speicherappliances liefern Storageserver vorkonfiguriert mit paritätsbasierten RAID-Levels (sprich vor allem RAID5 und seltener RAID6) aus, und die Admins sind anscheinend zu faul, um diese Konfiguration zu ändern damit zufrieden.

Das Problem - dies lehrt uns die Statistik - hängt vor allem mit den immer größer (und immer günstiger werdenden)  SATA-Festplatten zusammen und mit dem Einzug dieser SATA-Platten in Speichersysteme und Server von Firmen.  Wir sehen immer mehr > 1 TB SATA-Platten in Storagesystemen von Firmen, die uns als Vor-Ort-Dienstleister für verschiedene Storage- und Serverhersteller logischwerweise nur dann begegnen, wenn es Probleme gibt: Aber diese Probleme mit RAID5 und 6 nehmen von Monat zu Monat immer mehr zu.

Hier nocheinmal die Basics, stark vereinfachend:
RAID5-Plattenverbünde verkraften einen einzigen Plattenausfall pro RAID, das heißt, man kann die Daten bei Ausfall einer Platte im RAID-Verbund wiederherstellen. Das Problem besteht aber darin, dass wenn eine Platte ausfällt ein weiteres Problem hinzukommen kann (und dies ist leider sogar recht häufig der Fall!): Kommt beim Wiederhestellen des RAID noch ein unbehebbarer Lesefehler vor (engl. URE für unrecoverable read error), dann bricht die Wiederherstellung mit einer Fehermeldung ab, und Daten gehen verloren, wenn man kein aktuelles Backup hat!

Festlattenausfall
Obwohl Festplatten als sehr zuverlässig gelten, gehen Festplatten nun mal kaputt. Die Frage ist nur, wie häufig dies der Fall ist. Die besten Daten hierzu (von Google und CMU) zeigen auf, dass mehr als 3% aller Platten innerhalb der ersten 3 Jahre ausfallen, und das pro Jahr (!), nach 3 Jahren steigt die Ausfallrate steil an!
Das bedeutet, mit 8 nagelneuen Festplatten hat man eine ungefähr 25% Wahrscheinlichkeit dafür, dass eine Platte pro Jahr ausfällt. Mit anderen Worten: Innerhalb von 4 Jahren ist ein Plattenauswahl nahezu garantiert!
Sie meinen, Sie sind geschützt, da Sie RAID5 verwenden?

Unbehebbare Lesefehler (URE)
Schauen wir uns einmal an, wie häufig Lesefehler auftreten, so geben die Meisten SATA-Plattenhersteller einen unbehebbaren Lesefehler auf 100.000.000.000.000 oder einhundert Billionen Bits an, oder 1:(10^14). Hört sich nach unglaublich sicher an, nicht wahr? Ist es aber nicht! Denn das bedeutet einen URE auf 12 TB.

Zahlenbeispiel: Mit einem RAID5 aus sieben 2-TB-Disks ist ein URE so gut wie sicher!

Wenn dies passiert, sind 14 TB Ihrer wertvollen Daten verloren, hoffentlich sichern Sie Ihre Daten also täglich auf Band. Tun Sie nicht? Dann haben Sie Pech gehabt...

Sagen Sie also nicht, wir hätten Sie nicht gewarnt!

Für diejenigen, die sich ein wenig mehr mit der Thematik beschäftigen wollen, sei der folgende Eintrag aus Richard Elling's Blog - "Rambling from Richard's Ranch" bei SUN empfohlen: "ZFS RAID recommandations: size vs. MTBF" oder dieser hier: "Using MTBF and Time Dependent Reliability for Disks".

Wichtige Anmerkung: SAS, SCSI und FC-HDDs sind sehr viel zuverlässiger als SATA-HDDs und haben auch nicht so hohe Speicherkapazitäten wie letztere. Aus beiden Gründen sind Sie mindestens um 1-2 Größenordnungen ausfallsicherer. Auch RAID6 ist gegenüber RAID5 um etwa eine Größenordnung  ausfallsicherer!