Upgrade scenarios for XenServer and Citrix Virtual Apps and Desktops

XenServer contains features and optimizations that make it an ideal hypervisor to use in your Citrix Virtual Apps and Desktops environment.

If you are using XenServer with Citrix Virtual Apps and Desktops, there are some considerations when performing your upgrade that are not covered in the main upgrade article: Upgrade from an existing version. Review both this article and the main upgrade article before starting your upgrade from Citrix Hypervisor 8.2 to XenServer 8.

Important:

If you use your Citrix Virtual Apps and Desktops license to license your Citrix Hypervisor 8.2 Cumulative Update 1 hosts, this license no longer applies to XenServer 8. You must instead get XenServer Premium Edition licenses to cover every CPU socket in your pool. For more information about getting a XenServer license, see the XenServer website.

XenServer is now an entitlement of the Citrix for Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP, and Citrix Platform License subscriptions for running your Citrix workloads. Read more.

Considerations when upgrading XenServer in a Citrix Virtual Apps and Desktops environment:

• XenServer hosts restart twice as part of an upgrade. At the beginning of the upgrade, you must boot your server into the installation media. At the end of the process, the installer restarts the server to complete the upgrade. VMs on these hosts must be either migrated or stopped during this time.
• The approach to use for upgrading XenServer depends on your XenServer environment, your Citrix Virtual Apps and Desktops environment, and the types of machines and applications being hosted by XenServer.
• You might be required to do some preparation in your Citrix Virtual Apps and Desktops environment before starting your XenServer upgrade.
• This article only covers use cases where the Citrix Virtual Apps and Desktops workload is hosted in the XenServer pool. Cases where you are also hosting parts of your Citrix Virtual Apps and Desktops infrastructure on VMs in the XenServer pool are not covered by this article. Factor these components in when doing your upgrade planning.
• Ensure that the version of Citrix Virtual Apps and Desktops you are using is supported for both the version of XenServer you are upgrading from and the version you are upgrading to. For more information, see Supported Hypervisors for Citrix Virtual Apps and Desktops (MCS) and Citrix Provisioning (PVS).
• The time it takes to do the upgrade and the potential for service outage depends on your upgrade approach. The full upgrade of an entire pool might take multiple hours to complete.
• This article assumes that the time to fully upgrade a single XenServer host is 35 minutes. This host upgrade time includes the upgrade process and any required restarts.

The approaches described in this article aim to guide you to an upgrade method that reduces the possibility of service outage and enables the upgrade process to fit within your maintenance window. However, in some cases, service outages are unavoidable. If the XenServer upgrade process cannot fit within your maintenance window, you can run your pool in mixed mode for a short time between maintenance windows. However, this is not recommended. For more information, see Mixed-mode pools.

During your planned XenServer upgrade maintenance window, follow these restrictions:

• Do not attempt to reconfigure the infrastructure of the pool that is being upgraded. For example, do not add or eject hosts from the pool.
• Do not add, start, or stop any VMs in the pool that is being upgraded.
• Do not perform catalog updates during the window.

Rolling Pool Upgrade

Rolling Pool Upgrade is a XenServer feature designed to make the upgrade process easier and to minimize downtime.

The Rolling Pool Upgrade wizard in XenCenter guides you through the upgrade procedure and organizes the upgrade path automatically. For pools, each of the servers in the pool is upgraded in turn, starting with the pool coordinator. Before starting an upgrade, the wizard conducts a series of prechecks. These prechecks ensure certain pool-wide features, such as high availability, are temporarily disabled and that each server in the pool is prepared for upgrade. Only one server is offline at a time. Any running VMs are automatically migrated off each server before the upgrade is installed on that server.

You can use Rolling Pool Upgrade for many of the Citrix Virtual Apps and Desktops use cases outlined in this article. For each, the upgrade time is the same: the number of hosts in the pool multiplied by the upgrade time for a single host. (N x 35 minutes). The potential for VM outage depends on your Citrix Virtual Apps and Desktops workload and XenServer pool setup.

