Azure Migrate Migration ohne Agents von virtuellen VMware-Computern

Dieser Artikel beschreibt die Replikationskonzepte bei der Migration von VMware-VMs mit der agentlosen Migrationsmethode des Migrations- und Modernisierungstools.

Replikationsprozess

Die Replikationsoption ohne Agent funktioniert mithilfe von VMware-Momentaufnahmen und der VMware CBT-Technologie (VMware Changed Block Tracking), um Daten von Datenträgern virtueller Computer zu replizieren. Das folgende Blockdiagramm zeigt die verschiedenen Schritte, die beim Migrieren Ihrer VMs mit dem Migrations- und Modernisierungstool erforderlich sind.

Wenn Replikation für einen virtuellen Computer konfiguriert ist, wird zuerst eine anfängliche Replikationsphase durchlaufen. Während der ersten Replikation wird eine VM-Momentaufnahme erstellt, und eine vollständige Kopie der Daten von den Momentaufnahmedatenträgern wird auf verwaltete Datenträger in Ihrem Zielabonnement repliziert.

Nach Abschluss der ersten Replikation für die VM geht der Replikationsprozess in eine inkrementelle Replikationsphase (Deltareplikation) über. In der inkrementellen Replikationsphase werden Datenänderungen, die seit Beginn des letzten abgeschlossenen Replikationszyklus eingetreten sind, repliziert und auf die verwalteten Datenträger des Replikats geschrieben, wodurch die Replikation mit den Änderungen auf der VM synchron gehalten wird.

Änderungen zwischen Replikationszyklen werden mithilfe der VMware CBT-Technologie für geänderte Blöcke nachverfolgt. Zu Beginn des Replikationszyklus wird eine VM-Momentaufnahme erstellt, und die Nachverfolgung geänderter Blöcke wird verwendet, um die Änderungen zwischen der aktuellen Momentaufnahme und der zuletzt erfolgreich replizierten Momentaufnahme abzurufen. Es werden nur Daten repliziert, die seit dem vorherigen abgeschlossenen Replikationszyklen geändert wurden, um die Replikation für die VM synchron zu halten. Am Ende jedes Replikationszyklus wird die Momentaufnahme freigegeben und eine Momentaufnahmekonsolidierung für den virtuellen Computer ausgeführt.

Wenn Sie den Migrationsvorgang auf einem replizierenden virtuellen Computer ausführen, gibt es einen bedarfsorientierten Deltareplikationszyklus, der die verbleibenden Änderungen seit dem letzten Replikationszyklus repliziert. Nach Ende des bedarfsorientierten Zyklus werden die dem virtuellen Computer entsprechenden verwalteten Datenträger des Replikats verwendet, um den virtuellen Computer in Azure zu erstellen. Unmittelbar vor dem Auslösen der Migration/Failover müssen Sie den lokalen virtuellen Computer herunterfahren. Durch das Herunterfahren des virtuellen Computers wird sichergestellt, dass während der Migration kein Datenverlust entsteht.

Nachdem die Migration erfolgreich war und der virtuelle Computer in Azure gestartet wird, stellen Sie sicher, dass Sie die Replikation des virtuellen Computers beenden. Wenn Sie die Replikation beenden, werden die zwischengeschalteten Datenträger (Seed-Datenträger) gelöscht, die während der Datenreplikation erstellt wurden. Außerdem vermeiden Sie zusätzliche Gebühren für Speichertransaktionen auf diesen Datenträgern.

Replikationszyklen

Hinweis

Suchen Sie nach Momentaufnahmen von früheren Replikationsversuchen oder von anderen Drittanbieter-Apps. Die Änderungsnachverfolgung kann auf dem virtuellen Computer nicht aktiviert werden, wenn für diesen bereits Momentaufnahmen vorhanden sind. Löschen Sie die vorhandenen Momentaufnahmen, oder aktivieren Sie die Nachverfolgung geänderter Blöcke auf dem virtuellen Computer.

Replikationszyklen beziehen sich auf den regelmäßigen Prozess der Übertragung von Daten aus der lokalen Umgebung auf verwaltete Azure-Datenträger. Ein vollständiger Replikationszyklus besteht aus den folgenden Schritten:

