VMware Fixes für Heartbleed SSL Bug

VMware veröffentlichte kürzlich unter KB 2076225, welche Produkte vom Heartbleed SSL Bug betroffen sind. Jetzt gibts es bereits die ersten Updates, welche das Problem in betroffenen Produkten korrigieren.

Update

Hier ein Auswahl korrigierter Produkte:

  • VMware vCenter Server 5.5 Update 1a
  • VMware vCenter Server 5.5 Update 1a Appliance
  • VMware vSphere Management Assistant 5.5.0.1 (vMA)
  • VMware Horizon Mirage 4.4.2
  • VMware Workstation 10.0.2 for Windows

Laut KB 2076225 ist die vCenter Server Appliance (VCSA) selbst nicht vom Heartbleed Bug betroffen, dennoch gibt es ein aktuelles Update. Der Grund liegt in den Client Integration Plugins, die mit der VCSA ausgeliefert werden und vom SSL Bug betroffen sind.

vCenter 5.5: Aktualisierung self-signed Zertifikat

VMware vCenter verwendet Standard X.509 v3 Zertifikate, um Informationen zwischen Komponenten per SSL zu verschlüsseln. Bei der Installation von vCenter wird ein selbst signiertes Zertifikat erstellt, dessen Private- bzw. Public-Key in älteren Versionen (4.x) eine Schlüssellänge von 512 Bit hatte. Seit Version 5.5 muss die Schlüssellänge zwingend 2048 Bit sein. Hat man infolge von vCenter Upgrades noch einen dieser kurzen Schlüssel, so ist dies eine Problemquelle. Dienste verweigern die Zusammenarbeit, oder starten etwa gar nicht.

VMware bietet zum Austausch dieser Zertifikate ein Toolkit, welches den Vorgang erleichtern soll, aber das dennoch vielfältige Fallen bereit hält.

Weiterlesen

VMware Dienste und der Heartbleed Bug

Heartbleed.svgZahlreiche vSphere Dienste verwenden für die gesicherte Kommunikation OpenSSL Zertifikate. Einige produkte sind vom kürzlich veröffentlichten Heartbleed Bug betroffen. Unter KB 2076225 werden alle derzeit betroffenen Produkte aufgelistet.

Betroffen sind alle neueren Produkte, da für deren Zertifikate die OpenSSL Library ab Version 1.0.1 verwendet wurde. Ältere Zertifikate, die mit Version 0.9.8 erzeugt wurden sind nicht betroffen.

Veeam Backup und MOB-ID

Jede VM auf einem ESX Server erhält bei Erstellung oder Import eine interne Kennung, die so genannte MOB-ID oder MoRefID. Diese lautet ‘vm-’ gefolgt von einer Zahl. Zum Beispiel vm-25 oder vm-74. Diese ID ist innerhalb eines vCenters einzigartig und wird in der vCenter Datenbank gespeichert. Über diese ID referenziert Veeam Backup die zu sichernde VM zum Backup. Das ist prinzipiell in Ordnung, sorgt aber für Probleme wenn z.B. eine VM aus dem Backup wiederhergestellt wird. In diesem Fall wird die Backup-VM unter altem Namen neu im vCenter registriert und erhält eine neue MOB-ID. Welche Konsequenz hat dies für den nächsten Backuplauf? Veeam wird die VM nicht mehr finden und das nächste Backup wird fehlschlagen. Weiterlesen

Elasticsky.de geht ins vierte Jahr

Tick Tack

Die Zeit rast dahin. Vor genau drei Jahren publizierte ich den ersten Artikel auf ElasticSky.de. Über 340 kleinere und größere Artikel hat dieses Blog seither gesehen.

Notizbuch

Wie ich in meinem ersten Post schrieb, sollte dieses Blog eine Art digitales Notizbuch sein. Denn wie oft vergisst man Lösungen, die man schon einmal wusste. Ein besonders lustiges Beispiel dafür möchte ich Euch nicht vorenthalten: Kürzlich schilderte mir ein Kollege ein seltsames Phänomen mit verschwindenden Icons unter Windows7. Das Problem kam mir bekannt vor. Ich gab 2-3 Schlagworte in die allwissende Suchmaschine ein und landete… auf meinem eigenen Blog. Im Artikel findet sich eine Bemerkung, in der ich damals genau jenem Kollegen für den Tipp dankte. Er hatte es also auch vergessen und die Info fliesst im Kreis. :-D

Kommentare

Hatte ich vor einem Jahr noch einige Probleme mit Kommentar-Spam, so kann ich darüber derzeit nicht klagen. Die Einführung einer kleinen Rechenaufgabe am Ende des Kommentarfeldes sorgte dafür, dass über 99% der Spammer daran scheiterten. Schliessen wir daraus, dass die Spam-Bots nicht gut in Mathe sind? ;-)

Hin und wieder erreichen mich ernsthafte Kommentare, die mich ermutigen, mit dem Projekt weiter zu machen. Am meisten freue ich mich, wenn jemand durch einen Artikel hier ein Problem lösen konnte und das Wochenende gerettet wurde.

Ausblick

Ich freue mich auf 12 weitere Monate ElasticSky, neue Software, neue Hardware und neue Entwicklungen.

divnull

DataCore vDisk als Template verwenden

