PlateSpin Migrate 12.1 – Versionshinweise

Option zum Definieren des Generationstyps für den virtuellen Hyper-V-Zielcomputer

Mit der neuen Konfigurationsoption „Generationstyp des virtuellen Computers“ in PlateSpin Migrate 12.1 legen Sie einen der folgenden Generationstypen für den neuen virtuellen Computer fest:

Weitere Informationen finden Sie unter VM-Konfiguration: Hyper-V im Benutzerhandbuch für PlateSpin Migrate 12.1.

Option zum Definieren der virtuellen Netzwerk-ID für eine Ziel-VM auf einem Hyper-V-Host

Mit der neuen Option „VLAN-ID“ in PlateSpin Migrate 12.1 legen Sie die virtuelle Netzwerk-ID fest, die auf der Ziel-VM auf einem Hyper-V-Host verwendet werden soll. Wenn Sie hier keine ID festlegen, wird standardmäßig die virtuelle Netzwerk-ID des Ursprungscomputers verwendet.

Weitere Informationen finden Sie unter Post-Migrations-Netzwerkbetrieb für virtuelle Netzwerkschnittstellen (Windows und Linux) im Benutzerhandbuch für PlateSpin Migrate 12.1.

Option zum Ändern des Adaptertyps für den Vorgang „Ziel – Übernahme der Kontrolle“ bei der Workload-Migration zu einer Ziel-VM auf einem Hyper-V-Host

In PlateSpin Migrate 12.1 können Sie den Adaptertyp für den Vorgang „Ziel – Übernahme der Kontrolle“ bei der Workload-Migration zu einer Ziel-VM auf einem Hyper-V-Host bearbeiten.

Weitere Informationen finden Sie unter Ändern des Adaptertyps für den Vorgang „Ziel – Übernahme der Kontrolle“ bei der Workload-Migration zu einer Ziel-VM auf einem Hyper-V-Host im Benutzerhandbuch für PlateSpin Migrate 12.1.

Beim Entfernen eines Ziels wird in einem Browser mit deutscher Sprache kein Bestätigungsdialog geöffnet

Problem: Wenn die Sprachoption des Webbrowsers auf Deutsch eingestellt ist, wird in der Weboberfläche kein Bestätigungsdialog geöffnet, sobald Sie neben einem Ziel in der Liste der Ziele auf Entfernen klicken. Dieses Problem tritt sowohl bei VMware-Zielen als auch bei Azure-Zielen auf. Die Weboberfläche öffnet den Bestätigungsdialog über das Entfernen des Ziels in Webbrowsern, deren Sprachoption auf Englisch oder auf eine andere unterstützte Landessprache eingestellt ist (Französisch, Japanisch, Chinesisch [vereinfacht] und Chinesisch [traditionell]). (Bug 978490)

Behelfslösung: Wenn Sie einen Browser mit der Sprachoption Deutsch verwenden, gehen Sie beim Entfernen von Zielen vorsichtig vor. Alternativ können Sie in den Spracheinstellungen des Browsers eine andere unterstützte Sprache festlegen.

Hilfe für chinesische Locales wird in englischer Sprache angezeigt

Bei chinesischen Locales wird die Hilfe in englischer Sprache angezeigt.

Fehler bei der Testübernahme, wenn die Einstellung „Hostname“ auf der Konfigurationsseite eines Linux-Ziel-Workloads einen Unterstrich enthält

Problem: Bei Linux-Ziel-Workloads wird die Testübernahme mit der folgenden Meldung abgebrochen, wenn die Einstellung „Hostname“ auf der Konfigurationsseite eines Linux-Ziel-Workloads einen Unterstrich enthält:

Die virtuelle Maschine konnte nicht konfiguriert werden

(Bug 975854)

Behelfslösung: Unterstriche in Hostnamen werden auf den Linux-Plattformen allgemein nicht unterstützt. Ändern Sie den Hostnamen (zulässige Zeichen sind a bis z, 0 bis 9 und Bindestrich [-]) und wiederholen Sie dann den Vorgang.

Bei aktivierter Verschlüsselung wird die inkrementelle dateibasierte Reproduktion nicht abgeschlossen

Problem: Wenn Sie die·Verschlüsselung für einen Windows-Workload aktivieren, der für die dateibasierte Übertragung konfiguriert ist, bleibt der Windows-Empfänger unter Umständen am Ende der Übertragung für inkrementelle Reproduktionen hängen. Dieser Fall tritt ein, wenn das letzte gelesene Byte der Übertragung durch den Verschlüsselungsvorgang fehlerhaft auf einen Wert ungleich null gesetzt wurde. Dieser Wert bedeutet, dass noch weitere Dateien übertragen werden, sodass weiter aus dem Stream gelesen werden soll. (Bug 944559)

Behelfslösung: Wenn die Verschlüsselung für die Übertragung der Reproduktionsdaten aktiviert werden soll, nutzen Sie die blockbasierte Datenübertragung für Windows-Workloads.

Weboberfläche: Beim Ausführen von „Workload entfernen“ mit „Ursprung beibehalten“ wird die Bestätigungsmeldung nicht angezeigt

Problem: Wenn Sie einen Workload mit den Optionen Workload entfernen und Ursprung beibehalten entfernen, erhält der ermittelte Workload den Status „Nicht konfiguriert“ und der Zielspeicherort wird bereinigt. Der Validierungsverlauf enthält nur den letzten Vorgang, also Workload entfernen. Der Validierungsverlauf für die frühere Workload-Ermittlung ist nicht mehr verfügbar. (Bug 971118)

Behelfslösung: Bevor Sie den Workload entfernen, fertigen Sie ein Bildschirmfoto der Ermittlungsvalidierung an, oder kopieren Sie die Meldung an einen anderen Speicherort.

Fehler bei der Installation, wenn die Sprache und die Locale des Betriebssystems auf dem Computer nicht übereinstimmen

Problem: Wenn Sie PlateSpin Migrate auf einem Computer installieren, auf dem die Spracheinstellung für das Betriebssystem nicht mit der Einstellung für die Betriebssystem-Locale übereinstimmt, tritt ein Fehler bei der Installation auf. (Bug 939805)

Behelfslösung: Zur erfolgreichen Installation von PlateSpin Migrate muss die Sprache des Betriebssystems mit der Betriebssystem-Locale übereinstimmen. Sie können die Locale wieder auf die gewünschte Sprache umstellen, sobald die Installation abgeschlossen ist.

Ist beispielsweise Englisch als Betriebssystemsprache eingestellt, muss auch die Betriebssystem-Locale auf Englisch gesetzt werden, wenn Sie die englische oder die lokalisierte Version von PlateSpin Migrate installieren. Nach Abschluss der Installation können Sie die Locale des Computers wieder auf die gewünschte Sprache umstellen.

Option zum Installieren blockbasierter Treiber ist beim Konfigurieren der Workload-Migration selbst dann aktiviert, wenn die blockbasierten Treiber bereits installiert sind

Problem: Wenn Sie die Migration für einen Workload konfigurieren, auf dem die blockbasierten Treiber bereits installiert sind, wird die Option Während Reproduktionsvorbereitung installieren unter „Übertragungsmethode“ standardmäßig aktiviert. Diese Option muss deaktiviert werden, da die blockbasierten Treiber bereits installiert sind. Der Funktionsumfang wird hierdurch nicht eingeschränkt. (Bug 967018)

Behelfslösung: Ignorieren Sie die Option.

Inkonsistentes Verhalten bei Azure- und VMware-Zielen, wenn die LVM-Volume-Gruppe deaktiviert wird, nicht jedoch das zugehörige logische Volume

Problem: Wenn Sie bei einem Linux-Workload mit LVM die Volume-Gruppe deaktivieren, nicht jedoch das zugehörige logische Volume, ist das Verhalten bei den folgenden Zielen inkonsistent:

(Bug 973926)

Behelfslösung: Wenn Sie eine Volume-Gruppe deaktivieren, müssen Sie auch das zugehörige logische Volume deaktivieren.

Beim Migrieren von Linux-Workloads wird das Zuordnen von Volumes nicht unterstützt

Problem: Wenn Sie Linux-Workloads mit dem PlateSpin Migrate-Client migrieren, wird Folgendes nicht unterstützt: (Bug 930355)

Die Migration von Linux-Workloads mit Volumes, die auf einem Rohdatenträger ohne Partitionen erstellt wurden, ist nicht möglich

Problem: PlateSpin Migrate unterstützt die Migration von Linux-Workloads mit Volumes, die auf einem Rohdatenträger ohne Partitionen erstellt wurden, nicht. (Bug 937071)

Migration eines Workloads auf eine Hitachi-LPAR nicht möglich

Problem: Wenn Sie einen Workload auf eine Hitachi-LPAR migrieren, auf der ein Betriebssystem ausgeführt wird, kann die Migration unter Umständen nicht abgeschlossen werden. Der Migrationsauftrag wartet im Schritt Zielcomputer konfigurieren auf eine Eingabe des Benutzers. (Bug 902489)

Behelfslösung: Ändern Sie die UEFI-Boot-Reihenfolge, sodass die Hitachi-LPAR von der Festplatte statt aus dem ISO-Image heraus gebootet wird.

Warnmeldung beim Migrieren eines Workloads auf eine Hitachi-LPAR

Problem: Wenn Sie einen Workload auf eine Hitachi-LPAR migrieren, wird eine Warnmeldung angezeigt, beispielsweise: (Bug 917209)

Gerät 'Nicht zugewiesenes gemeinsam genutztes Hitachi-FC-Gerät 3017' wird nicht unterstützt von .....

Behelfslösung: Ignorieren Sie die Meldung.

PlateSpin Migrate kann nicht auf einem Computer mit Windows Server 2012 oder Windows Server 2012 R2 installiert werden

Problem: Wenn Sie die Benutzerkontensteuerung auf einem Computer mit Windows Server 2012 oder Windows Server 2012 R2 über die Systemsteuerung deaktivieren und dann PlateSpin Migrate auf dem Computer installieren, meldet das Dienstprogramm zum Prüfen der Voraussetzungen dennoch den Fehler, dass die Benutzerkontensteuerung noch aktiviert ist. Wird die Benutzerkontensteuerung über die Systemsteuerung deaktiviert, so wird diese Änderung nicht in den entsprechenden Registrierungsschlüssel übernommen. (Bug 929511) 

Behelfslösung: Anweisungen zum Deaktivieren der Benutzerkontensteuerung auf einem Computer mit Windows Server 2012 oder Windows Server 2012 R2 finden Sie unter „Windows Server 2012: Deaktivieren der Benutzerkontensteuerung“ im Microsoft TechNet-Wiki.

Ein ermittelter Hyper-V-Container wird in der PlateSpin Migrate-Weboberfläche als Workload dargestellt

Problem: Wenn Sie einen Hyper-V-Container über die PlateSpin Migrate-Weboberfläche ermitteln, wird dieser Container als Workload in der Weboberfläche aufgeführt. Dieser Hyper-V-Container darf nicht migriert werden. (Bug 929978) 

Behelfslösung: Dieser Hyper-V-Container darf nicht migriert werden.

Ein Linux-Workload kann nicht zu einem Container migriert werden, der die Firmware des Ursprungs-Workloads nicht unterstützt

Problem: Beim Migrieren eines Linux-Workloads tritt in den folgenden Szenarien ein Fehler auf, da die Konvertierung von UEFI zu BIOS (und umgekehrt) nicht unterstützt wird: (Bug 937070)

(Windows-Quellen) Nicht standardmäßige volumenbasierte VSS-Einstellungen werden nach der Migration nicht beibehalten

Problem: Die nicht standardmäßigen volumebasierten VSS-Einstellungen werden nach der Migration eines Windows-Workloads nicht beibehalten. (Bug 493589)

Behelfslösung: Konfigurieren Sie die benutzerdefinierten VSS-Einstellungen nach der Migration neu.

(ESX 4.1) Keine Warnmeldung oder kein Fehler bei falscher vCPU-Auswahl

Problem: Wenn die Anzahl der angeforderten vCPUs die Anzahl der physischen CPUs auf dem ESX 4.1-Host überschreitet, wird die angeforderte Anzahl ignoriert und die Ziel-VM mit einer einzigen vCPU erstellt, ohne dass eine Warnmeldung ausgegeben wird. (Bug 505426) 

Behelfslösung: Die vCPU-Auswahl darf die Anzahl der physischen CPUs auf dem ESX 4.1-Hostserver nicht überschreiten.

Sonderzeichen im Namen einer Datenablage verursacht Migrationsprobleme

Problem: Bei Migrationsvorgängen kann ein Fehler auftreten, wenn sie auf ESX-Datenablagen durchgeführt werden, deren Name das Pluszeichen (+) oder andere Sonderzeichen enthält. (Bug 506154) 

