Virtualisierung Archiv - credativ®

Rückblick auf den Dutch Proxmox Day 2025

Am 25. September 2025 waren wir beim Dutch Proxmox Day 2025 in Ede (Niederlande) – und ich darf sagen: die Veranstaltung war rundum gelungen. Organisiert von Tuxis B.V. im Hotel Belmont in der Veluwe-Region, bot der Tag eine ausgezeichnete Mischung aus Fachvorträgen und wertvollem Austausch.

Dank an die Gastgeber

Ein herzliches Dankeschön an das Tuxis-Team: Für die Einladung als Speaker, für das entgegengebrachte Vertrauen und für die perfekte Organisation. Ja — dieser Blogartikel kommt etwas später, aber wie man sagt: besser spät als nie.

Meine Perspektive als Speaker

Als Speaker hatte ich das Vergnügen, Teil eines spannenden Programms zu sein. Gleichzeitig war ich Teilnehmer: beides zugleich – das macht solche Tage besonders. Einige Vorträge möchte ich hervorheben:

• Aaron Lauterer (Linux Software Developer bei Proxmox Server Solutions) – „Let’s get technical with a Proxmox developer“: Ein Blick auf kommende Features von Proxmox VE. Besonders spannend die kommende Integration von OCI Containern (aka Docker).
• Rob Turk (Senior Presales Systems Engineer bei Veeam) – „Save the data“: Zeigt deutlich, das Proxmox mittlerweile in der Enterprise Welt angekommen ist.
• Mark Schouten (CTO bei Tuxis) – „Cool stuff you can do with Proxmox“: Proxmox Backup Server im Zusammenspiel mit ZFS wie man das ganze noch was performanter bekommt und was für unerwartete Probleme mit SCSI und Western Digital aufgetreten sind davon hat uns Mark Schouten erzählt
• Alexander Wirt  – „Balancing workloads in Proxmox“: Mein eigener Beitrag mit Fokus auf das  Projekt ProxLB meines werten Kollegen Florian Hoberg, das virtuelle Maschinen gleichmäßig über Knoten verteilt, zeigt wieder die Vorteile und OSS und offenen Schnittstellen. Diese ermöglichen es fehlende Funktionalität einfach zu ergänzen und damit auch den Branchengrößen Konkurrenz zu machen.
• Robbe Van Herck (Support & Maintenance Engineer bei International Polar Foundation) – „Proxmox on Antarctica“: Proxmox im Extrem-Einsatz – am anderen Ende der Welt und sehr fern vom üblichen Rechenzentrumsalltag. Robbe konnte gut zeigen das Proxmox auch in den abgelegensten Winkeln der Erde funktioniert, spannend sind hier eher die anderen Herausforderungen – wie Hardware die mit den niedrigen Temperaturen überfordert ist.
• Han Wessels (Operations System Engineer bei ESA) – „Challenged to run Proxmox out of this world“: Warum Proxmox auch auf der ISS oder im All betrieben werden kann – Technik trifft Vision. Han schilderte plastisch die Herausforderungen die dabei entstehen, wie z.B. die Vibration beim Start der Trägerrakete oder die Strahlung die die Lebensdauer von Speicher deutlich verkürzt.

Ich konnte viele Impulse mitnehmen – sowohl technisch als auch ideell. Und ich habe gute Gespräche geführt, die sich sicherlich noch weiter auszahlen werden.

Networking & Austausch

Der informelle Teil war genauso wertvoll wie das Programm: in den Pausen, beim Mittagessen oder beim Get-together am Nachmittag haben wir neue Kontakte geknüpft, interessante Einblicke erhalten und alte Bekannte getroffen. Genau diese Momente machen eine Tagung lebendig.

Ausblick

Wir freuen uns jetzt schon auf nächstes Jahr. Wenn das Tuxis-Team wieder ruft, sind wir gern wieder mit dabei. Nochmals vielen Dank an alle Beteiligten, alle Speaker und alle Teilnehmenden – auf ein Wiedersehen. Zwischendurch gibt es in diesem Dezember das erste Open Source Virtualization Gathering bei uns im Haus.

VMs von VMware ESXi zu Proxmox migrieren

Als Reaktion auf die jüngsten Änderungen von Broadcom am VMware-Abonnementmodell überdenken immer mehr Unternehmen ihre Virtualisierungsstrategien. Angesichts wachsender Bedenken hinsichtlich Lizenzkosten und des Zugangs zu Funktionen wenden sich Unternehmen open source Lösungen zu, um mehr Flexibilität und Kosteneffizienz zu erzielen. Insbesondere Proxmox hat als praktikable Alternative große Aufmerksamkeit erlangt. Proxmox ist bekannt für seinen robusten Funktionsumfang und seine offene Architektur und bietet eine überzeugende Plattform für Unternehmen, die die Auswirkungen proprietärer Lizenzmodelle abmildern und gleichzeitig umfassende Virtualisierungsfunktionen beibehalten möchten. Dieser Trend unterstreicht einen breiteren Branchenwandel hin zur Akzeptanz von Open-Source-Technologien als praktikable Alternativen in der Virtualisierungslandschaft. Nur um es zu erwähnen, Proxmox ist weithin als eine praktikable Alternative zu VMware ESXi bekannt, aber es gibt auch andere Optionen, wie z. B. bhyve, die wir auch in einem unserer Blog-Posts behandelt haben.

