Zum Inhalt springen
Zur Projektübersicht

Betrieb

Nach abgeschlossenen Hyper-V-Projekten bei Kunden im Einsatz und aktiv weiterentwickelt.

Hyper-VGroupManager

Portable Windows-Anwendung zur Verwaltung nativer Hyper-V-VM-Gruppen auf einzelnen Hosts und Failover-Clustern. Änderungen an Gruppen und Mitgliedschaften lassen sich zunächst planen, validieren und als erwarteter Zustand prüfen, bevor sie auf Hyper-V angewendet werden.

Rolle
Konzept · Architektur · Entwicklung
Disziplinen
Software Engineering · Infrastructure Engineering
Technologien
.NET 10 · C# · WPF · MVVM · PowerShell · Hyper-V · xUnit

01

Gruppen statt statischer VM-Auswahl

Hyper-V besitzt native VM-Gruppen (VMCollectionType), bietet dafür aber keine mit vSphere Tags oder Nutanix Categories vergleichbare Verwaltungsoberfläche – im administrativen Alltag bleiben sie vor allem über PowerShell zugänglich. Der Hyper-VGroupManager entstand als portable Oberfläche, um solche Gruppen strukturiert und nachvollziehbar zu verwalten.

Eine VM kann mehreren Gruppen gleichzeitig angehören. Änderungen an einer Gruppe überschreiben deshalb nicht automatisch andere bestehende Zuordnungen – ein Verhalten, das an die Bedienung von vSphere Tags oder Nutanix Categories erinnert, ohne diese Systeme technisch nachzubilden.

Ein wichtiger Anwendungsfall ist die Nutzung dieser Gruppen als stabile VM-Auswahlobjekte für Veeam Backup & Replication. Der Hyper-VGroupManager verändert dabei weder Veeam-Jobs noch andere Veeam-Konfigurationen – er verwaltet ausschließlich die zugrunde liegenden nativen Hyper-V-Gruppen.

02

Getrennt nach Oberfläche, Fachlogik und Backend

Die Anwendung ist bewusst in drei Bereiche getrennt. Zustandsmodell, Validierung und Change-Logik liegen unabhängig von WPF und PowerShell im Core; das PowerShell-Backend kommuniziert über einen klar definierten JSON-Vertrag mit der Anwendung.

  1. HyperVGroupManager.App

    WPF-Anwendung mit Views, ViewModels und Services nach dem MVVM-Muster (CommunityToolkit.Mvvm). Die ViewModels sprechen ausschließlich gegen Interfaces aus dem Core – nie direkt mit PowerShell.

    • Views und ViewModels
    • MVVM mit CommunityToolkit.Mvvm
    • Implementiert IHyperVGroupService und IPowerShellExecutor aus dem Core
  2. HyperVGroupManager.Core

    Models, Interfaces, Validatoren, Change Queue und Effective-State-Berechnung – ohne Abhängigkeit von WPF oder PowerShell.

    • Domain-Logik und Validatoren
    • Change Queue und Effective-State-Builder
    • Vollständig ohne UI- oder PowerShell-Bezug testbar
  3. HyperVGroupManager.PowerShell

    Eigenständiges PowerShell-Modul für Hyper-V und Failover Cluster unter Windows PowerShell 5.1, ohne Abhängigkeit zu C#.

    • Hyper-V- und Failover-Cluster-Zugriff
    • Kommunikation ausschließlich über JSON auf stdout
    • Könnte grundsätzlich ausgetauscht werden, ohne UI oder ViewModels anzufassen

Weil die Oberfläche nur gegen Interfaces aus dem Core arbeitet, ließe sich das PowerShell-Backend grundsätzlich austauschen, ohne die UI- und ViewModel-Logik umzubauen.

03

Erst planen. Dann anwenden.

Änderungen werden nicht sofort ausgeführt. Sie landen zunächst in einer Change Queue; die Anwendung berechnet daraus – aus aktuellem Hyper-V-Zustand plus geplanten Änderungen – bereits vor der Ausführung den erwarteten Zustand.

  1. 01

    Planen

    Gruppen erstellen, umbenennen oder löschen sowie VMs zu Gruppen hinzufügen oder aus ihnen entfernen – alles zunächst nur in der Change Queue. Eine neu geplante Gruppe kann innerhalb desselben Change-Sets bereits VMs zugeordnet bekommen.

  2. 02

    Prüfen

    Gruppen, Mitgliedschaften, Mitgliederzahlen, VM-Filter und Export zeigen bereits den erwarteten Zustand. Eine Preflight-Validierung prüft den vollständigen Lauf, bevor irgendetwas auf Hyper-V geschrieben wird.

  3. 03

    Anwenden

    Nach der Validierung wendet die Anwendung die Änderungen in sinnvoller Reihenfolge an (Gruppen erstellen, umbenennen, Mitglieder hinzufügen, entfernen, Gruppen löschen) und korreliert jede Backend-Antwort mit der gesendeten Änderung.

Redundante oder gegensätzliche Änderungen werden sinnvoll behandelt: Add und Remove derselben Mitgliedschaft heben sich auf, Create und Delete einer noch nicht angewendeten Gruppe ebenso, und mehrfaches Umbenennen wird auf den zuletzt geplanten Namen reduziert. Die Anwendung ist damit kein dünner PowerShell-Wrapper, sondern besitzt ein eigenes Zustands- und Änderungsmodell.

04

Sicherheitsgrenzen

Weil die Anwendung schreibend auf Produktionsumgebungen zugreift, sind ihre Grenzen bewusst eng gezogen.

  • 01Ausschließlich native VMCollectionType-Gruppen – keine Veeam-API, keine Änderungen an Veeam-Jobs
  • 02Kein Invoke-Expression und keine dynamisch zusammengesetzten PowerShell-Befehle
  • 03Parameterübergabe ausschließlich über JSON-Dateien, nie über Kommandozeilenargumente
  • 04Allowlist zulässiger Backend-Kommandos im PowerShell-Bootstrap
  • 05Validierung des vollständigen Änderungssatzes vor jedem Schreibvorgang, sowohl in C# als auch im PowerShell-Backend
  • 06Jede Backend-Antwort wird mit der gesendeten Änderung korreliert
  • 07Offene Änderungen sind an das aktuell verbundene Ziel gebunden; ein Wechsel auf einen anderen Host oder Cluster wird blockiert

Kann die Anwendung nach einer fehlgeschlagenen Operation – etwa nach Timeout, Transportfehler oder Prozessabbruch – den tatsächlichen Zustand des Zielsystems nicht sicher bestimmen, werden weitere Schreibvorgänge blockiert. Erst ein erfolgreicher Refresh hebt diese Sperre wieder auf.

05

Funktionsumfang

Der Funktionsumfang gliedert sich in Verwaltung, Change Control und Betrieb.

  1. Verwaltung

    Hyper-V-Hosts und Failover-Cluster verbinden, VMCollectionType-Gruppen erstellen, umbenennen und löschen, Mitgliedschaften pflegen.

    • Einzelne Hosts und Failover-Cluster
    • Mehrfachmitgliedschaften je VM
    • Gruppen erstellen, umbenennen, löschen
  2. Change Control

    Alle Änderungen laufen über die Change Queue mit Effective-State-Vorschau, Preflight-Validierung und kontrolliertem Apply-Prozess.

    • Change Queue mit Effective-State-Vorschau
    • Preflight-Validierung vor jedem Schreibvorgang
    • Safety Lock bei unklarem Zustand
  3. Betrieb

    Suche und Filter, Mehrfachauswahl, JSON-Export sowie ein zeitgesteuerter E-Mail-Bericht für VMs ohne Gruppe ergänzen den täglichen Einsatz.

    • Suche, VM-Filter und Mehrfachauswahl
    • JSON-Konfigurationsexport
    • Zeitgesteuerte E-Mail-Berichte, SMTP-Zugangsdaten per Windows DPAPI geschützt
    • Integrierte Hilfe über F1, Deutsch/Englisch zur Laufzeit

06

Desktop-App statt Admin-Skript

Die aktuelle Oberfläche basiert auf WPF mit Fluent-Design und folgt System-, Hell- oder Dunkelmodus samt Windows-Akzentfarben; der Modus lässt sich zur Laufzeit umschalten. Verbindungsstatus, kontextabhängige Aktionen und Empty States begleiten die Bedienung, geplante Änderungen werden direkt an VMs und Gruppen als Badges für Hinzufügen, Entfernen und Umbenennen sichtbar.

Die Anwendung unterstützt Deutsch und Englisch, umschaltbar zur Laufzeit ohne Neustart; die Auswahl wird benutzerspezifisch gespeichert. Eine integrierte Dokumentation ist über Hilfe oder F1 erreichbar und deckt Schnellstart, Sicherheitskonzept, E-Mail-Berichte und Fehlersuche ab.

Die Anwendung ist als portable, self-contained Windows-Anwendung ausgelegt. Die .NET-Runtime kann mitgeliefert werden; für die eigentliche Hyper-V-Verwaltung werden weiterhin die Windows Hyper-V PowerShell Tools benötigt.

07

Testbarkeit und aktueller Stand

Die zentrale Fachlogik lässt sich ohne Hyper-V-System automatisiert testen. xUnit-Tests decken unter anderem Change Queue, Validierung, Effective-State-Berechnung, ViewModels und den JSON-Vertrag ab; echte Hyper-V-Operationen bleiben bewusst Teil manueller Smoke-Tests auf einem Host bzw. Cluster.

Das Projekt wird aktiv weiterentwickelt. Der aktuelle Schwerpunkt liegt auf der Validierung in unterschiedlichen Host- und Clusterumgebungen, dem Release-Prozess und der weiteren Härtung der administrativen Workflows.