Der vRealize Automation 8-Migrationsassistent weist die folgenden Einschränkungen für Bereitstellungen auf.

  • Die Migration einer Bereitstellung ist endgültig. Dabei spielt es keine Rolle, ob Sie erfolgreich verlaufen oder fehlgeschlagen ist. Sie können die Migration einer Bereitstellung nicht wiederholen. Sie können den vom Migrationsdienst erstellten Plan unter „Onboarding-Dienst“ erneut ausführen. Wenn Sie den Onboarding-Dienst erneut ausführen, werden Besitzer, Lease und Verlauf der Bereitstellung nicht migriert.
  • Historische Kosteninformationen werden nicht mit Bereitstellungen migriert. Weitere Informationen zur Preisgestaltung und zu den Kosten finden Sie unter Was sind Preisgestaltungskarten.
  • Wenn Sie bei Bereitstellungen mit bedarfsgesteuerten Netzwerken eine Bereitstellung mit einer von IPAM verwalteten IP migrieren und die migrierte Bereitstellung dann aus vRealize Automation 8 löschen, müssen Sie die zugehörige IP-Adresse ebenfalls manuell aus Infoblox löschen.
  • Nach der Migration auf vRealize Automation 8 werden alle IPAM-Informationen migriert. Tag-2-Vorgänge, wie z. B. das Löschen von Bereitstellungen, geben jedoch die IP-Adressen aus einem externen IPAM nur für Bereitstellungen mit externen Netzwerkprofilen frei. Sie müssen die IP-Adresse manuell aus IPAM für Bereitstellungen entfernen, die bedarfsgesteuerte Netzwerke enthalten. Um das Problem zu umgehen, können Sie ein Abonnement erstellen, um die IP aus IPAM zu entfernen.
  • Wenn Ihre Quellumgebung einen Lastausgleichsdienst enthält, der für ein vorhandenes Netzwerk konfiguriert ist, das nicht mit einer Maschine verbunden ist, wird das externe Netzwerk nicht migriert, und die IP wird während der Migration nicht zugeteilt.
  • Die Funktionalität „Bereitstellung aktualisieren“ funktioniert nur für Bereitstellungen, die Komponenten der vSphere-Maschine enthalten. Beim Ausführen einer Aktion vom Typ „Bereitstellung aktualisieren“ in Bereitstellungen, die andere Komponententypen (Netzwerke, AWS-Maschinen, Azure-Maschinen usw.) enthalten, wird der Versuch unternommen, die Bereitstellungskomponenten erneut zu erstellen.
  • vRealize Automation 7 erfasst keine Daten von Azure-Endpoints, und es kann nicht festgestellt werden, ob eine Azure-Maschine außerhalb von vRealize Automation 7 gelöscht wurde. Während der Migrationsbewertung in vRealize Automation 8 wird jede gelöschte Azure-Bereitstellung als „Bereit“ aufgelistet. Sie wird während der Migration jedoch ausgeschlossen, da der Migrationsassistent die VMs nicht finden kann.
  • Sie können eine Quellbereitstellung nicht migrieren, wenn sie gemischte Netzwerktypen aufweist, wie z. B. NAT-/Routennetzwerke in derselben Bereitstellung für NSX-T/NSX-V.
  • Quellbereitstellungen, die mehr als eine NSX Load Balancer-Komponente enthalten, werden nicht migriert.
  • Wenn Ihre Quellumgebung mehrere Bereitstellungen eines vorhandenen One-Arm-Load Balancers (bedarfsgesteuerter Lastausgleichsdienst mit vorhandenem Netzwerk) enthält, der aus demselben Blueprint auf NSX-T erstellt wurde, erstellt der Migrationsassistent nur einen Lastausgleichsdienst. Nur bei einer der migrierten Bereitstellungen wird die Load Balancer-Komponente aufgelistet. Alle anderen vorhandenen One-Arm-Load Balancer-Bereitstellungen verfügen nicht über die Load Balancer-Komponente.
  • Die für das NAT-Netzwerk in Ihren Quellbereitstellungen konfigurierte IP-Adresse wird nach der Migration nicht als zugewiesen markiert. Die IP-Adressen von migrierten Lastausgleichsdiensten und VMs werden jedoch unter Infrastruktur > Netzwerke > IP-Adresse nach der Migration als zugewiesen markiert.
  • Wenn Ihre vRealize Automation 7-Quellbereitstellung eine ungültige Ressource enthält, z. B. wenn sie keine Eigenschaften für eine Ressource enthält, wird die Ressource nicht migriert. Wenn alle Ressourcen in der Bereitstellung ungültig sind, wird die gesamte Bereitstellung nicht migriert.
  • Bei einer Brownfield-Migration werden sowohl die integrierten als auch die migrierten Maschinen nicht mit den Cloud-Zonen verknüpft. Dies führt dazu, dass diese Maschinen nicht in die Definitionen des maximalen Speichers eingerechnet werden.
  • Wenn Sie eine Bereitstellung mit einer einzelnen Maschinenkomponente und einer vorhandenen Netzwerkkomponente migrieren, erstellt vRealize Automation die vorhandene Maschine neu und schlägt mit dem Fehler „Subnetz ist erforderlich“ fehl.
  • Wenn Sie eine mit einer Cloud-Vorlage verknüpfte vSphere-Bereitstellung migrieren und die Cloud-Vorlage dann nach der Migration aktualisieren, schlägt die Bereitstellung fehl.
  • Wenn eine Bereitstellung DNAT-Regeln enthält, können Tag-2-Aktionen nach der Migration nicht neu konfiguriert werden.
  • Migrierte Clustermaschinen unterstützen keine vertikale bzw. horizontale Skalierung, wenn iterative Cloud-Vorlagenaktualisierungen auf die übergeordnete Bereitstellung angewendet werden.
  • Sie können geclusterte Bereitstellungen nur aus vRealize Automation 7.6-Quellumgebungen migrieren. Das Migrieren geclusterter Bereitstellungen wird für vRealize Automation 7.5-, 7.4- oder 7.3-Quellumgebungen nicht unterstützt.
  • Die Migration schlägt fehl, wenn eine Bereitstellung 2 VMs enthält, die für dasselbe einzelne Netzwerkprofil konfiguriert sind, aber zu unterschiedlichen Netzwerken gehören. Bevor Sie diese Bereitstellung migrieren können, müssen Sie die Netzwerke in vCenter manuell aktualisieren, indem Sie den Netzwerkadapter so ändern, dass er für beide VMs identisch ist. Die Enusre-Datenerfassung ist abgeschlossen und die VMs werden mit den geänderten Netzwerken in den Quellbereitstellungen aktualisiert.