Vorteile von Open-Source-Lösungen

In der dynamischen Landschaft des modernen Geschäftslebens stellt die Entscheidung für open source Lösungen für die Virtualisierung einen strategischen Vorteil für Unternehmen dar. Mit Plattformen wie KVM, Xen und sogar LXC-Containern können Unternehmen von der Abwesenheit von Lizenzgebühren profitieren, was erhebliche Kosteneinsparungen ermöglicht und Ressourcen in Innovation und Wachstum umleitet. Diese finanzielle Flexibilität ermöglicht es Unternehmen, strategische Investitionen in ihre IT-Infrastruktur zu tätigen, ohne die Belastung durch proprietäre Lizenzkosten. Darüber hinaus fördert die Open-Source-Virtualisierung die Zusammenarbeit und Transparenz, sodass Unternehmen ihre Umgebungen an ihre individuellen Bedürfnisse anpassen und nahtlos in bestehende Systeme integrieren können. Durch die Community-gesteuerte Entwicklung und robuste Support-Netzwerke erhalten Unternehmen Zugang zu einem reichen Wissens- und Ressourcenpool, der die Zuverlässigkeit, Sicherheit und Skalierbarkeit ihrer virtualisierten Infrastruktur gewährleistet. Die Nutzung der Open-Source-Virtualisierung bietet nicht nur greifbare finanzielle Vorteile, sondern stattet Unternehmen auch mit der Agilität und Anpassungsfähigkeit aus, die sie benötigen, um in einer sich ständig weiterentwickelnden digitalen Landschaft erfolgreich zu sein.

Migrieren einer VM

Voraussetzungen

Um einen reibungslosen Migrationsprozess von VMware ESXi zu Proxmox zu gewährleisten, müssen mehrere wichtige Schritte unternommen werden. Zunächst muss der SSH-Zugriff sowohl auf dem VMware ESXi-Host als auch auf dem Proxmox-Host aktiviert werden, um die Remote-Verwaltung und -Administration zu ermöglichen. Darüber hinaus ist es entscheidend, Zugriff auf beide Systeme zu haben, um den Migrationsprozess zu erleichtern. Darüber hinaus ist die Einrichtung einer SSH-Verbindung zwischen VMware ESXi und Proxmox für eine nahtlose Kommunikation zwischen den beiden Plattformen unerlässlich. Dies gewährleistet eine effiziente Datenübertragung und -verwaltung während der Migration. Darüber hinaus ist es unerlässlich, das Proxmox-System oder den Cluster ähnlich wie beim ESXi-Setup zu konfigurieren, insbesondere in Bezug auf die Netzwerkkonfigurationen. Dies umfasst die Sicherstellung der Kompatibilität mit VLANs oder VXLANs für komplexere Setups. Zusätzlich sollten beide Systeme entweder auf lokalem Speicher laufen oder Zugriff auf gemeinsam genutzten Speicher wie NFS haben, um die Übertragung von Virtual-Machine-Daten zu erleichtern. Schließlich ist es vor der Einleitung der Migration unerlässlich, zu überprüfen, ob das Proxmox-System über ausreichend verfügbaren Speicherplatz verfügt, um die importierte virtuelle Maschine aufzunehmen, um einen erfolgreichen Übergang ohne Speicherbeschränkungen zu gewährleisten.

SSH auf ESXi aktivieren

Der SSH-Server muss aktiviert sein, um den Inhalt vom ESXi-System an den neuen Speicherort auf dem Proxmox-Server zu kopieren. Die virtuelle Maschine wird später vom Proxmox-Server kopiert. Daher ist es erforderlich, dass das Proxmox-System eine SSH-Verbindung auf tcp/22 zum ESXi-System herstellen kann:

• Melden Sie sich beim VMware ESXi-Host an.
• Navigieren Sie zu Konfiguration > Sicherheitsprofil.
• Aktivieren Sie SSH unter Dienste.

Quellinformationen über VM auf ESXi finden

Eine der herausfordernden Aufgaben ist das Auffinden des Speicherorts der virtuellen Maschine, die die virtuelle Festplatte enthält. Der Pfad kann in der Web-UI des ESXi-Systems gefunden werden:

• Suchen Sie den ESXi-Knoten, auf dem die virtuelle Maschine ausgeführt wird, die migriert werden soll
• Identifizieren Sie die zu migrierende virtuelle Maschine (z. B. pgsql07.gyptazy.ch).
• Ermitteln Sie den Speicherort der virtuellen Festplatte (VMDK), die der VM zugeordnet ist, über das Konfigurationsfeld.
• Der VM-Speicherortpfad sollte angezeigt werden (z. B. /vmfs/volumes/137b4261-68e88bae-0000-000000000000/pgsql07.gyptazy.ch).
• VM stoppen und herunterfahren.

