Schlagwort-Archive: vsphere

Labor-Umgebungen auf VMware vSphere erstellen mit der Ansible-Rolle vsphere_provision_lab

In diesem Artikel stelle ich euch meine Ansible-Rolle vsphere_provision_lab vor. Mit dieser ist es möglich, vordefinierte Labor-Umgebungen, bestehend aus virtuellen Maschinen (VMs), in einem VMware vSphere Cluster zu provisionieren.

Um dem Text folgen zu können, ist es hilfreich zu wissen, was eine Ansible-Rolle (engl.) ist und worum es sich bei VMware vSphere handelt.

Anwendungsfall

Zum Test von Ansible-Modulen, -Playbooks und -Rollen sowie neuer Shell-Skripte und Konfigurationsparameter benötige ich wiederholt Test- bzw. Labor-Umgebungen. Diese bestehen aus VMs, welche im Vergleich zum Provisionierungszeitpunkt möglichst wenig Änderungen aufweisen sollten.

Da die Konfiguration der Gast-Betriebssysteme durch einen Testlauf verändert wird, soll eine solche Labor-Umgebung nach einem Test möglichst schnell dekommissioniert und neu-provisioniert werden können.

Der Vorgang der Provisionierung und Dekommissionierung soll automatisiert erfolgen.

Voraussetzungen

Um die Ansible-Rolle vsphere_provision_lab nutzen zu können, benötigt man:

  • Einen Ansible Control Node mit einer Ansible-Version >= 2.9
  • Eine vCenter Server Appliance oder einen vCenter Server; getestet habe ich die Rolle mit Version 6.7 U3

Die Ansible-Rolle verwendet die Module vmware_guest und vmware_guest_disk aus der Collection community.vmware. Um diese nutzen zu können, muss auf dem Ansible Control Node Python in einer Version >= 2.6 und PyVmomi installiert sein.

Da die Rolle neue VMs aus Templates erstellt, müssen entsprechende vSphere Templates vorhanden sein.

Variablen

In diesem Abschnitt werden die Variablen dokumentiert, welche mit Werten zu belegen sind. Diese sind in defaults/main.yml definiert und können entsprechend der Variablen-Präzedenz überschrieben werden.

vCenter-Variablen

  • vsphere_provision_lab_vc_hostname – Der FQDN für die vCenter Server Appliance.
  • vsphere_provision_lab_vc_username – Ein Benutzeraccount mit der Berechtigung, neue VMs zu erstellen.
  • vsphere_provision_lab_vc_password – Spezifiziert das Benutzer-Passwort.
  • vsphere_provision_lab_vc_datacenter – Name des vSphere Datacenter in der Bestandsliste, das verwendet werden soll.
  • vsphere_provision_lab_vc_cluster – Der zu verwendende vSphere Cluster aus der Bestandsliste.
  • vsphere_provision_lab_vc_datastore – Name des Datenspeichers, in dem die VMDK-Datei(n) erstellt wird/werden.
  • vsphere_provision_lab_vc_folder – Der vSphere Folder Name, in dem die VM erstellt wird. Der Wert kann zuvor mit dem Playbook find_vmware_guest_folder.yml ermittelt werden.

Ich empfehle, sensible Informationen wie z.B. Benutzername und Passwort in einer verschlüsselten Ansible-Vault-Datei zu speichern.

Dictionary zur Spezifikation der VMs

Namen und Parameter der zu erstellenden VMs werden in einem YAML-Dictionary gespeichert. Der folgende Code-Block zeigt ein Beispiel für ein solches Dictionary mit einem Eintrag:

  vm1:
    vm_template: rhel8-en
    vm_ram_mb: 1024
    vm_vcpu: 2
    vm_net: VLAN123
    vm_ip: 192.168.0.5
    vm_netmask: 255.255.255.0
    vm_gateway: 192.168.0.254
    vm_domain: sub.example.com
    vm_hostname: host2
    vm_dns_servers:
      - 192.168.0.2
      - 192.168.0.3
    vm_dns_suffix:
      - sub.example.com
      - sub2.example.com
      - sub3.example.com
    vm_second_hdd: true
    vm_second_hdd_size_gb: "10"
    vm_second_hdd_type: "thin"
    vm_second_hdd_datastore: "DS1"
    vm_scsi_controller: "1"
    vm_unit_number: "1"
    vm_scsi_type: 'paravirtual'

