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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert