本主题简要介绍了代理更新功能如何在 Horizon Cloud 中用于专用 VDI 桌面分配。
此概述既适用于分配，也适用于单个桌面。
系统定期与 Horizon Cloud CDS（组件下载服务）软件分发网络联系，以查看是否有新版本的 Horizon Agents Installer 可用。如果有，系统会自动将该版本下载到您的 Horizon Cloud 容器中。
在分配级别，下载新版本后，管理控制台中列出该分配的页面将指出有更新可用。对于具有的代理相关软件级别早于新版本的专用 VDI 桌面分配，将显示一个可视化指示器。
您可以选择专用 VDI 分配，然后启动代理更新向导以启动更新，如在“分配”页面上更新专用 VDI 桌面分配的代理软件和更新专用 VDI 桌面分配的单个桌面上的代理软件中所述的步骤。除了选择要用于更新的版本外，您还可以指定以下选项。
| 选项 | 描述 |
|---|---|
| 用户可用的虚拟机: | 仅当更新分配时（而在更新单个桌面时），才可使用用户 可用的虚拟机 选项。 使用此字段指定在更新期间可供用户使用的分配虚拟机百分比。该选项对于小型桌面分配非常有用，即桌面数少于 30 或 30 的倍数（如 60 或 90）。 由于系统默认分批更新桌面，每批 30 个桌面，如果分配具有 30 个或更少的桌面，所有桌面将同时启动更新过程。如果所有桌面均参与到更新过程中，则在更新过程完成之前，任何授权用户都无法建立到桌面的新连接。代理更新过程大约需要 30 分钟的时间，然后更新的桌面才能供最终用户连接。同样，如果桌面分配的桌面数大约为 60 个，默认每批 30 个将导致 50% 的桌面不可用。 因此，您可以使用此字段来确保小型池在系统检查并更新桌面时有较大比例的桌面可供使用。如果设置较高的可用性百分比，将导致对每批更新的虚拟机中的桌面数进行调整。 对于具有很多桌面的分配，该选项影响较小，因为系统的每批最大虚拟机数默认为 30 个，这在分配的桌面总数中占很小一部分。 |
| 以登录用户身份跳过虚拟机: | 让系统跳过更新具有登录用户（活动会话或断开连接的会话）或正在运行冲突任务的虚拟机。此设置可避免在相应桌面上启动更新过程时强制最终用户从该桌面中注销的系统默认行为。 |
| 启用回滚 | （可选）激活回滚后，系统会在执行代理更新之前创建回滚副本，并将该副本保留七天。如果虚拟机上的代理更新失败，您有机会在此七天期限内回滚到该虚拟机之前的代理版本。 注意： 虽然回滚时段默认设置为 7 天，但您可以请求 Horizon Cloud 支持人员为您更改此设置。 |
| 失败阈值 | 在停止更新过程之前允许代理更新失败的虚拟机的数量。这样可以防止发生大量故障。 默认值是您在设置>常规设置 中配置的值注意：当更新过程因虚拟机更新失败而停止时，您可能会发现失败虚拟机的数量高于您设置的阈值。出现此问题的原因有多种。对于多容器分配，发生这种情况的原因可能是系统按容器而不是按分配应用阈值设置。 |
| 重试跳过的虚拟机 和 作业超时 | 在让系统跳过更新具有登录用户的虚拟机或正在运行冲突任务的虚拟机时，您可以选择指定是否让系统自动重试更新任何跳过的虚拟机。在这种情况下，在系统浏览分配的桌面虚拟机并更新没有登录用户的虚拟机后，系统：
|
- 在向导的最后一步中提交更新任务后，系统将开始更新桌面。
-
每个桌面虚拟机上的更新过程都从预检检查开始，以确认虚拟机处于正常运行状态。这包括确认具有足够的磁盘空间（至少 300 MB 可用空间），以及没有正在进行中的 Microsoft Windows 更新，没有由于两次重新引导未清除 Windows 更新而挂起的重新引导，或者没有由于两次重新引导未清除 Horizon Cloud 特定的应用程序安装而挂起的重新引导。
-
进行更新时，系统会在分配或单个桌面级别并行更新一批虚拟机。默认情况下，系统在每一批中使用 30 个虚拟机，直到要更新的剩余虚拟机数少于 30 个。此时，将在最后一组中更新这些剩余的虚拟机。完全更新虚拟机大约需要 30-45 分钟的时间，但所需时间可能因负载和回滚选项启用与否而异。批次大小不能超过 30 个。如果分配具有 30 个或更少的桌面，将统一更新分配中的所有桌面。Horizon Cloud 支持人员可以根据您的请求调整批次大小。
在分配级别（而不是桌面级别）进行更新时，您可以配置 用户可用的虚拟机 文本框，以指定要打开电源并可供最终用户使用的分配桌面虚拟机百分比。正在进行的虚拟机数取决于您是否已指定在更新期间保持可用一定比例的虚拟机。设置可用性百分比时，系统会调整一组正在进行的虚拟机以满足可用性百分比要求。下表说明了一些示例。
注意： 在 监控 > 活动 页面上查看更新进度时，正在进行的虚拟机数量可能大于基于批次大小的预期数量。出现此问题的原因是，系统还会计算当前处于预检检查和回滚副本创建过程中的虚拟机数。
示例 描述 未设置用户 可用的虚拟机 （= 0%） 如果未设置可用性百分比，则可用性百分比为零，并且运行时批次大小为 30 个虚拟机（默认值）。如果分配具有 30 个或更少的桌面，则在一个批次中统一更新分配中的所有桌面。 分配具有 20 个桌面，并且 用户 可用的虚拟机 = 80% 如果分配具有 20 个桌面，并且要将 80% 的桌面保持可用，这意味着系统必须始终将 16 个桌面保持可用。在这种情况下，系统： - 在第一批中更新 4 个虚拟机（20 减去 16）。
- 将 4 个更新的虚拟机加上 12 个尚未更新的虚拟机保持 16 个可用，并在第二批中更新 4 个虚拟机。
- 此时，更新了 8 个虚拟机，还有 12 个尚未更新的虚拟机。系统继续分批更新尚未更新的虚拟机，每批 4 个虚拟机。对于每个后续批次，保持可用的虚拟机由更新的虚拟机和尚未更新的虚拟机组成。
分配具有 100 个桌面，并且 用户 可用的虚拟机 = 80% 如果分配具有 100 个桌面，并且要将 80% 的桌面保持可用，这意味着系统必须始终将 80 个桌面保持可用。在这种情况下，系统： - 在第一批中更新 20 个虚拟机（100 减去 80）。
- 将 20 个更新的虚拟机加上 60 个尚未更新的虚拟机保持 80 个可用，并在第二批中更新 20 个虚拟机。
- 此时，更新了 40 个虚拟机，还有 60 个尚未更新的虚拟机。系统继续分批更新尚未更新的虚拟机，每批 20 个虚拟机。
分配具有 100 个桌面，并且 用户 可用的虚拟机 = 25% 如果分配具有 100 个桌面，并且要将 25% 的桌面保持可用，则可以先更新剩下的 75 个虚拟机。在这种情况下，系统： - 在第一批中更新 30 个虚拟机（默认批次大小），剩下 70 个尚未更新的虚拟机。
- 在 70 个尚未更新的虚拟机中，在第二批中更新其中的 30 个虚拟机，即在总共 100 个桌面中更新了 60 个虚拟机，还有 40 个尚未更新的虚拟机。
- 现已更新了 60 个虚拟机，其中的 25 个更新的虚拟机可以满足 25% 可用性设置要求。因此，系统使用默认批次大小（30 个虚拟机），并更新剩余的 40 个尚未更新的虚拟机中的 30 个虚拟机。
- 系统更新剩余的虚拟机，在最后一批中更新 10 个虚拟机。
-
在代理更新过程结束时，分配的摘要页面将列出生效的 Horizon Agents Installer 版本。
在系统更新桌面期间，桌面的最终用户遇到以下行为：
- 如果桌面具有活动会话，并且未指定跳过具有活动用户的虚拟机，则会在开始更新前五分钟提醒该用户。此五分钟警告旨在让用户有时间保存任何正在进行的工作。
- 如果用户尝试登录到正在更新的桌面，登录将失败，并且用户会收到一条消息，指出该桌面还不可用。
您可以通过选择 监控>活动来查看更新任务的进度。任务说明会指出正在执行的更新以及正在对其执行更新的分配。如果任务未在 24 小时内成功完成，并且重试和作业超时选项无效，则更新任务将显示为失败状态。
如果在更新任务中跳过了任何虚拟机，则更新任务在“活动”页面上的状态为部分成功。在活动页面中，您可以查看在更新任务中跳过了多少个虚拟机。
- 如果“活动”页面即使在重试选项已激活的情况下，仍在更新任务结束时显示一些跳过的虚拟机，则说明 作业超时 值不够长，系统无法更新所有跳过的虚拟机，或者最终用户从未注销这些虚拟机。
- 如果出现预检检查错误（例如“正在进行 Windows 更新”（Windows updates in-progress）、“磁盘空间不足”（low disk space） 和“计算机有待重新引导”（reboot pending on machine），也可以跳过虚拟机。
对于由于任何原因而跳过的虚拟机，管理员可以稍后重试代理更新。
此页面对您有帮助吗?