Aus dem obigen Dictionary wird eine VM mit den folgenden Parametern erstellt:

  • vSphere-Template ‚rhel8-en‘ wird als Vorlage verwendet.
  • Der VM werden 1 vCPU und 512 MB RAM zugewiesen.
  • Die vNIC an das VM-Netz ‚VLAN123‘ angeschlossen.
  • Die VM wird mit der IP 192.168.0.1/24 und dem Standardgateway 192.168.0.254 konfiguriert.
  • Im Gast-Betriebssystem wird der Hostname ‚host1‘ konfiguriert.
  • Es werden DNS-Server und DNS-Suffixe konfiguriert.
  • Es wird eine zweite Festplatte für die VM erstellt.

Diesen Block kann man nun für weitere VMs wiederholen. Wird keine zweite HDD benötigt, setzt man vm_second_hdd auf false.

Beispiel-Playbook

---
- hosts: localhost
  connection: local
  gather_facts: no
  vars_files:
    - /path/to/vault-with-vcenter-creds.vars
    - roles/vsphere_provision_lab/vars/rhel-lab.yml
 
  roles:
    - vsphere_provision_lab

In diesem Beispiel werden die Variablen aus zwei Dateien geladen.

  • /path/to/vault-with-vcenter-creds.vars ist eine Ansible-Vault-Datei, welche die Anmeldeinformationen für den vCenter Server beinhaltet.
  • roles/vsphere_provision_lab/vars/rhel-lab.yml enthält das Dictionary mit den zu erstellenden VMs.

Wie kann man diese Rolle nutzen?

Die Rolle steht unter der Lizenz GPLv2-or-later und kann aus dem GitLab-Repo vsphere_provision_lab heruntergeladen bzw. das Repo geklont werden. Sie ist im Role Path der Ansible-Installation zu speichern. Anschließend kann man sich an folgendem Ablaufplan orientieren:

  1. Im Vorfeld sollten IP-Adressen und FQDNs für die zu erstellenden VMs registriert werden. Dieser Punkt ist spezifisch für eure jeweilige Umgebung.
  2. Die Variablen sind mit gültigen Werten zu belegen.
  3. Die Rolle ist in ein Playbook einzubinden.
  4. Und schon kann das Playbook ausgeführt werden.

Fazit

Die Ansible-Rolle vsphere_provision_lab ermöglicht es, Labor-Umgebungen, bestehend aus VMs, als YAML-Dictionary zu definieren und auf einem VMware vSphere Cluster zu provisionieren.

Damit eignet sie sich, um wiederholt eine Umgebung mit gleichen Ausgangsbedingungen zu schaffen. Gleichzeitig wird die Zeit für die Provisionierung verkürzt, da manuelle Schritte entfallen.

So richtig idempotent arbeitet das Modul vmware_guest allerdings nicht. Führe ich das Playbook ein zweites Mal aus, wird der Status „Changed“ zurückgegeben, obwohl die VMs bereits existieren. Die VMs selbst überstehen den zweiten Lauf auch unbeschadet, jedoch zeigt der vSphere Client, dass sie rekonfiguriert wurden. Das könnte ich mir noch genauer ansehen, um der Ursache auf die Schliche zu kommen.

Was haltet ihr davon? Findet ihr diese Role nützlich, oder bevorzugt ihr andere Wege zur Provisionierung eurer VMs auf vSphere?