Weitere Informationen hierzu finden Sie im KB-Artikel 7009373.

Das Beibehalten einer Bootpartition führt zu Migrationsproblemen

Problem: In einigen Migrations-Szenarien erlaubt das System es Ihnen fälschlicherweise, Ihre Bootpartition auf dem Ziel beizubehalten, was das Booten des ordnungsgemäßen Workloads verhindert. (Bug 595490) 

Ausweichlösung: Legen Sie nicht fest, dass Ihre Bootpartition auf dem Ziel beibehalten werden soll.

(Linux nach ESX 4) Problem beim Abschließen der Migration, wenn beim Betriebssystem des Ursprungs die automatische Anmeldung oder das automatische Mounten von CD-Laufwerken aktiviert ist

Problem: Wenn beim Betriebssystem des Ursprungs die automatische Anmeldung oder das automatische Mounten von CD-Laufwerken aktiviert ist, wirkt sich dies auf die Migration aus. Zudem wird der Migrationsvorgang beeinträchtigt, wenn Sie sich beim Ziel während des Konfigurationsschritts des Auftrags anmelden. (Bug 604320) 

Ausweichlösung: Deaktivieren Sie die automatische Anmeldung und das automatische Einhängen von CD-Laufwerken auf dem Ursprung. Melden Sie sich nicht beim Ziel-Workload an, solange die Migration nicht abgeschlossen ist.

Fehler beim Ausführen eines Post-Migrations-Skripts mit Unicode-Zeichen im Dateinamen

Problem: Wenn sich Unicode-Zeichen im Dateinamen eines Post-Migrations-Skripts befinden, tritt ein Fehler bei der Skriptausführung auf. (Bug 619942) 

Ausweichlösung: Verwenden Sie beim Benennen einer Post-Migrations-Aktion ausschließlich ASCII-Zeichen.

VSS-Snapshots werden nicht beibehalten

Problem: VSS-Snapshots, die von Anwendungen von Drittanbietern auf dem Ursprungs-Workload erstellt wurden, werden bei der Migration nicht auf das Ziel reproduziert. (Bug 692680) 

Migration über WAN benötigt viel Zeit, wenn der Ziel-VM-Host eine große Anzahl an Datenablagen enthält

Problem: Wenn Ihr Migrate-Server über ein WAN mit dem VM-Host verbunden ist und Ihr VM-Host eine große Anzahl an Datenablagen enthält, kann die Suche nach dem für das Booten des Ziels erforderlichen entsprechenden ISO-Images in einigen Fällen länger als erwartet dauern. (Bug 702152) 

Behelfslösung: Zur Optimierung der verfügbaren Bandbreite planen Sie die Migration für einen Zeitpunkt ein, der nicht in die Zeiten mit dem größten Datenverkehr fällt.

Nicht zugeordnetes Basisverzeichnis wird nach einmaliger Zeitserversynchronisation deaktiviert und ausgehängt

Problem: Wenn Sie eine Serversynchronisation vornehmen und dann die Partition /home auf none umstellen, sollte das Verzeichnis /home der Partition eingehängt und auf dem Zielserver aktiviert werden; stattdessen wird es deaktiviert und ausgehängt. (Bug 779194) 

Behelfslösung: Heben Sie nach der Serversynchronisation die Kommentierung der entsprechenden Zeile in der Datei /etc/fstab auf dem Zielserver auf. Weitere Informationen hierzu finden Sie im KB-Artikel 7014638.

VMware-Tools werden beim Konvertieren eines Windows Server 2012-Kerns nicht installiert

Problem: Die VMware-Tools werden beim Konvertieren eines Windows Server 2012-Kerns nicht installiert. (Bug 810460)

Behelfslösung: Installieren Sie die VMware-Tools nach der Konvertierung manuell.

Netzwerkkarte wird auf einer SLES-11-Ziel-VM, die auf einem Windows-2008-Hyper-V-Host gehostet wird, nicht initialisiert

Problem: Wenn Sie einen SLES-11-Workload (geklonte VM) mit der halbautomatischen Methode auf eine (scheinbar physische) Ziel-VM auf einen Windows-2008-Hyper-V-Host migrieren, bleibt der Vorgang beim Schritt Konfigurieren des Betriebssystems hängen. (Bug 822601) 

Behelfslösung: Siehe KB-Artikel 7012911.

Ziel-VM wird nach der Migration von VMware ESX auf Citrix Xen nicht gebootet, wenn sich die Bootdateien im zweiten Laufwerk befinden

Problem: Wenn Sie eine VM von VMware ESX in Citrix Xen konvertieren und die zugehörigen Bootdateien im zweiten Laufwerk vorliegen, wird die VM nicht gebootet und Sie müssen manuell eingreifen. Der Grund liegt darin, dass die Citrix-XEN-VM versucht, mit dem Laufwerk 0 zu booten statt mit den Bootdateien, die Laufwerk 2 zugewiesen sind. (Bug 824724) 

Behelfslösung: Zur Behebung dieses Problems ordnen Sie die Position der virtuellen Laufwerke in XenCenter so um, dass die VM von dem virtuellen Laufwerk aus gebootet wird, in dem sich das Betriebssystem befindet. Im Artikel auf der Citrix-Website finden Sie Informationen zum Ändern der Position des virtuellen Laufwerks, das das Betriebssystem enthält. Weitere Informationen hierzu finden Sie im KB-Artikel 7012906.

XenServer-Tools werden nach der Konvertierung nicht entfernt

Problem: Die XenServer-Tools auf einer Windows-VM in einer Citrix-XenServer-Hypervisor-Umgebung werden nicht entfernt, wenn Sie die VM in einen VMware-Container oder einen physischen Container konvertieren. (Bug 825016) 

Behelfslösung: Deinstallieren Sie die XenServer-Tools nach der Konvertierung manuell.

Bei der Migration wurde die primäre Partition in eine logische Partition auf dem Ziel konvertiert

Problem: Folgendes Szenario dient zur Verdeutlichung:

Szenario: Verschieben oder Kopieren eines Computers mit Windows-Betriebssystem, der mehr als drei primäre Partitionen enthält, auf einen physischen Computer, auf dem ein Windows-Betriebssystem mit mindestens drei primären Partitionen installiert ist. Mindestens eine primäre Partition auf dem Zielcomputer wird beibehalten. (Bug 825434)

