Provisioning¶

Last updated on Jan 30 2025.

Inuvika OVD Enterprise 3.4 adds the ability to integrate your OVD Session Manager directly with your choice of virtualization platform. This can be on premise, hybrid, or cloud-based utilising both simple hypervisors such as Nutanix AHV, Proxmox, VMware vSphere, and Microsoft Hyper-V through to cloud providers such as Zadara, Microsoft Azure, Google Cloud Platform (GCP), and Amazon AWS.

This new functionality allows you to deploy both shared and dedicated OVD Application Server instances that run either Windows 10/11, Windows Server, or a Linux Server based operating system (Ubuntu 22.04/RHEL8) from a gold master template, or multiple templates curated for different use cases.

You can spin up and spin down on demand, plus there is the ability to set a working hours schedule where required.

How to enable Provisioning¶

Provisioning requires an additional role to be installed to allow it to be controlled from the Administration Console.

This can be installed on the OVD Session Manager via the OVD One Touch Installer (recommended), following the guidance on One Touch Installation, choosing the additional Provisioning Server option, and entering 127.0.0.1 when asked for the IP of the OVD Session Manager.

For a manual installation, please contact Inuvika Support.

Once Provisioning has been successfully installed and registered, you will now have a new Provisioning menu available in the Servers tab of the Administration Console.

This page allows you to configure Platforms - by this we mean your Hypervisor or Cloud Provider of choice.

The underlying technology used here is Terraform, so as long as the platform you wish to integrate has a Terraform Provider (see https://registry.terraform.io/browse/providers to search for yours), it can be added.

Adding a Platform¶

To add your platform (or platforms) to the Administration Console, navigate to Servers > Provisioning

Click the magnifying glass button which will load the Choose a Platform menu. We have included the most common hypervisors and cloud providers in this list which are fetched from an online service for easy configuration.

Note

When running OVD without internet access, an offline list is used, but it could be outdated.

Some additional files might be required from the Terraform registry in order to get the Provisoning functional.

For unlisted providers, you can either add this via the Advanced button by filling in the Terraform and Metadata sections, or you can contact the Inuvika Support Team, and we can add your platform to the supported list which will then preconfigure several fields within the Provisioning feature.

Choose your platform from the list, and you will be taken back to the Provisioning Tab now pre-filled with basic platform information.

Proceed to fill in your platform information, and click Test. If successful, you will get a confirmation message. This test only checks the syntax but not the connectivity to the platform.

Press Save.

What to do if the test fails?¶

If the test is unsuccessful, please check the details entered and try again

Note that all fields may be case sensitive depending on the platform used, and it is important that all spaces are included or excluded as required.

Linking your Platform to your OVD Provisioning Server¶

On the Provisioning tab, click Manage against your newly created platform.

Scroll down the page and you will see the OVD Provisioning Servers section

Usually, you will only see one server in this list. However, in a more complex environment, you may see multiple choices.

Click the Link button, which will ensure that your chosen Provisioning Server (usually the Session Manager) has permission to use and control the Platform you have added.

Now you have linked your Platform to your OVD Provisioning Server, we are ready to create our Gold Master image.

Gold Master Images¶

Important things to note:

OVD has no visibility or control over anything the Gold Master Image contains
OVD cannot perform the vm-to-template conversion (or vice-versa), so this has to be performed manually on your platform.
OVD expects your platform to be able to both create and destroy virtual machines in a reasonable time frame. If your platform is too slow, this may affect logon speeds if virtual machines cannot be deployed fast enough, where users are waiting for a VM to be deployed.
OVD does not control any networking, therefore your deployment network will need to use DHCP, and your Gold Master Image set to use DHCP instead of Static IP Addressing.

Creating your Gold Master Image¶

Deploy an OVD Application Server as per the guidance in the One Touch installation or Manual Installation Guide.

Give your VM a sensible name as this will be needed in the next step.

You should then proceed to install and configure all software that will be included with your Gold Master Image ahead of converting.

Next, you should register the OVD Application Server on the Administration Console. You can either Register or Register as a Template.

Register creates a standard Application Server which you have the option to convert to an OVD template, whereas Register as a Template skips the conversion step and automatically creates your new Application Server as a template.

Note

We would recommend using Register as a Template.

Once registered as a template, a new section will appear in Registered Servers named Provisioning Templates. Your new Application Server Template should show in this list as In Maintenance.

If using Windows 10/11/Server, you can now proceed to perform a Sysprep on your Application Server as per standard Microsoft guide. If using Ubuntu/RHEL, then perform any prep as required using cloud-init or similar.

Once your VM has been fully prepared, shut it down and convert it to a template directly on your chosen platform. OVD cannot perform this step for you.

Your new Application Server Template should now show in the Provisioning Templates list as In Maintenance.

Configuring Template Settings¶

Click into your newly created template from the Provisioning Templates list

In here, you can configure all the template specific settings related to deployment and general virtual machine function.

Below is a summary of all settings, explaining what each setting does.

Summary of Configuration Section¶

Display Name: Set a custom display name instead of the automatically generated name
RDP port for this server: If you are using a custom RDP port instead of 3389, please change this as required
Switch to Maintenance/Switch to Production: This allows you to take the template in and out of maintenance mode. When in maintenance mode, no automatic provisioning will take place.
Revert to Regular Server: You can convert an OVD Provisioning Template back to a standard OVD Application Server. Note that you must convert the template back to a VM, and ensure it is running on your chosen platform before a conversion is possible. Then set the correct IP address in the FQDN field.
Clone: Make a copy of the current template allowing additional customisation with different working hours or published groups, for example.
Delete: Remove this OVD Provisioning Template from your environment. Deletion cannot be undone and all dependant VM instances will be deleted during the top-of-the-hour collection.

Summary of Template Configuration Section¶

Deployment Mode: There are two options here:
- Shared, meaning an application server delivering application and desktop sessions to multiple users usually running Windows/Linux Server Operating Systems.
- Dedicated, meaning an application server for one user only for either an application or desktop-based session (commonly known as VDI) usually running Windows 10/11 but could also be Windows/Linux Server Operating Systems. Dedicated mode also enables Protected mode, which prevents the instance from being automatically deleted when unused.
Instance protected by default: It prevents the instance from being automatically deleted when unused. Instances assigned to user in Dedicated mode will never be automatically removed, regardless of this option.
Power-Save Idle Instances outside working hours: This option is available only if supported by the target platform. When enabled, OVD will shut down unused instances outside the defined working hours to save resources.
Power-Save Idle Instances inside working hours: This option is available only if supported by the target platform. When enabled, OVD will shut down unused instances inside the defined working hours to save resources.
Delete instance on logout (Dedicated mode): Instance is deleted when the linked session is finished.
Maximum Instances: The absolute maximum number of instances that OVD will provision from this template. This is a safe-guard feature to prevent over-provisioning.
Minimum available sessions outside working hours: Where working hours have been specified, OVD will ensure that there are enough instances to support the defined number of users outside of the defined working hours.
Minimum available sessions inside working hours: Where working hours have been specified, OVD will ensure that there are enough instances to support the defined number of users inside of the defined working hours.
Defined Working Hours Used in conjunction with the two settings above. This allows you to set a time window your business working hours to allow for different VM numbers based on a time schedule.
Apply Instantly: This button will apply the configuration changes immediately instead of waiting for the top-of-the-hour timer to apply them

Summary of Terraform Configuration Section¶

Platform: Choose which platform this template is accessible, and will be provisioned from
Virtual Machine Type: This will vary depending on your chosen platform. Some platforms allow for multiple different VM types, so please choose correctly based on your needs.
Advanced:
- Terraform: Allows you to customise the Terraform provider further to suit your needs if required. See Terraform for more information.
- Metadata: Allows you to customise the Terraform metadata further to suit your needs if required. See Metadata for more information.

Some dynamic parameters will show depending on what the Metadata field contains. They have different meaning depending on the platform or the type of VM created. For example, a Proxmox provider VM could look like:

Template Name: This is the name of the Gold Master Image template created in the previous step. Please enter this exactly as it is named.
VM Name Prefix: Customise the prefix that OVD will apply to virtual machines cloned from your template. The default machine name would be ovd-sum7skt for example, where the ovd- section is customisable.
Cores: Define how many Cores (vCPUs) your cloned instances will have
Memory: Define how much memory in MB your cloned instances will have

Summary of Instances section¶

New Instance on Demand: This allows you to create a new instance based on the configuration of the previous section instantly. Useful for testing
Rebuild Instances: Automatically rebuild your existing instances based on an updated Gold Master Template or where you have changed the Cores and Memory in the previous section, for example.

Summary of Role: Application Server - Access Parameters section¶

Current Access Policy: There are two options here:
- Open to All Users: This allows the provisioned instances to be accessed to all users as per their application group publishing rules.
- Restrict to Group Membership: Restricts the provisioned instances so they can only be accessed by the defined user groups regardless of application group publishing rules
Advanced Priority: Set to 0 as default. This is a weighted metric useful, for example, where you have multiple platforms accessible to the same users, but want to steer users to a primary platform first (through the use of multiple templates with different priorities set).
List of Server Groups including this server: Where server groups are in use, you can see what groups this template has been added to and add/remove it if needed.

Summary of Role: Application Server - Server Parameters section¶

Number of available sessions on this server: Defines the number of concurrent users (sessions) each instance will permit.
Activate Memory allocation enforcement: Where memory has been defined in Resource Restrictions, this setting guarantees that users will always have the memory their session requires. If the application server does not have sufficient free memory, the session will not be allowed to start.
Reserved System Memory: Allows you to set the amount of memory in MB that should be reserved for Operating System use to ensure performance.

Summary of Role: Application Server - Applications available on this server section¶

This shows a list of detected applications from the Start Menu (or equivalent folder) on the Gold Master Image

What needs to be set on the Template Configuration Page¶

You will need to go through and at a minimum set:

Template Configuration
- Choose a Deployment Mode
- Define working hours and instance limits (if required)
Terraform Configuration
- Check the Platform in use
- Set the Virtual Machine Type
- Set the Specific VM Type settings
Role: Application Server - Access Parameters
- Set the Current Access Policy
- Add to a server group (if required)
- Set the Number of available sessions on this server
- Set the Reserved System Memory

How to do Pooled Session Based Apps/Desktops¶

A pooled session-based desktop is where a user is allocated to an application server based on their group membership and/or access policy defined on the template. User profile data roams with the user, but any specific VM customizations will not follow them. This can be Desktop OS or Server OS based, and many users can connect at one time up to the defined limit.

To publish pooled session-based desktops¶

Choose Shared Deployment Mode
Set Number of available sessions on this server as appropriate based on resources
(somewhere 30-60 users is the recommended figure)

How to do Pooled One-to-One Desktops¶

A pooled one-to-one desktop is where a user is allocated to an application server based on their group membership and/or access policy defined on the template. User profile data roams with the user, but any specific VM customizations will not follow them. This can be Desktop OS or Server OS based, but only one user can use an instance defined this way at any point in time.

To publish pooled one-to-one desktops¶

Choose Shared Deployment Mode
Set Number of available sessions on this server to 1

How to do Non-Pooled (Persistent) One-to-One Desktops¶

A non-pooled (persistent) one-to-one desktop is where a user is allocated to their own instance, and it remains theirs until it is destroyed. When they log into OVD for the first time, the user will be automatically allocated and locked to a specific instance. Administrators can also manually assign users to instances by clicking inside the instance and setting the Assign to Specific User field. This can be Desktop OS or Server OS based, but only one user can use an instance defined this way at any point in time.

To publish non-pooled desktops¶

Choose Dedicated Deployment Mode

Note

Note that there is no requirement to publish any applications to your users. They will receive a desktop automatically.

Pushing your Template into Production Mode¶

Once you have made your changes, ensure you hit Change/Save as appropriate for the setting configured.

Then, at the top, click Switch to Production

Finally, press Apply Instantly which will trigger the Gold Master Image template to begin deploying on your Platform up to the defined limits.

You can now proceed to configure your Application Group to User Group publishing and any other configuration as per a standard OVD environment

Advanced configuration¶

Terraform¶

The Terraform field contains the equivalent of a .tf HCL file with some Jinja2 templating. The available template variables are defined in the associated Metadata field with some additional values.

For a Platform configuration, the fields contains:

ovd_backend: Is a configuration to add to the terraform {} structure in order to store the Terraform state and lock in the OVD Database.
hypervisor_name: The internal unique identifier given to this hypervisor.

For a Virtual Machine configuration, the fields contains all the parameters from the Platform configuration plus:

name: The unique internal name of this Virtual Machine, to be used as the Terraform resource ID (e.g. resource "aws_instance" "{{ name }}" {}).
server_type: windows or linux
server_version: The detected Operating System Details
server_hash: A big integer uniquely identifying the current server instance. This can be used as a seed for random host fencing.
counter: An incremental number defined for the template that starts from 1 and is reused, removing gaps.
initialization: Used to define template initialization sections set to true only for the first VM in the file.

Some additional Jinja2 filters are available in addition to the defaults:

b64decode: Decode a base64-encoded string and returns a binary data. Compose with str to render a string. E.g., name = "{{ name|b64decode|str|e }}"
b64encode: Encode a binary or string data to a base64 string. E.g., data = "{{ 'some value'|b64encode }}"
bool: Converts the value to an HCL boolean value. E.g. secure = {{ secure|bool }} results in either true or false
bytes: Convert to binary data. E.g., value = "{{ "data" | bytes }}"
e and escape: Are used to protect the String values in HCL syntax. E.g. name = "{{ name|e }}" correctly escape the quotes " and special characters like \n or \.
hash: Generate a hexadecimal-encoded hash of the data. Supported algorithms include: sha1, sha256, md5 and more. E.g. name = "{{ name|hash('sha256') }}" returns the sha256 of name.
hexdecode: Decode a hexadecimal-encoded string and returns a binary data. Compose with str or b64encode to render a string. E.g., data = "{{ '68656C6C6F'|hexdecode|str|e }}"
hexencode: Encode binary or string data to an hexadecimal-encoded string. E.g., data = "{{ 'some value'|hexencode }}"
str: Convert to a string. E.g., value = "{{ 34 | str }}"
tag: Convert the String to a lower case value containing only a-z, 0-9, and -. This is useful to generate predictable filenames or VM names. E.g. With name set to My New #Server, name = "{{ name|tag }}" results in my-new--server.
xmlescape: Escape XML/HTML strings. E.g., {{ '<a b="c">' | xmlescape }} results in <a b="c">

Metadata¶

The Metadata field allows to create custom UI elements in the OVD Administration Console to configure the Terraform Jinja2 template.

It is defined as a Json document containing a list of fields to display.

Each field is defined with a map containing:

id: The variable name
name: The caption to display in the Administration Console
type: The type of variable, one of text, password, integer, bool, select
defaultValue: The default value
values: (optional) lists all the possible values for a select field
required: (optional) true or false indicates if the field is required or not. Defaults to true.

Example:

[
    {
        "id": "image",
        "name": "Image Id",
        "type": "text",
        "defaultValue": "ami-"
    },
    {
        "id": "api_token",
        "name": "API Token",
        "type": "password"
    },
    {
        "id": "thin",
        "name": "Thin provisioning",
        "type": "bool",
        "defaultValue": true
    },
    {
        "id": "cores",
        "name": "Number of CPU Cores",
        "type": "integer",
        "defaultValue": 8
    },
    {
        "id": "tenancy",
        "name": "Tenancy of the instance",
        "type": "select",
        "values": ["dedicated", "default", "host"],
        "defaultValue": "default"
    }
]

How to stop Terraform deployment¶

Terraform deployment is a blocking action that may take some time to complete. In some cases, aborting the process may be necessary.

In the Provisioning page, under the Platform management section, an orange status indicator shows that the plaform is busy and which Ovd Agent is managing the action. You can click on Abort Execution to stop Terraform.

Warning

Stopping the pending action can leave your infrastructure in an inconsistent state. This might result in:

Partially applied changes.
Resources not being properly created, updated, or destroyed.
Terraform being locked.

Manual intervention may be required to fix the state, so unless absolutely necessary, it is recommended to allow the action to complete.