1. Erstellen einer VMware-Momentaufnahme für jeden Datenträger, der dem virtuellen Computer zugeordnet ist
2. Hochladen von Daten in das Protokollspeicherkonto in Azure
3. Releasemomentaufnahme
4. Konsolidieren von VMware-Datenträgern

Ein Zyklus wird als abgeschlossen bezeichnet, nachdem die Datenträger konsolidiert wurden.

Komponenten, die an der Replikation beteiligt sind

Lokale Komponenten: Die Azure Migrate Appliance verfügt über die folgenden Komponenten, die für die Replikation verantwortlich sind

• DRA-Agent
• Gateway-Agent

Azure-Komponenten: In der folgenden Tabelle sind die verschiedenen Azure Artifacts zusammengefasst, die mithilfe der VMware-VM-Migrationsmethode ohne Agent erstellt werden.

Komponente	Region	Abonnement	Beschreibung
Recovery Services-Tresor	Azure Migrate-Projektregion	Azure Migrate-Projektabonnement	Wird zum Orchestrieren der Datenreplikation verwendet
Service Bus	Zielregion	Azure Migrate-Projektabonnement	Wird für die Kommunikation zwischen Clouddienst und Azure Migrate Appliance verwendet
Protokollspeicherkonto	Zielregion	Azure Migrate-Projektabonnement	Wird zum Speichern von Replikationsdaten verwendet, die vom Dienst gelesen und auf den verwalteten Datenträger des Kunden angewendet werden
Gatewayspeicherkonto	Zielregion	Azure Migrate-Projektabonnement	Wird zum Speichern von Computerzuständen während der Replikation verwendet
Key vault	Zielregion	Azure Migrate-Projektabonnement	Verwaltet Verbindungszeichenfolgen für Service Bus und Zugriffsschlüssel für das Protokollspeicherkonto
Virtuelle Azure-Computer	Zielregion	Zielabonnement	VM, die bei der Migration in Azure erstellt wurde
Azure Managed Disks	Zielregion	Zielabonnement	Verwaltete Datenträger, die an Azure-VMs angefügt sind
Netzwerkschnittstellenkarten	Zielregion	Zielabonnement	Die NICs, die an die in Azure erstellten VMs angefügt sind

Erforderliche Berechtigungen

Wenn Sie die Replikation zum ersten Mal starten, müssen dem angemeldeten Benutzer die folgenden Rollen zugewiesen werden:

• Besitzer oder Mitwirkender und Benutzerzugriffsadministrator für die Ressourcengruppe und Zielressourcengruppe des Azure Migrate Projekts

Für die nachfolgenden Replikationen müssen dem angemeldeten Benutzer die folgenden Rollen zugewiesen werden:

• Besitzer oder Mitwirkender für die Ressourcengruppe und Zielressourcengruppe des Azure Migrate Projekts

Zusätzlich zu den oben beschriebenen Rollen benötigt der angemeldete Benutzer die folgende Berechtigung auf Abonnementebene: Microsoft.Resources/subscriptions/resourceGroups/read

Datenintegrität

Es gibt zwei Phasen in jedem Replikationszyklus, die die Datenintegrität zwischen dem lokalen Datenträger (Quelldatenträger) und dem Replikatdatenträger in Azure (Zieldatenträger) sicherstellen.

1. Zunächst überprüfen wir, ob jeder Sektor, der sich auf dem Quelldatenträger geändert hat, auf den Zieldatenträger repliziert wird. Die Validierung wird mithilfe von Bitmaps ausgeführt. Der Quelldatenträger ist in Sektoren mit 512 Bytes unterteilt. Jeder Sektor auf dem Quelldatenträger wird einem Bit in der Bitmap zugeordnet. Wenn die Datenreplikation startet, wird die Bitmap für alle geänderten Blöcke (im Deltazyklus) auf dem Quelldatenträger erstellt, die repliziert werden müssen. Entsprechend wird beim Übertragen der Daten auf den Azure-Zieldatenträger eine Bitmap erstellt. Nachdem die Datenübertragung erfolgreich abgeschlossen wurde, vergleicht der Clouddienst die beiden Bitmaps, um sicherzustellen, dass kein geänderter Block ausgelassen wurde. Falls zwischen den Bitmaps ein Konflikt besteht, wird der Zyklus als fehlgeschlagen betrachtet. Da jeder Zyklus neu synchronisiert wird, wird der Konflikt im nächsten Zyklus behoben.

2. Als Nächstes stellen wir sicher, dass die Daten, die auf die Azure-Datenträger übertragen werden, mit den Daten übereinstimmen, die von den Quelldatenträgern repliziert wurden. Jeder geänderte Block, der hochgeladen wird, wird komprimiert und verschlüsselt, bevor er als Blob in das Protokollspeicherkonto geschrieben wird. Wir berechnen die Prüfsumme dieses Blocks vor der Komprimierung. Diese Prüfsumme wird zusammen mit den komprimierten Daten als Metadaten gespeichert. Bei der Dekomprimierung wird die Prüfsumme für die Daten berechnet und mit der Prüfsumme verglichen, die in der Quellumgebung berechnet wird. Wenn ein Konflikt vorliegt, werden die Daten nicht auf die Azure-Datenträger geschrieben, und der Zyklus wird als fehlgeschlagen betrachtet. Da jeder Zyklus neu synchronisiert wird, wird der Konflikt im nächsten Zyklus behoben.

Sicherheit

Die Azure Migrate-Appliance komprimiert Daten und verschlüsselt sie vor dem Hochladen. Daten werden über einen sicheren Kommunikationskanal über HTTPS übertragen und verwenden TLS 1.2 oder höher. Zudem werden Ihre Daten von Azure Storage beim Speichern in der Cloud automatisch verschlüsselt (Verschlüsselung ruhender Daten).

Replikationsstatus

Wenn für eine VM Replikation (Datenkopie) durchgeführt wird, gibt es mehrere mögliche Zustände:

• Erste Replikation (in Warteschlange): Die VM wird für die Replikation (oder Migration) in die Warteschlange gestellt, wenn andere VMs die lokalen Ressourcen (während der Replikation oder Migration) nutzen. Sobald die Ressourcen frei sind, wird dieser virtuelle Computer verarbeitet.
• Erste Replikation wird ausgeführt: Die VM wird für die erste Replikation geplant.
• Erste Replikation: Für die VM wird eine erste Replikation ausgeführt. Wenn die erste Replikation für den virtuellen Computer ausgeführt wird, können Sie nicht mit der Testmigration bzw. der Migration fortfahren. Sie können die Replikation nur in dieser Phase beenden.
• Erste Replikation (x %): Die erste Replikation ist aktiv, der Fortschritt beträgt x %.
• Deltasynchronisierung: Die VM durchläuft möglicherweise einen Deltareplikationszyklus, der die verbleibenden Daten seit dem letzten Replikationszyklus repliziert.
• Anhalten in Bearbeitung: Die VM durchläuft einen aktiven Deltareplikationszyklus und wird in einiger Zeit angehalten.
• Angehalten: Die Replikationszyklen wurden angehalten. Die Replikationszyklen können fortgesetzt werden, indem ein Fortsetzungsreplikationsvorgang ausgeführt wird.
• Fortsetzen in der Warteschlange: Die VM wird für das Fortsetzen der Replikation in die Warteschlange eingereiht, da andere VMs derzeit die lokalen Ressourcen nutzen.
• Fortsetzen in Bearbeitung (x %): Der Replikationszyklus wird für die VM fortgesetzt, der Fortschritt beträgt x %.
• Beenden der Replikation in Bearbeitung: Replikationsbereinigung wird ausgeführt. Wenn Sie die Replikation beenden, werden die verwalteten Zwischendatenträger (Seed-Datenträger), die während der Replikation erstellt wurden, gelöscht. Weitere Informationen
• Abschließen der Migration in Bearbeitung: Migrationsbereinigung wird ausgeführt. Wenn Sie die Migration abschließen, werden die verwalteten Zwischendatenträger (Seed-Datenträger) gelöscht, die während der Replikation erstellt wurden. Weitere Informationen
• –: Wenn die VM erfolgreich migriert wurde und/oder wenn Sie die Replikation beendet haben, ändert sich der Status in „-“. Sobald Sie die Replikation beenden bzw. die Migration abschließe und der Vorgang erfolgreich abgeschlossen wurde, wird die VM aus der Liste der replizierenden Computer entfernt. Sie finden die VM auf der Registerkarte „VMs“ im Replikations-Assistenten.

Alle anderen Status

• Fehler bei der ersten Replikation: Die anfänglichen Daten konnten nicht für die VM kopiert werden. Folgen Sie den Anleitungen zur Behebung des Problems.
• Reparatur ausstehend: Es gab ein Problem im Replikationszyklus. Sie können den Link auswählen, um mögliche Ursachen und Aktionen zu verstehen, die zur Behebung verwendet werden können (sofern zutreffend). Wenn Sie sich für die Option Replikation automatisch reparieren entschieden haben, indem Sie Ja ausgewählt haben, als Sie die Replikation der VM initiiert haben, startet das Tool einen Reparaturversuch. Wählen Sie andernfalls die VM aus, und wählen Sie dannReplikation reparieren aus. Wenn Sie die Option Replikation automatisch reparieren nicht ausgewählt haben oder der oben angegebene Schritt nicht funktioniert hat, beenden Sie die Replikation für die VM, setzen Changed Block Tracking für die VM zurück und konfigurieren die Replikation dann neu.
• Replikation reparieren (in Warteschlange): Die VM wird für die Reparatur der Replikation in die Warteschlange eingereiht, da andere VMs derzeit die lokalen Ressourcen nutzen. Sobald die Ressourcen frei sind, wird die für die Reparatur der Replikation verarbeitet.
• Erneut synchronisieren ( x%): Für die VM erfolgt erneute Synchronisierung der Daten. Dies kann passieren, wenn während der Datenreplikation ein Problem bzw. ein Konflikt aufgetreten ist.
• Fehler beim Beenden der Replikation/Abschließen der Migration: Wählen Sie den Link aus, um die möglichen Ursachen für Fehler und Aktionen zur Behebung (wenn zutreffend) zu verstehen.

Hinweis

Einige VMs befinden sich in der Warteschlange, um minimale Auswirkungen auf die Quellumgebung aufgrund des IOPS-Speicherverbrauchs sicherzustellen. Diese VMs werden basierend auf der Planungslogik verarbeitet (siehe nächster Abschnitt).

Status der Migration/Testmigration

• Testmigration ausstehend: Die VM befindet sich in der Deltareplikationsphase, und Sie können jetzt eine Testmigration (oder Migration) durchführen.
• Bereinigung der Testmigration ausstehend: Führen Sie nach Abschluss der Testmigration eine Bereinigung aus, um Gebühren in Azure zu vermeiden.
• Bereit zum Migrieren: Die VM ist bereit, zu Azure migriert zu werden.
• Migration in Bearbeitung (in Warteschlange): Die VM wird für die Migration in die Warteschlange eingereiht, da andere VMs die lokalen Ressourcen während der Replikation (oder Migration) nutzen. Sobald die Ressourcen frei sind, wird diese VM verarbeitet.
• Migration/Testmigration in Bearbeitung: Die VM wird einer Testmigration/Migration unterzogen. Sie können den Link auswählen, um den laufenden Migrationsauftrag zu überprüfen.
• Datum, Zeitstempel: Das Datum und der Zeitstempel der Migration/Testmigration.
• –: Die erste Replikation ist in Bearbeitung. Sie können eine Migration oder Testmigration durchführen, nachdem der Replikationsprozess in eine Deltasynchronisierungsphase (inkrementelle Replikation) wechselt.

Alle anderen Status

• Abgeschlossen mit Informationen: Der Migrations-/Testmigrationsauftrag wurde mit Informationen abgeschlossen. Sie können den Link auswählen, um den letzten Migrationsauftrag auf mögliche Ursachen und Aktionen zu überprüfen, die zur Reparatur ausgeführt werden sollen (sofern zutreffend).
• Fehler: Fehler beim Migrations-/Testmigrationsauftrag. Sie können den Link auswählen, um den letzten Migrationsauftrag auf mögliche Ursachen und Aktionen zu überprüfen, die zur Reparatur ausgeführt werden sollen.

Planungslogik

Die erste Replikation wird geplant, wenn die Replikation für einen virtuellen Computer konfiguriert wird. Darauf folgen inkrementelle Replikationen (Deltareplikation).

