This page describes the key things to be aware of when migrating first-gen pods that are involved in multi-cloud assignments with other first-gen pods (multi-pod multi-cloud assignments).
Relationship between first-gen multi-cloud assignments and Horizon Cloud pool groups, and the first-gen pods and pools in those pool groups
In the migration process, each such assignment becomes a pool group in the Horizon Cloud environment.
When one of the pods from the multiple pods of a first-gen assignment is migrated to Horizon Cloud, the assignment becomes a pool group and that migrated pod's VMs become a pool (also called templates) associated with that Horizon Cloud pool group.
Treatment of power schedules - differences
In the first-gen assignments, you set power schedules on a per-pod basis in the assignment. For example, with two pods in an assignment, using the Horizon Cloud console you select one pod and click Add Power Management Schedule to set on the pod and then you select the other pod and click Add Power Management Schedule to set on that second pod.
In Horizon Cloud, the power schedule is set at the pool group level. The configured power schedule applies to the pool group overall, and all pools in the pool group receive the same power schedule.
During the first pod migration, the system creates pool groups in the Horizon Cloud environment for all of the multi-pod assignments that pod participates in, and the power schedules configured for that first pod on the first-gen side are migrated over to those pool groups.
Then when the next pod and subsequent pods are migrated, the power schedules that are configured for those pods on the first-gen side aren't migrated over to the Horizon Cloud pool groups. The pool groups' power schedules continue to reflect the schedules from the first migrated pod and remain unchanged in subsequent pod migrations.
Entitlement migration
If entitlements are added on the first-gen assignment during the time between one pod's migration and the next pod's migration, those entitlements are applied to Horizon Cloud pool group during the subsequent pod migration.
If an entitlement is removed from the first-gen assignment in between one pod's migration and the next pod's migration, those entitlements aren't removed from the Horizon Cloud pool group. You can manually remove those entitlements from the pool group.
Post-migration behaviors
After the migration on a pod is completed but not yet finalized, and that pod was one of multiple pods in first-gen assignments, administrators will observe the following system behaviors for the first-gen assignments that have a mixture of the non-finalized pod and unmigrated pods.
- Deleting such first-gen assignments is unsupported.
- Removal of pods from such assignments is unsupported.
- Although you can edit such assignments, any changes made to a migrated pod in the assignment aren't persisted.
- Running agent update on the first-gen side on the VMs from the migrated pod is unsupported.
End users will observe the following behaviors:
- Until the migrated pod is finalized, end users will still see their first-gen pod entitlements from that pod
- For a dedicated assignment, when the migrated pod is finalized, the end users assigned at the assignment level can still get unassigned desktops that are coming from the unmigrated pods in that first-gen assignment (if unassigned desktops are available from those pods).
Was this page helpful?