Intro

Virtual machines can now be created automatically by Flexxible|SUITE by using a Windows ISO image and other installable. These VMs may be:

• Servers for tenants (e.g. a file server, IIS server, etc.).

• Desktop templates ("Desktop template definitions"; they were named “Templates” in earlier versions).

• Application templates ("Application template definitions"): This new type of VM template is used to publish applications via XenApp or to start SDI ("Shared Desktop Infrastructure"; a user desktop session in an application server, which is shared with other desktop or application sessions).

This article describes the required settings to enable the VM creation in Flexxible|Platinum Appliance and Flexxible|Enterprise Appliance.

Paths

In case the Flexxible IT appliance is selected as a container for the new VM, three paths are needed to be specified In the "VDI appliance" details screen, to set up the storage for the new servers or templates created by Flexxible|SUITE:

• Desktop template definitions path.

• Applications template definitions path.

• Servers path.

These paths may have different formats:

• “F:\Templates”, “G:\Servers”, etc., if it is a Windows-based VDI appliance that is not part of a failover cluster.

• “C:\ClusterStorage\Disk-001\Templates”, etc., if it is a Windows-based VDI appliance that is part of a failover cluster.

• “ESXi01-datastore\templates”, etc., if it is a VDI appliance based on ESXi (VMWare).

To assess which VDI appliance will store a new virtual machine (server or template), Flexxible|SUITE will use an algorithm. If a VDI appliance does not have a VM type storage path specified, it will be discarded to host the new VMs of that type. E.g. If the storage path isn't set for servers, a new server won't' be stored in that appliance. 

Administrator users can see the selected HA hypervisor as a destination for the VM and to change it.

Settings

VMTempDiskPath

This is the path were temporary files are stored during VM creation. It can be a UNC path (DFS is not recommended) or a local path to the worker machines that create the VMs.

If you use local path, please, take in account that the path must exist in every worker machine, and the disk should have at least 20 GB of available storage. If it is a UNC path, keep 20 GB of available storage for each worker machine in your infrastructure, to allow for multiple, simultaneous creation of VMs in each worker.

Whenever possible, using a local path offers better performance and reduces chances of failures due to network communications.

Once the VM has been correctly created, the files in this path a deleted. If the creation fails, the files are preserved for a couple of hours, to help you diagnose the problem.

Settings that control the location algorithm for the new VMs

The algorithm considers the best HA hypervisor for locating the new VM to be whichever has the most CPU, RAM and storage resources available. To do this, it assesses the average CPU and RAM usage according to the VDI OS Manager log.

The HA hypervisors based on Windows 2008 R2 are excluded, as they do not support PowerShell, as well as some others that do not meet some minimum available resources.

These required resources are indicated by some settings in Flexxible|SUITE:

The algorithm assesses three components separately:

• CPU: 100 - % CPU usage; the less CPU used, the greater the score.

• RAM: available RAM; the more RAM available, the greater the score.

• Storage: available space; the more space available, the greater the score.

An overall score is calculated using these three factors and the HA hypervisor with the highest value is selected.

CPU, RAM, and storage are weighted so that the CPU is given the most importance, then RAM and finally storage. This weighting is based on the assumption that the lack of process capability (available CPU and RAM) highly affects performance and user experience.

Score = CPU + (RAM/5,000) + (Storage/80,000)

Network adapter names

This table contains the name given to the default network adapter when installing a particular Windows version and edition for a language. This information is required to configure the adapter during VM creation.

Although new records can be added to this table, it contains one for each version and edition of Windows (from Windows 7/Server 2008 to Windows 10/Server 2016) in any language.

OS definitions

This table contains information on the various Windows versions that may be installed in a new VM. It contains information such as:

• Windows internal version number.

• Windows type (server or desktop).

• Architecture (32 or 64 bits).

Although new OS definitions can be created in Flexxible|SUITE, the definitions for all versions of Windows (from Windows 7/Server 2008 to Windows 10/Server 2016) are supplied in any language.

OS editions

It provides the edition of each operating system and contains data such:

• Product key: it's required to activate Windows.

• Windows edition code: it's used when installing from a multi-edition ISO image.

• VMWare Guest ID: it's required when creating a new VM in vSphere. 

Each OS edition refers to an OS definition, meaning that several OS editions may refer to a single OS:

Although new OS editions can be created, all the Windows ones (from Windows 7/Server 2008 to Windows 10/Server 2016) are supplied.

OS images

This gives information on an OS ISO image, which includes:

• Architecture (32 or 64 bits).

• OS edition: It's the Windows edition contained in the image. If the ISO contains various editions, an OS image must be created for each one.

• Network adapter name: it's the name of the default network adapter. This is automatically informed by populating the Windows edition and UI language.

• ISO file path: it's the UNC path to the ".ISO" file.

• Last updates date: it's the date when the last Windows updates were installed in the ".ISO" file.

An OS image must be created for each ".ISO" file that will be used to create the VM or several may be used referring to the same file if it is a multi-edition ISO.

The synchronize infrastructure process, which is automatically and periodically run in VDI OS Manager, it checks that the ".ISO" files referred by the OS images are found at the indicated path. In case eight hours after it started no ".ISO" file is found, an email notification will be sent to the set accounts in the “HA_AlertRecipientTo” setting.

Windows updates

To avoid unnecessary costs, in regards to the processes and time to update Windows each time a new VM is created, Flexxible|SUITE assumes that Windows updates are already installed in the ".ISO" file.

To install Windows updates in an ".ISO" file, please follow the procedure given in Creating a Windows image with updates.

