Für Hosting-Provider, MSPs und Reseller, die nach dem VMware-Umbruch und dem Azure Cloud Fokus des SCVMM von Microsoft eine tragfähige Antwort für ihre Kunden suchen.
Einflussfaktor Digitale Souveränität
Ein Markttrend spielt technologieunabhängig eine Rolle im nachfolgenden Kontext. Digitale Souveränität ist 2026 vom politischen Schlagwort zur operativen Anforderung geworden. Für einen relevanten Teil der europäischen Cloud-Branche der Top-Trend des Jahres. Regularien wie NIS2 und der EU Data Act führen dazu, dass Kunden gezielter fragen, wo bestimmte Workloads liegen und wer sie betreibt.
Wichtig ist die richtige Einordnung beider Szenarien. Ob Public oder Private Cloud, entscheidet am Ende jeder Kunde für sich. Beide Wege sind legitim und für unterschiedliche Workloads richtig. Ein Provider, der beides anbietet, bedient das gesamte Spektrum. Daraus resultiert allerdings auch eine Anforderung an die Autonomie des Management-Stacks.
Die Problemstellung: Zwei Erdbeben gleichzeitig
Vor dem Hintergrund stellen wir uns die typische Situation eines Hosting-Providers Anfang 2026 vor. Über Jahre gewachsen ist eine heterogene IaaS Plattform: vSphere für die Enterprise Workloads oder als Standard Hypervisor, Hyper-V mit SCVMM für die Microsoft-Welt oder als Budget Optimierung, dazu erste Proxmox-Cluster als Antwort auf die neue Lizenzrealität. Die Herausforderung für Service Provider besteht darin, nicht oder nicht mehr alle eine Schnittstelle für die Interaktion der Kunden mit ihren IaaS Resourcen anbieten.
Genau in diese ohnehin fragile Struktur schlagen zwei Entwicklungen gleichzeitig ein:
- Der Umbruch bei VMware bzw. Broadcom treibt Provider in eine Multi-Hypervisor-Strategien. Gleichzeitig sind Proxmox und KVM vom Bastel-Setup zur strategischen Alternative geworden. Damit steigt die Zahl der zu bedienenden Backends.
- Microsoft denkt den Provider-Weg nur noch über Azure. Windows Azure Pack und Service Provider Foundation (SPF) sind die Bausteine, mit denen Provider ihren Kunden bislang ein Self-Service-Portal auf die Hyper-V-Private-Cloud anbieten konnten. Leider sind beide Teile abgekündigt. Nicht, weil Microsoft das Thema aufgibt, sondern weil Microsoft die Zukunft konsequent in Verbindung mit der Azure Cloud sieht: Der offizielle SPF-Nachfolger ist Azure Arc-enabled SCVMM. Für den Public-Cloud-Weg ist das schlüssig. Offen bleibt aber der Fall, den viele Service Provider mit eigener Private Cloud bedienen. Gerade den Weg der Unabhängigkeit zu einem der Hyper-Scaler. Genau dafür liefert der Azure-zentrierte Ansatz kein passendes Self-Service-Portal. Damit bleibt der direkte Zugang der Kunden zur private Cloud Infrastruktur des Providers ungelöst.
Das Ergebnis für Entscheider: steigende Komplexität, wegbrechende Werkzeuge und kein Standardprodukt am Markt, das all das zusammenführt.
Die Idee: Die Heterogenität verbannen
Der entscheidende Gedanke ist unspektakulär formuliert und ungeheuer anspruchsvoll umgesetzt: Die Unterschiede der Hypervisor gehören hinter eine einzige, saubere Abstraktionsschicht und nicht mit verschiedenen Portalen auf den Bildschirm des Kunden.
VMSimple ist als API-First-Plattform gedacht. Eine einheitliche REST-API mit sauberer OpenAPI-Spezifikation nach außen; nach innen austauschbare Adapter je Hypervisor. vSphere spricht vSphere API, Hyper-V mit SCVMM spricht PowerShell, Proxmox spricht seine eigene REST-API. Der Kunde und die Web-UI sehen davon nichts. Sie sehen eine VM und die typischen Aktionen wie einen Ein-/Aus-Schalter, Snapshots-Trigger einen Konsolen-Button.
Der API-First-Ansatz hat einen strategischen Nebeneffekt, der oft den Ausschlag gibt. Die mitgelieferte Web-UI ist nur ein Konsument der API. Weil alles über eine dokumentierte REST-API läuft, lässt sich dieselbe Funktionalität nativ in bestehende Systeme einbinden. Das kann z.B. ServiceNow und andere ITSM-Werkzeuge ebenso wie in das bereits vorhandene Kundenportal des Providers sein.
VMSimple legt keine VMs an und rechnet nicht ab. Es ist die Self-Service- und Konsolen-Schicht über der bestehenden Realität. Das hält den Scope scharf und die Integration in bestehende Provider-Prozesse schmerzarm.
Die Lösung: Technische Machbarkeit bewiesen
Das ist der Punkt, an dem aus einer guten Idee ein belastbares Produkt wird. Wir haben die technische Machbarkeit im Proof of Concept vollständig nachgewiesen. Das schließt die Teile ein an denen es üblicherweise scheitert.
Für vSphere, Hyper-V mit SCVMM und Proxmox haben wir den browserbasierten Konsolenzugang über HTML5 bewiesen. Und das für alle Hypervisoren so, dass ein Gateway zwischen den Host-Systemen und dem Endpunkt der HTML5 Webkonsole gibt jede Verbindung autorisieren muss. Diese Gateway akzeptieren nur vom VMSimple API signierte Token und schalten den Zugriff auf die Hypervisoren für einzelne VMs zeitlich begrenzt frei. Durch die HTML5 Konsole für alle Hypervisoren kommt zu keinem Zeitpunkt eine direkte Verbindung zwischen dem Webbrowser des Nutzers und den Hypervisoren zustande.
Konzipiert und im Proof of Concept nachgewiesen wurde VMSimple gemeinsam mit Unicorn Development dem Team für genau die Klasse von Problemen, bei denen Standardsoftware endet und echte Systemtiefe beginnt. Multi-Hypervisor-Abstraktion, signierte Konsolenpfade, Post-SPF-Strategien. Kein Buzzword-Bingo, sondern lauffähiger Code gegen echte Backends.
Aber gibt es das nicht längst?
Die berechtigte Gegenfrage jedes Entscheiders lautet: Warum baut das niemand fertig von der Stange? Wir haben den Markt systematisch durchleuchtet.
Das Ergebnis: Es gibt viele gute Werkzeuge aber jedes löst nur einen Ausschnitt und keines die eigentliche Provider-Aufgabe. Nämlich den bestehenden, gemischten Bestand vereinigen, ohne ihn in einer separaten Datenbank neu aufzubauen, und dabei den sicheren Konsolenpfad mitzuliefern. Die Alternativen zerfallen in drei Lager:
Lager 1 - Provider-Stacks
Die herstellergebundenen Provider-Stacks. VMware beantwortet die Frage mit VMware Cloud Director – dem De-facto-Goldstandard für Provider-Self-Service. Nur: vCloud Director lebt ausschließlich in der vSphere-/NSX-Welt und vertieft damit genau die VMware-Bindung, aus der man nach dem Broadcom-Umbruch gerade herauswill. Microsofts Pendant, Azure Arc-enabled SCVMM / Azure Local, bindet den Kunden an das Azure-Portal und ein Microsoft-Verbrauchsmodell.
Lager 2 - Cloud-Management-Plattformen
Die offenen Cloud-Management-Plattformen. Apache CloudStack, OpenNebula, OpenStack und das kommerzielle HPE Morpheus (ehem. Morpheus Data) sind mächtige IaaS-Orchestratoren. Ihr gemeinsames Prinzip ist aber, die Infrastruktur zu besitzen: Sie provisionieren, verwalten Netz und Storage und wollen Ihren Bestand in ihr Modell re-platformen also ein Migrationsprojekt, keine Vereinigung. Hyper-V ist dabei durchweg das Stiefkind. Bei CloudStack nur experimentell über das neue Extensions-Framework und ungetestet, bei OpenNebula angekündigt statt erstklassig, bei OpenStack praktisch tot. Und keine dieser Plattformen liefert den einen sicheren HTML5 Konsolenpfad.
Lager 3 - Hosting Control-Panels
Die Hosting-Control-Panels. Virtualizor, SolusVM, VirtFusion und OnApp sind für die VPS-Welt gebaut für z.B. KVM, Proxmox, Xen, OpenVZ. Sie kennen weder Enterprise-vSphere über vCenter noch Hyper-V über SCVMM und bringen ihr eigenes Provisioning und Billing mit. Ein anderes Spielfeld.
Gegenüberstellung verschiedener Lösungen
VMSimple ist das einzige Modell, das Ihren bestehenden gemischten Bestand vereinigt, statt ihn zu ersetzen, und dabei genau den sicheren Hyper-V-Konsolenpfad löst, den Microsoft mit dem SPF-Aus hinterlassen hat und diesen sogar in Richtung HTML5 Konsole weiterentwickelt.
Lösung | Multi-Hypervisor inkl. SCVMM | Lösung für den Bestand | Sichere HTML5 Konsole | Provider-eigen, ohne Public Cloud |
|---|---|---|---|---|
Azure Arc-SCVMM / Azure Local | nur Hyper-V | teilweise | ✅ | ❌ |
VMware Cloud Director | ❌ | ❌ | ✅ | ✅ |
Apache CloudStack | teilw. (Hyper-V experimentell) | ❌ (Orchestrator) | ❌ | ✅ |
OpenNebula | teilw. (KVM/vCenter) | ❌ | ✕ | ✅ |
OpenStack | ❌ | ❌ | ❌ | ✅ |
HPE Morpheus | ✅ | teilweise | ❌ | kommerziell, schwergewichtig |
Virtualizor / SolusVM / VirtFusion | ❌ | ❌ | ❌ | ✅ |
VMSimple | ✅ | ✅ | ✅ | ✅ |
Der Mehrwert gegenüber den genannten Alternativen ist damit sehr konkret. Wo CloudStack, OpenNebula oder OpenStack ein Re-Platforming-Projekt mit Monaten Migrationsrisiko bedeuten, ist VMSimple additiv: vCenter, SCVMM und Proxmox bleiben unangetastet, VMSimple legt sich als dünne Schicht darüber. Wo vCloud Director und die Azure-Wege Sie an ein Ökosystem binden, bewahrt VMSimple Ihre Multi-Hypervisor-Freiheit. Sie können Bestände abbauen oder aufbauen, ohne die Portal-Ebene anzufassen. Wo die schwergewichtigen Plattformen einen eigenen Betriebsapparat samt Netz- und Storage-Verwaltung mitbringen, hält VMSimple den Scope schlank und den Betriebsaufwand niedrig.
Warum das ein komplexes Thema ist
Machen wir uns nichts vor, diese Lösung ist kein Wochenendprojekt. Sie verlangt tiefes Verständnis von SCVMM-Interna, dem RD-Gateway-Tunneling, dem vSphere API und einem interoperablen Krypto-Token-Flow über zwei Laufzeitumgebungen hinweg.
Der Proof of Concept ist erbracht, die Fallstricke sind kartiert, die Referenzimplementierung existiert. Für einen Service-Provider bedeutet das: Statt Jahre in eine ungewisse Eigenentwicklung zu investieren, setzen Sie auf eine bereits bewiesene Architektur und differenzieren sich am Markt genau dort, wo Ihre Wettbewerber gerade den Boden unter den Füßen verlieren.
Next Steps - Für Service Provider
Die betreiben eine Private Cloud und suchen nach einer Lösung? Sie benötigen ebenfalls Unterstützung für XenServer oder KVM? Sprechen Sie mit uns. Wir zeigen Ihnen den End-to-End und das live, nicht auf Folien.