Deltareplikationszyklen werden wie folgt geplant:

• Der erste Deltareplikationszyklus wird unmittelbar nach Abschluss des ersten Replikationszyklus geplant.
• Die nächsten Deltareplikationszyklen werden gemäß der folgenden Logik geplant: min. [max. [1 Stunde, (Zeit des vorherigen Deltareplikationszyklus / 2)], 12 Stunden]

Das heißt, die nächste Deltareplikation wird für nicht vor einer Stunde und nicht später als 12 Stunden geplant. Beispiel: Wenn ein Deltareplikationszyklus für eine VM vier Stunden dauert, wird der nächste Deltareplikationszyklus in zwei Stunden geplant, nicht in der nächsten Stunde.

Hinweis

Die Planungslogik ist nach Abschluss der ersten Replikation anders. Der erste Deltazyklus wird unmittelbar nach Abschluss der ersten Replikation geplant, und die nachfolgenden Zyklen folgen der oben beschriebenen Planungslogik.

• Wenn Sie die Migration auslösen, wird für den virtuellen Computer vor der Migration ein bedarfsbasierter Deltareplikationszyklus (Deltareplikationszyklus vor dem Failover) ausgeführt.

Priorisieren von VMs für verschiedene Phasen der Replikation

• Laufende VM-Replikationen werden gegenüber geplanten Replikationen (neue Replikationen) priorisiert.
• Der Zyklus vor dem Failover (bedarfsbasierte Deltareplikation) hat die höchste Priorität, gefolgt vom ersten Replikationszyklus. Der Deltareplikationszyklus hat die geringste Priorität.

Das heißt, wenn ein Migrationsvorgang ausgelöst wird, wird der bedarfsbasierte Replikationszyklus für den virtuellen Computer geplant und andere laufende Replikationen stehen wieder hintenan, wenn sie um Ressourcen konkurrieren.

Einschränkungen:

Wir verwenden die folgenden Einschränkungen, um sicherzustellen, dass wir die IOPS-Grenzwerte für die SANs nicht überschreiten.

• Jede Azure Migrate Appliance unterstützt die parallele Replikation von 52 Datenträgern.
• Jeder ESXi-Host unterstützt acht Datenträger. Jeder ESXi-Host verfügt über einen NFC-Puffer von 32 MB. Daher können wir acht Datenträger auf dem Host planen (jeder Datenträger benötigt 4 MB Puffer für IR, DR).
• Jeder Datenspeicher kann maximal 15 Datenträgermomentaufnahmen enthalten. Die einzige Ausnahme ist, wenn einem virtuellen Computer mehr als 15 Datenträger angefügt sind.

Replikation für horizontale Skalierung

Azure Migrate unterstützt die gleichzeitige Replikation von 500 virtuellen Computern. Wenn Sie planen, mehr als 300 virtuelle Computer zu replizieren, müssen Sie eine Appliance für die horizontale Skalierung bereitstellen. Die Appliance für die horizontale Skalierung ähnelt einer primären Azure Migrate Appliance, besteht aber nur aus einem Gateway-Agent, um die Datenübertragung zu Azure zu vereinfachen. Das folgende Diagramm zeigt die empfohlene Methode zur Verwendung der Appliance für die horizontale Skalierung.

Nachdem Sie die primäre Appliance konfiguriert haben, können Sie die Appliance für die horizontale Skalierung jederzeit bereitstellen, aber dies ist nicht erforderlich, bis 300 VMs gleichzeitig repliziert werden. Wenn 300 VMs gleichzeitig repliziert werden, müssen Sie die Appliance für die horizontale Skalierung bereitstellen, um fortzufahren.

Replikation beenden/Migration abschließen

Wenn Sie die Replikation beenden, werden die verwalteten Zwischendatenträger (Seed-Datenträger), die während der Replikation erstellt wurden, gelöscht. Sie können die Replikation nur während einer aktiven Replikation beenden. Sie können Migration abschließen auswählen, um die Replikation zu beenden, nachdem die VM migriert wurde.

Die VM, für die die Replikation beendet wird, kann repliziert werden, indem die Replikation erneut aktiviert wird. Wenn die VM migriert wurde, können Sie die Replikation und Migration erneut fortsetzen.

Als bewährte Methode sollten Sie die Migration immer abschließen, nachdem die VM erfolgreich zu Azure migriert wurde, um sicherzustellen, dass keine zusätzlichen Gebühren für Speichertransaktionen auf den verwalteten Zwischendatenträgern (Seed-Datenträger) entstehen. In einigen Fällen werden Sie feststellen, dass das Beenden der Replikation einige Zeit dauert. Dies liegt daran, dass der fortlaufende Replikationszyklus bei jedem Beenden der Replikation abgeschlossen wird (nur wenn sich der virtuelle Computer in der Deltasynchronisierung befindet), bevor die Artefakte gelöscht werden.

Auswirkung des Churn

Wir versuchen, die Menge der Datenübertragungen in jedem Replikationszyklus zu minimieren, indem wir zulassen, dass sich die Daten so weit wie möglich falten, bevor wir den nächsten Zyklus planen. Da bei der Replikation ohne Agent Daten zusammengelegt werden, ist das Änderungsmuster wichtiger als die Änderungsrate. Wenn eine Datei immer wieder geschrieben wird, hat die Rate keine große Auswirkung. Dagegen verursacht ein Muster, bei dem in jeden zweiten Sektor geschrieben wird, im nächsten Zyklus viele Änderungen.

Verwaltung der Replikation

Drosselung

Sie können die Replikationsbandbreite mithilfe von NetQosPolicy erhöhen oder verringern. Das in NetQosPolicy zu verwendende AppNamePrefix-Element ist „GatewayWindowsService.exe“.

Sie können eine Richtlinie auf der Azure Migrate-Appliance erstellen, um den Replikationsdatenverkehr von der Appliance zu drosseln, indem Sie eine Richtlinie wie die folgende erstellen:

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Hinweis

Dies gilt für alle replizierenden VMs von der Azure Migrate Appliance gleichzeitig.

Sie können die Replikationsbandbreite auch nach einem Zeitplan erhöhen und verringern, indem Sie das Beispielskript verwenden.

Blackout-Fenster

Azure Migrate bietet einen konfigurationsbasierten Mechanismus, über den Kunden das Zeitintervall angeben können, in dem keine Replikationen fortgesetzt werden sollen. Dieses Zeitintervall wird als Blackout-Fenster bezeichnet. Ein Blackout-Fenster kann in mehreren Szenarien notwendig sein, z. B. wenn die Quellumgebung ressourcenbeschränkt ist oder wenn Kunden möchten, dass die Replikation nur außerhalb der Geschäftszeiten erfolgt usw.

Hinweis

• Die vorhandenen Replikationszyklen am Anfang des Blackout-Fensters werden abgeschlossen, bevor die Replikation angehalten wird.
• Bei jeder während des Blackout-Fensters initiierten Migration wird die endgültige Replikation nicht ausgeführt, sodass die Migration fehlschlägt.

Ein Blackout-Fenster kann für die Appliance angegeben werden, indem die Datei GatewayDataWorker.json in C:\ProgramData\Microsoft Azure\Config erstellt/aktualisiert wird. Eine typische Datei hat die folgende Form:

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

Die Liste der Blackout-Fenster ist eine durch eine "|" getrennte Zeichenfolge im Format „Wochentag;Startzeit;Dauer“. Die Dauer kann in Tagen, Stunden und Minuten angegeben werden. Das Blackout-Fenster kann beispielsweise wie folgt angegeben werden:

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

Der erste Wert im obigen Beispiel zeigt ein Blackout-Fenster, das jeden Montag um 7:00 Uhr Ortszeit (Zeit auf der Appliance) beginnt und sieben Stunden dauert.

Sobald die Datei GatewayDataWorker.json mit diesen Inhalten erstellt/aktualisiert wurde, muss der Gatewaydienst auf der Appliance neu gestartet werden, damit diese Änderungen wirksam werden.

Im Szenario mit horizontaler Skalierung werden die Blackout-Fenster von der primären Appliance und der Appliance für die horizontale Skalierung unabhängig voneinander unterstützt. Als bewährte Methode empfiehlt es sich, die Fenster applianceübergreifend konsistent zu halten.

Nächste Schritte

Migrieren von virtuellen VMware-Computern ohne Agents