Step 3: Create Virtual Machines

Overview

Now that you have a functional Google Cloud project and core network services in place. The next step is to create the virtual machine resources needed to have a functional Citrix Cloud resource location. As described in the Reference Architecture: Citrix Virtualization on Google Cloud, a functional resource location requires the following:

  • Active Directory domain services

  • Citrix Cloud Connectors

  • One or more Citrix VDAs

Applying the Cloud Forward design pattern, these resources are deployed on virtual machine instances attached to a VPC. The virtual machine instances are deployed in a highly available manner by splitting between Google Cloud zones in the region. In this section of the guide, we provide additional information on Google Cloud resource and service types, followed by creating the virtual machine instances.

Google Cloud virtual machine resources Google Cloud provides reliable, high performance block storage for use by virtual machine instances. Block storage is presented to virtual machines as Persistent Disks. The persistent disks, available either as standard hard drive or solid-state drives (SSD). The persistent disks are durable network storage devices that your instance can access as though they were physical disks in a desktop or a server. Google Compute Engine instances by default have a single root persistent disk with an operating system. Extra disks can be added later for instances where applications require more local storage. The choices for disk expansion are Standard or SSD persistent disks, Local SSDs, and Cloud Storage Buckets. The Local SSD is not recommended for Citrix Virtual Apps deployment because data stored on the local SSD are temporary. The persistent disks are located independently from the virtual machine instances. You can choose to detach or move persistent disks to retain data even after the VM instance is deleted. The persistent disks performance scales automatically with size. You can resize the persistent disks or add more persistent disks to an instance to meet performance to storage space requirements. The persistent disk has no per I/O cost, so estimate the monthly I/O budget is unnecessary. SSD persistent disks have a read IOPS of 40,000 and write IOPS of 30,000 per instance. Compared to standard persistent disks, which only have a read IOPS of 3,000 and write IOPS of 15,000. The SSD persistent disk is recommended for deploying Citrix Virtual Apps workloads. When estimating storage capacity, remember that Virtual Apps and Desktops deployments have two storage needs: (1) storage for Virtual Apps servers and applications and (2) storage for user profiles. Deploying a Virtual Apps server master image requires 50 GB of storage which can vary based on installed applications and the Windows Server operating system version. For example, the Windows Server 2016 OS boot size is 50 GB while the Windows Server 2012 R2 is 32 GB. Citrix recommends creating a new Virtual Apps master image to minimize the required capacity instead of migrating an existing on-premise image.

On the Google Cloud, the service that runs virtual machine instances is referred to as the Google Compute Engine. Compute Engine offers predefined virtual machines configurations for every requirement. The offerings range from small micro instances to high memory and high CPU configurations. The following compute resources are relevant to any Virtual Apps deployment on GCP:

  • General purpose or Workload Optimized - you can choose between general purpose or workload optimized based on workloads requirments.

  • Predefined Machine Type – has a predefined number of vCPUs and memory and is charged at a set price described in the pricing page.

  • Custom Machine Type – provide the flexibility to configure the vCPU and memory for specific needs and potentially reducing the cost.

Microsoft licensing requires that the Citrix Virtual Desktop instances are not deployed in a non-Microsoft public cloud. You can implement Citrix Virtual Desktop on GCP by using either Sole Tenant Nodes (STNs) or Google Cloud VMware Engine (GCVE). STNs and GCVE are beyond the scope of this deployment guide.

Microsoft License Mobility enables the deployment of Windows Server applications (Citrix Virtual Apps), such as Remote Desktop Services (RDS), in GCP while using your existing Microsoft licenses. You are recommended to review your Microsoft licensing agreements with Microsoft before starting this deployment. Microsoft Windows Server instances require an internet network connection to activate with the GCP KMS host kms.windows.googlecloud.com. The standard grace period for Windows Server instances to register with the KMS host is 30 days. After 30 days, the instances will stop functioning. Alternatively, you can also bring your own Windows KMS licensing into GCP and host the required licenses. In this guide, we are not deploying a Microsoft RDS server. Instead, we are using the 30-days grace period for validation.

1 Create virtual machine instances

The Cloud Forward design pattern requires three different types of virtual machine instances to be deployed (Active Directory, Citrix Cloud Connector, Citrix VDA). Using the details in the table, repeat the steps outlined to create and start each virtual machine. Once complete, generate and store credentials to log in to each virtual machine instance the first time.

VM Type Compute Sizing VPC Network Google Zone Hostname IP Address Network Tags
Active Directory Domain #1 N1-Standard-2 Citrix Cloud Network us-west1-a dc1.ctx.lab 10.240.1.2 dc dns
Active Directory Domain #2 N1-Standard-2 Citrix Cloud Network us-west1-b dc2.ctx.lab 10.240.1.3 dc dns
Cloud Connector #1 N2-Standard-4 Citrix Cloud Network us-west1-a cc1.ctx.lab 10.240.1.4 cc
Cloud Connector #2 N2-Standard-4 Citrix Cloud Network us-west1-b cc2.ctx.lab 10.240.1.5 cc
Server VDA Master Image N2-Standard-4 Citrix Cloud Network us-west1-a mcs.ctx.lab Ephemeral (Automatic) vda
  1. Click the hamburger icon, located in the top left-hand corner of the Google Console

  2. Navigate to Compute Engine

  3. Click VM Instances

    vm-instances

  4. Click Create Instance

    vm-create-instances

  5. Input a name: dc1

  6. Select the region: us-west1

  7. Select the zone: us-west1-a

  8. Select the General-purpose tab

  9. Select N2 series

  10. Select n2-standard-2 (follow the corresponding compute sizing listed for each virtual machine in the table at the beginning of this section.)

    vm-dc1

  11. At Boot disk click Change

    vm-boot-disk

  12. Click Public Image tab

  13. Select Windows Server operating system

  14. Select Windows Server 2019 Datacenter (for this deployment we are using the evaluation license)

  15. Select Balanced persistent disk

  16. Provide the required size in GB: 50

  17. Click Select

    vm-public-images

  18. Expand the management, security, disks, networking, sole tenancy blade

    vm-blade

  19. Expand Networking section and input the corresponding virtual machine network tags: dc dns

  20. Input a host name as listed in the table at the beginning of this section: dc1.ctx.lab

    dc-dns-networking

  21. Select the network created in the Virtual Private Cloud section: citrixcloudnetwork

  22. The Subnetwork should auto populate

  23. Select Ephemeral IP Address (Custom) under the Primary internal IP section

  24. Input the IP Address 10.240.1.2 under the Custom ephemeral IP address

    Note

    The Server VDA master image requires the IP address to be assigned automatically. To allow the Server VDA master image to obtain an IP address automatically select Ephemeral (Automatic).

  25. Set the External IP to None

  26. Click Done

    dc-dns-network-interface

  27. Click Create

    dc-dns-network-interface-create

  28. Once the machine has been created and powered on, the next step is to create a default username and password.

    Note

    The Set Windows password function in Google Cloud sets/resets a strong password using the username you specify. If the account exists, it resets the password. If it does not, Google Cloud creates the user in the local security database of the Windows instance, then creates the password. The user Google Cloud creates (or updates) is a local administrator on the instance.

    There are multiple ways to access the Set Windows password function - here’s one of them, and it starts by clicking the VM instance to view instance details.

    vm-instances-view-details

  29. Under the VM instance details section, click Set Windows password

    vm-instances-details

  30. Input the username admin

  31. Click Set

    Note

    If during creation of the password you are prompted an error “Windows password could not be set. Try again. If you just created this instance, allow 10 minutes for it to be ready.”, we recommend allowing the suggested time before trying to create the password.

    vm-set-new-password

  32. By default, a unique new password is auto generated by Google Cloud and cannot be changed from the console. If a custom password is required, you need do the password change within the Windows operating system.

  33. You can either copy it down manually or Click on the copy icon. Store the password securely as it is required to log in to the virtual machine console in the upcoming section.

  34. Click Close

    vm-set-new-windows-password

    After following steps 1 through 35 to build each VM as indicated in the table at the beginning of this section. The results should be similar to the image:

    vm-instances-tabel-result

  35. If you are unable to view the Network tags column, click the column display option icon

  36. Select Network tags from the list

  37. Click OK

    vm-network-tags

Step 3: Create Virtual Machines