Eine neue leere VM auf Proxmox erstellen

• Erstellen Sie eine neue leere VM in Proxmox.
• Weisen Sie die gleichen Ressourcen wie im ESXi-Setup zu.
• Stellen Sie den Netzwerktyp auf VMware vmxnet3 ein.
  • Stellen Sie sicher, dass die benötigten Netzwerkressourcen (z. B. VLAN, VXLAN) ordnungsgemäß konfiguriert sind.
• Stellen Sie den SCSCI-Controller für die Festplatte auf VMware PVSCSI ein.
  • Erstellen Sie keine neue Festplatte (diese wird später von der ESXi-Quelle importiert).
• Jeder VM wird von Proxmox eine ID zugewiesen (notieren Sie diese, sie wird später benötigt).

VM von ESXi zu Proxmox kopieren

Der Inhalt der virtuellen Maschine (VM) wird vom ESXi- zum Proxmox-System mit dem open source Tool rsync zur effizienten Synchronisierung und zum Kopieren übertragen. Daher müssen die folgenden Befehle vom Proxmox-System aus ausgeführt werden, wo wir ein temporäres Verzeichnis erstellen, um den Inhalt der VM zu speichern:

mkdir /tmp/migration_pgsql07.gyptazy.ch
cd /tmp/migration_pgsql07.gyptazy.ch
rsync -avP root@esx02-test.gyptazy.ch:/vmfs/volumes/137b4261-68e88bae-0000-000000000000/pgsq07.gyptazy.ch/* .

Abhängig von der Dateigröße der virtuellen Maschine und der Netzwerkkonnektivität kann dieser Vorgang einige Zeit dauern.

VM in Proxmox importieren

Anschließend wird die Festplatte mit dem Dienstprogramm qm importiert, wobei die VM-ID (die während des VM-Erstellungsprozesses erstellt wurde) zusammen mit der Angabe des Festplattennamens (der kopiert wurde) und des Zieldatenspeichers auf dem Proxmox-System definiert wird, in dem die VM-Festplatte gespeichert werden soll:

qm disk import 119 pgsql07.gyptazy.ch.vmdk local-lvm

Abhängig vom Erstellungsformat der VM oder dem Exportformat kann es mehrere Festplattendateien geben, die auch mit _flat ergänzt werden können. Dieses Verfahren muss für alle verfügbaren Festplatten wiederholt werden.

VM starten

Im letzten Schritt sollten alle Einstellungen, Ressourcen, Definitionen und Anpassungen des Systems gründlich überprüft werden. Nach der Validierung kann die VM gestartet werden, um sicherzustellen, dass alle Komponenten korrekt für den Betrieb in der Proxmox-Umgebung konfiguriert sind.

Fazit

Dieser Artikel behandelt nur eine von vielen möglichen Methoden für Migrationen in einfachen, eigenständigen Setups. In komplexeren Umgebungen mit mehreren Host-Knoten und verschiedenen Speichersystemen wie Fibre Channel oder Netzwerkspeicher gibt es erhebliche Unterschiede und zusätzliche Überlegungen. Darüber hinaus kann es spezifische Anforderungen in Bezug auf Verfügbarkeit und Service Level Agreements (SLAs) geben, die zu berücksichtigen sind. Dies kann für jede Umgebung sehr spezifisch sein. Sie können sich jederzeit gerne an uns wenden, um eine persönliche Beratung zu Ihren spezifischen Migrationsanforderungen zu erhalten. Gerne bieten wir Ihnen auch unsere Unterstützung in verwandten Bereichen in open source wie Virtualisierung (z. B. OpenStack, VirtualBox) und Themen im Zusammenhang mit Cloud-Migrationen an.

Nachtrag

Am 27. März veröffentlichte Proxmox ihren neuen Import-Assistenten (pve-esxi-import-tools), der die Migration von VMware ESXi-Instanzen in eine Proxmox-Umgebung erheblich vereinfacht. In einem kommenden Blog-Beitrag werden wir weitere Informationen über die neuen Tools und Fälle bereitstellen, in denen diese möglicherweise nützlicher sind, aber auch die Eckfälle abdecken, in denen der neue Import-Assistent nicht verwendet werden kann.

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
Bus 002 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E230/E270/E870 HSDPA/HSUPA Modem

[...]
<devices>
  [...]
  <hostdev mode='subsystem' type='usb' managed='no'>
    <source>
      <vendor id='0x12d1'/>
      <product id='0x1003'/>
    </source>
  </hostdev>
</devices>

$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 001 Device 003: ID 0409:55aa NEC Corp. Hub
Bus 001 Device 004: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E230/E270/E870 HSDPA/HSUPA Modem

USB Serial support registered for GSM modem (1-port)
option 1-2.1:1.0: GSM modem (1-port) converter detected
usb 1-2.1: GSM modem (1-port) converter now attached to ttyUSB0
option 1-2.1:1.1: GSM modem (1-port) converter detected
usb 1-2.1: GSM modem (1-port) converter now attached to ttyUSB1
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems