Alternative zu VMWare Workstation mit PVE für VM Zugriff

[pvenewbie]

Moin in die Runde,

wir sind inzwischen soweit das wir uns für PVE entschieden haben, aber noch nicht produktiv eingeführt haben.

Zu meinem Szenario:

Wir sind ein IT-Systemhaus mit recht großer Entwicklungsabteilung und unsere Entwickler nutzen aktuell ein auf VMware basierendes 3 Node Cluster und verbinden sich via VMWare Workstation zu ihren eigenen VMs.
In Zukunft wollen wir ein größeres PVE Cluster aus 4 oder 5 Nodes betreiben welches das besagte VMWare Cluster ablöst.
Wir suchen nun für die Zukunft eine Lösung mit der
1. Die Benutzer basierend auf einem Login nur die Ihnen zugewiesenen VMs sehen, Ein- und ausschalten können
2. Die Benutzer volle RDP Funktionalitäten haben, Auflösung anpassen, copy&paste etc.
3. gewisse Kollegen mit mehr Privililegien auch VMs klonen/neu erstellen können

Gibt es hier Erfahrungswerte wie man dies am besten umsetzen kann, so wie ich das sehe dürfte es nicht direkt über das WebUI von Proxmox abbildbar sein das mit copy&paste gearbeitet werden kann.

Über Feedback wär ich dankbar, VG

 

[mariol]

Proxmox VE kann über verschiedene Authprovider [0] verwaltet werden, also Benutzer/Gruppen [1]. Dazu kann man explizit ACLs [2] definieren -> wer, was genau tun darf. Somit kann man z.B. verschiedene Gruppen/Abteilungen, differente/gewünschten Rechten bereit stellen.

Gibt es hier Erfahrungswerte wie man dies am besten umsetzen kann, so wie ich das sehe dürfte es nicht direkt über das WebUI von Proxmox abbildbar sein das mit copy&paste gearbeitet werden kann.

2. Die Benutzer volle RDP Funktionalitäten haben, Auflösung anpassen, copy&paste etc.

RDP hat mit mit Proxmox VE direkt nichts zu tun. Das ist eine Einstellung in der VM. Natürlich ist es von Vorteil wenn die VM genug VRAM verwenden kann. Es gbit auch GPU/vGPU-Passthrough, falls das ein Thema bei euch sein sollte [3], [4], [5].

Alternativ gibt es auch noch den Spice Client [6]. Den ich persöhnlich sehr gerne verwende, da man auch gleich Files über das Spicefenster vom Desktop direkt in die VM auf den anderen Desktop kopieren kann.

Hast du hier für uns ein Beispiel was bei "copy&paste" funktionieren sollte?

