Vm-Ware auf Proxmox Vm mit Windows Server 2019

[Marco Reichel]

Guten Tag liebe Proxmox Community,

Wir versuchen derzeit Vm-Ware auf einer Proxmox Vm-Instanz mit Windows Server 2019 einzurichten, respektive 2 Vms auf welchen einmal Debian 9 und einmal Debian 10 laufen soll.

Es kommt leider eine Fehlermeldung, welche besagt, dass Vm-Ware nicht mit Hyper-V kompatibel sei.
Da wir Hyper-V nicht eingeschaltet haben, haben wir nach kurzer Recherche festgestellt,
dass es sich auch um andere Virtualisierungssoftwares handeln kann, also bei uns naheliegend wäre dann Proxmox.
Wer von euch hat bezüglich Vm-Ware auf Proxmox Vms Kenntnisse und könnte uns weiterhelfen?

Viele Grüße und schonmal danke an euch

 

[Dominic]

Hallo!

Habe ich das richtig verstanden? Bare-metal ist Proxmox VE installiert. In Proxmox VE läuft eine Windows Server 2019 VM mit einer VMware-Software und darin laufen dann 2 Debian VMs?

Wie ist die VM in Proxmox VE konfiguriert qm config <vmid>? In jedem Fall könntet ihr verschiedene CPU-Einstellungen probieren, zum Beispiel hidden=1.

Gibt es einen speziellen Grund, warum die Debian VMs nicht direkt in Proxmox VE laufen sollen?

 

[bluesite]

hm warum nutzt ihr nicht einfach Samba unter Linux um von Windows auf Linux zuzugreifen?
Das hat ja nichts mit Virtualisierung zu tun im Grunde.

 

[Marco Reichel]

Hallo!

Habe ich das richtig verstanden? Bare-metal ist Proxmox VE installiert. In Proxmox VE läuft eine Windows Server 2019 VM mit einer VMware-Software und darin laufen dann 2 Debian VMs?

Wie ist die VM in Proxmox VE konfiguriert qm config <vmid>? In jedem Fall könntet ihr verschiedene CPU-Einstellungen probieren, zum Beispiel hidden=1.

Gibt es einen speziellen Grund, warum die Debian VMs nicht direkt in Proxmox VE laufen sollen?

Danke für die schnelle Antwort !

Unsere Config ist:
bootdisk: scsi0
cores: 8
cpu: host
memory: 65536
name: WindowsServer2019
net0: virtio=82:E3:06:BC:95:CA,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: win10
scsi0: SSD-WIN:100/vm-100-disk-0.vmdk,discard=on,iothread=1,size=800G,ssd=1
scsi1: SAS-WIN:100/vm-100-disk-0.vmdk,discard=on,iothread=1,size=10000G
scsihw: virtio-scsi-single
sockets: 2
vga: virtio
(ids ausgelassen)

Wir wollen eine schnelle Lösung, um im Windows Server auf die Linux Serverinhalte/Verzeichnisse zuzugreifen.
Sollte das Einrichten hiervon auf Proxmox schneller umsetzbar sein, sind wir auch für eine solche Lösung offen.
Wie kann man die Cpu-Einstellungen auf hidden=1 stellen ? im Config Fenster finden wir diesbezüglich nichts, welcher shell-command würde das erfüllen ?

Viele Grüße und vielen Dank !

 

[Marco Reichel]

hm warum nutzt ihr nicht einfach Samba unter Linux um von Windows auf Linux zuzugreifen?
Das hat ja nichts mit Virtualisierung zu tun im Grunde.

Da unsere Debian Instanzen bisher über VM-Ware gelaufen sind, wollen wir eine schnelle Integration, wenn möglich ohne neue Methoden zu integrieren, aber danke für die alternative Möglichkeit, wir ziehen das mal in Betracht !

 

[gmed]

"auf die Linux Serverinhalte/Verzeichnisse zuzugreifen."

Was spricht dagegen, die betreffenden Daten aus den Debian-VM's direkt auf die 2019er VM zu kopieren? Oder laufen auf den Linuxen Anwendungen, welche die Daten generieren?

Was ihr da macht, ist "nested Virtualization".
Hier mal die Doku dazu.
https://pve.proxmox.com/wiki/Nested_Virtualization

Darin steht auch beschrieben, wie der Gast-Hypervisor auf die zum einigermassen performanten Ausführen notwendigen Ressourcen Zugriff bekommt.
Hinsichtlich der Netzwerkverbindungen kann es u.U. auch zu Fallstricken kommen, da die Netzwerkkarte des 2019er-Gastes ja auch den Traffic seiner Gäste aktzeptieren muss.
Stichwort "promiscous Mode"


Evtl. ist es einfacher, die Debian vmdk's zu konvertieren und direkt unter Proxmox zu betreiben.

 

[Marco Reichel]

Okay danke für den Hinweis auf nested Virtualiszatoin, das ist interessant.

Bisher lief VMWorkstation auf einem nativen Windows Server 2008 R2. Jetzt läuft ein neuer Server auf Proxmox VE mit Window Server 2019 als Gast. Der Umzug der VMWorkstation inkl. VMs und VDs wäre einfach und schnell.

Da dies nicht so einfach wie gewünscht geht, gibt es vermutlich mehrere möglichen Gründe:

• Die Server Hardware ist anders (besser)
• Die Windows Server Version ist anders, jetzt 2019 statt 2008 R2
• Die Installationsart von Windows Server ist anders, jetzt virtuell statt nativ
• Proxmox virtualisiert die Hardware nicht so vollständig, dass es praktisch keinen Unterschied macht, ob Windows Server nativ oder virtuell läuft (das ist dann doch verbesserungsfähig)

Grundsätzlich ist es einfach, mit VMware Workstation bestehende VMs zu öffnen. Diese Funktion fehlt in Proxmox und man kann es wohl nur mit einem Workaround lösen. D.h. es gibt mehrere Aufgaben: vmdk übertragen (wie?), VM in proxmox anlegen und mit bestehender vmdk überschreiben. Das geht ja noch, aber es gibt eine Reihe VDs und dann wird es vermutlich aufwendig, wenn der Hypervisor das Öffnen von bestehenden VMs und VDs nicht so optimal unterstützt wie VMware Workstation. Daher stockt der Umzug auf den neuen Server erst mal bis geklärt ist, wie es am einfachsten weiter geht.

 

[gmed]

"Proxmox virtualisiert die Hardware nicht so vollständig, dass es praktisch keinen Unterschied macht, ob Windows Server nativ oder virtuell läuft (das ist dann doch verbesserungsfähig)"

Diese Eigenschaft bringen alle! Hypervisoren mit sich, da sie das Gast-OS von der Hardware abstrahieren.
Proxmox als OpenSource bietet hier Gelegenheit, selbst Verbesserungen beizutragen.

Der Imort von VmWare-Gästen gestaltet sich bei Proxmox relativ unkompliziert und wird u.a. hier näher beschrieben:

https://deepdoc.at/dokuwiki/doku.ph...direkter_import_von_anderen_virtualisierungen

https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE9

Grundsätzlich ist Proxmox kein Versuch VmWare zu klonen, sondern ein eigenständiges Produkt. Analog zu MS-Office und LibreOffice.
Und so wie LibreOffice eine weitgehende Kompatibilität zu den MS-Office Formaten bietet, gilt dies auch für den Umgang von vmdk-Dateien in Proxmox.
Sollte dies aus irgendwelchen Gründen Probleme bereiten, bleibt grundsätzlich immer der Weg, die jeweils andere, dann passendere Software einzusetzen.
Gerade, wenn die Zeit drängt und eigene Erfahrung noch nicht soweit aufgebaut ist.

 

[Dominic]

cpu: host
(...)
Wie kann man die Cpu-Einstellungen auf hidden=1 stellen ? im Config Fenster finden wir diesbezüglich nichts, welcher shell-command würde das erfüllen ?

Das ist tatsächlich nicht möglich im GUI. Sobald dieser

qm set <vmid> --cpu host,hidden=1

Befehl ausgeführt wurde, sollte es aber im GUI auch angezeigt werden.
In der Hardware-Ansicht wird dann [host] zu [host,hidden=1].

• Die Windows Server Version ist anders, jetzt 2019 statt 2008 R2

Windows Server sollte auch in der Version 2008 als Gast in Proxmox VE betrieben werden können. Siehe gegebenenfalls die Best Practices im Wiki.

https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE9

Da hat sich ein Tippfehler eingeschlichen. Der Link sollte wohl dahin https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE#VMware gehen.

Und so wie LibreOffice eine weitgehende Kompatibilität zu den MS-Office Formaten bietet, gilt dies auch für den Umgang von vmdk-Dateien in Proxmox.

Kann man so sagen. Die man page von qemu-img (PVE verwendet qemu-img zum Importieren) hat dazu noch ein paar Details:

QEMU also supports various other image file formats for compatibility with older QEMU versions or other hypervisors, including VMDK, VDI, VHD (vpc), VHDX, qcow1 and QED. For a full list of supported formats see qemu-img --help. For a more detailed description of these formats, see the QEMU block drivers reference documentation.
The main purpose of the block drivers for these formats is image conversion. For running VMs, it is recommended to convert the disk images to either raw or qcow2 in order to achieve good performance.

D.h. es gibt mehrere Aufgaben: vmdk übertragen (wie?),

Egal wie. Netzwerkspeicher, rsync... sogar eine USB-Festplatte reicht. Die korrekte Übertragung zu kontrollieren mit sha512sum oder ähnlichem wäre danach sinnvoll.

VM in proxmox anlegen und mit bestehender vmdk überschreiben. Das geht ja noch, aber es gibt eine Reihe VDs und dann wird es vermutlich aufwendig, wenn der Hypervisor das Öffnen von bestehenden VMs und VDs nicht so optimal unterstützt wie VMware Workstation. Daher stockt der Umzug auf den neuen Server erst mal bis geklärt ist, wie es am einfachsten weiter geht.

qm importovf und qm importdisk nehmen hier Arbeit ab. Beide sind Teil desselben qm CLI Befehls wie schon oben bei den CPU-Einstellungen.

Wir sind gerade dabei, genau diesen Import-Prozess von VMware zu Proxmox VE zu optimieren. Feedback ist also willkommen

 

[Marco Reichel]

Gerne hier - wie oben gewünscht - Feedback zum Öffnen einer bestehenen Windows VMware Workstation Maschine und Disk in Proxmox:

1. Virtuelle Maschine (bei uns Debian10) und Laufwerk (für Virtuelle Disk) in Proxmox (im gleichen Storage, man lernt dazu, um gleiche Dateinamen in Proxmox zu vermeiden) erstellt
2. Datensicherung der neuen VM inkl. VD per proxmox Backup (schnell da real leer, auch wenn virtuell groß)
3. Kopieren der VMware Maschine und Disk jeweils als vmdk Datei von Windows zu Proxmox über WinSCP
4. Umbennenen der vmdk Dateien und Anpassen der Linux Berechtigungen
5. ISO in der GUI entfernen
6. Booten der VM und Anpassen der fstab Datei, d.h. Auskommentieren der Shared Folders

Also alles wird über "kopieren" gelöst und "importiert" im engeren Sinne wird nichts. Das hat den Vorteil, dass vmdk Dateien erhalten bleiben und ggf. zurück gespielt werden können.

Was jetzt ein bissl anders war, ist die Angabe der Größe der Laufwerke, bei VMware in GB und bei Proxmox in GiB. Wir haben den gleichen Standardwert genommen, d.h. 950 GB in VWware und 950 GiB in Proxmox. Also wenn man die Größe in Proxmox auch in GB angeben könnte, wäre das schon mal cool.

 

[gmed]

"4. Umbennenen der vmdk Dateien und Anpassen der Linux Berechtigungen"

also ein mv xxx.vmdk diskxxx.qcow + anpassen der Rechte?

 

[r.jochum]

Wie Dominic geschrieben hat würde ich "qm importdisk" verwenden.

 

[Marco Reichel]