Even if you intend to use Rolling Pool Upgrade to upgrade your XenServer pool, review the information for your specific environment to ensure that you understand the Citrix Virtual Apps and Desktops prerequisite actions, any special considerations, and the behavior to expect.

Use cases

This article identifies several broad use cases. For each of these use cases, we assume that the XenServer pool hosts only one type of Citrix Virtual Apps and Desktops workload. If your pool contains a mix of different types of workload, review all the cases that apply to your pool to decide what your preferred upgrade approach is.

First, consider how your XenServer environment is configured:

• XenServer pool with shared storage

  In a XenServer pool with one or more shared storage repositories (SRs), the VM disks can be hosted on this shared storage, which enables the VMs to migrate between hosts during the upgrade. This configuration can reduce or remove the need for VM downtime.

• XenServer pool without shared storage or a standalone host

  In a XenServer pool without shared storage or on a standalone XenServer host, the VMs can’t migrate during the upgrade process. When the host reboots as part of the upgrade, you must shut down the VMs.

XenServer pool with shared storage

If you are upgrading a pool where the VM disks are located on shared storage, you can evacuate VMs from each XenServer host in the pool while it is upgraded.

Most use cases on this type of pool can be upgraded by using Rolling Pool Upgrade. However, the prerequisite actions required in Citrix Virtual Apps and Desktops and the outage behavior is different depending on your workload.

Consider what type of Citrix Virtual Apps and Desktops workload is hosted in your pool:

• Unassigned single-session desktops

• Other workloads

XenServer pool without shared storage or a standalone host

If you are upgrading a pool where the VM disks are located on local storage or you have a single host in your pool, the VMs cannot be migrated off the XenServer hosts while they are upgraded. In these cases, the VMs must be shut down for the duration of the host or pool upgrade. Some outage to your virtual apps and desktops is unavoidable in these cases.

Consider what type of Citrix Virtual Apps and Desktops workload is hosted in your pool:

• Assigned desktops
• Other workloads

Case 1: Single-session desktops running on a pool with shared storage

This use case covers XenServer pools with shared storage whose primary workload is single-session virtual desktops with the random machine allocation type. Machines of this type must be managed by either Citrix Provisioning or by Machine Creation Services.

For any workload that is managed by Citrix Virtual Apps and Desktops, including those that are power managed by Citrix Provisioning and Machine Creation Services, you cannot maintain a complete workload while the upgrade is being performed. Power management of machines can be problematic during the upgrade process and you cannot disable power management without also disabling new session creation.

Recommended options for upgrade:

• Rolling Pool Upgrade
  • Estimated upgrade time: The number of hosts in the pool multiplied by the upgrade time for a single host. (N x 35 minutes)
  • Outage behavior: All machines are in Citrix Virtual Apps and Desktops maintenance mode for the entire upgrade time.

If possible, make the workload available from other XenServer pools with capacity during the upgrade of this pool. This approach might cause reduced capacity during the upgrade. If you do not have capacity for the workload on your other XenServer hosts and pools, we recommend that you declare an outage for all machines in your workload.

Rolling Pool Upgrade (1)

Review the steps and guidance in Before you start.

1. Put all the machines in the pool in maintenance mode. If all of the machines are using the same connection, you can put the entire machine catalog in maintenance mode.

2. Notify all impacted users of the impending outage.

   • If sessions are still running on the machines in this pool, ask users to log off or force their sessions to end.

   • Inform users that after they log off they can’t log in again until full service is resumed.

3. In XenCenter, start the Rolling Pool Upgrade wizard and choose automatic mode. For more information, see Rolling Pool Upgrade by using XenCenter.

   When the upgrade is complete, any VMs that were suspended as part of the Rolling Pool Upgrade are restarted.

4. Take the machines out of maintenance mode.

   New sessions can now be started and full service resumed.

Case 2: Other workloads running on a pool with shared storage

This use case covers XenServer pools with shared storage whose primary workload is either single-session virtual desktops with the assigned machine allocation type or multiple-session virtual applications with the random machine allocation type.

Recommended options for upgrade:

• Rolling Pool Upgrade
  • Estimated upgrade time: The number of hosts in the pool multiplied by the upgrade time for a single host. (N x 35 minutes)
  • Outage behavior: No service outage

Rolling Pool Upgrade (2)

Review the steps and guidance in Before you start.

1. Ensure that the pool has enough capacity to run your workload with one fewer host in the pool. During the upgrade process, each host is removed one at a time. The remaining hosts must be able to run all required VMs.

   If there is not enough capacity in the pool, some machines might not be available during the upgrade process. If possible, you can suspend any non-critical VMs during the upgrade process.

2. Ensure that all machines provided by the XenServer pool are powered on and are registered with Citrix Virtual Apps and Desktops in the relevant Delivery Groups.

   • For unmanaged machines:

     • Use XenCenter to confirm that all VMs are powered on.
     • Do not perform any manual power actions during the upgrade process.

   • For power-managed machines:

     • Ensure that all machines are powered on (by using XenCenter, Citrix Studio, or Web Studio).
     • To enable new sessions to start during the upgrade process:
       • Do not set the machines in maintenance mode.
       • Do not perform any manual power actions during the upgrade process.
       • Disable any power management schemes that might suspend machines.
       • Ensure that there are no other processes that might power off or suspend the machines.
     • If it’s acceptable for new sessions to be unable to start during the upgrade:
       • Put the hosting connection in maintenance mode. For more information, see Turn maintenance mode on or off for a connection.
       • Inform end users that if they log off they cannot reconnect for the time of the upgrade.

     For more information, see Power managed machines in a delivery group.

   • For machines managed by Machine Creation Services

     • Follow the same guidance as for power-managed machines in the preceding list item.
     • In addition, do not attempt to create new machines during the entire upgrade period.

3. In XenCenter, start the Rolling Pool Upgrade wizard and choose automatic mode. For more information, see Rolling Pool Upgrade by using XenCenter.

4. Restore your environment operations to their usual configuration.

   • Remove any maintenance mode flags set in earlier steps.
   • Revert any power management scheme adjustments made in the earlier steps.

Case 3: Assigned desktops running on a pool with local storage or on a standalone host

This use case covers XenServer standalone hosts or pools that do not have shared storage whose primary workload is either single-session virtual desktops with the assigned machine allocation type.

Recommended options for upgrade:

• Rolling Pool Upgrade Use RPU in automatic mode in a single maintenance window. This requires all users to have outage for the entire upgrade, but has a lower administration overhead for a pool
  • Estimated upgrade time: The number of hosts in the pool multiplied by the upgrade time for a single host. (N x 35 minutes)
  • Outage behavior: All machines are in Citrix Virtual Apps and Desktops maintenance mode for the entire upgrade time.
• Manual upgrade This mode provides the least outage for each user during the upgrade, but is more involved for the administrator
  • Estimated upgrade time: Two times the upgrade time for a single host. (Approximately 70 minutes)
  • Outage behavior: Each desktop is unavailable during the upgrade time for their individual host. This time is typically 35 minutes.

Rolling Pool Upgrade (3)

Review the steps and guidance in Before you start.

1. Put all delivery groups or catalogs that are providing machines from the pool into maintenance mode.

   While the machines are in maintenance mode, new sessions cannot be started on machines in the pool. Existing sessions are maintained until the machines are shut down or suspended.

   For more information, see Prevent users from connecting to a machine in a delivery group.

2. Notify all affected users of the impending outage. Provide a time by which they must end their sessions and indicate when service will be restored.

3. Check for remaining sessions on impacted machines and take appropriate actions for these sessions.

4. In XenCenter, start the Rolling Pool Upgrade wizard and choose automatic mode. For more information, see Rolling Pool Upgrade by using XenCenter.

   When the upgrade is complete, any VMs that were suspended as part of the Rolling Pool Upgrade are restarted.

5. Take the machines out of maintenance mode.

   New sessions can now be started and full service resumed.

Manual upgrade (3)

You can use this manual process to upgrade the pool coordinator first then all other hosts in parallel to reduce overall outage time significantly.

Note:

With the parallel upgrade approach, the risk profile changes. If there is an issue during the upgrade, it might not be detected until all hosts have been upgraded and are experiencing the issue. Whereas if you upgrade your hosts sequentially, you can verify that the upgrade is successful on each host before going on to the next.

Review the steps and guidance in Before you start.

1. Ensure that all machines provided by the XenServer pool or host are turned on and are registered with Citrix Virtual Apps and Desktops in the relevant delivery groups.

   • For unmanaged machines:

     • Use XenCenter to confirm that all VMs are powered on.
     • Do not perform any manual power actions during the upgrade process.

   • For power-managed machines:

     • Ensure that all machines are powered on (using XenCenter or Studio).
     • To enable new sessions to start during the upgrade process:
       • Do not set the machines in maintenance mode.
       • Do not perform any manual power actions during the upgrade process.
       • Disable any power management schemes that might suspend machines.
       • Ensure that there are no other processes that might power off or suspend the machines.
     • If it’s acceptable for new sessions to be unable to start during the upgrade:
       • Put the hosting connection in maintenance mode. For more information, see Turn maintenance mode on or off for a connection.
       • Inform end users that if they log off they cannot reconnect for the time of the upgrade.

     For more information, see Power managed machines in a delivery group.

   • For machines managed by Machine Creation Services

     • Follow the same guidance as for power-managed machines in the preceding list item.
     • In addition, do not attempt to create machines during the entire upgrade period.

2. Identify the pool coordinator and associated VMs.

3. Put the machines in the catalog on the pool coordinator host into maintenance mode.

4. Use Director, Citrix Studio, or Web Studio to send messages to users that are still connected to active sessions, warning them that their desktop is going offline for a period. This period is the upgrade time for this individual host (approximately 35 minutes).

5. Update the pool coordinator by using the xe CLI:

   1. Disable the pool coordinator. This prevents any new VMs from starting on or being migrated to the specified host.

      xe host-disable host=<uuid_or_name_label>
      

   2. Ensure that no VMs are running on the pool coordinator. Shut down, suspend, or migrate VMs to other hosts in the pool.

      • To shut down a VM, use the following command:

         xe vm-shutdown
        

      • To suspend a VM, use the following command:

         xe vm-suspend
        

      • To migrate a specific VM, use the following command:

         xe vm-migrate
        

        Migrating specified VMs to specified hosts gives you full control over the distribution of migrated VMs to other hosts in the pool.

      • To evacuate the host, use the following command:

         xe host-evacuate
        

        Evacuating all VMs from a host leaves the distribution of migrated VMs to XenServer.

   3. Shut down the pool coordinator.

      xe host-shutdown
      

      Important:

      You are unable to contact the pool coordinator until the upgrade of the pool coordinator is complete. Shutting down the pool coordinator causes the other hosts in the pool to enter emergency mode. Hosts can enter emergency mode when they in a pool whose pool coordinator has disappeared from the network and cannot be contacted after several attempts. VMs continue to run on hosts in emergency mode, but control operations are not available.

   4. Boot the pool coordinator using the XenServer installation media and method of your choice (such as, USB or network).

   5. Follow the XenServer installation procedure until the installer offers you the option to upgrade. Choose to upgrade.

      When your pool coordinator restarts, the other hosts in the pool leave emergency mode and normal service is restored after a few minutes.

   6. Start or resume any shutdown or suspended VMs.

   7. Migrate any VMs that you want back to the pool coordinator.

   If anything interrupts the upgrade of the pool coordinator or if the upgrade fails for any reason, do not attempt to proceed with the upgrade. Reboot the pool coordinator and restore to a working version.