Resultat: Nach der Migration kann der Computer mit Windows-Betriebssystem nicht mehr gebootet werden.

Beispiel: Beim Konvertieren eines Computers mit Windows Server 2003 in einen physischen Computer tritt der folgende Fehler auf:

Windows could not start because the following file is missing or corrupt:
<Windows root>\system32\ntoskrnl.exe.Please re-install a copy of the above file.

Behelfslösung: Siehe KB-Artikel 7012913.

Ermittlung eines Computerknotens wird nicht rückgängig gemacht, wenn Migrate die Ermittlung eines Computers rückgängig macht

Problem: Wenn Sie die Ermittlung eines Workloads rückgängig machen, wird dies entsprechend im Migrate-Client angezeigt. Der ESX-Host zeigt jedoch, dass die Ermittlung des Knotens nicht rückgängig gemacht wurde. (Bug 826545)

Behelfslösung: Machen Sie die Ermittlung des Workloads auf dem ESX-Host rückgängig und aktualisieren Sie dann den ESX-Host.

Fehler beim Abrufen von Daten vom VMware-vCenter-Server

Problem: Beim Abrufen von Daten vom VMware-vCenter-Server tritt der folgende Ausnahmefehler auf: Berechtigung zum Ausführen dieses Vorgangs verweigert. (Bug 839329)

Behelfslösung: Dieses Problem kann anhand der Verfahren zum Definieren der VMware-Rollen mit Tools behoben werden; siehe Definieren von VMware-Rollen mit Tools im Benutzerhandbuch für PlateSpin Migrate 12.1. 

V2P-Konvertierung bleibt beim Schritt „Konfigurieren des Betriebssystems“ hängen

Problem: Wenn die Firmware mehrere Bootoptionen bietet und die Festplatte nicht das erste Bootgerät in der Liste der Bootoptionen ist, wird der Zielcomputer nicht von der Festplatte gebootet und die Konvertierung bleibt hängen. (Bug 859440)

Ausweichlösung: Ändern Sie die Bootreihenfolge in den Bootoptionen des physischen Computers so, dass Festplatte als erste Option angezeigt wird. Starten Sie dann den Computer neu. Weitere Informationen hierzu finden Sie auch im KB-Artikel 7014623.

Fehler beim Konvertieren von UEFI in BIOS für Windows 8.1 in Schritt „Dateien senden“

Problem: Bei der OEM-Standardinstallation von Windows 8.1 (UEFI) wird eine Wiederherstellungspartition erstellt, deren Speicherplatz nicht ausreicht, um eine VSS (Volume Shadow Copy) für die Partition anzulegen. (Bug 864325)

Behelfslösung: Entfernen oder erweitern Sie die Wiederherstellungspartition. Weitere Informationen hierzu finden Sie im KB-Artikel 7014696.

Fehler beim Konvertieren während des Downgrades von UEFI- auf BIOS-Firmware

Problem: Beim Konvertieren eines UEFI-Workloads (Windows-Kernel-Version 6.2 und höher) auf einen BIOS-basierten Computer tritt beim Schritt Vorbereiten des Betriebssystems ein Fehler auf, da die aktive Partition zum Aktualisieren der Bootparameter nicht aufgefunden wird. (Bug 864326)

Behelfslösung: Aktualisieren Sie den Partitionstyp Disk as MBR (Festplatte als MBR), bei dem das System-Volume entweder im Ursprungsworkload oder im Image vorliegt. Bearbeiten Sie die XML-Daten mit den Optionen zum Exportieren und Importieren der Benutzeroberfläche oder im OFX-Browser. Eine vollständige Liste der Schritte finden Sie im KB-Artikel 7014637.

Fehler bei dateibasierter Übertragung für Windows Server 2012 R2-UEFI-Workload

Problem: Bei der X2P-Datei-basierten Übertragung für Windows-Kernel 6.2 und höher tritt beim Senden und Empfangen der Dateien ein Fehler auf. (Bug 865570)

Behelfslösung: Zum Erzwingen der Dateiübertragung in diesem X7014698P-Szenario deaktivieren Sie die erweiterten CPU-Flags in der Firmware: VT-d, VT-s, Execute Disable Bit. Siehe KB-Artikel 7014698.

Fehler beim Erstellen eines Image eines Windows-32-Bit-Betriebssystems

Problem: Migrate erwartet einen Ordner mit dem Namen C:\Windows\Boot\EFI auf dem Ursprungsserver, damit Inhalte für den späteren Gebrauch exportiert werden können. Dieser Ordner ist in Windows-32-Bit-Betriebssystemen vor Windows Server 2008 oder Windows Vista nicht vorhanden. Wenn Migrate also BCD-Informationen in den Ordner exportiert, tritt der folgende Fehler auf:

Fehlermeldung: C:\Windows\Boot\EFI

(Bug 866467)

Behelfslösung: Legen Sie den Ordner C:\Windows\Boot\EFI an und erstellen Sie unter C:\Windows eine Verzweigung auf C:\Windows\System32. Weitere Informationen hierzu finden Sie im KB-Artikel 7014710.

Ursprungscomputer verbleibt nach Offline-Konvertierung weiterhin im Status „Unter Kontrolle“

Problem: Wenn Sie die Einstellung Endstatus für einen Offline-Konvertierungsauftrag als Neustart konfigurieren, verbleibt der Ursprungscomputer nach dem erfolgreichen Abschluss des Auftrags im Status Unter Kontrolle. (Bug 875562)

Behelfslösung: Starten Sie den Ursprungscomputer nach Abschluss der Konvertierung manuell neu.

Bootkonfiguration des Ursprungscomputers wird nach der Offline-Konvertierung nicht wiederhergestellt

Problem: Das Bootmenü eines Windows-Ursprungscomputers wird nach der Offline-Konvertierung nicht wiederhergestellt. (Bug 878043)

Behelfslösung: Nach erfolgter Konvertierung enthält das Bootmenü des Ursprungscomputers eine Option für den Linux-RAM-Datenträger (LRD) sowie eine Option für das Betriebssystem (OS). Wählen Sie beim ersten Booten nach der Konvertierung manuell die Option für das Betriebssystem. Damit wird die LRD-Bootoption für künftige Bootvorgänge aus dem Bootmenü gelöscht.

Das Erstellen und Verschieben einer VM im Ressourcenpool als Einstellung wird vom CLI-Werkzeug nicht unterstützt

