VMware vSphere 7.0U2 verliert Zugriff auf SD-Karten

Beim Betrieb von vSphere 7 Update 2 auf einer SD-Karte kann es unter Umständen dazu kommen, dass das Betriebssystem den Zugriff auf selbige verliert und der ESXi-Host einfach einfriert.

Problem

Hierbei stehen durch den Verlust des Zugriffs auf die SD-Karte die Systempartitionen nicht mehr zur Verfügung. Dadurch wird es unmöglich, die VMs zu verwalten. Laufende VMs sind zwar weiterhin funktional, können aber nicht mehr herunter- und hochgefahren oder auf einen anderen Host migriert werden.

Die CPU-Last des ESXi-Hosts steigt kontinuierlich an, so dass schlussendlich die Leistung und nach einiger Zeit auch die Funktionalität der VMs betroffen ist. Eine Evakuierung (z.B. durch den Wartungsmodus) ist nicht möglich, es bleibt lediglich ein harter Reset als letzte Option. Ist in der Umgebung ein vCenter mit aktivem HA vorhanden, werden die VMs anschließend auf einem anderen Host neu gestartet.

Workaround

Aktuell gibt es nur einen temporären Workaround. Dieser setzt Kenntnisse und Zugriff auf die Konsole des ESXi-Hosts voraus:

Das Ausführen von

esxcfg-rescan -d vmhba32

führt dazu, dass tote Pfade zur SD-Karte verworfen werden und das Gerät erneut gescannt wird. Der Befehl muss unter Umständen mehrfach in einem Abstand von mehreren Minuten ausgeführt werden, solange bis keine Fehler mehr auftreten.

Nach einem anschließenden Neustart der Management Agents können die VMs vom Host evakuiert werden. Ein kontrollierter Reboot des Hosts ist nun möglich.

Der Verbindungsverlust zur SD-Karte tritt nach 24 bis 48 Stunden erneut auf und das Prozedere beginnt von vorn.

Lösung

Eine Lösung mittels eines Updates oder Patches ist bisher noch nicht gegeben. VMware hat die Behebung des Problems für einen zukünftigen Patch angekündigt. Ein konkretes Release-Datum gibt es bisher nicht.

„VMware engineering has a fix that will be in the next release of 7.02 P03 which is planned for sometime in July 2021.“

VMware,

Sichere Abhilfe schafft momentan nur ein Downgrade (sofern möglich) oder die Neuinstallation des ESXi-Hosts mit vSphere 7.0U1.

Der Betrieb von vSphere 7.0U2 auf internen SSD- oder HDD-Medien ist problemlos möglich.

Update

Patch 7.02 P03 wurde zwischenzeitlich veröffentlich, konnte das Problem allerdings nicht beheben.
Die Lösung wird mit Version 7.0U3 erwartet. Eine offizielle Bestätigung seitens des Herstellers fehlt hierzu allerdings noch.

Unterstützung gewünscht?

Sie benötigen Unterstützung oder Beratung in diesem oder anderen Themen? Wir unterstützen gerne.

Weiterführende Informationen zum Thema Servervirtualisierung gibt es hier.

Quellen

Problem: https://kb.vmware.com/s/article/83963

Workaround: https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/td-p/2852027

VMware vSphere: Kritische Sicherheitslücke im vCenter

Kürzlich gab VMware bekannt, dass es eine Sicherheitslücke in den Plugins des vCenter Servers bekanntgeworden ist (CVE-2021-21985). Betroffen hiervon sind die folgenden vCenter Versionen:

  • VMware vSphere 6.5
  • VMware vSphere 6.7
  • VMware vSphere 7.0
  • VMware Cloud Foundation Versionen 3.x und 4.x

Ohne Gegenmaßnahmen ist es Angreifern möglich, über das vSAN Health Plugin (Siehe Link) des vSphere Clients (HTML5) Schadcode in das System zu übertragen und Root-Rechte zu erlangen. Diese Sicherheitslücke betrifft auch Kunden, die kein vSAN im Einsatz haben, denn das Plugin ist standardmäßig installiert und aktiviert. Um diese Sicherheitslücke zu schließen hat VMware für die betroffenen vCenter-Versionen jeweils ein Update für den vCenter-Server bereitgestellt. In diesem wird gleichzeitig auch eine weitere Sicherheitslücke (CVE-2021-21986) geschlossen. Diese wurde seitens VMware hingegen als moderat gefährlich bezeichnet und ist im verlinkten KB-Artikel ebenfalls aufgeführt.

Response-Matrix der betroffenen Versionen

ProduktVersionCVE IdentifierCVSSv3EinstufungBehoben ab VersionWorkaroundsDokumentation
vCenter Server 7.0CVE-2021-219859.8Kritisch 7.0 U2bKB83829FAQ
vCenter Server6.7CVE-2021-219859.8Kritisch 6.7 U3nKB83829FAQ
vCenter Server6.5CVE-2021-219859.8Kritisch 6.5 U3pKB83829FAQ
VMware vCenter Response-Matrix für CVE-2021-21985
ProduktVersionCVE-IdentifierCVSSv3EinstufungBehoben ab VersionWorkaroundsDokumentation
Cloud Foundation (vCenter Server) 4.xCVE-2021-219859.8Kritisch 4.2.1KB83829FAQ
Cloud Foundation (vCenter Server) 3.xCVE-2021-219859.8Kritisch 3.10.2.1KB83829FAQ
VMware vCenter Cloud Federation Response-Matrix für CVE-2021-21985

Möglicher Workaround (nur ohne aktives vSAN möglich)

Falls es nicht möglich sein sollte, das Update kurzfristig einzuspielen, gibt es einen Workaround, der in dem VMware KB-Artikel 83829 beschrieben wird. Dieser sieht vor in den betroffenen vCenter Versionen das schadhafte Plugin in den Dateien

/etc/vmware/vsphere-ui/compatibility-matrix.xml

bzw.

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

über einen Editor zu deaktivieren. Dies funktioniert allerdings nur, wenn Sie kein VMware vSAN im Einsatz haben.

Sollten Sie noch Fragen zum Schließen der Sicherheitslücke haben oder Unterstützung bei der der Umsetzung benötigen, sind wir gerne behilflich. Kontaktieren Sie gerne kurzfristig unseren Servicedesk oder Ihren Account Manager.

Weiterführende Informationen

https://www.vmware.com/security/advisories/VMSA-2021-0010.html
https://kb.vmware.com/s/article/83829
https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html

vSphere 7 bringt umfassende Neuerungen

VMware hat am 02.04.2020 vSphere 7 angekündigt und nun veröffentlicht, und bezeichnet es selbst als größte Innovation seit der Einführung des Hypervisors vSphere ESXi (siehe VMware-Blogpost).

vSphere 7 enthält zahlreiche Neuerungen wie den vSphere Lifecycle Manager, vCenter Server Profile, Versionierung von VM-Vorlagen und Verbesserungen von DRS und vMotion.

Kubernetes- und Containersupport

Außerdem wurde mit vSphere 7 die Kubernetes-Infrastruktur direkt in den ESXi-Kernel integriert. Die Ausführung von Containern wird nun nativ unterstützt. vSphere 7 mit Kubernetes ist als Teil der VMware Cloud Foundation erhältlich.

Abschneiden alter Zöpfe

Dem Rotstift zum Opfer gefallen sind dafür beispielsweise der Support eines externen PSC, der auf Flash basierende vSphere Web Client, sowie der Betrieb des vCenters auf einem Windows Server.

Schaffen neuer Möglichkeiten

Neue Features im Überblick

  • vSphere Lifecycle Manager ersetzt den VMware Update Manager für Upgrade und Patch Management
  • vCenter Server Update Planner für Kompatibilitäts- und Interoperabilitäts-Checks bei Upgrades des vCenter Servers
  • vCenter Server Profile um eine Baseline der aktuellen Konfiguration festzulegen oder die Konfiguration mehrerer vCenter zu vereinfachen
  • Content Library als zentrales Management von Vorlagen virtueller Maschinen, virtueller Appliances und ISO Images
  • DRS Überarbeitung hinsichtlich eines Workload-zentrierten Designs, weg vom Host-Balancing Ansatz
  • vMotion Verbesserung der Performance, besonders in Hinsicht auf Datenbanken und unternehmens-kritische Anwendungen
  • vSphere Trust Authority zur Absicherung sensibler Workloads durch Remote-Beglaubigung
  • Föderierte Identitäten mit ADFS für sichere Authentifizierung und vereinfachte Benutzerverwaltung

Editionen und Lizenzierung

vSphere 7 ist wie gewohnt in den Editionen Standard und Enterprise Plus erschienen. Erhältlich sind außerdem die bekannten Acceleration-, ROBO- und Essentials-Kits. Weggefallen sind die Platinum Editionen.
Eine unscheinbare aber wichtige Neuerung gibt es bei der Lizenzierung:

Zwar ist die Lizenz weiterhin sockelbasiert, allerdings zukünftig auf 32 Cores begrenzt. Dies bedeutet wiederum, dass mehr als eine Lizenz pro CPU benötigt wird, wenn diese über mehr als 32 Kerne verfügt. Für Klein- und Kleinstkunden dürfte diese Neuerung in der Lizenzierung wenig Auswirkungen haben, in größeren Rechenzentren verteilt sich die Lizenzierung künftig allerdings anders, sodass u.U. mehr als eine Lizenz je Sockel erworben werden muss.

Sie wünschen weitere Informationen oder Beratung in diesem oder angrenzenden Themen? Sprechen Sie uns gerne an! Wir stehen mit Rat und Tat zur Seite und unterstützen Ihr Business – Ihre Kernkompetenz – mit unserer Kernkompetenz, der IT.

Weiterführende Informationen zum Thema Servervirtualisierung gibt es hier.

VMware VCSA stellt den Dienst ein

In der Vergangenheit kam es bei einzelnen VMware-Implementierungen zu Problemen mit der VCSA. Diese stellte die Dienste ein und war nicht mehr erreichbar. Ist es nicht eine Wohltat, wenn man morgens die URL des vSphere Web Clients aufruft und mit folgender Meldung begrüßt wird?

vcsa_1

Achtung!

Bevor irgendwelche Arbeiten an der VMware vCenter Server Appliance durchgeführt werden, sollte unbedingt ein Snapshot erstellt werden.

Was ist da los?

Ein Blick auf die Shell der vCSA zeigt, dass einige Dienste nicht gestartet sind.

service-control –status

vcsa_2

Ein manuelles Starten schlägt fehl.

service-control –start –all

vcsa_3

Ein kurzer Blick in die Suchmaschine der Wahl zeigt: Die Ursache hierfür kann vielfältig sein, beispielsweise ein abgelaufenes root-Kennwort oder aber abgelaufene Zertifikate.

Die Vorgehensweisen zu diesen beiden Fehlerbehebungen werden nachfolgend skizziert:

Root-Kennwort abgelaufen?

Auch wenn das root-Kennwort abgelaufen ist, ist ein Login auf der Shell per Web Konsole oder VMRC noch möglich.

Mit chage -l root kann die Gültigkeit des Passworts geprüft werden.

vcsa_4

Ist das der Fall, ändert man das Passwort mittels passwd root

vcsa_5

Anschließend kann noch einmal die Passwortgültigkeit geprüft werden.

vcsa_6

Zertifikate abgelaufen?

Um die Gültigkeit der Zertifikate zu prüfen, lässt man sich zuerst mit /usr/lib/vmware-vmafd/bin/vecs-cli store list den Inhalt des Zertifikat Stores anzeigen.

