Schlagwort-Archive: vmware

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?

VMware ESXi: VMDK-Datei einer Gast-VM mit virt-sysprep bereinigen

Soll eine virtuelle Maschine (VM) als Vorlage (engl. template) für weitere VMs dienen, so ist es in der Regel ausreichend, eine VM mit dem gewünschten Betriebssystem zu installieren und zukünftig als Vorlage zu verwenden. Anschließend kann diese VM über die Werkzeuge im ESXi-Host- bzw. vSphere-Client geklont werden. Die dabei erzeugte VM kann während dieses Vorgangs mithilfe einer Gast-Anpassungsspezifikation angepasst werden, um z.B. einen neuen Hostnamen oder eine abweichende IP-Adresse zu vergeben.

Klont man nach dem beschriebenen Verfahren eine Linux-VM, enthält diese noch die Historie des Originals. So werden z.B. bash-history, crontabs, ssh-hostkeys, ssh-userdirs, etc. vom Original übernommen und bestehen in der neuen VM fort. Um dies zu verhindern, sind diese Informationen zuvor aus der VM, welche als Vorlage dient, zu entfernen. Dazu kann man sich eigener Skripte bedienen oder auf das Programm virt-sysprep zurückgreifen, welches genau für diese Aufgabe geschaffen wurde.

Im Folgenden dokumentiere exemplarisch, wie man mit virt-sysprep eine VMDK-Datei bearbeiten kann, die im Datenspeicher eines ESXi-Hosts abgelegt ist.

Warnung: Folgende Schritte werden von VMware nicht unterstützt. Es besteht die Gefahr des Datenverlusts durch beschädigte VMDK-Dateien. Wer diesem Tutorial folgt, tut dies auf eigene Gefahr. Zuvor sollte geprüft werden, ob ein aktuelles Backup existiert, welches bei Bedarf wiederhergestellt werden kann.

Umgebung

Für dieses Tutorial wird ein Linux-Arbeitsplatz verwendet, auf dem die Pakete libguestfs-tools und sshfs zu installieren sind.

Die zu bearbeitende VMDK-Datei heißt in diesem Beispiel vmname-flat.vmdk und liegt im Datenspeicher eines ESXi-Hosts.

Vom Linux-Arbeitsplatz aus kann via SSH auf den Root-Account des ESXi-Hosts zugegriffen werden.

Ein virt-sysprep-wrapper-Skript

Ich möchte auf meine VMDK-Dateien die Standard-Operationen von virt-sysprep, mit Ausnahme der Operation ssh-userdir anwenden (siehe OPERATIONS in virt-sysprep(1)). Dazu habe ich ein kurzes Wrapper-Skript erstellt, welches eine notwendige Umgebungsvariable setzt, den Pfad zur zu bearbeitenden VMDK-Datei als Argument übergeben bekommt und die gewünschten Operationen darauf ausführt. Das Skript ist im Folgenden dargestellt. Die eigentliche Aktion passiert in den letzten beiden Zeilen.

#!/bin/bash
# Author: Joerg Kastning
# Description:
# Sysprep RHEL vSphere templates using `virt-sysprep` from `libguestfs-tools`.

usage()
{
  cat << EOF
  usage: $0 OPTIONS $1

  This script use virt-sysprep to reset, unconfigure or customize a virtual machine so clones can be made (virt-sysprep(1)).

  The path to the file VMNAME-flat.vmdk has to be provided as $1.

  OPTIONS:
  -h Shows this help message.
EOF
}

export LIBGUESTFS_BACKEND=direct
virt-sysprep --operations defaults,-ssh-userdir -a $1

Das Skript liegt im Verzeichnis bin, im HOME-Verzeichnis meines Benutzers. Damit befindet sich das Skript im PATH und kann ohne den vollqualifizierten Pfad aufgerufen werden.

Der Ablauf

Wichtig: Die VM, deren VMDK-Datei bearbeitet werden soll, MUSS ausgeschaltet sein.

Zuerst müssen die Pakete libguestfs-tools und sshfs auf dem Linux-Arbeitsplatz installiert werden:

sudo [apt|yum|dnf] install libguestfs-tools sshfs

Alle weiteren Schritte werden auf dem Linux-Arbeitsplatz ausgeführt:

$ mkdir vmfs
$ sshfs root@esxi-host.beispiel.de:/vmfs vmfs
$ cd vmfs/pfad/zum/verzeichnis/der/VM/
$ virt-sysprep-wrapper.sh vmname-flat.vmdk
[   0,0] Examining the guest ...
[  15,1] Performing "abrt-data" ...
[  15,3] Performing "backup-files" ...
[  24,4] Performing "bash-history" ...
[  24,5] Performing "blkid-tab" ...
[  24,7] Performing "crash-data" ...
[  24,7] Performing "cron-spool" ...
[  24,8] Performing "dhcp-client-state" ...
[  25,0] Performing "dhcp-server-state" ...
[  25,0] Performing "dovecot-data" ...
[  25,0] Performing "logfiles" ...
[  28,2] Performing "machine-id" ...
[  28,3] Performing "mail-spool" ...
[  28,3] Performing "net-hostname" ...
[  28,6] Performing "net-hwaddr" ...
[  28,8] Performing "pacct-log" ...
[  28,9] Performing "package-manager-cache" ...
[  30,5] Performing "pam-data" ...
[  30,5] Performing "passwd-backups" ...
[  30,6] Performing "puppet-data-log" ...
[  30,7] Performing "rh-subscription-manager" ...
[  30,8] Performing "rhn-systemid" ...
[  30,9] Performing "rpm-db" ...
[  31,0] Performing "samba-db-log" ...
[  31,1] Performing "script" ...
[  31,1] Performing "smolt-uuid" ...
[  31,1] Performing "ssh-hostkeys" ...
[  31,2] Performing "sssd-db-log" ...
[  31,3] Performing "tmp-files" ...
[  31,8] Performing "udev-persistent-net" ...
[  31,9] Performing "utmp" ...
[  31,9] Performing "yum-uuid" ...
[  32,0] Performing "customize" ...
[  32,2] Setting a random seed
[  32,3] Setting the machine ID in /etc/machine-id
[  32,9] Performing "lvm-uuids" ...
$ cd
$ fusermount -u vmfs

Damit ist die VM von ihrer Geschichte befreit und kann nun als bereinigte Vorlage für weitere VMs dienen.

Quellen und weiterführende Links

Running a NetBSD Virtual Machine on VMware ESXi on Arm Fling

Dies ist ein Gastbeitrag von meinem geschätzten Kollegen Jörn Clausen. Der Beitrag wurde in englischer Sprache verfasst und behandelt die Installation von NetBSD auf dem VMware ESXi on ARM Fling.

In October 2020, VMware released a preview of their hypervisor ESXi for
the ARM architecture. It is free to download (registration needed, though) and will run for 180 days, and one of the supported platforms is the Raspberry Pi 4B. So it’s quite easy to give it a try. To install the ESXi ARM Fling, use the instructions you’ll find at the download page. The ESXi installation is not covered by this article.

A lot of Linux distributions and FreeBSD are working as guest OSes, and luckily NetBSD’s motto holds up: „Of course it runs NetBSD!“. Thanks to the work of Jared McNeill, the ARM port of NetBSD will run on ESXi for ARM.

As his instructions for creating a running NetBSD VM are a bit terse, I’d like to elaborate a little bit.

Prerequisites

You will need the following things:

  • ESXi on Arm Fling up and running (duh!)
  • SSH access to the ESXi host (activate either from the console or the
    web interface)
  • qemu-img, for example by installing emulators/qemu from
    pkgsrc

And of course you will need NetBSD. Download the latest installation image either from Jared’s site „http://www.armbsd.org/arm/“ (be sure to download „Generic 64-bit“ from the tab „NetBSD -current“), or use the latest HEAD release.

Creating a NetBSD VMDK file

Unpack the image:

$ gunzip arm64.img.gz

Increase the image to the size the hard disk should have. In this case, we grow it to just 2 GB:

$ qemu-img resize -f raw arm64.img 2g
Image resized.

Convert the image to a VMDK file

$ qemu-img convert -o compat6 -f raw arm64.img -O vmdk arm64.vmdk

Transfer the last file arm64.vmdk to the datastore on the ESXi host, either using scp or by uploading it via the web interface.

Creating a NetBSD VM

Log on to the ESXi host using ssh. Navigate to the directory where you uploaded the VMDK file. If you used a basic setup with all the defaults, this will be /vmfs/volumes/datastore1/.

Convert the VMDK file to a proper virtual hard disk:

# vmkfstools -i arm64.vmdk -d thin arm64-hd.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk 'arm64.vmdk'...
Clone: 100% done.

Switch to the web interface of ESXi and create a new VM. Use „Other“ as Guest OS family and „Other (64-bit)“ as Guest OS version.

Remove the hard disk that is automatically added to the VM. Instead, select „Add hard disk“ and „Existing hard disk“. Choose the VMDK you created in the last step (be sure to use arm64-hd.vmdk and not arm64.vmdk).

You can use the default network adapter (E1000e) or you can replace it with the paravirtualized one (VMXNET3).

Running the NetBSD VM

Now start the VM and open the console. The virtual machine should boot straight into the NetBSD boot loader and then into NetBSD. On the first boot, NetBSD will grow the filesystem to use the complete hard disk and reboot. After that, you should be able to login as root.

Now you have a complete NetBSD system. You can even run an X server on the console.

VMDK-Dateien mit Hilfe der PowerCLI vergrößern

In diesem Tutorial möchte ich an einem Minimal-Beispiel zeigen, wie mit Hilfe der PowerCLI ausgewählte VMDK-Dateien spezifischer VMs vergrößert werden können.

Dies bietet sich z.B. immer dann an, wenn so viele VMs betroffen sind, dass der Aufwand der manuellen Vergrößerung über den vSphere-(Web)-Client zu groß erscheint.

Betrachtet wird hier lediglich die Vergrößerung der VMDK-Datei. Die anschließend ebenfalls notwendige Vergrößerung von Partition und Dateisystem innerhalb des Gast-Betriebssystems ist nicht Bestandteil dieses Tutorials.

Zielstellung

Für das Minimalbeispiel sollen aus einer Gruppe VMs die jeweils zweite und dritte Festplatte von VM-Test-5 und VM-Test-6 vergrößert werden. Die jeweilige zweite Festplatte ist von 250 GB auf 500 GB zu vergrößern und die jeweilige dritte Festplatte soll von 400 GB auf 800 GB vergrößert werden.

Voraussetzungen

Eine funktionsfähige Installation der VMware PowerCLI und die Möglichkeit den vCenter Server über diese ansprechen zu können, ist Voraussetzung, um diesem Tutorial zu folgen.

Ablauf

Im folgenden Code-Block wird dargestellt, wie wir die notwendigen Informationen über die zu bearbeitenden VMs auslesen.

PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-\d"}

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
VM-Test-5        PoweredOn  4        24.000
VM-Test-7        PoweredOn  4        16.000
VM-Test-6        PoweredOn  4        24.000


PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
VM-Test-5        PoweredOn  4        24.000
VM-Test-6        PoweredOn  4        24.000


PowerCLI C:\Scripts> $VM = Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}
PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize

Parent        Name        CapacityGB
------        ----        ----------
VM-Test-5 Hard disk 1         40
VM-Test-5 Hard disk 2        250
VM-Test-5 Hard disk 3        400
VM-Test-5 Hard disk 4         80
VM-Test-6 Hard disk 1         40
VM-Test-6 Hard disk 2        250
VM-Test-6 Hard disk 3        400
VM-Test-6 Hard disk 4         80