Kommentar: VMware vSphere Web Client – Welch ein Fluch

Es war einmal vor langer Zeit, als einzig und allein der vSphere Client für Windows existierte, um einen ESX-Host bzw. einen vSphere Cluster zu verwalten. Und die vSphere-Admins waren glücklich und froh.

In dieser guten und glücklichen Zeit war der einzige Wermutstropfen, dass der vSphere Client nur für Microsoft Windows existierte und man als Linux-Liebhaber darauf angewiesen war, für die Administration der vSphere-Umgebung ein anderes Betriebssystem zu booten. Doch konnte dies die Freude nicht mindern. Und alle freuten sich und waren froh.

Doch in dieser Welt des Frohsinns und der Glückseligkeit gab es einen Dämon, dem dies alles gar nicht gefiel. Und dieser Dämon beeinflusste die guten Software-Engineers bei VMware und veranlasste sie dazu, den vSphere Web Client auf Basis von Flash zu entwickeln. Dies war der Beginn von dunklen Zeiten, welche bis in die Gegenwart anhalten.

Wer den vSphere Client kennt und sich den Web-Client ansieht, fragt sich vermutlich: „Warum? Warum investiert man Zeit, um so einen Mist zu entwickeln?“

Der vSphere Web Client ist langsam, kann nichts besser als der Fat-Client, bietet keine neuen Funktionen und basiert auf Flash. Letzteres sorgt dafür, dass es für Linux weiterhin keinen nutzbaren Client gibt. Doch den Göttern sei Dank, wir konnten weiterhin den althergebrachten Fat-Client nutzen und das Flash-Gespenst links liegen lassen. Und nachdem wir uns alle von dem Schreck erholten hatten, waren wir wieder glücklich und froh.

Dies gefiel dem Dämon nicht und so lies er verkünden, dass die Entwicklung des guten etablierten vSphere Client eingestellt wird, da man sich in Zukunft auf den Web-Client konzentrieren will. Dachte man anfangs noch an einen Aprilscherz, so wurden die Zeiten nun richtig finster. Denn der vSphere Web Client war immer noch mies und unbenutzbar. Der Unmut vieler Nutzer entlädt sich seit April 2014 in diesem Thread, welcher bis in die aktuelle Zeit Updates erfährt. Denn das Grundproblem ist immer noch nicht gelöst. Der vSphere Web Client ist immer noch nicht zu gebrauchen.

Um es noch einmal zusammenzufassen, der vSphere Web Client:

  • Ist so langsam, dass ich meinen Bart wachsen höre
  • Zwingt mich Flash auf meiner Admin-Workstation zu installieren, um ihn überhaupt nutzen zu können
  • Funktioniert nicht in allen Browsern
  • Funktioniert mal in dem einen, mal in dem anderen Browser (scheint mit der Mondphase zu wechseln)
  • Benötigt für volle Funktionalität das Client Integration Plugin (CIP), welches noch bescheidener funktioniert, als der Rest des Clients

Dieser Drecks-Web-Client raubt mir den letzten Nerv. Warum beschäftige ich mich überhaupt damit? Weil Client-Probleme im Web-Client reproduziert werden müssen, damit der VMware-Support helfen kann. Dies zieht einen Service Request nicht selten in die Länge, da man mit dem Support erstmal den Web-Client zum Laufen bringen muss, bevor man das eigentliche Problem analysieren kann. Eine echte Lösung gab es für den Client nie. Ein Workaround folgte dem Nächsten.

Unter uns, die Arbeit im VMware-Support kann doch auch keinen Spaß machen, wenn man so ein Drecks-Werkzeug supporten muss. Die Aussage eines Supporters dazu: „Ich gehe groß feiern, wenn der HTML5-Client endlich fertig ist.“