vcsa_7

Der Inhalt eines bestimmten Zertifikates kann per /usr/lib/vmware-vmafd/bin/vecs-cli entry list –store NAME_DES_ZERTIFIKATES –text angezeigt werden.

vcsa_8

Das aktuelle Datum der vCSA kann mittels date geprüft werden.

vcsa_9

Durch zurückstellen des Datums auf einen Wert, an dem die Zertifikate noch gültig waren, lassen sich die Dienste wieder starten. Hier in diesem Fall mit date -s ‚2020-06-01 10:00:00‘

vcsa_10

Achtung!

Um eine Aktualisierung der Zeit zu verhindern, muss in der VMware vCenter Server Appliance Web-Konsole die Zeitsynchronisierung deaktiviert sein.

vcsa_11

Die Web Konsole erreicht man im Browser unter https://IP-oder-Name-der -VCSA:5480/

Anschließend lassen sich die Dienste per service-control –start –all starten. Alternativ kann auch die Appliance neu gestartet werden.

Das eingebaute Zertifikat-Manager Tool, das auf der Shell mittels /usr/lib/vmware-vmca/bin/certificate-manager aufgerufen werden kann lief auf einen Fehler beim Erneuern des MACHINE_SSL_CERT-Zertifikates und führte ein Rollback durch.

Auch im Administrationsberiech des vSphere Web Clients ließ sich in diesem Fall das MACHINE_SSL_CERT-Zertifikat nicht erneuern.

vcsa_12

In der Webkonsole des Platform Service Controllers gibt es ebenfalls einen Bereich für das Zertifikatsmanagement. Darüber ließen sich schlussendlich alle Zertifikate erneuern.

Handelt es sich um eine embedded Installation erreicht man den PSC im Browser unter https://IP-oder-Name-der-VCSA/psc

vcsa_13
vcsa_14

Die zu erneuernden Zertifikate auswählen und Erneuern anklicken.

Ein weiteres Zertifikat gibt es im Bereich der SSO Konfiguration. Das STS Signing Zertifikat lässt sich über keine der Webkonsolen erneuern, da es sich um ein internes VMware Zertifikat handelt und normalerweise nicht ausgetauscht werden soll.

vcsa_15

Da es ebenfalls abgelaufen war, muss dennoch ein neues Zertifikat generiert und dem Java key store hinzugefügt werden.

Eine sehr detaillierte Anleitung gibt es dazu in den VMware Docs:

Generieren des Zertifikats: Generate a New STS Signing Certificate on the Appliance
Einspielen des Zertifikats: Refresh the Security Token Service Certificate

Abschließend sollte die vCSA unbedingt neu gestartet werden.

Sie benötigen Unterstützung oder Beratung in solchen oder anderen Themen? Wir unterstützen Sie gerne.

VMware – moving a single virtual disc (vmdk file) to a different datastore

Hi folks.

Let me explain: There is a virtual machine with more than one virtual disk – so we got more than one vmdk file for that specific VM. All located at the same datastore. For some reason it becomes necessary that the first disk (e.g. the system drive C:\) still remains at the original datastore, while the second disk (e.g. some data disc Z:\) should be moved to a different datastore2.

I checked that in Google but wasn’t able to find anything. Maybe I just missed the right search terms. So I tried myself with the VMware „Migrate“ option for virtual machines (which moves the whole VM with all its files, but not single vmdk’s) and also by copying the single vmdk file manually via the VMware datastore browser (which left an outdated configuration state on the virtual machine unable to find its disks).

Well. Here is how it works.

  • Right click the particular VM
  • Choose „Migrate“
  • Select „Change Datastore“
  • And there you’ll find a not that flashy button labeled „Advanced“ – near the right border and below half of the dialog box. He’s your friend! 🙂
  • On that next window you can choose an individual datastore for every single vmdk file of your VM
  • Make your changes and press the „Next“ button