"4. Umbennenen der vmdk Dateien und Anpassen der Linux Berechtigungen"

also ein mv xxx.vmdk diskxxx.qcow + anpassen der Rechte?

Nein. Die Anforderung ist nach dem Nachdenken über raw, qcow2 und vmdk, dass alles VMs und VDs einheitlich vmdk als Format für virtuelle Disks und virtuelle Maschinen haben sollen, daher eher so:

root@S-4215:/mnt/SAS-LIN/images/101# ls -l
total 36677248
-rw-r--r-- 1 root root 24035590144 Aug 20 13:36 'Debian 10.x 64-bit.vmdk'
-rw-r--r-- 1 root root 13521387520 Aug 20 13:36  reichel-internet.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:13  vm-101-disk-0.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:47  vm-101-disk-1.vmdk
root@S-4215:/mnt/SAS-LIN/images/101# mv vm-101-disk-0.vmdk vm-101-disk-0.vmdk_backup
root@S-4215:/mnt/SAS-LIN/images/101# mv vm-101-disk-1.vmdk vm-101-disk-1.vmdk_backup
root@S-4215:/mnt/SAS-LIN/images/101# ls -l
total 36677248
-rw-r--r-- 1 root root 24035590144 Aug 20 13:36 'Debian 10.x 64-bit.vmdk'
-rw-r--r-- 1 root root 13521387520 Aug 20 13:36  reichel-internet.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:13  vm-101-disk-0.vmdk_backup
-rw-r----- 1 root root   124780544 Aug 28 12:47  vm-101-disk-1.vmdk_backup
root@S-4215:/mnt/SAS-LIN/images/101# mv 'Debian 10.x 64-bit.vmdk' vm-101-disk-0.vmdk
root@S-4215:/mnt/SAS-LIN/images/101# mv reichel-internet.vmdk vm-101-disk-1.vmdk
root@S-4215:/mnt/SAS-LIN/images/101# ls -l
total 36677248
-rw-r--r-- 1 root root 24035590144 Aug 20 13:36 vm-101-disk-0.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:13 vm-101-disk-0.vmdk_backup
-rw-r--r-- 1 root root 13521387520 Aug 20 13:36 vm-101-disk-1.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:47 vm-101-disk-1.vmdk_backup
root@S-4215:/mnt/SAS-LIN/images/101# chmod o= vm-101-disk*
root@S-4215:/mnt/SAS-LIN/images/101# ls -l
total 36677248
-rw-r----- 1 root root 24035590144 Aug 20 13:36 vm-101-disk-0.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:13 vm-101-disk-0.vmdk_backup
-rw-r----- 1 root root 13521387520 Aug 20 13:36 vm-101-disk-1.vmdk
-rw-r----- 1 root root   124780544 Aug 28 12:47 vm-101-disk-1.vmdk_backup

 

[Marco Reichel]

Wie Dominic geschrieben hat würde ich "qm importdisk" verwenden.

Warum, ich möchte ja nichts importieren. VMs importieren wäre aus meiner Sicht höchst sinnwidrig und Importieren ist was für Daten in Datenbanken. Hier soll einfach nur eine VM und eine VD kopiert und als bestehende VM geöffnet werden unter Beibehaltung des virtuellen Formats vmdk. Ein Import impliziert eine evtl. Veränderung des Dateiformats, was ausdrücklich nicht gewünscht ist. Die Anforderung ist, ein einheitliches Format und das ist bei uns jetzt als vmdk festgelegt, weil wir schon vor vielen Jahren mit Desktop Virtualisierung angefangen haben via VWware Workstation Pro. Falls die VM und VD auf einen Desktop kopiert werden soll, ist das jetzt weiterhin einfach möglich. D.h. man kann z.B. die Virtuelle Maschine inkl. virtuelle Disks am Server operativ laufen haben und bei Bedarf eine kopierte Version am Desktop PC oder Laptop PC als Entwickler Maschine parallel fahren.

 

[Dominic]

Sowohl qm importdisk als auch qm importovf besitzen einen Parameter --format, der das Zielformat von VM-Festplatten bestimmt. Auch VMDK ist da als Option vorhanden.

 