Der neue vSphere Client (HTML5) verspricht Licht am Ende des Tunnels. Die Kritik am verhassten vSphere Web Client scheint VMware erreicht zu haben. Doch offensichtlich muss es erst noch einmal schlechter werden, bevor es besser werden kann. Denn mit vSphere 6.5 hat uns VMware eine Version spendiert, in der sich der ausgereifte vSphere Client nicht mehr verwenden lässt, der vSphere Web Client immer noch totaler Mist ist und der vSphere Client (HTML5) noch nicht voll funktionsfähig ist. Super. Ganz toll. Statt eines gut funktionierenden Clients gibt es jetzt einen gammeligen und einen erst teilweise fertiggestellten.

Was bleibt ist die Hoffnung, dass der HTML5-Client in der nächsten vSphere-Version voll funktionsfähig ist und ein würdiger Nachfolger des guten alten Clients wird, welchen VMware so lieblos sterben lies. Und vielleicht kommt das VMware-Marketing auf der Suche nach Innovationen dann ja auf die Idee, einen schnellen, stabilen Fat-Client zu entwickeln. Und damit sind wir Admins wieder glücklich und zufrieden, bis ans Ende unserer (Arbeits-)Tage.

TLDR;

VMware vSphere ist ein gutes Produkt. Auch im Fall von Störungen in der IT-Infrastruktur lässt einen diese Lösung nur selten im Stich. Virtuelle Maschinen werden bis zuletzt korrekt ausgeführt, während der sie umgebene Rest schon am Boden liegt.

Warum das Unternehmen die Admins über die letzten Jahre mit einem vSphere Web Client straft, der einem jeglichen Spaß an der Arbeit nimmt, wird vielleicht für immer ein Rätsel bleiben.

Hoffentlich bekommt das Unternehmen mit dem neuen vSphere Client (HTML5) endlich die Kurve. Denn die Mitbewerber haben bereits aufgeschlossen und sind einen Blick wert, wenn einem bei Nutzung der Client-Anwendung übel wird.

Nun, wo der Frust einmal raus ist, geht es mir schon besser und ich wünsche euch ein schönes und erholsames Wochenende.

vSphere PowerCLI: Snapshots nach Namen suchen und löschen

In diesem Beitrag möchte ich kurz dokumentieren, wie vSphere Snapshots mit Hilfe der PowerCLI nach Namen gesucht und gelöscht werden können.

Anwendungsfall

Beruflich betreue ich mehrere vSphere-Cluster mit einigen hundert virtuellen Maschinen (VMs). Um diese VMs zu sichern, kommt eine Image-Backup-Software zum Einsatz. Diese erstellt zum Zeitpunkt der Sicherung von jeder VM einen Snapshot, sichert die zur VM gehörenden Dateien und löscht den Snapshot anschließend wieder.

Läuft es mal nicht so gut und das Backup wird unterbrochen oder schlägt fehl, werden diese Snapshots nicht immer von allen VMs entfernt. Diese liegengebliebenen Snapshots von Hand suchen und löschen zu müssen, macht keinen Spaß. Zum Glück lässt sich diese Aufgabe automatisieren.

Alle Snapshots mit einem bestimmten Namen löschen

Mit der folgenden Befehlszeile wird der verbundene vCenter Server angewiesen, alle Snapshots, die dem spezifizierten Namensmuster entsprechen, zu löschen:

Get-VM | Get-Snapshot | Where {$_.Name -like "SNAPSHOTNAME*"} | Remove-Snapshot -Confirm:$false

Es wird dabei immer ein Snapshots nach dem anderen gelöscht. Dies kann durch Angabe des Parameters RunAsync beschleunigt werden. Es ist jedoch zu beachten, dass durch die Parallelisierung eine hohe I/O-Last im Storage erzeugt wird. Damit besteht das Risiko, den gesamten Cluster lahmzulegen.

Möchte man statt des Namens des Snapshots dessen Beschreibung verwenden, ist dies mit folgendem Befehl ebenfalls möglich:

get-vm | get-snapshot | where {$_.Description -match "Snapshot generated for backup"}| Remove-Snapshot -Confirm:$false

Quellen und weiterführende Links

VirtualBox VDI Datei in VMware VMDK Datei konvertieren

Schon 2012 habe ich im Artikel Virtualbox und das Open Virtualization Format darüber berichtet, dass sich ins OVF bzw. OVA Format exportierte VMs nicht in einer VMware vSphere Umgebung importieren lassen. Leider hat sich an diesem Umstand bis heute nichts geändert. Daher habe ich mir einen neuen Weg gesucht, um VMs von Virtualbox nach vSphere zu migrieren.

Auf dem ESXi ist zuerst eine neue virtuelle Maschine ohne Festplatte zu erstellen. Um nun die VDI aus VirtualBox nutzen zu können, muss diese zuerst in eine VMDK Datei konvertiert werden.

Eine Lösung fand ich in diesem englischsprachigen Blogpost. Zur Konvertierung nutzen wir das Tool „vboxmanage“ auf der Komandozeile. Der folgende Codeschnipsel zeigt einen Beispielaufruf:

C:\Program Files\Oracle\VirtualBox>vboxmanage clonehd "Pfad zur VDI Datei\quelldatei.vdi" "Pfad zur VDI Datei"\zieldatei.vmdk --format VMDK --variant Standard

vditovmdk

Beispiel einer Konvertierung von VirtualBox zu VMware.

Mit dem obigen Aufruf wird im selben Verzeichnis, in dem die VDI Datei liegt eine VMDK Datei erzeugt. Diese kann nun in den Datastore eines ESXi Hypervisor hochgeladen und als virtuelle Festplatte einer VM hinzugefügt werden.

Anschließend kann man die VM starten und sie weiter nutzen.

Update 16.3.2014: Hier kommt ein wichtiger Nachtrag aus der Praxis. Er soll ich davor bewahren, die gleichen Erfahrungen wie ich machen zu müssen. Die oben beschriebene Migration von VirtualBox zu vSphere führte zu einem wahren Härtetest von vSphere HA.

Nach dem Start der VM im vSphere Cluster sollten im nächsten Schritt die VBox Guest Additions deinstalliert und die VMware Tools installiert werden. Doch soweit bin ich gar nicht erst bekommen.

Denn die migrierte VM hängte sich auf und lies sich nicht mehr steuern. Auch ein Zurücksetzen der VM zeigte keinerlei Wirkung. Nur kurze Zeit später stürzte der ganze Hypervisor ab und der Cluster führte einen Failover durch. Dadurch wurde leider auch die fehlerhafte VM auf einen anderen Host übertragen und brachte diesen ebenfalls zum Absturz, bevor ich die VM stoppen und löschen konnte.

Zwei Hypervisor-Abstürze innerhalb von 30 Minuten sind eindeutig zwei zu viel. Für den VMware Support war dieses Verhalten ebenfalls neu. Hier bekam ich den Rat zukünftig die VirtualBox Guest Additions zu deinstallieren, bevor ich die VDI Datei konvertiere.

Für unseren Betrieb haben wir hingegen festgelegt keine weiteren VMs auf diesem Weg zu migrieren. Wir werden VMs nach einer Testphase durch Neuinstallation ins Cluster überführen. So können wir durch Konvertierung verursachte Fehler ausschließen und erstellte Dokumentationen überprüfen, indem wir das System nach der Dokumentation erneut bereitstellen.

vSphere: Virtuelle Festplatte klonen

Möchte man mehrere gleichartige Server bereitsellen, lässt sich die Bereitstellung beschleunigen, indem man einen Server installiert und die Festplatte klont.

Man erstellt dazu weitere VMs ohne Festplatte über den vSphere Client. Eine VMDK kann über die SSH-Shell mit folgendem Befehl geklont werden:

vmkfstools -i /path/old/vm/foo.vmdk /path/new/foo.vmdk