Problem: Das Befehlszeilenschnittstellen-Werkzeug (CLI-Werkzeug) unterstützt derzeit nicht das Verschieben oder Erstellen einer VM im Ressourcenpool als Einstellung in der Datei conversion.ini. (Bug 891690)

Behelfslösung: Verschieben Sie den Computer nach erfolgter Konvertierung manuell in den gewünschten Ressourcenpool.

Partitionen werden nach der Konvertierung nicht zu Laufwerkbuchstaben gemountet

Problem: Nach der Konvertierung in Windows Server 2012 R2 Hyper-V ist nur das Laufwerk „C“ sichtbar. Andere Partitionen werden nicht zu Laufwerkbuchstaben gemountet.(Bug 894623)

Behelfslösung: Öffnen Sie nach erfolgter Konvertierung die Datenträgerverwaltung und weisen Sie die Laufwerkbuchstaben manuell den Partitionen zu.

Beim Konvertieren eines Workloads in Windows Server 2012 R2 Hyper-V können Datenträger- und Volume-Zuordnungen nicht problemlos hinzugefügt werden

Problem: Beim Booten der Hyper-V-VM unter Windows Server 2012 R2 mit LRD werden IDE- und/oder SCSI-Festplatten in der Liste der Festplattengeräte in willkürlicher Reihenfolge angezeigt. (Bug 896584)

Behelfslösung: In der Liste sollten zunächst die IDE-Festplatten aufgeführt werden und danach die SCSI-Festplatten. Passen Sie die Liste mit dem Migrate-Client entsprechend an.

Die folgenden Szenarien zeigen Beispiele für das Listenverhalten. Annahmen in diesen Szenarien: Die Ziel-VM ist Generation 1. Sie müssen mindestens drei virtuelle Festplattenlaufwerke erstellen:

Szenario 1 -- IDE-zu-SCSI-Verhalten

Gegebene anfängliche Einstellung:

• Disk2: IDE
• Disk3: IDE

Szenario 2 -- SCSI-zu-IDE-Verhalten

Gegebene anfängliche Einstellung:

• Disk2: SCSI
• Disk3: SCSI

Nach der blockbasierten Migration von RHEL 6.2 x64 zu Windows Server 2012 R2 Hyper-V sind redundante Datenträger vorhanden

Problem: Nach der erfolgreichen blockbasierten RHEL 6.2 x64-Migration mit der Option Integrationsdienste installieren gibt der Befehl fdisk -l redundante Datenträger zurück. Ein einzelner Datenträger wird also als sda und sdb angezeigt. (Bug 896598)

Behelfslösung: Dies ist ein bekanntes Problem in Microsoft-Umgebungen und wird derzeit bearbeitet.

Anforderungen für die Unterstützung von VMware-DRS-Cluster

Problem: PlateSpin Migrate unterstützt VMware-Cluster mit und ohne aktives DRS und mit jeder DRS-Stufe (Manuell, Teilweise automatisiert oder Vollautomatisch). Damit der VMware-Cluster jedoch ein gültiges Migrationsziel ist, muss er über VMware vCenter und nicht über die direkte Inventarisierung einzelner ESX-Server ermittelt werden. (Bug 896598)

Weitere Informationen finden Sie im Abschnitt "Leitfaden zur Ermittlung von Maschinentypen und Berechtigungsnachweisen" im Benutzerhandbuch.

Fehler beim Installieren des PlateSpin-Imageservers, wenn der vollständige Dateipfad der Imagedatei mehr als 248 Zeichen enthält

Problem: Wenn Sie einen Computer als PlateSpin-Imageserver festlegen und der vollständige Pfad der Imagedatei mehr als 248 Zeichen enthält, tritt beim Installieren des Imageservers ein Fehler auf. (Bug 967414)

Behelfslösung: Der vollständige Pfad der angegebenen Imagedatei darf maximal 248 Zeichen enthalten.

Fehler beim Konvertierungsauftrag; NICs können auf einem Zielcomputer mit Windows 2000 Server nicht konfiguriert werden

Problem: Wenn Sie einen Windows 2000 Server migrieren, der mindestens eine NIC umfasst, kann der Konvertierungsauftrag die NICs auf dem Zielcomputer nicht konfigurieren. (Bug 971414)

Behelfslösung: Konfigurieren Sie die NICs nach Abschluss des Konvertierungsauftrags manuell.

Beim erneuten Ermitteln eines ESX-Servers im Migrate-Client wird in der Weboberfläche ein doppelter Servereintrag mit der Fehlermeldung „Hinzufügevorgang fehlgeschlagen“ angezeigt

Problem: Wenn Sie einen ESX-Server mit dem Migrate-Client entweder direkt oder über einen vCenter-Server ermitteln, wird der ermittelte Server in der Weboberfläche aufgeführt. Wenn Sie dann denselben ESX-Server erneut mit dem Migrate-Client ermitteln, wird ein doppelter Eintrag für diesen Server mit der Fehlermeldung Hinzufügevorgang fehlgeschlagen in der Weboberfläche angezeigt. (Bug 975870)

Behelfslösung: Löschen Sie den doppelten Servereintrag aus der Weboberfläche.

Geplante Vollreproduktion wird beim Erreichen des geplanten Zeitpunkts nicht gestartet

Problem: Unter bestimmten Umständen wird in PlateSpin Migrate 12.0 ein Zeitplan für eine Vollreproduktion nicht beachtet. (Bug 971849)

Behelfslösung: Nach dem Aufrüsten von Version 12.0 Hotfix 1 auf Version 12.1 sind einige frühere Zeitpläne ggf. beschädigt. Falls unter Nächste Reproduktion kein Zeitplan angezeigt wird, müssen Sie den Zeitplan für den betreffenden Workload neu konfigurieren. Die in PlateSpin 12.1 festgelegten Zeitpläne werden beachtet.

Fehler bei der Übernahme während der Partitionierung

Problem: Während der Festplattenpartitionierung kann in seltenen Fällen eine besondere Situation eintreten, wenn PlateSpin Migrate versucht, die Partitionstabelle zu lesen, bevor das Dienstprogramm npart alle Partitionsinformationen zurückgegeben hat. Durch diese Situation tritt bei der Übernahme ein Fehler mit der folgenden Meldung auf:

Kein Gerät zum Zuordnen des Windows-Volumes gefunden

(Bug 959079)

Behelfslösung: Führen Sie die Übernahme erneut durch.

Netzwerkverbindungen auf der Ziel-VM werden ggf. nicht dem richtigen virtuellen Azure-Netzwerk oder -Teilnetz zugeordnet