6. After the pool coordinator is upgraded, take the machines on the pool coordinator out of maintenance mode in Citrix Studio or Web Studio.

7. Complete the following steps in parallel for all remaining hosts in the pool:

   1. Put the machines in the catalog on the host into maintenance mode.

   2. Use Director, Citrix Studio, or Web Studio to send messages to users that are still connected to active sessions, warning them that their desktop is going offline for a period. This period is the upgrade time for this individual host (approximately 35 minutes).

   3. Disable the host by using the xe CLI.

      xe host-disable host-selector=<host_selector_value>
      

   4. Ensure that no VMs are running on the host. Shut down, suspend, or migrate VMs to other hosts in the pool.

      • To shut down a VM, use the following command:

         xe vm-shutdown
        

      • To suspend a VM, use the following command:

         xe vm-suspend
        

      • To migrate a specific VM, use the following command:

         xe vm-migrate
        

        Migrating specified VMs to specified hosts gives you full control over the distribution of migrated VMs to other hosts in the pool.

      • To evacuate the host, use the following command:

         xe host-evacuate
        

        Evacuating all VMs from a host leaves the distribution of migrated VMs to XenServer.

   5. Shut down the host.

      xe host-shutdown
      

   6. Boot the host using the XenServer installation media and method of your choice (such as, USB or network).

   7. Follow the XenServer installation procedure until the installer offers you the option to upgrade. Choose to upgrade.

   8. After the host upgrade is complete, start or resume any shutdown or suspended VMs.

   9. Migrate any VMs that you want back to the host.

   If the upgrade of a subordinate host fails or is interrupted, you do not have to revert. Run the command xe host-forget in the pool to forget that host. Reinstall XenServer on the host, and then join it, as a new host, to the pool using the command xe pool-join.

8. After the XenServer hosts are updated, take the machines out of maintenance mode in Citrix Studio or Web Studio.

Case 4: Other workloads running on a pool with local storage or on a standalone host

This use case covers XenServer pools with shared storage whose primary workload is single-session virtual desktops or multiple-session virtual applications with the random machine allocation type.

For any workload that is managed by Citrix Virtual Apps and Desktops, including those that are power managed by Citrix Provisioning and Machine Creation Services, you cannot maintain a complete workload while the upgrade is being performed. Power management of machines can be problematic during the upgrade process and you cannot disable power management without also disabling new session creation.

Recommended options for upgrade:

• Rolling Pool Upgrade
  • Estimated upgrade time: The number of hosts in the pool multiplied by the upgrade time for a single host. (N x 35 minutes)
  • Outage behavior: All machines are in Citrix Virtual Apps and Desktops maintenance mode for the entire upgrade time.
• Manual upgrade
  • Estimated upgrade time: Two times the upgrade time for a single host. (Approximately 70 minutes)
  • Outage behavior: All machines are in Citrix Virtual Apps and Desktops maintenance mode for the entire upgrade time.

If possible, make the workload available from other XenServer pools with capacity during the upgrade of this pool. This approach might cause reduced capacity during the upgrade. If you do not have capacity for the workload on your other XenServer hosts and pools, we recommend that you declare an outage for all machines in your workload.

Rolling Pool Upgrade (4)

Review the steps and guidance in Before you start.

1. Put all the machines in the pool in maintenance mode. If all of the machines are using the same connection, you can put the entire machine catalog in maintenance mode.

2. Notify all impacted users of the impending outage.

   • If sessions are still running on the machines in this pool, ask users to log off or force their sessions to end.

   • Inform users that after they log off they can’t log in again until full service is resumed.

