This topic is a high-level description of how the agent update capability works in Horizon Cloud for dedicated VDI desktop assignments.
This overview applies to both assignments and individual desktops.
The system makes regular contact with the Horizon Cloud CDS (Component Download Service) software distribution network to see if a new version of the Horizon Agents Installer is available. If so, the system automatically downloads that version to your Horizon Cloud pods.
At the assignment level, after a new version is downloaded, the administrative console's page on which that assignment is listed reflects that an update is available. A visual indicator is displayed for those dedicated VDI desktop assignments that have the agent-related software at a level prior to the new version.
You initiate the update by selecting the dedicated VDI assignment and starting the agent update wizard as described in the steps in Update Agent Software on the Assignments Page for Dedicated VDI Desktop Assignments and Update Agent Software on Individual Desktops for Dedicated VDI Desktop Assignments. Besides selecting the version to use for the update, you can specify the following options.
| Option | Description |
|---|---|
| Available VMs to Users | This Available VMs to Users option is available solely when updating assignments, not when updating individual desktops. Use this field to specify a percentage of the assignment's VMs to keep available for users during the update. This option is useful for a small-sized desktop assignment, with desktops fewer than 30 or a couple of multiples of 30 (like 60 or 90). Because the system updates the desktops in batches of 30 by default, if the assignment has 30 or less desktops, all the desktops will start the update process at the same time. If all the desktops are actively in the update process, none of the entitled users can make new connections to the desktops until the update process has completed. The agent update process takes approximately 30 minutes until the updated desktop is ready for an end-user connection. Similarly, in the case where the desktop assignment's desktops are around 60, the default batch of 30 results in 50% of the desktops being unavailable. Therefore, you can use this field to ensure that a greater percentage of a small-sized pool is available as the system goes through and updates the desktops. Setting a higher availability percentage results in an adjustment to the number of desktops in each batch of updating VMs. For an assignment with many desktops, this option has less effect because the system's maximum default 30 VMs per batch is a small percentage of the assignment's total number of desktops. |
| Skip VMs with Logged-in User | Have the system skip updating VMs that have a logged-in user (active or disconnected session) or a conflicting task running. This setting avoids the system's default behavior of forcing end users off their desktop when the update process starts on that desktop. |
| Enable Rollback | (Optional) When rollback is activated, the system creates a rollback copy before the agent update is performed and keeps that copy for seven days. If the agent update fails on a VM, you have an opportunity to roll back to the previous agent version for that VM during that seven-day window. Note: Although the rollback window is set at seven days by default, you can request that Horizon Cloud Support change this setting for you. |
| Failure Threshold | The number of VMs for which the agent update is allowed to fail before the update process is stopped. This prevents mass failures from occurring. The default value is the one you configured in Settings > General Settings Note: When the update process stops due to failed VM updates, you might observe a number of failed VMs that is higher than the threshold you set. This can occur for a variety of reasons. For multi-pod assignments, this can occur because the system applies the threshold setting per pod rather than per assignment. |
| Retry Skipped VMs and Job Timeout | When you have the system skip updating VMs that have a logged-in user or a conflicting task running, you can optionally specify whether to have the system automatically retry updating any skipped VMs. In this case, after the system has gone through the assignment's desktop VMs and updated those VMs without logged-in users, the system:
|
- After you submit the update task in the wizard's last step, the system begins updating the desktops.
-
The update process on each desktop VM begins with a preflight check to confirm that the VM is in a healthy state. This includes confirming that there is sufficient disk space (at least 300 MB free) and that there is no Microsoft Windows update actively in-progress, pending reboot due to a Windows update that is not cleared by two reboots, or pending reboot due to a Horizon Cloud specific application installation that is not cleared by two reboots.
-
When an update occurs, at the assignment or individual-desktop level, the system updates a batch of VMs in parallel. By default, the system uses 30 VMs for each batch until the remaining number of VMs to update is less than 30. At that point, that final set is for updating those remaining VMs. It takes approximately 30-45 minutes to fully update a VM, although the amount of time required can vary depending on the load and whether the rollback option is enabled or not. The batch size cannot be larger than 30. If the assignment has 30 or fewer desktops, all desktops in the assignment are updated together. Horizon Cloud Support can adjust the batch size if you request it.
When the update occurs at the assignment level, not at the desktop level, you can configure the Available VMs to Users text box to specify the percentage of desktop VMs in the assignment that you want powered on and available to end users. The number of in-progress VMs depends on whether you specified a percentage of the VMs to be kept available during the update. When you set an availability percentage, the system adjusts the set of in-progress VMs to meet the availability percentage. The following table illustrates some examples.
Note: When you view update progress on the Monitor > Activity page, the number of VMs in progress can be larger than the expected number based on the batch size. This occurs because the system is also counting VMs that are currently in the preflight check and rollback copy creation process.
Examples Description Available VMs to Users not set (= 0%) When you do not set an availability percentage, the availability percentage is zero and the run-time batch size is 30 VMs, the default. If the assignment has 30 or fewer desktops, all desktops in the assignment are updated together in one batch. Assignment has 20 desktops and Available VMs to Users = 80% With an assignment of 20 desktops, and you want 80% of them to be kept available, that means the system must keep 16 available at any time. In this case, the system: - First updates a batch of 4 VMs (20 minus 16).
- Counts the 4 updated VMs plus 12 not-yet-updated ones to keep 16 available, and updates a second batch of 4 VMs.
- At this point, 8 VMs are updated and 12 are not-yet-updated. The system continues updating the not-yet-updated VMs in batches of 4. With each subsequent batch, the ones kept available are a mixture of updated VMs and not-yet-updated VMs.
Assignment has 100 desktops and Available VMs to Users = 80% With an assignment of 100 desktops, and you want 80% of them to be kept available, that means the system must keep 80 available at any time. In this case, the system: - First updates a batch of 20 VMs (100 minus 80).
- Counts the 20 updated VMs plus 60 not-yet-updated ones to keep 80 available, and updates a second batch of 20 VMs.
- At this point, 40 VMs are updated and 60 are not-yet-updated. The system continues updating the not-yet-updated VMs in batches of 20.
Assignment has 100 desktops and Available VMs to Users = 25% With an assignment of 100 desktops, and you want 25% of them to be kept available, that leaves 75 VMs that can be updated first. In this case, the system: - First updates a batch of 30 VMs, which is its default batch size, leaving 70 not-yet-updated.
- Out of the 70 not-yet-updated, updates a second batch of 30 VMs out of that, to make 60 VMs updated and 40 VMs not-yet-updated from the 100 total number of desktops.
- Now that 60 VMs are updated, 25 of those updated VMs can meet the 25% availability setting. So the system uses its default 30 VM batch size and updates 30 VMs out of the remaining 40 not-yet-updated VMs.
- The system updates the remaining VMs, with 10 in this final batch.
-
At the end of the agent update process, the assignment's summary page lists the version of the Horizon Agents Installer that is in effect.
During the time the system is updating the desktops, the desktops' end users encounter the following behaviors:
- If a desktop has an active session and you did not specify skipping VM with active users, that user is warned five minutes before the update occurs. This five-minute warning is to give the user time to save any in-progress work.
- If a user attempts to log in to a desktop that is being updated, the login is unsuccessful and the user receives a message that the desktop is not yet available.
You can view the progress of the update task by selecting Monitor > Activity. The task description indicates the update being performed and the assignment on which it is being performed. If the task is not completed successfully within 24 hours, and the retry and job timeout options are not in effect, the update task is shown in failure status.
If any VMs are skipped in the update task, the update task has Partial Success status on the Activity page. In the Activity page, you can see how many VMs are skipped in the update task.
- If the Activity page shows a number of skipped VMs at the end of the update task even though the retry option was activated, either the Job Timeout value was not long enough for the system to get to all the skipped VMs or the end users never logged out of those VMs.
- VMs can also be skipped with preflight check errors such as “Windows updates in-progress”, “low disk space”, and "reboot pending on machine".
For VMs that were skipped for any reason, the administrator can retry the agent update later.
¿Le resultó útil esta página?