[gmed]

Meiner Meinung nach stellt sich hier langsam die Sinnfrage.
Das kvm qcow2 oder raw am besten unterstützt ist halt so.
Dies hat auch Auswirkungen bei Backups und/ oder dem Anlegen von Snapshots.

Meinem Empfinden nach ist hier der Wunsch eindeutig, ein VmWare-System ohne Einschränkungen aber eben unter Proxmox, an Stelle mit VmWare aufzubauen.
Das ist durchaus verständlich, muß aber immer wieder zu Problemen führen.

Gerade weil kvm auf die Nutzung von qcow2 etc. ausgelegt ist kann es bei der Nutzung von vmdk zu Schwierigkeiten kommen.
Um diese zu umgehen gibt es ja die passenden Importfunktionen, welche ja auch gegebenenfalls einen Export ermöglichen, wenn auf VmWare als Hypervisor gewechselt werden soll.

 

[Marco Reichel]

Meiner Meinung nach stellt sich hier langsam die Sinnfrage.
Das kvm qcow2 oder raw am besten unterstützt ist halt so.
Dies hat auch Auswirkungen bei Backups und/ oder dem Anlegen von Snapshots.

Meinem Empfinden nach ist hier der Wunsch eindeutig, ein VmWare-System ohne Einschränkungen aber eben unter Proxmox, an Stelle mit VmWare aufzubauen.
Das ist durchaus verständlich, muß aber immer wieder zu Problemen führen.

Gerade weil kvm auf die Nutzung von qcow2 etc. ausgelegt ist kann es bei der Nutzung von vmdk zu Schwierigkeiten kommen.
Um diese zu umgehen gibt es ja die passenden Importfunktionen, welche ja auch gegebenenfalls einen Export ermöglichen, wenn auf VmWare als Hypervisor gewechselt werden soll.

Die gelöste Sinnfrage war, welches virtuelles Format zu benutzen ist: raw, qcow2 oder vmdk? Die Antwort ist für uns vmdk, weil wir das schon haben. Bisher gab es keine Probleme, auch nicht mit Backups als Snapshot. Importe irgendwelcher Art wurden nicht benötigt.

Gelöst ist jetzt auch das Problem, wie man die von VMware bekannten und bewährten shared folders einrichtet, damit Linux auf Windows zugreifen kann. Freigegebene Ordner unter Windows Server (VM in Proxmox) werden in Debian (VM in proxmox) über die IP Adresse des Windows Servers gemounted und das ganze in die fstab eingetragen statt der früheren hgfs mounts von VMware shared folders (Debian on top of Windows). Jetzt läuft Debian parallel zu Windows und das hat diverse Vorteile (bei Windows Updates muss Debian nicht runtergefahren werden, ein virtuelles Windows System kann per proxmox Backup gesichert werden).

 

[celtar]

Hi,

nur als Hinweis (falls es in einer Fa. eingesetzt wird) da wir gerade auch das planen. Achte auf die Lizenzen (Virtualisierungsmöglichkeiten) bei Windows 2019. Das ist tricky und kann im Falle eines MS Audit etwas teuer werden. Hier hat sich lt. unserem Berater bei 2019 was getan.

vG
John

 

[Marco Reichel]

Danke für den Hinweis: wir achten immer sehr genau auf die Lizenzen. Bei Windows Server gibt es z.B. eine 180 Tage Lizenz für die Evaluation (Windows Server 2019 Standard Evaluation 180 Tage). Allerdings stellt sich die Frage, ob man wirklich Windows Server braucht, oder ob nicht ein einfaches Windows 10 Pro auch genügt. Weil, wenn ich mir die Unterschiede anschaue, siehe Quelle, dann frage ich mich, was mir die Server Version eigentlich an echten Vorteilen für den Mehrpreis bringt? Wobei für DATEV am Server schon Windows Server empfohlen wird.

Quellen:
https://www.hagel-it.de/it-dienstle...terscheidet-er-sich-vom-normalen-windows.html
https://apps.datev.de/dnlexka/document/0908081