3. In XenCenter, start the Rolling Pool Upgrade wizard and choose automatic mode. For more information, see Rolling Pool Upgrade by using XenCenter.

   When the upgrade is complete, any VMs that were suspended as part of the Rolling Pool Upgrade are restarted.

4. Take the machines out of maintenance mode.

   New sessions can now be started and full service resumed.

Manual upgrade (4)

You can use this manual process to upgrade the pool coordinator first then all other hosts in parallel to reduce overall outage time significantly.

Note:

With the parallel upgrade approach, the risk profile changes. If there is an issue during the upgrade, it might not be detected until all hosts have been upgraded and are experiencing the issue. Whereas if you upgrade your hosts sequentially, you can verify that the upgrade is successful on each host before going on to the next.

Review the steps and guidance in Before you start.

1. Ensure that all machines provided by the XenServer pool or host are turned on and are registered with Citrix Virtual Apps and Desktops in the relevant delivery groups.

   • For unmanaged machines:

     • Use XenCenter to confirm that all VMs are powered on.
     • Do not perform any manual power actions during the upgrade process.

   • For power-managed machines:

     • Ensure that all machines are powered on (using XenCenter or Studio).
     • To enable new sessions to start during the upgrade process:
       • Do not set the machines in maintenance mode.
       • Do not perform any manual power actions during the upgrade process.
       • Disable any power management schemes that might suspend machines.
       • Ensure that there are no other processes that might power off or suspend the machines.
     • If it’s acceptable for new sessions to be unable to start during the upgrade:
       • Put the hosting connection in maintenance mode. For more information, see Turn maintenance mode on or off for a connection.
       • Inform end users that if they log off they cannot reconnect for the time of the upgrade.

     For more information, see Power managed machines in a delivery group.

   • For machines managed by Machine Creation Services

     • Follow the same guidance as for power-managed machines in the preceding list item.
     • In addition, do not attempt to create machines during the entire upgrade period.

2. Identify the pool coordinator and associated VMs.

3. Put the machines in the catalog on the pool coordinator host into maintenance mode.

4. Use Director, Citrix Studio, or Web Studio to send messages to users that are still connected to active sessions, warning them that their desktop is going offline for a period. This period is the upgrade time for this individual host (approximately 35 minutes).

5. Update the pool coordinator by using the xe CLI:

   1. Disable the pool coordinator. This prevents any new VMs from starting on or being migrated to the specified host.

      xe host-disable host=<uuid_or_name_label>
      

   2. Ensure that no VMs are running on the pool coordinator. Shut down, suspend, or migrate VMs to other hosts in the pool.

      • To shut down a VM, use the following command:

         xe vm-shutdown
        

      • To suspend a VM, use the following command:

         xe vm-suspend
        

      • To migrate a specific VM, use the following command:

         xe vm-migrate
        

        Migrating specified VMs to specified hosts gives you full control over the distribution of migrated VMs to other hosts in the pool.

      • To evacuate the host, use the following command:

         xe host-evacuate
        

        Evacuating all VMs from a host leaves the distribution of migrated VMs to XenServer.

   3. Shut down the pool coordinator.

      xe host-shutdown
      

      Important:

      You are unable to contact the pool coordinator until the upgrade of the pool coordinator is complete. Shutting down the pool coordinator causes the other hosts in the pool to enter emergency mode. Hosts can enter emergency mode when they in a pool whose pool coordinator has disappeared from the network and cannot be contacted after several attempts. VMs continue to run on hosts in emergency mode, but control operations are not available.

   4. Boot the pool coordinator using the XenServer installation media and method of your choice (such as, USB or network).

   5. Follow the XenServer installation procedure until the installer offers you the option to upgrade. Choose to upgrade.

      When your pool coordinator restarts, the other hosts in the pool leave emergency mode and normal service is restored after a few minutes.

   6. Start or resume any shutdown or suspended VMs.

   7. Migrate any VMs that you want back to the pool coordinator.

   If anything interrupts the upgrade of the pool coordinator or if the upgrade fails for any reason, do not attempt to proceed with the upgrade. Reboot the pool coordinator and restore to a working version.

6. After the pool coordinator is upgraded, take the machines on the pool coordinator out of maintenance mode in Citrix Studio or Web Studio.

7. Complete the following steps in parallel for all remaining hosts in the pool:

   1. Put the machines in the catalog on the host into maintenance mode.

   2. Use Director, Citrix Studio, or Web Studio to send messages to users that are still connected to active sessions, warning them that their desktop is going offline for a period. This period is the upgrade time for this individual host (approximately 35 minutes).

   3. Disable the host by using the xe CLI.

      xe host-disable host-selector=<host_selector_value>
      

   4. Ensure that no VMs are running on the host. Shut down, suspend, or migrate VMs to other hosts in the pool.

      • To shut down a VM, use the following command:

         xe vm-shutdown
        

      • To suspend a VM, use the following command:

         xe vm-suspend
        

      • To migrate a specific VM, use the following command:

         xe vm-migrate
        

        Migrating specified VMs to specified hosts gives you full control over the distribution of migrated VMs to other hosts in the pool.

      • To evacuate the host, use the following command:

         xe host-evacuate
        

        Evacuating all VMs from a host leaves the distribution of migrated VMs to XenServer.

   5. Shut down the host.

      xe host-shutdown
      

   6. Boot the host using the XenServer installation media and method of your choice (such as, USB or network).

   7. Follow the XenServer installation procedure until the installer offers you the option to upgrade. Choose to upgrade.

   8. After the host upgrade is complete, start or resume any shutdown or suspended VMs.

   9. Migrate any VMs that you want back to the host.

   If the upgrade of a subordinate host fails or is interrupted, you do not have to revert. Run the command xe host-forget in the pool to forget that host. Reinstall XenServer on the host, and then join it, as a new host, to the pool using the command xe pool-join.

8. After the XenServer hosts are updated, take the machines out of maintenance mode in Citrix Studio or Web Studio.

Mixed-mode pools

A mixed-mode pool is one where hosts in the pool are using different versions of XenServer. Do not operate your pool in mixed-mode (with multiple versions of XenServer) for longer than necessary, as the pool operates in a degraded state during upgrade. In this degraded state, certain VM, SR, VDI, and host operations are blocked. VMs that have run on a host at the higher version of XenServer cannot be migrated to or started on a host at the lower version of XenServer.

Mixed-mode pools are not supported for standard usage and are only supported as a transitional state during the upgrade of a pool. If you experience an issue while running in mixed mode, Technical Support will ask you to complete your pool upgrade and then reproduce the issue in a non-mixed pool.

After reviewing the upgrade options for your Citrix Virtual Apps and Desktops environment, your planned XenServer upgrade path might take longer than the available maintenance window. If possible, extend the maintenance window to enable your XenServer upgrade to complete within it. If this is not possible, you can choose to run the pool in mixed mode until your next maintenance window. However, running your pool in mixed mode increases the likelihood of unexpected behaviors or issues that might cause you to need an emergency maintenance window instead. Plan to minimize the time your pool spends in mixed mode.

If your Citrix Virtual Apps and Desktops environment is running temporarily on top of a mixed-mode XenServer pool, be aware of the following behaviors:

• For Pooled Desktop workloads that require the VMs to restart before they are reused, the VMs are restarted only on the hosts that are running the newer version of XenServer. The effective capacity of the pool is restricted. Depending on how many of the hosts in your pool have been upgraded, there might be insufficient capacity for all required VMs to be restarted. This behavior can result in failures and some Citrix Virtual Apps and Desktops users might not be able to access their required sessions.

• If you have dedicated machines using local storage that are located on hosts running the older version of XenServer, these VMs can be stopped, but they cannot be restarted until the upgrade is complete and the pool is no longer in mixed mode.