Horizon on Google Cloud VMware Engine Architecture

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Workspace ONE and Horizon solutions. This chapter provides information about architecting VMware Horizon on Google Cloud VMware Engine. 

This design is a small-scale consolidated design with all the Horizon components inside of each SDDC. This design will scale to a maximum of two SDDCs.

Introduction

VMware Horizon for Google Cloud VMware Engine (GCVE) delivers a seamlessly integrated hybrid cloud for virtual desktops and applications. It combines the enterprise capabilities of the VMware Software-Defined Data Center (SDDC), delivered as a service on Google Cloud Platform (GCP), with the market-leading capabilities of VMware Horizon for a simple, secure, and scalable solution. You can easily address use cases such as on-demand capacity, disaster recovery, and cloud co-location without buying additional data center resources.

For customers who are already familiar with Horizon or have Horizon deployed on-premises, deploying Horizon on Google Cloud VMware Engine lets you leverage a unified architecture and familiar tools. This means that you use the same expertise you know from VMware vSphere and Horizon for operational consistency and leverage the same rich feature set and flexibility you expect. By outsourcing the management of the vSphere platform to VMware, you can simplify management of Horizon deployments. For more information about Horizon for Google Cloud VMware Engine, visit Google Cloud VMware Engine.

Horizon on Google Cloud VMware Engine

Figure 1: Horizon on Google Cloud VMware Engine

The purpose of this design section is to provide a set of best practices on how to design and deploy Horizon on Google Cloud VMware Engine. This section is designed to be used in conjunction with Horizon documentation, Google Cloud VMware Engine documentation, and Google Cloud Platform documentation.

It is highly recommended that you review the design concepts covered in the Horizon Architecture chapter. This chapter builds on the Horizon Architecture chapter and only covers specific information for Horizon on Google Cloud VMware Engine.

Table 1: Horizon on Google Cloud VMware Engine Strategy

Decision

A Horizon deployment was designed and deployed on GCVE.

The environment was designed to be capable of scaling to 1,500 concurrent connections per SDDC for users.

Justification

This strategy allowed the design, deployment, and integration to be validated and documented.

Architectural Overview

The following figure shows the high-level logical architecture of the Horizon components in Google Cloud VMware Engine The current architecture locates all the management components inside the SDDC. There is a customer provided load-balancer that sits in GCP to forward protocol traffic into the SDDC.

Figure 2: Horizon on Google Cloud VMware Engine Logical Overview

Components

The individual server components used for Horizon, whether deployed on Google Cloud VMware Engine (GCVE) or on-premises, are the same. See the Components section in Horizon Architecture for details on the common server components.

The components and features that are specific to Horizon on GCVE are described in this section.

Software-Defined Data Centers

Google Cloud VMware Engine allows you to create vSphere Software-Defined Data Centers (SDDCs) on Google Cloud Platform (GCP). These SDDCs include VMware vCenter Serverfor VM management, VMware vSAN for storage, and VMware NSXfor networking. For reference, the SDDC construct is the same as the Google term Private Cloud.

You can connect an on-premises SDDC to a cloud SDDC and manage both from a single VMware vSphere Web Client interface. Review the VMware Engine Prerequisites document for more details on requirements.  You log in to https://console.cloud.google.com/ to access both your GCP and GCVE environments. For more information, see theGoogle Cloud VMware Engine documentation.

After you have deployed an SDDC on Google Cloud VMware Engine, you can deploy Horizon in that cloud environment just like you would in an on-premises vSphere environment. This enables Horizon customers to outsource the management of the SDDC infrastructure. There is no requirement to purchase new hardware, and you can choose between two pricing options for VMware Engine nodes:

  • On-demand pricing - Prices are based on your hourly usage in a particular region.
  • Commitment-based pricing - Prices are discounted in exchange for committing to continuously use VMware Engine nodes in a particular region for a one- or three-year term.

Management Component

The management components for the SDDC include vCenter Server and NSX-T. These components are managed by Google. Google will handle upgrades and maintenance of these components at the infrastructure level. The management interfaces are available to customers to manage vSphere and NSX-T.

Compute Component

The compute component includes the following Horizon infrastructure components:

  • Horizon Connection Servers
  • Unified Access Gateway appliances
  • App Volume Managers
  • Virtual Desktops
  • RDSH Hosts

Table 2: Compute components

Decision

Management servers were placed inside the SDDC.

Justification

Currently the Unified Access Gateway is not supported running on native GCP.

 

Resource Pools

A resource pool is a logical abstraction for flexible management of resources. Resource pools can be grouped into hierarchies and used to hierarchically partition available CPU and memory resources.

Within a Horizon pod on Google Cloud VMware Engine, you can use vSphere resource pools to separate management components from virtual desktops or published applications workloads to make sure resources are allocated correctly. 

After a Google Cloud VMware Engine SDDC is provisioned, two resource pools exist:

  • A Workload Resource Pool
  • HCX Management - Not in the scope of this Reference Architecture

When deploying both management and user resources in the same SDDC, it is recommended to create two sub-resource pools within the Workload Resource Pool for your Horizon deployments:

  • A Horizon Management Resource Pool for your Horizon management components, such as connection servers
  • A Horizon User Resource Pool for your desktop pools and published apps


Figure 3: Resource Pools for Horizon on Google Cloud VMware Engine

Scalability and Availability

Pod and Block

A key concept of Horizon, whether deployed on Google Cloud VMware Engine or on-premises is the use of blocks and pods. See the Pod and Block section in Horizon Architecture.

Table 3: Block and Pod Strategy

Decision

A single pod containing one resource block (one SDDC) was deployed.

Justification

In this small-scale design, all management components are inside of the SDDC. We are using a FQDN to directly connect to the POD.

Cloud Pod Architecture

Cloud Pod Architecture (CPA) is a standard Horizon feature that allows you to connect your Horizon deployment across multiple pods and sites for federated management. It can be used to scale up your deployment, to build hybrid cloud, and to provide redundancy for business continuity and disaster recovery. CPA introduces the concept of a global entitlement (GE) that spans the federation of multiple Horizon pods and sites. Any users or user groups belonging to the global entitlement are entitled to access virtual desktops and RDS published apps on multiple Horizon pods that are part of the CPA.

Important: CPA is not a stretched deployment; each Horizon pod is distinct and all Connection Servers belonging to each of the individual pods are required to be located in a single location and run on the same broadcast domain from a network perspective.

Here is a logical overview of a basic two site/ two pod CPA implementation. For Google Cloud VMware Engine, Site 1 and Site 2 might be different GCP regions, or Site 1 might be on-prem and Site 2 might be on Google Cloud VMware Engine.

Figure 4: Cloud Pod Architecture

For the full documentation on how to set up and configure CPA, refer to Administering View Cloud Pod Architecture in the Horizon documentation and the Cloud Pod Architecture section in Horizon Configuration.

In this design, because all management components are located inside the SDDC this can lead to protocol hair-pinning (shown in Figure 5). The user could be directed to either pod with a global entitlement. If the users’ resource is not in the SDDC they get directed to, they are directed back out via the NSX edge and directed to the other site. This causes reduction in scale due to this protocol hair-pinning. For this reason, we are not recommending the use of Horizon Cloud Pod with this design. 


Timeline

Description automatically generated

Figure 5: Horizon Protocol Traffic Hair-pinning

Table 4: Horizon on GCVE Solution Strategy

Decision

Cloud Pod Architecture was not used in this small-scale design.

Justification

The small-scale design locates the Unified Access Gateways inside the SDDC and can cause protocol traffic to hairpin through the wrong SDDC significantly reducing capacity.

Horizon Universal Broker

The Horizon Universal Broker is the cloud-based brokering technology used to manage and allocate virtual resources from multi-cloud assignments to end users. It allows users to access assignments by connecting to a fully qualified domain name (FQDN), which is defined in the Horizon Universal Broker configuration settings.

Currently the Universal Broker is not supported or available with Horizon on Google Cloud VMware Engine.

Table 5: Horizon on GCVE Solution Strategy

Decision

Universal Broker was not used.

Justification

Universal Broker is not currently supported with Horizon on GCVE.

Workspace ONE Access

Workspace ONE access can be used to broker Horizon resources. In this case the entitlements and resources are synched to Workspace ONE access and Workspace ONE access knows the FQDN of each POD to properly direct users to their desktop or application resources. 

For more design details, see Horizon and Workspace ONE Access Integration in the Platform Integration chapter.


Figure 6: Synching Horizon resources into Workspace ONE Access


Figure 7: Brokering into Horizon resources using Workspace ONE Access

Sizing Horizon on Google Cloud VMware Engine

Similar to deploying Horizon on-premises, you must size your requirements for deploying Horizon on Google Cloud VMware Engine to determine the number of hosts you will need to deploy. Hosts are needed for the following purposes:

  • Your virtual desktop or RDS workloads.
  • Your Horizon infrastructure components, such as connection servers, Unified Access Gateways, App Volumes managers.
  • SDDC infrastructure components on Google Cloud VMware Engine. These components are deployed and managed automatically for you by VMware, but you will need capacity in your SDDC for running them.

The methodology for sizing Horizon on Google Cloud VMware Engine is the same as for on-premises deployments. What is different (and simpler) is the fixed hardware configurations on Google Cloud VMware Engine.Work with your VMware sales team to determine the correct sizing.

At time of writing, the minimum number of hosts required per SDDC on Google Cloud VMware Engine for production use is 3 nodes (hosts).For testing purposes, a 1-node SDDC is also available. However, because a single node does not support HA, we do not recommend it for production use. Horizon can be deployed on a single-node SDDC or a multi-node SDDC. If you are deploying on a single-node SDDC, be sure to change the FTT policy setting on vSAN from 1 (default) to 0.

Network Configuration

When SDDCs are deployed on Google Cloud VMware Engine, NSX-T is used for network configuration.

The recommended network architecture consists of a double DMZ and a separation between Horizon management components and the RDSH and VDI virtual machines.

Figure 8: Network Diagram (Subnets are for Illustrative Purposes Only)

You must create segments in NSX-T to use within your SDDC – you will need the following segments. Review the NSX-T documentation for details.

 

VDI Segment with DHCP Enabled

 

  • Could also be for RDS applications
  • It is recommended to use a /22 subnet because it contains 1024 addresses and fits within the size of single SDDC

Management Segment (DHCP Optional)

  • Connection Servers
  • Unified Access Gateway - Deployed as two-NIC
  • App Volumes Managers
  • File Server
  • SQL Server
  • Workspace ONE Connector
  • Horizon Cloud Connector

Segment for Unified Access Gateway Internal DMZ

  • NIC 2 on each Unified Access Gateway

Segment for Unified Access Gateway External DMZ

  • NIC 1 on each Unified Access Gateway

Unified Access Gateway

Two Unified Access gateways should be deployed in a two-NIC (Double DMZ) configuration. See Two-NIC Deployment in the Unified Access Gateway Architecture chapter for details. 

In this configuration an internal and external DMZ segment should be created in GCVE with the following firewall rules:

  • Internal DMZ – Access to segments containing desktops, connection servers and DNS
  • External DMZ – Access to the segment in GCP containing the 3rd party Load Balancer used for forwarding Horizon protocol traffic.

Static routes might be needed on the Unified Access Gateway as follows:

  • Internal DMZ (NIC 2) – Static route to segments containing desktops and the connection servers.
  • External DMZ (NIC 1) – Static route to segments in GCP containing the third-party load balancer used for forwarding Horizon protocol traffic.

See Change Network Settings for details on setting static routes in Unified Access Gateway.

Load Balancing

A third-party load balancer is required in Google Cloud Platform to forward Horizon protocol traffic from the Internet into the UAGs inside each SDDC. There is no way to forward protocol traffic directly from the Internet into the SDDC. This will also allow for a highly available configuration for Horizon.

See GCVE configuration for more details.

See Load Balancing Unified Access Gateway in Horizon Architecture for details.

Table 6: Load Balancing Strategy

Decision

A third-party load balancer was used to load balance the Unified Access Gateways and App Volumes Managers.

NSX Advanced load balancer was used.

Justification

A load balancer enables the deployment of multiple management components, such as Unified Access Gateways, to allow scale and redundancy.

A third-party load balancer is required to route protocol traffic into the SDDC from GCP.

The NSX load balancer was used as it integrates with Google Cloud Platform for orchestration.

External Networking

When direct external access is required, configure a public IP address that will be forwarded with the GCP network load balancing forwarding rules to the load balancer. See Connection Server for details on how to do this.

For external management or access to external resources, create a VPN or direct connection within GCP, do this in the Networking | Hybrid connectivity section of the GCP console. See Google Cloud How-to guides for details.

Scaling Deployments

In this section, we will discuss scaling options for scaling out Horizon on GCVE. Following are the design decisions for a single SDDC and for two SDCC (max for this design).

Single SDDC

This is the design that we built this Reference Architecture from. This design is comprised of a single SDDC for up to 1,500 concurrent users. There will be a single FQDN (customer.desktops.com) bound to the Public IP address the third-party load balancer uses. Users will use this FQDN via the Horizon Client, HTML access or it will automatically be used with Workspace ONE Access integration.

Figure 9: Horizon connection flow with single SDDC

Figure 10: Logical Architecture for a single SDDC

Table 7: Connection Server Strategy

Decision

Two connection servers were deployed.

These ran on dedicated Windows 2019 VMs located in the internal network.

Justification

One connection server is recommended per 2,000 concurrent connections.

A second server provides redundancy and availability (n+1).

Table 8: Unified Access Gateway Strategy

Decision

Two standard-size Unified Access Gateway appliances were deployed as part of the Horizon solution.

These were located in the DMZ network.

Justification

UAG provides secure external access to internally hosted Horizon desktops and applications.

One standard UAG appliance is recommended for up to 2,000 concurrent Horizon connections.

A second UAG provides redundancy and availability (n+1).

Table 9: App Volumes Manager Strategy

Decision

Two App Volumes Managers were deployed.

Justification

App Volumes is used to deploy applications locally.

The two App Volumes Managers provide scale and redundancy.

The two App Volumes Managers are load balanced with the third-party load balancer in GCP.

Table 10: Horizon Cloud Connector Strategy

Decision

One Horizon Cloud Connector was deployed in licensing only mode.

Justification

To license the solution via subscription licensing.

Control plane services beyond licensing are not supported at this time.

Table 11: Workspace ONE Access Connector Strategy

Decision

One Workspace ONE Access connector was deployed.

Justification

To connect back to our Workspace ONE instance to integrate entitlements and allow for seamless brokering into desktops and applications.

Table 12: Dynamic Environment Manager Strategy

Decision

Dynamic Environment Manager (DEM) was deployed on the local file server.

Justification

This is used to provide customization / configuration of the Horizon desktops.

This location contains the Configuration and local Profile shares for DEM.

Table 13: SQL Server Strategy

Decision

A single SQL server was deployed.

Justification

This SQL server was used for the Horizon Events Database and App Volumes.

Figure 11: Single SDDC with Networking

Table 14: Load balancing strategy

Decision

A third-party load balancer was used to load balance the Unified Access Gateways and App Volumes Managers.

NSX Advanced load balancer was used.

Justification

A load balancer enables the deployment of multiple management components, such as Unified Access Gateways, to allow scale and redundancy.

A third-party load balancer is required to route protocol traffic into the SDDC from GCP.

The NSX load balancer was used as it integrates with Google Cloud Platform for orchestration.

Networking to On-Premises

Figure 12: GCVE Deployment with Networking to On-Premises

Table 15: Virtual Private Network Strategy

Decision

A Virtual Private Network (VPN) was established between GCP and our on-premises environment.

Justification

Allow for extension of on-premises services into the GCVE environment.

Table 16: Domain Controller Strategy

Decision

A single domain controller was deployed as a member of on-premises domain.

This domain controller is used as a DNS server for the SDDC.

Justification

A site was created to keep authentication traffic local to the site.

This allows Group Policy settings to be applied locally.

This allows for local DNS queries.

In the event of an issue with the local domain controller, authentication requests can traverse the VPN back to our on-premises domain controllers.

Table 17: File Server Strategy

Decision

A single file server was deployed with DFS-R replication to on-premises file servers.

Justification

General file services for the local site.

Allow the common DEM configuration data to be replicated to this site.

Keep the Profile data for DEM local to the site, with a backup to on-premises.

Multiple SDDC

As the current architecture for Horizon in Google Cloud VMware Engine places all the management components inside the SDDC, there are some considerations when scaling above a single SDDC. We support a maximum of two SDDCs in this design.

The current recommendation is that a Horizon pod, based in Google Cloud VMware Engine, should only contain a single SDDC. As mentioned earlier, each pod will have a dedicated FQDN for user access. For example, desktops1.company.com and desktops2.company.com. Each SDDC would have a dedicated external IP address that would tie to the FQDN. 

In this example, users are assigned an FQDN which they use to connect via the Horizon Client, HTML Access, or integration with Workspace ONE Access which would only show the users the items they are entitled to. It does not matter if the user is entitled to site1 or site2; they are automatically routed to the proper FQDN. They have the option of connecting via the Horizon Client or HTML Access.

Figure 13: Horizon connection flow for two SDDCs

 

Figure 14: Logical Architecture for Multiple SDDC

Figure 15: Multiple SDDC Deployment with Networking

The third-party load balancer would be used for both SDDCs. There would be two external IPs (VIPs) that would be tied to an external FQDN that users would connect to desktops / apps with. The two sites would be set up the same way.

Licensing

Enabling Horizon to run on Google Cloud VMware Engine requires two separate licenses: a capacity license for Google Cloud VMware Engine and a Horizon subscription license. 

For a POC or pilot deployment of Horizon on Google Cloud VMware Engine, you can use a temporary evaluation license or your existing perpetual license. However, to enable Horizon for production deployment on Google Cloud VMware Engine you must purchase a Horizon subscription license. To obtain a Horizon subscription license or for more information on how to upgrade your existing perpetual license to a subscription license and associated discounts, contact your VMware representative.

Licenses are available as Concurrent User or Named User, with the exception of Workspace ONE, which only offers Named User licensing.

You can use different licenses (including perpetual licenses) on different Horizon pods, regardless of whether the pods are connected by CPA.You cannot mix different licenses within a pod because each pod only takes one type of license.For example, you cannot use both a perpetual license and a subscription license for a single pod. You also cannot use both the Horizon Apps Universal Subscription license and the Horizon Universal Subscription license in a single pod.

Horizon Cloud Connector

Regardless of whether you are deploying Horizon on-premises or on Google Cloud VMware Engine, if you are using any of the subscription licenses, you must install the Horizon Cloud Connector to enable subscription license management for Horizon. The Horizon Cloud Connector is a virtual appliance that connects a Horizon pod with Horizon Cloud Service features.

Horizon control plane services beyond license management are not supported on GCVE at this time.

A MyVMware account from https://my.vmware.com is required for Horizon subscription license. After you purchase the subscription license, a record will be created in the Horizon Cloud Service using your MyVMware email address, and your subscription license information will be visible to the Horizon Administrator console.

As part of the subscription license fulfillment process, you will receive an email with a link to download the Horizon Cloud Connector as an OVA (open virtual appliance) file. Follow the instructions in the email to deploy the Cloud Connector, using the vSphere web client, alongside your new or existing Horizon pods. After the Cloud Connector is deployed, it is paired with a Connection Server in the Horizon pod, and this pod is connected to the Horizon Cloud Service. The Horizon Cloud Service manages the Horizon subscription license between connected Horizon pods.

Unlike the Horizon perpetual license, with a subscription license, you do not need to retrieve or manually enter a license key for Horizon product activation. However, supporting component license keys, such as the license keys for vSphere, App Volumes, and others, will be delivered separately, and the administrator must manually enter them to activate the product.

Review the Horizon documentation for more details on Enabling VMware Horizon for Subscription Licenses and Horizon Control Plane Services. You will need a separate Cloud Connector for each Horizon pod.

Preparing Active Directory

Horizon requires Active Directory services. For supported Active Directory Domain Services (AD DS) domain functional levels, see the VMware Knowledge Base (KB) article: Supported Operating Systems and MSFT Active Directory Domain Functional Levels for VMware Horizon 8 2006 (78652).

If you are deploying Horizon in a hybrid cloud environment by linking an on-premises environment with an GCVE Horizon pod, you should extend the on-premises Microsoft Active Directory (AD) to GCVE.

Although you could access on-premises active directory services and not locate new domain controllers in GCVE, this could introduce undesirable latency.

A site should be created in Active Directory Sites and Services and defined to the subnets containing the Domain Controller(s) in GCVE. This will keep the active directory services traffic local.

Table 18: Active Directory Strategy

Decision

Active Directory domain controllers were installed into GCVE.

Justification

Locating domain controllers in GCVE reduces latency for Active Directory queries, DNS and KMS.

 

Shared Content Library

Content Libraries are container objects for VM, vApp, and OVF templates and other types of files, such as templates, ISO images, text files, and so on. vSphere administrators can use the templates in the library to deploy virtual machines and vApps in the vSphere inventory. Sharing golden images across multiple vCenter Server instances, between multiple Google Cloud VMware Engine and/or on-premises SDDCs guarantees consistency, compliance, efficiency, and automation in deploying workloads at scale.

For more information, see Using Content Libraries in the vSphere Virtual Machine Administration guide in the VMware vSphere documentation.

Resource Sizing

Memory Reservations

Because physical memory cannot be shared between virtual machines, and because swapping or ballooning should be avoided at all costs, be sure to reserve all memory for all Horizon virtual machines, including management components, virtual desktops, and RDS hosts.

CPU Reservations

CPU reservations are shared when not used, and a reservation specifies the guaranteed minimum allocation for a virtual machine. For the management components, the reservations should equal the number of vCPUs times the CPU frequency. Any amount of CPU reservations not actively used by the management components will still be available for virtual desktops and RDS hosts when they are not deployed to a separate cluster.

Virtual Machine–Level Reservations

As well as setting a reservation on the resource pool, be sure to set a reservation at the virtual machine level. This ensures that any VMs that might later get added to the resource pool will not consume resources that are reserved and required for HA failover. These VM-level reservations do not remove the requirement for reservations on the resource pool. Because VM-level reservations are taken into account only when a VM is powered on, the reservation could be taken by other VMs when one VM is powered off temporarily.

Leveraging CPU Shares for Different Workloads

Because RDS hosts can facilitate more users per vCPU than virtual desktops can, a higher share should be given to them. When desktop VMs and RDS host VMs are run on the same cluster, the share allocation should be adjusted to ensure relative prioritization.

Deploying Desktops

With Horizon on Google Cloud VMware Engine both instant clones and full clones can be used. Instant clones, coupled with App Volumes and Dynamic Environment Manager helps accelerate the delivery of user-customized and fully personalized desktops.

Connection Server

When deploying the first Connection Server in the SDDC, make sure to choose “Google Cloud” as the deployment type. This sets the proper configuration and permissions on the Connection Server and Virtual Center.

Graphical user interface, text, application

Description automatically generated

Figure 16: Horizon Deployment Methods Option

At time of writing, Horizon 8 (2006) and Horizon 7.13 are supported on GCVE. For details, see the KB: VMware Horizon on Google Cloud VMware Engine (GCVE) Support (81922).

Instant Clones

Dramatically reduce infrastructure requirements while enhancing security by delivering a brand-new personalized desktop and application services to end users every time they log in:

  • Reap the economic benefits of stateless, non-persistent virtual desktops served up to date upon each login.
  • Deliver a pristine, high-performance personalized desktop every time a user logs in.
  • Improve security by destroying desktops every time a user logs out.
  • On the golden image VM, add the domain’s DNS to avoid customization failures.

When you install and configure Horizon for instant clone for deployment on Google Cloud VMware Engine, do the following:

CBRC is not supported or needed on Google Cloud VMware Engine. CBRC has not been disabled as of Horizon 8 (2006) in GCVE. Do NOT enable CBRC on vCenter when creating an Instant Clone Pool. You will see this message when creating an Instant Clone pool because CBRC is disabled on vCenter.

Figure 17: Warning about turning on View Storage Accelerator (CBRC)

Make sure to choose Ignore on this dialog message.

Multi-VLAN is not yet supported when creating Horizon instant-clone pools on Google Cloud VMware Engine.

For more information on Instant clones, see Instant Clone Smart Provisioning.

App Volumes

App Volumes provides real-time application delivery and management, for on-premises and now on Google Cloud VMware Engine:

  • Quickly provision applications at scale.
  • Dynamically attach applications to users, groups, or devices, even when users are already logged in to their desktop.
  • Provision, deliver, update, and retire applications in real time.
  • Provide a user-writable volume, allowing users to install applications that follow them across desktops.
  • Provide end users with quick access to a Windows workspace and applications, with a personalized and consistent experience across devices and locations.
  • Simplify end-user profile management by providing organizations with a single and scalable solution that leverages the existing infrastructure.
  • Speed up the login process by applying configuration and environment settings in an asynchronous process instead of all at login.
  • Provide a dynamic environment configuration, such as drive or printer mappings, when a user launches an application.

For design guidance, see App Volumes Architecture.

Transfer App Volumes from vSphere to Google Cloud VMware Engine

For migration or BCDR purposes, you can transfer your AppStacks or user-writable volumes from on-premises to the Google Cloud VMware Engine environment using your vSphere client in a two-step process.

From the vSphere Client:

  1. Create a VM with thin provisioning and attach the volume that you want to transfer to the VM.
  2. Select the VM and export it as an OVF template from File > Export to OVF Template.

From the Google Cloud VMware Engine web client:

  1. Click Actions > Deploy OVF Template.
  2. Follow the on-screen instructions and when prompted to select the storage format, select Thin provision.

After the VM is created, browse the datastore where the OVF was exported and move the VMDK file with its metadata to the cloudvolumes directory.

Ensure that you change the template location in the metadata file to point to the new datastore.

Dynamic Environment Manager

Use VMware Dynamic Environment Manager for application personalization and dynamic policy configuration across any virtual, physical, and cloud-based environment. Install and configure Dynamic Environment Manager on Google Cloud VMware Engine just like you would install it on-premises.

See Dynamic Environment Manager Architecture.

What’s Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.

 

Filter Tags

Horizon Horizon Document Reference Architecture Advanced Design Windows Delivery