Wait for the vmdk file beeing moved by VMware and there you go: A working virtual machine with multiple virtual disks each running on different datastores.

Veeam – Komponenten, Lizensierung & Editionen

Eine Veeam-Umgebung besteht grundsätzlich immer aus den folgenden drei Software-Komponenten, welche es dem Produkt ermöglichen sich einfach & effektiv der Komplexität Ihrer Virtualisierungs-Umgebung anzupassen. Das Produkt ist sehr gut skalierbar und kann somit in fast jeder Unternehmens-Größe eingesetzt werden.

Veeam Backup Server (System zur Administration von Backup-Jobs & Recovery-Aufgaben)

  • Kann ein physikalischer oder virtueller Server sein.
  • Kann für große Umgebungen um die Komponente „Veeam Enterprise Manager“ erweitert werden, wodurch sich zentral mehrere Veeam Backup Server gleichzeitig verwalten lassen.

Veeam Backup Proxy (Instanz zur Verarbeitung von Backup-Jobs & Recovery-Aufgaben, kurz: Data-movement)

  • Kann ein physikalischer oder virtueller Server sein.
    Wird standardmäßig direkt auf dem Veeam Backup Server installiert.
  • Kann für große Umgebungen auf einen oder mehrere dedizierte Server ausgelagert werden, um eine sinnvolle Lastverteilung zu ermöglichen und somit eine optimale Backup-Performance zu erzielen.

Veeam Backup-Repository (Speicher zur Ablage der Backupdaten)

  • Nahezu jede Speicherart kann zur Bereitstellung verwendet werden: SMB/CIFS, NAS, iSCSI, FibreChannel, USB, DAS, interner Storage.

Die Sicherungs- und Wiederherstellungsmöglichkeiten mit Hilfe einer Veeam-Umgebung sind vielfältig. Hinzu kommt die Tatsache, dass Veeam auf Grund seiner jahrelangen Erfahrungen im Bereich „Backup von virtuellen IT-Umgebungen“ ein sehr stabiles und somit zuverlässiges Produkt bereitstellt.

Die Lizensierung seiner Backup-Lösung gestaltet der Hersteller dennoch denkbar einfach:

  • Die o.g. Software-Komponenten sind Bestandteil von „Veeam Backup & Replication“ und unterliegen somit keiner Zusatzlizensierung (bspw. Anzahl einer Komponente).
    [Hinweis: Die Produkte „Veeam ONE“ & „Veeam Backup & Replication Cloud Edition“ sind optionale Produkte und sind immer separat zu lizensieren.]
  • Der Funktionsumfang von „Veeam Backup & Replication“ verteilt sich auf die Editionen „Standard“, „Enterprise“ und „EnterprisePlus“.
  • Die Lizensierung der jeweiligen Edition richtet sich ausschließlich nach der Anzahl der belegten CPU-Sockel des Virtualisierungs-Hosts.
    [Hinweis: Soll der Umfang (bereitgestellte VMs) von mehreren Virtualisierungs-Hosts gesichert werden, so ist die Summe aller belegten CPU-Sockel der jeweiligen Hosts maßgebend.]
  • Bei einer Anzahl bis zu maximal sechs CPU-Sockeln kann die jeweilige Edition nach dem vergünstigten Lizenzpaket „Backup Essentials“ erworben werden. Eine „Backup Essentials“-Lizenz umfasst dabei immer zwei CPU-Sockel.

Wann Sie welche Veeam Edition benötigen, ist immer am Einzelfall (Anforderungen & Umgebung) zu klären! Nach unseren Erfahrungen kann folgendes bei der Orientierung helfen.

  • Standard Edition | Tape- und Item-Recovery-Möglichkeiten werden für das Backup der virtuellen Infrastruktur nicht bzw. nur stark eingeschränkt benötigt.
  • Enterprise Edition | Tape- und Item-Recovery-Möglichkeiten werden für das Backup der virtuellen Infrastruktur in vollem Umfang benötigt.
  • EnterprisePlus Edition | „WAN-Acceleration“, „Backup from SAN-Snapshots“, „Self-Service-Portal“ oder „Aufgabenautomatisierungen“ werden für das Backup der virtuellen Infrastruktur grundlegend benötigt.

Veeam – Auf einen Blick! (Was es ist und was es kann…)

Wenn man in der IT unterwegs ist kommt man seit einigen Jahren um das Thema „Virtualisierung“ nicht mehr herum. Virtuelle Umgebungen bilden inzwischen einen großen (wenn nicht sogar den) Pfeiler in Unternehmens-Netzwerken. Die hohe Verbreitung von virtuellen Maschinen und deren einfache Möglichkeit zur Bereitstellung technischer Ressourcen bringt unweigerlich die Frage nach einer zuverlässigen Datensicherungslösung mit sich.

Und genau hier setzt die Firma Veeam an. Das Produkt „Veeam Backup & Replication“ ist eine Backupsoftware zur Sicherung von virtuellen Maschinen auf Basis der beiden großen Virtualisierungsplattformen „VMware vSphere ESXi“ und „Microsoft Hyper-V“. Mit dem optionalen Softwarepaket „Veeam ONE“ stehen weitere umfangreiche Monitoring- & Reportingfunktionen für „Veeam Backup & Replication“ zur Verfügung.

Bereits seit 2008 ist Veeam auf die Sicherung von virtuellen Maschinen aus dem Hause VMware spezialisiert. Mit dem Erscheinen von Microsoft Hyper-V im Jahre 2011 (stable & standalone Release) floss dieses langjährige KnowHow in die Erweiterung von „Veeam Backup & Replication“ mit ein. Seit 2012 unterstützt Veeam somit auch die Sicherung von virtuellen Maschinen aus dem Hause Microsoft.

Bei der Sicherung & Wiederherstellung virtueller Maschinen stehen Ihnen mit der aktuellen Version „Veeam Backup & Replication 7“ zahlreiche Möglichkeiten zur Verfügung:

  • Backup-Jobs zur Sicherung ganzer VMs (inkl. Auswahl der einzelnen VM-Festplatten)
  • Backup-Copy-Jobs zur Vervielfältigung erstellter VM-Backup-Images
  • Backup aus SAN-Snapshots heraus
  • File-Copy-Jobs zur Vervielfältigung einzelner Dateien
  • VM-Copy-Jobs zur Vervielfältigung einzelner VMs
  • Replication-Jobs für VMs
  • Wiederherstellung ganzer VMs
  • Wiederherstellung einzelner Dateien
  • Item-Recovery für Fileserver
  • Item-Recovery für Microsoft Exchange
  • Item-Recovery für Microsoft SharePoint
  • Item-Recovery für Microsoft Active Directory
  • Item-Recovery für Microsoft SQL
  • Bereitstellung einer VM direkt aus dem Backup-Image
  • Suchfunktion für Backup-Images (inkl. deren Inhalt)
  • integrierte WAN-Optimierung
  • integrierte Deduplizierung
  • 1-Click-Restore
  • Self-Service-Portal
  • Aufgabenautomatisierung
  • Automatische Überprüfung von Backups
  • Unterstützung von diversen Public-Clouddiensten
  • Unterstützung von diversen Dateisystemen (FAT, NTFS, ReFS, Linux, Solaris, Novell Netware, etc.)
  • Unterstützung aller Bandlaufwerke, Autoloader und Tape-Libraries mit lauffähigem Windows-Treiber
  • Unterstützung aller gängigen VM-Gastbetriebssysteme
  • u.v.m. …

Wenn auch Sie an einer stabilen und zuverlässigen Lösung zur Sicherung Ihrer virtuellen Infrastruktur interessiert sind, dann sprechen Sie uns einfach an. Wir unterstützen Sie gerne bei allen Fragen und Aufgaben rund um das Thema Veeam!