Die Bereitstellung einer neuen vDisk mit den Einstellungen einer bereits vorhandenen Disk ist in SANSymphony 9 recht einfach gelöst. Man kann eine bestehende vDisk als Vorlage für weitere Disks verwenden.

Dazu öffnet man das Kontextmenü einer bestehenden vDisk und wählt “Use as Template”.

DCoreTPL01

 

 

 

Nun öffnet sich der Dialog zur Erstellung des Abbilds. Man kann hier z.B. auch einstellen, wie viele neue vDisks vom Template erstellt werden sollen.

DCoreTPL02

 

 

 

 

Standard bei der Auswahl der Mirror Pfade ist “Auto select”. In diesem Fall möchte ich aber eine identische Pfadwahl wie bei der bestehenden vDisk und wähle daher “Duplicate paths”.

Die neue vDisk befindet sich anschliessend für kurze Zeit im Status “Full recovery pending” bis quelle und Ziel synchronisiert sind.

DCoreTPL03

 

 

 

 

 

 

Die Präsentation der Hosts wird nicht von der Vorlage übernommen. Das ist auch gut so, da hier ggf. Unverträglichkeiten zwischen den Hosts auftreten könnten.

Links

vmk0 duplicate MAC Problem

Seltsames Verhalten

Wir haben ein seltsames Netzwerk-Phänomen in unterschiedlichen (isolierten) ESX Clustern bemerkt.

  • Cluser bestehend aus zwei ESXi Hosts (5.5.0)
  • IP Adresse, Netzmaske etc. waren korrekt konfiguriert
  • Die Switch Hardware ist in Ordnung (auch wenn es erst nicht so aussah)
  • Beide Hosts sind per PING erreichbar (vom Notebook), jedoch mit unregelmäßigem Kontaktverlust
  • Die ESXi Hosts konnten sich untereinander nicht pingen
  • Jeder Host konnte das Notebook pingen

Nachdem jedes Kabel und jeder Switch getauscht waren, konnte ein Hardwaredefekt ausgeschlossen werden. Das Problem hatte ähnlichkeit mit duplikaten IP oder MAC Adressen. Die IP Adressen waren jedoch unterschiedlich und die MAC Adressen auch. Es musste etwas mit dem Management Network zu tun haben. Mit der vSphereCLI schaute ich mit den Kernelport des Management Netzwork genauer an.

Weiterlesen

DcsAdmin Password für DataCore Services ändern

Durch einen Tippfehler wurden bei der Datacore Installation für beide Server unterschiedliche DCSAdmin Passwörter vergeben. Eine Paarung der beiden Sewrver war somit nicht möglich. Das Passwort musste neu vergeben werden. Dies funktioniert leicht mit einem Datacore Powershell cmdlet.

Ablauf

Achtung! Dies ist nur eine Zusammenfassung für zwei Hosts, wobei nur das Passwort eines Servers geändert werden muss. Für alle anderen Szenarien bitte die genaue Anleitung bei Datacore Webhelp lesen.

  • DataCore Powershell starten
Set-DcsAdminPassword.ps1 -Password <new password>

Links

Installing vCenter Server 5.5 best practices

VMware hat unter KB 2052334 einen best practise guide für vCenter 5.5.0b erstellt. Ein kurzes YouTube Video ist ebenfalls enthalten.

Links

KMS Aktivierung Server Template

Die Bereitstellung virtueller Maschinen mit Hilfe von Templates ist eine sehr komfortable Methode, um schnell standardisierte Server zu produktivieren. Die Aktivierung über einen Key Management Server (KMS) erspart weitere Zeit bei der Bereitstellung. Genau hier stieß ich kürzlich auf ein Problem, was dazu führte dass die Ableitung vom Template nach einiger Zeit nicht mehr funktionierte.

Die Eckdaten

  • Windows Server 2008 R2 Datacenter Edition mit Volumen-Lizenz.
  • Template vorbereitet für KMS.
  • Domänen Beitritt erfolgt bei der Ableitung.

Spurensuche

Beim Start des Templates (Convert to VM) war sehr schnell erkennbar daß die Microsoft Aktivierung die Finger im Spiel hatte. Das Display war schwarz und ich wurde auf die Möglichkeit einer Software Fälschung hingewiesen. ;-)

Eigentlich sollte sich die Template VM gegen den KMS aktivieren können. Ein Test auf der Kommandozeile (PC in der Domäne) lieferte die richtige Adresse des KMS.

nslookup -type=SRV _vlmcs._tcp

Antwort vom DNS:

Server:  dns1.mydomain.local
Address:  10.0.1.10

_vlmcs._tcp.mydomain.local   SRV service location:
          priority       = 0
          weight         = 0
          port           = 1688
          svr hostname   = kms.mydomain.local
kms.mydomain.local       internet address = 10.0.1.120

Der selbe Test von der Template VM lieferte kein Ergebnis, d.h. die VM kann den KMS nicht auflösen und sich daher auch nicht aktivieren. Die Ursache ist ein fehlendes Domänen-Suffix (mydomain.local), welches die VM normalerweise erst beim Domänenbeitritt erhält.

Domänensuffix einstellen

Eigenschaften > vollständiger Computername > Einstellungen ändern > Computername > Ändern > weitere

Hier die vollqualifizierte Suchdomäne eintragen (mydomain.local). Danach kann die Template VM gegen den KMS aktiviert werden und die Ableitung erfolgt wieder reibungslos.