Skip to content

Override Deployment Settings

In the latest release of the HyWorks Controller, a new option has been introduced to provide administrators greater control over VM cloning and re-composition processes. The new Override Server Defaults of VM distribution feature offers two sub-options to handle the distribution of VMs when recomposing a desktop pool or re-creating a VM. This feature aims to improve flexibility and reduce the likelihood of deployment failures by allowing administrators to choose between a fail-safe approach or a strict adherence to previous settings.

When administrators recompose a Desktop pool, the Override server defaults of VM distribution option determine how the VMs will be deployed according to the clone settings established during the initial pool creation. In some cases, changes to the environment, such as storage changes or node failures, may affect the viability of the initial clone settings. These options provide administrators with the flexibility to manage these changes more effectively.

The following are two Override Options that cater to different deployment needs:

  1. Last known settings with fail-safe

  2. Strictly use last known settings without fail-safe

These options allow the administrators to either ensure that the deployment follows the last known settings with a built-in safety check, or to strictly deploy VMs as per the last known settings, without considering any fail-safe mechanisms.

Understanding when and how to use these options will help ensure a more robust and reliable deployment process.

  1. Last known settings with fail-safe This option uses the last known deployment settings to clone or recompose virtual machines, while also introducing an additional fail-safe mechanism. When selected, the system first checks if the previous settings (used during the creation of the VM pool) are still valid. If these settings are still applicable and sufficient for the deployment, the machine is cloned or recomposed using those settings. However, if the previous settings are no longer suitable (e.g., due to changes in the environment or configuration), the system will automatically fall back to the new settings that have been defined by the administrator. This ensures that the deployment continues using the best available configuration, without requiring manual intervention, even if the previous settings have become outdated or incompatible.

Use Case

  • Administrators who want to ensure VM cloning or recomposing remains adaptable to configuration updates can rely on this fail-safe mechanism. If the environment changes (e.g., a node goes down or storage becomes unavailable), the system will first attempt to use the last known valid settings. If those settings are no longer viable, the system will automatically switch to the current settings provided by the administrator, ensuring the re-composition or cloning process succeeds with minimal disruption.

  • Strictly use last known settings without fail-safe This option completely bypasses any fail-safe mechanisms, strictly adhering to the last known deployment settings as defined during the pool's creation. There is no fallback to previous settings, or any system checks to verify whether the new environment is suitable for the deployment. While this approach ensures consistency in VM deployment based on the original configuration, it also increases the risk of failure if the environment has changed or if there are issues with resources such as storage or node availability.

Use Case:

  • This option is ideal for administrators who prefer a rigid, predictable deployment process and are confident that the original settings are still valid or that the environment is stable. It offers less flexibility but ensures that the deployment is carried out according to predefined configurations.

Example Scenario 1: Recomposition with Override server defaults of VM distribution

Let's walk through a practical example to better understand how the Override server defaults of VM distribution feature works, particularly when selecting the sub-options Last known settings with fail-safe and Strictly use last known settings without fail-safe during the recompositing process.

Initial Setup

  • Admin Action: When the administrator first creates the desktop pool, they choose the following deployment settings:

  • Datastore: Datastore-HyWorks-QA1

  • Cluster: HWQA-Pool

  • Sample log while cloning:

05-Nov-2024 03:29:30 PM RAVI-HW1 systemUser Info [Cloning desktop:'TEST-0001'] Selected Data store: Datastore-HyWorks-QA1 with used space in percentage: 9.05 and Datastore Status: green, selected resource pool: HWQA POOL, selected host: 10.7.0.6 with Host Status: green.
  • Result: The VMs are successfully cloned and deployed to the selected datastore (Datastore-HyWorks-QA1) and cluster (HWQA-Pool), as per the original deployment settings.

Example Scenario 2: Selecting Last known settings with fail-safe during recompose

  1. Admin Action: The administrator decides to recompose the desktop pool (perhaps to refresh VM configurations or apply updates).

  2. Admin selects: Override server defaults of VM distribution

  3. Sub-option chosen: Last known settings with fail-safe

  4. Additional Action: The administrator manually selects a different deployment configuration for this recompose:

    • Datastore: Datastore-HyWorks-QA2
    • Cluster: HWQA-Pool

  5. Recompose Process

  6. System Action: During the recompose process, the system first checks the previous deployment settings (i.e., the settings used when the pool was first created).

    • Datastore: Datastore-HyWorks-QA1 (original setting)
    • Cluster: HWQA-Pool (original setting)

  7. Fail-Safe Check: The system evaluates whether the original settings are still valid and can support the cloning operation. Specifically, it checks:

    • Available Storage Space: Does Datastore-HyWorks-QA1 have enough free space for the new VMs?
    • Node Availability: Are resources available in HWQA-Pool to support the VMs being cloned?

Outcome of the Fail-Safe Check

  • If the original settings (Datastore-HyWorks-QA1 and HWQA-Pool) are valid (i.e., sufficient space and available resources), the cloning will proceed using the original settings.
  • If any issues are detected (e.g., Datastore-HyWorks-QA1 has insufficient space or HWQA-Pool does not have enough available resources), the system will automatically fall back to the new settings manually selected by the administrator during the recompose:
    • New settings:
      • Datastore: Datastore-HyWorks-QA2
      • Cluster: HWQA-Pool

Example Outcome for Scenario 1

  1. If the original settings are valid: Datastore-HyWorks-QA1 has enough space, and HWQA-Pool has available resources, the system will proceed to deploy the VMs using the original settings (Datastore-HyWorks-QA1 and HWQA-Pool).
  2. If there is a resource issue: Such as, Datastore-HyWorks-QA1 is full or a node in HWQA-Pool is down, the system will fall back to the new settings selected by the administrator (i.e., Datastore-HyWorks-QA2 and HWQA-Pool).

Scenario 2: Selecting Strictly Use Last Known Settings Without Fail-Safe during Recompose

  1. Admin Action: The administrator decides to recompose the desktop pool, this time choosing not to apply any fail-safe checks.

    1. Admin selects: Override Server Defaults of VM Distribution
    2. Sub-option chosen: Strictly Use Last Known Settings Without Fail-Safe
    3. Additional Action: The administrator does not manually adjust the deployment configuration, so the system will continue to use the original settings as defined during pool creation:
      1. Datastore: Datastore-HyWorks-QA1
      2. Cluster: HWQA-Pool

  2. Recompose Process:

    1. The system will strictly adhere to the last known settings (i.e., Datastore-HyWorks-QA1 and HWQA-Pool), without performing any checks for the health or availability of the resources.
    2. If there is any issue with the selected datastore (e.g., insufficient space in Datastore-HyWorks-QA1), the recomposition will fail.
    3. The system will not attempt to use any alternative resources (e.g., Datastore-HyWorks-QA2), as this option bypasses the fail-safe mechanism entirely.
05-Nov-2024 03:29:30 PM RAVI-HW1 systemUser Info [Cloning desktop:'TEST-0001'] Selected Data store: Datastore-HyWorks-QA1 with used space in percentage: 9.05 and Datastore Status: green, selected resource pool: HWQA POOL, selected host: 10.7.0.6 with Host Status: green.
### Example Outcome for Scenario 2
  1. If there is enough space in Datastore-HyWorks-QA1, the recomposition will proceed and the VMs will be deployed as originally configured.
  2. If there is insufficient space or any other issue with Datastore-HyWorks-QA1, the recomposition will fail, and the administrator will need to resolve the issue manually.

Key Differences

  • Last known settings with fail-safe

    • The system checks whether the previously selected deployment settings (e.g., Datastore-HyWorks-QA1 and HWQA-Pool) are valid and sufficient.
    • If there is an issue with the previous settings (e.g., lack of space or unavailable resources), the system will use the new settings (i.e., Datastore-HyWorks-QA2 and HWQA-Pool), ensuring the recompose succeeds with a valid configuration.

  • Strictly use last known settings without fail-safe

    • The system strictly follows the previous deployment settings without performing any validation or fail-safes.
    • If there are issues with the previous settings (e.g., insufficient space), the recomposition will fail, and no alternative resources will be considered.