Schlagwort-Archive: esxi

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

Schreibe eine Antwort

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

Schreibe eine Antwort

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.

VirtualBox VDI Datei in VMware VMDK Datei konvertieren

Schreibe eine Antwort

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

Schreibe eine Antwort

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