Hyper-V-VMs in einem geführten Workflow zu eEVOS migrieren.
Hyper-V-Host verbinden, Windows- und Linux-Workloads erkennen, Ziel-Storage auswählen, Netzwerke zuordnen und virtuelle Laufwerke direkt über die eEVOS-Oberfläche konvertieren.
Von der Quellerkennung bis zur validierbaren Ziel-VM.
Die Oberfläche führt durch alle Entscheidungen. Übertragung und Konvertierung erfolgen durch die eEVOS-Dienste und nicht durch den Browser.
Verbinden
Hyper-V-Host über WinRM und die erforderlichen Windows-Administrationsrechte hinterlegen.
VMs auswählen
Workloads, Zielnamen, Gastprofile und ein verfügbares Datei- oder Ceph-Laufwerk auswählen.
Netzwerke zuordnen
Quell-Switches und Access-VLANs auf eEVOS-Netzwerke oder Virtual Switches abbilden.
Prüfen und importieren
Platzierung und Zuordnungen bestätigen und anschließend Status und Logs pro VM verfolgen.
Mehrere Workloads auswählen und jede VM passend platzieren.
Das Hyper-V-Inventar liefert Status, CPU, Startspeicher, Firmware, Laufwerke, Adapter und verfügbare Gastinformationen. Administratoren wählen das Ziellaufwerk und können das erkannte Gastprofil vor der Konvertierung anpassen.
- Generation 1 wird als BIOS-, Generation 2 als UEFI-VM angelegt.
- Vorhandene Zielnamen werden abgelehnt – eine VM wird niemals überschrieben.
- Die verfügbare Kapazität wird direkt am Ziellaufwerk angezeigt.
- Laufende Quellen können nach ausdrücklicher Zustimmung kontrolliert heruntergefahren werden.
Betriebssystem-Erkennung und Treibervorbereitung gehören zum Import.
Wenn die Gastinformationen erkannt werden, wählt eEVOS das passende Profil. Für unterstützte Gastsysteme installiert der Import automatisch die benötigten paravirtualisierten Treiber, damit virtuelle Storage- und Netzwerkgeräte effizient genutzt werden können.
Vor der Umschaltung sollten Bootverhalten, Laufwerke, Netzwerkadapter und Anwendungsdienste trotzdem geprüft werden.
Gastbetriebssystem
Erkannte Hyper-V-Metadaten werden zur Auswahl des passenden eEVOS-Gastprofils verwendet.
Paravirtualisierte Treiber
Die benötigten Treiber werden für unterstützte Gäste automatisch installiert – wie beim vSphere-Import.
Switches und VLANs vor dem Import eindeutig zuordnen.
Der Assistent gruppiert Adapter nach Quell-Switch und Access-VLAN und zeigt die betroffenen VMs. Jede Kombination wird einem eEVOS-Netzwerk oder Virtual Switch und bei Bedarf einem vorhandenen Netzwerkprofil zugeordnet.
- Mehrere NICs und zugeordnete MAC-Adressen bleiben erhalten.
- Adapter können für einen isolierten ersten Start bewusst weggelassen werden.
- Die VLAN-Richtlinie des Zielsystems bleibt explizit und überprüfbar.
Direkt in das gewählte eEVOS-Storage-Modell konvertieren.
Auf eEVOS ist keine zusätzliche vollständige VHDX-Zwischenkopie erforderlich. Die Laufwerksdaten werden verschlüsselt und schreibgeschützt über SMB gelesen und in das ausgewählte Ziel konvertiert.
qcow2-Ziel
Unterstützte VHD- und VHDX-Inhalte werden als VM-Laufwerksdateien auf dem gewählten Laufwerk gespeichert.
Natives RBD-Ziel
Der Konvertierungsdienst schreibt direkt in native Ceph-RBD-Images für verteilte eEVOS-Installationen.
Aktuellen Stand zusammenführen
Differencing-Ketten werden auf dem Hyper-V-Host zusammengeführt. Der aktuelle Datenstand wird importiert, nicht die Checkpoint-Historie.
Den vollständigen Plan vor dem Start der Konvertierung prüfen.
Quell- und Zielnamen, Storage-Platzierung und Netzwerkzuordnungen sind vor dem Import sichtbar. Eine laufende Quelle wird nur nach ausdrücklicher Zustimmung kontrolliert heruntergefahren. Ein erzwungenes Ausschalten findet nicht statt.
Quell-VM, Konfiguration und Original-Laufwerke bleiben erhalten. Die importierte VM wird registriert, bleibt aber bis zur Validierung ausgeschaltet.
Die Änderung der Sicherheitsidentität transparent behandeln.
Eine normale Generation-2-VM mit virtuellem TPM kann mit einem neuen persistenten TPM 2.0 auf dem Ziel importiert werden. Der geschützte TPM-Zustand der Quelle wird nicht übertragen.
Geschützte Verwaltung und Übertragung
WinRM dient zur Erkennung und Administration. Laufwerksdaten werden verschlüsselt und schreibgeschützt über SMB gelesen. Gespeicherte Passwörter sind verschlüsselt; ein Agent im Gast ist nicht erforderlich.
TPM-bewusster Workflow
Der Administrator muss ausdrücklich bestätigen, dass das Ziel eine neue TPM-Identität erhält. Shielded VMs werden weiterhin nicht unterstützt.
Was der Workflow übernimmt – und was eine Migrationsentscheidung bleibt.
| Bereich | Aktueller Workflow | Aufgabe des Administrators |
|---|---|---|
| Verfügbarkeit beim Import | Offline-Konvertierung; optionales kontrolliertes Herunterfahren einer laufenden Quelle. | Wartungsfenster, Anwendungs-Shutdown und Umschaltung planen. |
| Quellumfang | Verbindung zu einem einzelnen Hyper-V-Host. | Den Host verwenden, der die VM und ihre Laufwerke besitzt; keine automatische SCVMM- oder Cluster-Owner-Erkennung. |
| Virtuelle Hardware | Übernahme von CPU, Startspeicher, unterstützten Laufwerken, Firmware-Modus und zugeordneten Adaptern. | Dynamic-Memory-Richtlinie, nicht unterstützte Geräte, Secure Boot und Anwendungsanforderungen prüfen. |
| Sicherheit | Erzeugt bei ausdrücklicher Zustimmung ein neues Ziel-TPM. | Verschlüsselungs-Recovery vorbereiten; Shielded VMs und geschützter TPM-State-Transfer werden nicht unterstützt. |
| Abschluss | Erzeugt ein ausgeschaltetes Ziel und behält die Quelle bei. | Boot, Treiber, Netzwerke, Daten und Anwendungen prüfen und anschließend ein neues Ziel-Backup erstellen. |
Eine kontrollierte Hyper-V-Migration planen.
Quell-Hosts, VM-Generationen, Storage-Platzierung, Netzwerkzuordnungen, Recovery-Anforderungen und Umschaltreihenfolge gemeinsam mit euroNAS prüfen.