Problem: Wenn Sie einen Windows-Workload mit mehreren NICs mit DHCP zu Azure migrieren, wird die Netzwerkverbindung auf der Ziel-VM unter Umständen nicht dem richtigen virtuellen Azure-Netzwerk oder -Teilnetz zugeordnet.

Beispiel: Der Ursprungs-Workload besitzt drei NICs mit DHCP und die Netzwerkverbindungen sind wie folgt zugeordnet:

Nach der Migration werden die Netzwerkverbindungen auf der Ziel-VM wie folgt zugeordnet:

(Bug 967316)

Behelfslösung: Sie können den Ziel-Workload in diesem Status nicht verwenden. Entfernen Sie den fehlerhaften Ziel-Workload und wiederholen Sie dann die Migrationseinrichtung und die Übernahme. Beim zweiten Versuch werden die DHCP-NICs in der Regel den richtigen virtuellen Azure-Netzwerken oder -Subnetzen zugeordnet.

Nach der erfolgreichen Übernahme sollten in der Weboberfläche des Azure-Portals der Computername und der DNS-Name der Ziel-VM angezeigt werden

Problem: Im Microsoft Azure-Portal sind die Felder DNS-Name und Eigenschaften > COMPUTERNAME leer. (Bug 969489)

Behelfslösung: Melden Sie sich über den Remote-Desktop beim Computer an. Öffnen Sie die Systemsteuerung und wechseln Sie zur Seite „System“. Dort werden der Computername und der DNS-Name des Computers angezeigt.

Azure-Ziel-VMs werden mit einer zusätzlichen Festplatte erstellt

Problem: Azure fügt automatisch einen Datenträger in die VM ein, der nicht mit einem Laufwerkbuchstaben eingehängt wird. Die Größe des Datenträgers ist dabei abhängig von der Cloud-Instanz, die Sie für die Bereitstellung ausgewählt haben. (Bug 967314)

Behelfslösung: Sie können den zusätzlichen Azure-Datenträger aus der VM-Konfiguration entfernen.

Bei der maximalen Azure-Instanzengröße ist eine Prüfung in der Benutzeroberfläche erforderlich, damit die Anzahl der Datenplatten für die Reproduktion auf 63 Datenplatten begrenzt wird

Problem: PlateSpin Migrate unterstützt Azure-VMs mit bis zu 64 Datenplatten. Bei der maximalen Instanzengröße zieht Migrate nur eine einzige Datenplatte für die Reproduktion des Betriebssystems in der PlateSpin-Reproduktionsumgebung heran. Nach der Migration wird diese Datenplatte zur Betriebssystemplatte und Sie können eine Datenplatte hinzufügen. Wenn Sie einen Ursprungs-Workload mit 64 Datenplatten zur Reproduktion senden, wird in der Benutzeroberfläche keine Warnung angezeigt und bei der Reproduktion tritt ein Fehler auf. (Bug 972053)

Behelfslösung: Bei der maximalen Azure-Instanzengröße darf der Ursprungs-Workload nur maximal 63 Datenplatten umfassen, wenn Sie den Workload zur Reproduktion senden.

Bei der Migration von Azure zu Azure wird der Ursprungs-Workload ggf. gelöscht, wenn Sie dasselbe Ziel und dieselbe Datenablage auswählen

Problem: Wenn Sie versehentlich versuchen, einen Azure-Ursprungs-Workload zu demselben Ziel und demselben Datenablage-Speicherort in Azure zu migrieren, wird die Migration erwartungsgemäß mit dem Fehler BLOB bereits vorhanden abgebrochen. Beim Bereinigen des Ziel-Workloads nach dem Fehler wird der Ursprungs-Workload gelöscht, da sich beide Workloads in demselben Speicherort befinden. (Bug 971998)

Behelfslösung: Verzichten Sie auf die Migration eines Azure-Ursprungs-Workloads zu demselben Ziel und demselben Datenablage-Speicherort in Azure.

Datenträgernummern und Datenträgerindexnummern sind bei ermittelten Workloads mit dynamischen Datenträgern nicht sequenziell

Problem: Bei Windows-Ursprungs-Workloads mit dynamischen Datenträgern des Typs „Einfach“, „Übergreifend“, „Stripeset“, „Gespiegelt“ und „RAID5“ weist die Konfiguration des Ziel-Workloads den Datenträgernamen und Datenträgerindizes nichtsequenzielle Nummern zu. Die nichtsequenzielle Nummerierung ist ein Artefakt, das von den Typen der dynamischen Datenträger im Ursprungs-Workload herrührt. Alle notwendigen Datenträger für den Ziel-Workload sind vorhanden. Dieses Problem tritt bei Azure-Ziel-Workloads und VMware-Ziel-Workloads auf. (Bug 973266)

Behelfslösung: Es gibt keine Behelfslösung.

Standardmäßige Größe der Cloud-Instanz für Workloads mit dynamischem Datenträger ist zu groß

Problem: Bei Windows-Ursprungs-Workloads mit dynamischen Datenträgern des Typs „Einfach“, „Übergreifend“, „Stripeset“, „Gespiegelt“ und „RAID5“ ist die standardmäßige Größe der Cloud-Instanz für den Ziel-Workload ggf. größer als nötig. Die Standardeinstellungen für die Datenplattenkomponente beruht auf der Gesamtanzahl der Datenträger im Ursprungs-Workload, nicht auf der Nettoanzahl der im Ziel-Workload zu erstellenden Datenträger. (Bug 973265)

Behelfslösung: Legen Sie manuell die richtige und gewünschte Einstellung für die Größe der Cloud-Instanz fest. Unter Umständen eignet sich eine Cloud-Instanzengröße mit weniger Datenplatten für Ihre Anforderungen.

Reihenfolge der virtuellen Datenträger wird fehlerhaft geändert, wenn ein Datenträger auf der Konfigurationsseite von der Migration ausgeschlossen wird

Problem: Für einen ermittelten Workload werden alle ermittelten Datenträger auf der Konfigurationsseite aufgeführt. Wenn Sie einen Datenträger von der Migration ausschließen und die Änderung speichern, wird die vdisk-Liste mit den zugehörigen Datenträgerpfaden neu geordnet, wobei unter Umständen nicht der angegebene Datenträger ausgeschlossen wird. Dieses Problem tritt bei VMware- und Azure-Ziel-VMs auf. (Bug 969639)

