[Vision/Epic] Hypervisor-Abstraktionsschicht (Proxmox heute; Hyper-V & ESXi künftig) #68

New issue

Open

opened 2026-06-02 17:36:11 +00:00 by chinux · 0 comments

chinux commented

2026-06-02 17:36:11 +00:00

Owner

Vision / Backlog — NICHT fuer jetzt. Strategisches Epic, kein eingeplantes Feature. Voraussetzung fuer alles Weitere ist die Abstraktionsschicht selbst.

Idee

theProx so umbauen, dass es nicht mehr fest an Proxmox haengt, sondern ueber eine HypervisorBackend-Abstraktion mehrere Hypervisoren bedienen kann: Proxmox (heute), Hyper-V und ESXi (kuenftig).

Heutiger Zustand (das Hindernis)

theProx ist durchgaengig Proxmox-nativ: der Node-Agent spricht ueberall direkt pvesh/qm/pct, das Datenmodell ist vms/cts, Kanal 1 = PVE-API, Kanal 2 = QEMU-Guest-Agent, Storage = PVE-Storage, Backup = PBS/vzdump. Das ist kein Feature-Mangel, sondern verdrahtete DNA.

Was portabel ist — und was nicht

Portabel: der In-Guest-Agent (Kanal 3). Laeuft im Gast → Hypervisor egal. vm.scan, vm.port_scan, vm.update, compose_check laufen unveraendert, sobald der Agent drin ist.
Nicht portabel: die Host-Ebene (Kanal 1/2) — muss pro Hypervisor neu implementiert werden.

Abstraktion (Vorbedingung)

Interface HypervisorBackend mit u. a.: list_vms, list_containers (optional), lifecycle(start/stop/...), storage, node_status, guest_exec, snapshot/backup, network.

Proxmox = Referenz-Implementierung (der bestehende pvesh/qm/pct-Code, hinter das Interface gezogen).
Datenmodell generalisieren: vms/cts → Hypervisor-neutral (CT nur dort, wo es das Konzept gibt).

Backend: Hyper-V (bester Verwaltungs-Zweitkandidat)

Agent auf dem Host moeglich (Hyper-V-Host = Windows Server) → das Node-Agent-Modell traegt; baut auf vorhandenem Windows-Agent (#27) auf.
Steuerung ueber PowerShell/WMI (Get-VM, Start-VM, Get-VMHost, CIM-Namespace root\virtualization\v2).
Guest-Exec: PowerShell Direct (Invoke-Command -VMName) — Host→Gast ohne Netz, aber nur Windows-Gast auf Windows-Host; Linux-Gaeste ueber hv-Integration-Services/KVP oder Kanal-3-Agent.
Kein LXC-Aequivalent (nur VMs). Storage VHDX, Checkpoints statt Snapshots, kein PBS.
Stolpersteine: Standalone-Host easy (lokales PS), aber Failover-Cluster/SCVMM = eigene Management-Ebene; WinRM/Kerberos/CredSSP + Double-Hop in fremden AD-Umgebungen fummelig.

Backend: ESXi/vSphere (eher Migrationspfad)

Kein persistenter Custom-Agent auf dem Host (gelockt, VIB-Signing) → Node-Backend muss als Appliance-VM laufen, die vCenter/ESXi ueber Netz anspricht (agentless-zum-Hypervisor).
API: vCenter/vSphere (SOAP/REST, govc/pyvmomi/PowerCLI). Guest-Exec ueber VMware-Tools Guest Operations statt qm-agent. Datastores statt PVE-Storage.
Positionierung: wegen Broadcom-Preiswende eher ESXi-Inventory lesen + Migration nach Proxmox begleiten als Voll-Verwaltung. Passt zur DACH-MSP-Nische und reitet die Abwanderungswelle.

Strategische Einordnung (Breite vs. Tiefe)

Jeder weitere Hypervisor verdoppelt Test-/Wartungsflaeche → das Solo-Risiko aus dem Projekt-Assessment.
Scharfer Schnitt statt Paritaet: Hyper-V als Verwaltung (passt zum Windows-Know-how), ESXi als Migrations-/Onboarding-Feature.
Reihenfolge: erst die Abstraktion (Proxmox als Referenz), dann Hyper-V (naeher am Modell), ESXi als Migrationspfad.

Erster sinnvoller Schritt (wenn ueberhaupt)

Nur die Abstraktion einziehen, Verhalten fuer Proxmox 1:1 erhalten — reiner Refactor ohne Funktionsaenderung. Danach kann ein zweites Backend als isoliertes Experiment entstehen.

Bezug

#56 (Haertung auf fremden Umgebungen — die Abstraktion ist die Generalisierung davon)
Projekt-Assessment (Breite-vs-Tiefe / Solo-Wartungslast)

Branch (erster Schritt)

refactor/hypervisor-backend-abstraction

> **Vision / Backlog — NICHT fuer jetzt.** Strategisches Epic, kein eingeplantes Feature. Voraussetzung fuer alles Weitere ist die Abstraktionsschicht selbst. ## Idee theProx so umbauen, dass es nicht mehr fest an Proxmox haengt, sondern ueber eine **`HypervisorBackend`-Abstraktion** mehrere Hypervisoren bedienen kann: Proxmox (heute), Hyper-V und ESXi (kuenftig). ## Heutiger Zustand (das Hindernis) theProx ist durchgaengig **Proxmox-nativ**: der Node-Agent spricht ueberall direkt `pvesh`/`qm`/`pct`, das Datenmodell ist `vms`/`cts`, Kanal 1 = PVE-API, Kanal 2 = QEMU-Guest-Agent, Storage = PVE-Storage, Backup = PBS/vzdump. Das ist kein Feature-Mangel, sondern verdrahtete DNA. ## Was portabel ist — und was nicht - **Portabel:** der **In-Guest-Agent (Kanal 3)**. Laeuft *im* Gast → Hypervisor egal. `vm.scan`, `vm.port_scan`, `vm.update`, `compose_check` laufen unveraendert, sobald der Agent drin ist. - **Nicht portabel:** die **Host-Ebene (Kanal 1/2)** — muss pro Hypervisor neu implementiert werden. ## Abstraktion (Vorbedingung) Interface `HypervisorBackend` mit u. a.: `list_vms`, `list_containers` (optional), `lifecycle(start/stop/...)`, `storage`, `node_status`, `guest_exec`, `snapshot/backup`, `network`. - **Proxmox = Referenz-Implementierung** (der bestehende pvesh/qm/pct-Code, hinter das Interface gezogen). - Datenmodell generalisieren: `vms`/`cts` → Hypervisor-neutral (CT nur dort, wo es das Konzept gibt). ## Backend: Hyper-V (bester Verwaltungs-Zweitkandidat) - **Agent auf dem Host moeglich** (Hyper-V-Host = Windows Server) → das Node-Agent-Modell traegt; baut auf vorhandenem Windows-Agent (#27) auf. - Steuerung ueber **PowerShell/WMI** (`Get-VM`, `Start-VM`, `Get-VMHost`, CIM-Namespace `root\virtualization\v2`). - **Guest-Exec:** PowerShell Direct (`Invoke-Command -VMName`) — Host→Gast ohne Netz, aber nur Windows-Gast auf Windows-Host; Linux-Gaeste ueber hv-Integration-Services/KVP oder Kanal-3-Agent. - **Kein LXC-Aequivalent** (nur VMs). Storage VHDX, Checkpoints statt Snapshots, kein PBS. - **Stolpersteine:** Standalone-Host easy (lokales PS), aber **Failover-Cluster/SCVMM** = eigene Management-Ebene; **WinRM/Kerberos/CredSSP + Double-Hop** in fremden AD-Umgebungen fummelig. ## Backend: ESXi/vSphere (eher Migrationspfad) - **Kein persistenter Custom-Agent auf dem Host** (gelockt, VIB-Signing) → Node-Backend muss als **Appliance-VM** laufen, die vCenter/ESXi ueber Netz anspricht (agentless-zum-Hypervisor). - API: vCenter/vSphere (SOAP/REST, `govc`/pyvmomi/PowerCLI). Guest-Exec ueber **VMware-Tools Guest Operations** statt qm-agent. Datastores statt PVE-Storage. - **Positionierung:** wegen Broadcom-Preiswende eher **ESXi-Inventory lesen + Migration nach Proxmox begleiten** als Voll-Verwaltung. Passt zur DACH-MSP-Nische und reitet die Abwanderungswelle. ## Strategische Einordnung (Breite vs. Tiefe) - Jeder weitere Hypervisor verdoppelt Test-/Wartungsflaeche → das Solo-Risiko aus dem Projekt-Assessment. - Scharfer Schnitt statt Paritaet: **Hyper-V als Verwaltung** (passt zum Windows-Know-how), **ESXi als Migrations-/Onboarding-Feature**. - Reihenfolge: erst die Abstraktion (Proxmox als Referenz), dann Hyper-V (naeher am Modell), ESXi als Migrationspfad. ## Erster sinnvoller Schritt (wenn ueberhaupt) Nur die Abstraktion einziehen, Verhalten fuer Proxmox 1:1 erhalten — reiner Refactor ohne Funktionsaenderung. Danach kann ein zweites Backend als isoliertes Experiment entstehen. ## Bezug - #56 (Haertung auf fremden Umgebungen — die Abstraktion ist die Generalisierung davon) - Projekt-Assessment (Breite-vs-Tiefe / Solo-Wartungslast) ## Branch (erster Schritt) `refactor/hypervisor-backend-abstraction`

chinux added the

tech-debt

agent

labels

2026-06-02 17:36:11 +00:00

chinux referenced this issue

2026-06-20 14:35:41 +00:00

Projekt-Umbenennung: weg von "theProx" (Proxmox-Markennaehe) — Namensfindung #107

chinux referenced this issue

2026-06-26 14:55:03 +00:00

[Vision/Konzept] Generic-Host-Agent: Nicht-Proxmox-Hosts (NAS/Standalone) ins System aufnehmen #190