Aus der obigen Ausgabe ist zu erkennen, dass wir die VMDK-Dateien, welche als „Hard disk 2“ bzw. „Hard disk 3“ bezeichnet werden, vergrößern möchten.

In dem nun folgenden Code-Block definiere ich zuerst ein paar Variablen, welche ich für den Verarbeitungslauf benötige, anschließend prüfe ich noch einmal, ob ich die richtigen VMDK-Dateien für die Operation auswähle und vergrößere sie anschließend.

PowerCLI C:\Scripts> $HardDisk = 2
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 500
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
250.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
250.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk


PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
500.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
500.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk


PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize

Parent        Name        CapacityGB
------        ----        ----------
VM-Test-5 Hard disk 1         40
VM-Test-5 Hard disk 2        500
VM-Test-5 Hard disk 3        400
VM-Test-5 Hard disk 4         80
VM-Test-6 Hard disk 1         40
VM-Test-6 Hard disk 2        500
VM-Test-6 Hard disk 3        400
VM-Test-6 Hard disk 4         80


PowerCLI C:\Scripts> $HardDisk = 3
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 800
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
400.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
400.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk


PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false

CapacityGB      Persistence                                                    Filename
----------      -----------                                                    --------
800.000         IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
800.000         IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk


PowerCLI C:\Scripts>

Falls der obige Code-Block nicht selbsterklärend ist, stellt eure Fragen dazu gern in den Kommentaren. Ich versuche das Tutorial dann zeitnah zu ergänzen.

Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen

Unter VMware vSphere lassen sich neue Festplatten im laufenden Betrieb zu einer virtuellen Maschine hinzufügen. Damit man diese neuen Festplatten im Gastbetriebssystem auch verwenden kann, müssen sie dem Kernel jedoch noch bekannt gemacht werden. Wie dies ohne Neustart geht, möchte ich in diesem Artikel dokumentieren.

Um die neuen Festplatten zu erkennen, muss man den Kernel veranlassen die vorhanden Speicher-Adapter (SATA/SAS/SCSI) nach neuen Geräten abzusuchen. Leider habe ich dafür kein einfaches Kommando gefunden, weswegen ich folgendes Verfahren anwende.

Unter /sys/class/scsi_host findet man die dem Kernel bekannten Speicher-Adapter des Systems:

$ ls /sys/class/scsi_host
host0  host1  host2

Um einen Speicher-Adapter nach neuen Geräten abzusuchen, führt man folgendes Kommando auf dem entsprechenden Adapter aus:

# echo '- - -' > /sys/class/scsi_host/host0/scan

Ist man sich nicht sicher, an welchen Speicher-Adapter die neuen Festplatten angeschlossen wurden, können alle Adapter mit der folgenden kleinen Schleife abgesucht werden:

# for f in /sys/class/scsi_host/host*; do echo '- - -' > $f/scan; done

Anschließend tauchen die neuen Festplatten in der Ausgabe von parted -l oder fdisk -l auf und können wie gewohnt formatiert und genutzt werden.

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

Installation von VMware Tools in einer Ubuntu VM

Update 2021-06-09

Um den Netzwerkadapter VMXNET3[1. Choosing a network adapter for your virtual machine (1001805)] in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein. In den aktuellen Versionen von Ubuntu und weiteren Distributionen wie z.B. RHEL, SLES, etc. sind inzwischen Treiber für die VMXNET3-Netzwerkkarte enthalten. Dennoch ist die Installation der VMware Tools empfohlen.
Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB2073803[2. VMware support of open-vm-tools (2073803)].

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.[3. VMware Tools in an Ubuntu 14.04 Guest] Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. [4. https://github.com/vmware/open-vm-tools]

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB1022525[5. Installing VMware Tools in an Ubuntu virtual machine (1022525)] und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

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