Behelfslösung: Dies ist eine kosmetische Änderung der Konfiguration über die Benutzeroberfläche. Die zugrunde liegende Konfiguration wird korrekt gespeichert und der Benutzer muss die Pfade oder die Reihenfolge der Datenträger nicht ändern.

Fehler bei der Migration zu Azure für SLES 11 SP4 mit 3 Nicht-LVM-Datenträgern

Problem: Bei der Migration eines Workloads mit SUSE Linux Enterprise Server (SLES) 11 SP4, der lediglich Nicht-LVM-Datenträger umfasst, zu Azure ist ein Fehler aufgetreten. Bei mehreren Versuchen sind verschiedene Fehler aufgetreten:

Befehl fehlgeschlagen. Weitere Informationen finden Sie in den Befehlsdetails. Der Konfigurationsdienst auf dem Zielcomputer wurde offenbar nicht gestartet.

Migrationen von Workloads mit anderen SLES-Versioen und anderen Linux-Betriebssystemen, die nur mit Nicht-LVM-Datenträgern konfiguriert sind, zu Azure sind erfolgreich. (Bug 972062)

Behelfslösung: Für Workloads mit SLES 11 SP4 und Nicht-LVM-Datenträgern gibt es keine Behelfslösung.

Linux-Datenträger oder -Partitionen werden in anderer Reihenfolge zum Ziel migriert als im Linux-Ursprung

Problem: Linux-Datenträger werden im Ziel-Workload in einer anderen Reihenfolge angelegt, also nicht in der Reihenfolge wie im Ursprungs-Workload. Alle Datenträger und Partitionen sind vorhanden, lediglich in anderer Reihenfolge. (Bug 974156)

Behelfslösung: Es gibt keine Behelfslösung. Die Ziel-VM ist voll funktionsfähig.

LVM-Volume-Gruppen werden auf entgegengesetzten Partitionen auf demselben Datenträger auf der Linux-Ziel-VM erstellt

Problem: In einem Linux-Workload mit mehreren LVM-Volume-Gruppen auf demselben Datenträger werden die LVM-Volume-Gruppen im Ziel-Workload in umgekehrter Reihenfolge angelegt. Wenn die Ursprungs-Volumes beispielsweise in der Reihenfolge AB angeordnet sind, lautet die Reihenfolge der Ziel-Volumes entsprechend BA. Dieses Problem tritt bei Ziel-Workloads unter Azure und VMware auf. (Bug 973227)

Behelfslösung: Die Reihenfolge der LVM-Volume-Gruppen wirkt sich nicht auf die Funktionsfähigkeit aus. Der Zielcomputer arbeitet wie erwartet.

Linux-Partitionen werden auf entgegengesetzten Partitionen auf demselben Datenträger auf der Linux-Ziel-VM erstellt

Problem: In einem Linux-Workload mit mehreren Linux-Partitionen auf demselben Datenträger werden die Partitionen im Ziel-Workload in umgekehrter Reihenfolge angelegt. Wenn die Ursprungspartitionen beispielsweise in der Reihenfolge AB angeordnet sind, lautet die Reihenfolge der Zielpartitionen entsprechend BA. Dieses Problem tritt bei Ziel-Workloads unter Azure und VMware auf. (Bug 970822)

Behelfslösung: Die Reihenfolge der Linux-Partitionen wirkt sich nicht auf die Funktionsfähigkeit aus. Der Zielcomputer arbeitet wie erwartet.

Azure-Ziel-VM wird nach erfolgreicher Übernahme eines Workloads im sicheren Modus gestartet

Problem: Wenn Sie einen Workload mit Windows Small Business Server 2011 zu Azure migrieren, wird die Übernahme ausgeführt, die Ziel-VM in Azure wird jedoch im sicheren Modus gestartet.(Bug 978131)

Behelfslösung: So booten Sie die Ziel-VM im normalen Modus:

Auf der Seite „Einstellungen des virtuellen Computers“ der Ziel-VM im Azure-Portal wird nicht die Größe der VM angezeigt

Problem:·Nach·der·erfolgreichen·Übernahme·eines·Workloads·in·Azure·wird auf der Seite „Einstellungen des virtuellen Computers“ im Azure-Portal nicht die Größe der Azure-VM angezeigt, wenn die VM zur Serie DSX_v2 gehört. Die VM-Größe wird zwar nicht auf der Einstellungsseite angezeigt, sie wird jedoch in der zugrunde liegenden VM-Konfiguration berücksichtigt. (Bug 977497)

Behelfslösung: Sie können die VM-Größe von VMs der Serie DSX_v2 in der Azure-Befehlszeilenschnittstelle abrufen.

Reproduktionsumgebungs-BLOBs werden nach „Übernahme“ oder „Workload entfernen“ oder „Abbrechen“ nicht automatisch bereinigt

Problem: Bei Migrationen zu Microsoft Azure erstellt der Azure-BLOB-Dienst bestimmte Speicherartefakte (einen Seiten-BLOB und einen Block-BLOB) in der zugewiesenen Datenablage für die Reproduktionsumgebung des Workloads. Sobald der Workload erfolgreich übernommen, abgebrochen oder entfernt wurde, werden diese Artefakte nicht mehr in PlateSpin Migrate benötigt; die Artefakte werden allerdings nicht automatisch entfernt. Microsoft Azure stellt Ihnen die Speicherung dieser unnötigen Datendateien in Rechnung. (Bug 977308)

Behelfslösung: Sobald eine Workload-Migration abgeschlossen, abgebrochen oder entfernt wurde, sollten Sie die zugehörigen Speicherartefakte manuell aus dem vhds-Speichercontainer der Datenablage, die der Migration zugewiesen ist, entfernen. Entfernen Sie keine BLOB-Dateien, während die zugehörige Migration noch ausgeführt wird.

Bei zwei Datenträgern ist auf der Konfigurationsseite für Workloads mit dynamischen Datenträgern derselbe Datenträgerpfad angegeben

Problem: Bei Windows-Ursprungs-Workloads mit dynamischen Datenträgern des Typs „Einfach“, „Übergreifend“, „Stripeset“, „Gespiegelt“ und „RAID5“ wird in der Konfiguration des Ziel-Workloads dieselbe Einstellung für den Datenträgerpfad verwendet. Die doppelte Einstellung wird bei der Migration ignoriert und es werden eindeutige Pfade für die beiden Datenträger im Ziel-Workload konfiguriert. Die Migration wird erfolgreich abgeschlossen. (Bug 973271)

Behelfslösung: Für die Konfiguration ist keine Aktion erforderlich.

Datenträgernummern und Datenträgerindexnummern sind bei ermittelten Workloads mit dynamischen Datenträgern nicht sequenziell

Problem: Bei Windows-Ursprungs-Workloads mit dynamischen Datenträgern des Typs „Einfach“, „Übergreifend“, „Stripeset“, „Gespiegelt“ und „RAID5“ weist die Konfiguration des Ziel-Workloads den Datenträgernamen und Datenträgerindizes nichtsequenzielle Nummern zu. Die nichtsequenzielle Nummerierung ist ein Artefakt, das von den Typen der dynamischen Datenträger im Ursprungs-Workload herrührt. Alle notwendigen Datenträger für den Ziel-Workload sind vorhanden. Dieses Problem tritt bei Azure-Ziel-Workloads und VMware-Ziel-Workloads auf. (Bug 973266)

Behelfslösung: Es gibt keine Behelfslösung.

Reihenfolge der virtuellen Datenträger wird fehlerhaft geändert, wenn ein Datenträger auf der Konfigurationsseite von der Migration ausgeschlossen wird

Problem: Für einen ermittelten Workload werden alle ermittelten Datenträger auf der Konfigurationsseite aufgeführt. Wenn Sie einen Datenträger von der Migration ausschließen und die Änderung speichern, wird die vdisk-Liste mit den zugehörigen Datenträgerpfaden neu geordnet, wobei unter Umständen nicht der angegebene Datenträger ausgeschlossen wird. Dieses Problem tritt bei VMware- und Azure-Ziel-VMs auf. (Bug 969639)

Behelfslösung: Dies ist eine kosmetische Änderung der Konfiguration über die Benutzeroberfläche. Die zugrunde liegende Konfiguration wird korrekt gespeichert und der Benutzer muss die Pfade oder die Reihenfolge der Datenträger nicht ändern.

LVM-Volume-Gruppen werden auf entgegengesetzten Partitionen auf demselben Datenträger auf der Linux-Ziel-VM erstellt

Problem: In einem Linux-Workload mit mehreren LVM-Volume-Gruppen auf demselben Datenträger werden die LVM-Volume-Gruppen im Ziel-Workload in umgekehrter Reihenfolge angelegt. Wenn die Ursprungs-Volumes beispielsweise in der Reihenfolge AB angeordnet sind, lautet die Reihenfolge der Ziel-Volumes entsprechend BA. Dieses Problem tritt bei Ziel-Workloads unter Azure und VMware auf. (Bug 973227)

Behelfslösung: Die Reihenfolge der LVM-Volume-Gruppen wirkt sich nicht auf die Funktionsfähigkeit aus. Der Zielcomputer arbeitet wie erwartet.

Linux-Partitionen werden auf entgegengesetzten Partitionen auf demselben Datenträger auf der Linux-Ziel-VM erstellt

Problem: In einem Linux-Workload mit mehreren Linux-Partitionen auf demselben Datenträger werden die Partitionen im Ziel-Workload in umgekehrter Reihenfolge angelegt. Wenn die Ursprungspartitionen beispielsweise in der Reihenfolge AB angeordnet sind, lautet die Reihenfolge der Zielpartitionen entsprechend BA. Dieses Problem tritt bei Ziel-Workloads unter Azure und VMware auf. (Bug 970822)

Behelfslösung: Die Reihenfolge der Linux-Partitionen wirkt sich nicht auf die Funktionsfähigkeit aus. Der Zielcomputer arbeitet wie erwartet.

Übernahme bleibt mit der Meldung über eine VMware-vCDROM-Sperre im vSphere-Client hängen; manuelles Eingreifen des Benutzers erforderlich

Problem: Bei Linux-Ziel-Workloads in VMware-Containern bleibt die Übernahme hängen, sobald das Kopieren der Daten abgeschlossen ist und der Konfigurationsdienst gestartet wird. In der Weboberfläche wird die folgende Meldung angezeigt:

The ReconfigVM_Task submitted to VMware vCenter server failed: Connection control operation failed for disk ide0:0 (Fehler beim Ausführen der an den VMware-vCenter-Server gesendeten Methode „ReconfigVM_Task“: Verbindungskontrolle für Datenträger ide0:0 fehlgeschlagen)

Im vSphere-Client für die Zielumgebung werden Sie mit dem Dialogfeld „Virtual Machine Message“ (Virtueller Computer – Meldung) und dem Dialogfeld „Virtual Machine Question“ (Virtueller Computer – Frage) dazu aufgefordert, die CD-ROM-Sperre außer Kraft zu setzen. In der Weboberfläche bleibt die Übernahme so lange hängen, bis Sie die vCDROM-Sperre im vSphere-Client für die Zielumgebung manuell außer Kraft setzen.

Dieses Problem tritt nicht bei allen Linux-Ziel-Workloads und nicht bei allen VMware-Containerversionen auf. (Bug 975853)

Behelfslösung: Melden Sie sich beim vSphere-Client für die Zielumgebung an. Wenn Sie aufgefordert werden, die CD-ROM-Sperre außer Kraft zu setzen, wählen Sie Ja und klicken Sie auf OK.

Beim Konfigurieren des Betriebssystems für Linux-Ziel-Workloads mit dem Migrate-Client ist ggf. das manuelle Eingreifen des Benutzers erforderlich

Problem: Wenn Sie das Betriebssystem für Linux-Ziel-Workloads auf VMware-Containern mit dem Migrate-Client konfigurieren, reagiert der Migrate-Client unter Umständen nicht.

Im vSphere-Client für die Zielumgebung werden Sie mit dem Dialogfeld „Virtual Machine Message“ (Virtueller Computer – Meldung) und dem Dialogfeld „Virtual Machine Question“ (Virtueller Computer – Frage) dazu aufgefordert, die CD-ROM-Sperre außer Kraft zu setzen. Der Migrate-Client reagiert ggf. erst dann, wenn Sie die vCDROM-Sperre im vSphere-Client für die Zielumgebung manuell außer Kraft setzen.

Dieses Problem tritt nicht bei allen Linux-Ziel-Workloads und nicht bei allen VMware-Containerversionen auf. (Bug 975853)

Behelfslösung: Melden Sie sich beim vSphere-Client für die Zielumgebung an. Wenn Sie aufgefordert werden, die CD-ROM-Sperre außer Kraft zu setzen, wählen Sie Ja und klicken Sie auf OK.