[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_authentication_realms
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_users
[2] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_permission_management
[3] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_pci_passthrough
[4] https://pve.proxmox.com/wiki/PCI_Passthrough#GPU_passthrough
[5] https://pve.proxmox.com/wiki/NVIDIA_vGPU_on_Proxmox_VE
[6] https://pve.proxmox.com/wiki/SPICE

 

[pvenewbie]

Proxmox VE kann über verschiedene Authprovider [0] verwaltet werden, also Benutzer/Gruppen [1]. Dazu kann man explizit ACLs [2] definieren -> wer, was genau tun darf. Somit kann man z.B. verschiedene Gruppen/Abteilungen, differente/gewünschten Rechten bereit stellen.




RDP hat mit mit Proxmox VE direkt nichts zu tun. Das ist eine Einstellung in der VM. Natürlich ist es von Vorteil wenn die VM genug VRAM verwenden kann. Es gbit auch GPU/vGPU-Passthrough, falls das ein Thema bei euch sein sollte [3], [4], [5].

Alternativ gibt es auch noch den Spice Client [6]. Den ich persöhnlich sehr gerne verwende, da man auch gleich Files über das Spicefenster vom Desktop direkt in die VM auf den anderen Desktop kopieren kann.

Hast du hier für uns ein Beispiel was bei "copy&paste" funktionieren sollte?

[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_authentication_realms
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_users
[2] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_permission_management
[3] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_pci_passthrough
[4] https://pve.proxmox.com/wiki/PCI_Passthrough#GPU_passthrough
[5] https://pve.proxmox.com/wiki/NVIDIA_vGPU_on_Proxmox_VE
[6] https://pve.proxmox.com/wiki/SPICE

Moin Mario, vielen Dank für deine Antwort.

Nach etwas tieferer Analyse sehe ich aktuell folgende Punkte bzw. offene Fragen:


Die Rechteverwaltung, AD-Anbindung, ACLs und die Sichtbarkeit von VMs pro Benutzer scheinen mit Proxmox grundsätzlich gut lösbar zu sein.
Unser Hauptthema ist weniger die VM-Verwaltung als vielmehr die tägliche Nutzung der VMs durch die Entwickler.
Aktuell arbeiten unsere Entwickler über VMware Workstation direkt auf ihren Entwicklungs-VMs und haben dadurch eine sehr komfortable Benutzererfahrung.
Die Entwickler kennen heute weder Hostnamen noch IP-Adressen ihrer VMs und müssen diese auch nicht kennen.
Es werden regelmäßig Klone von Entwicklungs-VMs erstellt.
Die geklonten VMs behalten häufig denselben Computernamen wie das Original. Eine eindeutige Namensstruktur innerhalb der Gastbetriebssysteme existiert daher oft nicht.
Die VM selbst ist für den Entwickler das Arbeitsobjekt, nicht deren Hostname oder Netzwerkadresse.
Ein klassischer RDP-Ansatz über DNS-Namen oder feste IP-Adressen erscheint deshalb nicht ohne Weiteres praktikabel.
Nach meinem aktuellen Verständnis stehen innerhalb von Proxmox im Wesentlichen noVNC und SPICE als integrierte Konsolenlösungen zur Verfügung.
noVNC wirkt für einen ganztägigen produktiven Einsatz eher ungeeignet.
SPICE erscheint deutlich besser nutzbar, allerdings habe ich zumindest im ersten Test unter Windows mit Virt-Viewer noch keine Performance erreicht, die sich mit VMware Workstation vergleichen lässt.
Besonders bei Fensterbewegungen, Animationen, Scrollen und generell der Desktop-Flüssigkeit wirkt die Darstellung über SPICE teilweise ruckelig.
Für unsere Entwickler wäre eine möglichst „Workstation-ähnliche“ Benutzererfahrung wünschenswert.
Daher meine eigentliche Frage an alle, die Proxmox bereits auf ähnliche Weise einsetzen:

Wie greifen eure Entwickler oder Power-User im Alltag auf ihre VMs zu?

• Nutzt ihr tatsächlich SPICE als primären Zugang?
• Verwendet ihr eine andere Lösung (z. B. RDP, Guacamole, Apache Guacamole, RustDesk, Parsec o. Ä.)?
• Wie löst ihr die Zuordnung zwischen Benutzer und VM, wenn regelmäßig VM-Klone erstellt werden und Hostnamen/IP-Adressen für die Anwender keine Rolle spielen sollen?
• Gibt es einen etablierten Ansatz, der dem bisherigen VMware-Workstation-Workflow möglichst nahekommt?
  
  
  
  Vielen Dank für eure Antworten.

 

[ThoSo]

Was sprich für euch dagegen, das der Entwickler sich direkt im Webbrowser am PVE anmeldet und dann "seine" VMs mit den Möglichkeiten sieht?
Die VmWare Workstation bietet meines Wissens auch nicht die Möglichkeit, das die Entwickler die Maschinen clonen. Müsste ich mich jetzt arg täuschen.
Alternativ gibt es auch noch den Virtual Maschine Manager (https://virt-manager.org/)

Es ist aber auch die Frage, wie restriktiv man innerhalb der Entwicklungsabteilung die Resourcen abschotten will/muss

 

[Falk R.]

1. Die Benutzer basierend auf einem Login nur die Ihnen zugewiesenen VMs sehen, Ein- und ausschalten können
2. Die Benutzer volle RDP Funktionalitäten haben, Auflösung anpassen, copy&paste etc.
3. gewisse Kollegen mit mehr Privililegien auch VMs klonen/neu erstellen können

Ihr nutzt die VMware Workstation ja nicht als solches sondern nur den Teil der VMware Remote Console.
Das Problem sehe ich nur bei Punkt2 da die VMware Remote Console euch Features bietet die es nicht 100% identisch im Open Source Umfeld gibt, vor allem aus dem Security Aspekt.
Du kannst ja mit den Berechtigungen und AD Anbindung den Leuten nur Zugriff auf Ihre VMs geben und dann müssten diese mit dem Spice Client arbeiten um einen Großteil der VMware Remote Console features zu haben. Aber ich persönlich finde den Spice Client nicht so prall, weil der sich langsamer anfühlt und eher mal zickt als z.B. noVNC.

 

[TErxleben]

Wir nutzen sehr gerne Guacamole. I.d.R sind es aber reine Endanwender, die alles andere wollen als an ihren VMs rumzuschrauben. Folgende Punkte möchte ich bemerken:

• C&P ist umständlich
• Verwaltung ist sehr gut.
• Operationen mit VMs nicht machbar.
• Wenn du klonen, starten, löschen etc. willst, bleibt die PVE-GUI oder CLI mit entsprechendem Verwaltungsaufwand
• Multimonitorbetrieb puzzelig oder (noch) kaum machbar.
• Da bleibt netzintern aber z.B. mstsc oder krdc. Ist natürlich nebenläufig.
• schwer zu beurteilen, da du nur rudimentäre Eckdaten nennst.

Sonst rennt Guacamole wie die wilde Watz (sogar mit CAD-VMs). Keinerlei zusätzliches Geraffel mit irgendwelchen Clients sondern Browserbetrieb.
Die C&P-"Problematik" sehe ich eher nicht, wenn eine ordentlich Infrastruktur verfügbar ist.
Ändern von gewohnten Abläufen ist immer hartes Brot aber durchaus machbar.

 

[mariol]

Die Entwickler kennen heute weder Hostnamen noch IP-Adressen ihrer VMs und müssen diese auch nicht kennen.

Ich denke jetzt mal das sich das organisatorisch sicher lösen lässt ?

Es werden regelmäßig Klone von Entwicklungs-VMs erstellt.
Die geklonten VMs behalten häufig denselben Computernamen wie das Original. Eine eindeutige Namensstruktur innerhalb der Gastbetriebssysteme existiert daher oft nicht.
Die VM selbst ist für den Entwickler das Arbeitsobjekt, nicht deren Hostname oder Netzwerkadresse.

Es gibt mehrere Möglichkeiten wie man sich das organisieren kann. Wie die VM selbst direkt benennt wird, also Hostname und IP ist eine Sache. Das ist unabhängig von der Benamung in Proxmox VE. Für mich persönlich halte ich das immer gleich. Sprich der FQDN in der VM ist auch der Name der VM und so ist sie auch per DNS erreichbar. Aber das muss natürlich überhaupt nicht so sein.

Ich persönlich organisiere mir das sehr gerne mit VM-Pools [0]. Ich finde das recht übersichtlich. Vielleicht wäre das ja auch was für euch? Hier ein kleines Beispiel:

Nach meinem aktuellen Verständnis stehen innerhalb von Proxmox im Wesentlichen noVNC und SPICE als integrierte Konsolenlösungen zur Verfügung.
noVNC wirkt für einen ganztägigen produktiven Einsatz eher ungeeignet.
SPICE erscheint deutlich besser nutzbar, allerdings habe ich zumindest im ersten Test unter Windows mit Virt-Viewer noch keine Performance erreicht, die sich mit VMware Workstation vergleichen lässt.
Besonders bei Fensterbewegungen, Animationen, Scrollen und generell der Desktop-Flüssigkeit wirkt die Darstellung über SPICE teilweise ruckelig.
Für unsere Entwickler wäre eine möglichst „Workstation-ähnliche“ Benutzererfahrung wünschenswert.

Kann ich sehr gut nachvollziehen. NoVNC ist mehr für, "ja ich mach mal kurz ne Wartung".

Nutzt ihr tatsächlich SPICE als primären Zugang?

Absolut, nutze ich täglich. Hier mit Server 2022 und Server 2025. Für Youtube schauen oder ähnliches würde ich es jetzt nicht verwenden wollen, aber für generelle Entwicklungsarbeiten, funktioniert es meiner Meinung nach sehr gut. Wichtig ist auch zu erwähnen das Spice für den das lokale LAN gedacht ist und über das WAN nicht gut benutzbar ist. Hier ist auch eine Beispielconfig von meinem Server 2022:

agent: 1,fstrim_cloned_disks=1
audio0: device=ich9-intel-hda,driver=spice
balloon: 10240
bios: ovmf
boot: order=scsi0;sata0
cores: 6
cpu: host
efidisk0: SSD:vm-102-disk-1,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
hotplug: disk,network,usb
machine: pc-q35-11.0+pve2
memory: 20480
meta: creation-qemu=6.2.0,ctime=1656281676
name: badboy.osit.cc
net0: virtio=02:A8:C4:41:8E:34,bridge=vmbr0,firewall=1
numa: 1
ostype: win11
rng0: source=/dev/urandom
sata0: none,media=cdrom
scsi0: SSD:vm-102-disk-2,discard=on,iothread=1,size=60G,ssd=1
scsihw: virtio-scsi-single
sockets: 1
tags: Microsoft
tpmstate0: SSD:vm-102-disk-0,size=4M,version=v2.0
vga: qxl,memory=256

Zusätzlich können auch noch TAGS verwendet werden [1].

Verwendet ihr eine andere Lösung (z. B. RDP, Guacamole, Apache Guacamole, RustDesk, Parsec o. Ä.)?

Ich verwende hier auch noch RDP, Rustdesk und Nomachine. Aber für interne Windows nehme ich zu gut wie immer Spice. Nomachine ist ne feine Sache, wenn man Windows eine GPU mit übergibt [2].

Wie löst ihr die Zuordnung zwischen Benutzer und VM, wenn regelmäßig VM-Klone erstellt werden und Hostnamen/IP-Adressen für die Anwender keine Rolle spielen sollen?

Das würde ich auch wieder über die Ressourcen Pools lösen wollen. Hab sowas mal vor vielen Jahren für ein größeres DEV-ENV (~200VMs) gebaut. Funktionierte sehr gut.

Meine Empfehlung wäre einfach mal einige Dinge austesten. Dann fallen solche Entscheidungen meist auch leichter.



[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pveum_resource_pools
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#gui_tags
[2] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_pci_passthrough

 

[Bu66as]

Moin, das kann man eigentlich ganz gut trennen: Rechte und Power-Management über PVE, den eigentlichen Zugriff aber nicht über die noVNC-Konsole. Pack pro Entwickler (oder pro Team) die VMs in einen eigenen Pool und gib dem User darauf die Rolle PVEVMUser. Dann sieht er im WebUI nur seine VMs und kann sie starten und stoppen. Die Kollegen mit mehr Rechten bekommen PVEVMAdmin auf den Pool, dazu noch Rechte auf Storage und Bridge (Datastore.AllocateSpace, SDN.Use), sonst schlägt das Klonen fehl. Bei uns hat es sich bewährt, Templates bereitzustellen und davon zu klonen. Das alles am besten gegen AD/LDAP als Realm, dann läuft der Login mit den bestehenden Accounts.

Für die tägliche Arbeit würde ich RDP direkt in den Gast nehmen, also übers Netz an der PVE-Konsole vorbei. Clipboard, Auflösung usw. gehen dann wie gewohnt. Dass die Entwickler weder Hostnamen noch IPs kennen, ist dabei kein Hindernis: Mit qemu-guest-agent im Gast und aktivierter Guest-Agent-Option in der VM zeigt das WebUI die aktuelle IP in der Übersicht der VM an. Der Entwickler findet seine VM also über den Namen in PVE und nicht über den Computernamen im Gast. Ein Klon bekommt eine neue MAC und zieht per DHCP eine eigene Adresse, auch wenn der Computername gleich bleibt. Im schon genannten Guacamole kann man die Verbindungen zentral unter dem VM-Namen hinterlegen, dann muss auch dort keiner eine IP kennen. Das ebenfalls schon genannte SPICE mit virt-viewer ginge auch (Clipboard und dynamische Auflösung über spice-vdagent bzw. die Guest Tools), ist aber eher die Notlösung, wenn die VM keine eigene Netzanbindung haben soll. Laufen da hauptsächlich Windows-VMs oder auch Linux-Desktops?

Falls ihr bei der Ablösung vom VMware-Cluster Unterstützung braucht: Wir (B1 Systems) machen sowas beruflich, https://www.b1-systems.de