VM configuration scripts

These PowerShell scripts are used to configure new VMs, once Windows is installed. Or to install additional components, such as .NET Framework, VDI ClientService or Citrix Virtual Desktop Agent.

Each script is linked to the applicable OS definition. E.g. The script that installs the server VDA will only apply to the server type operating systems, not desktop.

Attributes:

• Desktop template, Application template, Server: they indicate whether the script applies or not to desktop template definition, application template definition or server creation.

• Auto Load for VMModels: if it is checked, the script will be automatically included, when creating a VM model of a type that script applies to (desktop template, application template, server), based on the applicable operating system.

• Execution Order Priority: it's the script run order. As they are automatically added to the VM model, they're numbered one by one.

Every time a new VM is created, the VM configuration scripts associated with the related VM model are compiled, sorted and included in the configuration script “c:\temp\VM_Setup.ps1”, which is run every time the VM starts up.

Some configuration scripts may cause the VM to reboot, in which case the “c:\temp\VM_Setup.ps1” script will be run again until all the configurations have been completed and the end of the script is reached. At this point, the script programming will be deleted on reboot.

When creating a new VM configuration script, a script “skeleton” should be followed. Each script first checks to see whether the setting or component has already been installed or configured. If not, the script installs and configures it. 

A list of the most necessary scripts is supplied by default (marked as “Is default”). These scripts cannot be modified. Although it is possible to develop new scripts for any necessary functionality or configuration. These scripts use installable, that should be located in "[ResourcesUNCPath] \Clients\scripts\UpdateVDA\Resources\Packages". E.g. They can be copied to the path "\\Sd.local\resources\Clients\scripts\UpdateVDA\Resources\Packages" by extracting them from the Packages.zip file, which is located on the drive ("VDI Appliance/Versions/3.1").

VM models

A VM model is like a pattern used to create the same type of VM repeatedly, with no need to specify all the features each time. For instance, a VM model can be defined to create a particular file server and then create some file servers for different Tenants from that VM model; or a server VM model for Office applications that can be used to create application template definitions for several tenants.

The VM model provides the following data:

Configuration

• Name: It's the name of the VM model, which is displayed when choosing a VM model to create a new VM.

• Type: It indicates the type of VM that this VM model will produce: Desktop template definition, Application template definition, or Server. When selecting this value, other fields on the screen are displayed or hidden, based on whether or not they are relevant.

• Administrator password: It's the password assigned to the local administrator of the new VM.

• OS image: It's the ISO image to be used to install the operating system on the new VM.

• Enable this VM model: if it is unchecked, this VM model will not be available to create a new VM, except for administrators. The idea is that administrators are able to enable that VM model by marking this checkbox, once the VM creation using it has been tested OK.

Hardware

• Num. Cores: It's the number of CPU cores to be assigned to the new VM. Values must be between 1 and 8.

• System Disk (Gigabytes): It's the size of the system disk (C:) in GB. Values between 5 and 500.

• RAM Type: only for templates, whether desktop or applications. Values: Dynamic, Static. For servers, this is always static.

• Startup RAM (MB): It's the RAM assigned to the VM on startup. If RAM type is dynamic, the memory can grow to the maximum defined. Values between 1,024 and 16,384.

• Minimum and Maximum RAM: it's only visible for templates, and if dynamic RAM is selected. Values between 1,024 and 16,384.

Additional Disks

List of additional disks (besides the C: system disk) to be created for the new VM. Please specify the drive letter, volume label, and size (values between 1 and 500 GB).

Inbound rules

Inbound rules that will be defined in the Windows firewall of the new VM. As well as the rules necessary for VDI OS operation, new rules can be created indicating a name, a protocol (TCP/UDP) and a port, port range or special name, for example: “8080”, “8080,8081”, “8080-8090”, ”RPC”.

Inbound groups

Default port groups that will be opened in the Windows firewall of the new VM. New inbound rule groups can be defined, but bear in mind that the Group Name may vary depending on the Windows version and language, so they are configured with an expression like “@FirewallAPI:dll,-34251”. 

To find the group name, please enable the firewall group in a Windows version similar to the new VM one (same version and language) and then use the following PowerShell command to view the enabled groups by showing the Group Name:

Get-NetFirewallRule | sort -unique Group | sort DisplayGroup | ft Group, displayGroup

For Windows 7 or Windows 2008, which do not support cmdLet Get-NetFirewWallRule, the same list can be viewed in the following Windows registry key:

HKLM\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

Please, keep in mind that the opening of firewall ports (inbound rules and inbound groups) applies when the VM has already been created and Windows installed, at the end of the VM creation process. If the installation or configuration of Windows or some other component requires some open ports, they must be configured via GPO. E.g. Windows Remote Management ports must be opened via GPO, to be applied immediately after booting up the VM for the first time, so that the machine creation can be completed successfully.

Templates

Only visible for templates (desktop or application):

• Virtual desktop type: If the VM model is a desktop template definition, the default virtual desktop type can be specified. This value will be copied to the new template.

• VDA Version: If the VM model is a template (desktop or application), this allows you to indicate the version of the VDA to be installed (using the appropriate VM configuration script). This value will be copied to the new template.

Configuration scripts

This list of VM configuration scripts will be run when creating a new VM from the VM model after installing Windows. Although some scripts can be automatically added to the list by selecting the VM model type and OS image, you are allowed to manually add or remove configuration scripts from this VM model or change their execution order. The “New” option in this list allows you to add a new VM configuration script to the end. Afterward, you can change the execution order with the arrows: