Workload Balancing Errors - When troubleshooting Workload Balancing, begin by reviewing the available logs. These include the Workload Balancing log and XenCenter logs - http://support.citrix.com/article/CTX124479
Workload Balancing Stops Working - If Workload Balancing does not allow you to view optimization recommendations, or save changes to settings or star ratings, it is usually because of a virtual machine failure that appears as:
- A stop error due to the failure of a Windows virtual machine.
- An unresponsive console or failed shutdown of a Linux virtual machine.
Check the Workload Balancing log file for the following error message:
"dwmdatacolsvc.exe: Don't have a valid pool. Trying again in 10 minutes."
To correct this error:
- Force the virtual machine to shut down.
- Migrate all of the virtual machines to another XenServer host, then run the following command:
xe-toolstack-restart
For more information see Citrix XenServer Workload Balancing Administrator's Guide - http://support.citrix.com/article/CTX127330
Workload Balancing New Server Errors - If you change the Workload Balancing server that a resource pool references without first removing the Workload Balancing configuration on the resource pool, Workload Balancing will fail to monitor the resource pool properly. If this occurs, you can either uninstall the old Workload Balancing server or manually stop the Workload Balancing services (analysis, data collector, and Web service) to ensure that it will no longer monitor the resource pool. For the reasons stated above, Citrix does not recommend using the following command to change the Workload Balancing servers: pool-initialize-wlb XE
Trunked Network Switches - When NICs are bound together to form a NIC bond in XenServer, bandwidth is aggregated and load-balanced across the pair. However, bandwidth must be available for the backend network switch environment if the NICs are connected to trunked network switches. Trunked network switches provide redundancy and allow for separation of network traffic into several subnets. If NICs are connected across separate trunked network switches, the ability to aggregate bandwidth can affect the communication between the two switches and cause network congestion. Trunked network switches do not support as much bandwidth as a single-switch fabric.

VLANs - XenServer supports the use of multiple VLANs to mapped physical network interfaces on the host server. When creating a network, an engineer must properly configure the VLAN tag for the virtual NIC in XenServer to correspond with the VLANs on the physical switches. If a virtual machine attempts to start or résume and that action causes the resource pool to become overcommitted, a warning alert is triggered. The alert is displayed in XenCenter and can also be configured to be displayed in the Xen API or sent as an e-mail.
XenMotion - XenMotion is the name for XenServer live migration and allows for active virtual machines to dynamically move between XenServer hosts with little downtime.
Issues might occur when:
- The processor vendor on the XenServer host joining the resource pool is not the same as the processor vendors on the hosts already in the resource pool. To overcome this problem Citrix supports heterogeneous resource pools. Refer to the XenServer hardware compatibility list (HCL - http://hcl.vmd.citrix.com/) for details on mixing processor models.
- The XenServer host joining the resource pool is running a different XenServer software version than the hosts already in the resource pool.

Processor Affinity - The process of assigning a specific processing core on a XenServer host to a virtual machine is known as processor affinity. There are certain use cases for processor affinity, but it should be avoided if possible. Assigning a virtual machine to a processor on the host can affect the utilization of resources and make it a less dynamic system. Virtual machines with processor affinity configured cannot be moved between XenServer hosts using XenMotion.

Virtual Machine Templates - Before a virtual machine is converted into a XenServer template, Sysprep should be used to prepare the template for quick virtual machine deployment. Running the Sysprep tool ensures that each cloned virtual machine has a unique machine identifier. Sysprep assigns the following unique system elements to a virtual machine:
- Computer name
- Security Identifier (SID)
- Globally Unique Identifier (GUID)
- Driver cache
Some applications installed on a system prior to using Sysprep exhibit undesired behaviors after the cloning process. Testing the Sysprep process with the operating systems and applications used in production is recommended to ensure expected results.
Storage - You can provide either the hostname of the IP address of the NFS server when creating an NFS storage repository. Issues might arise if DNS is not properly configured and the hostname of the server is used. If the NFS storage repository (SR) has problems connecting to the NFS server, you should verify that DNS is configured correctly. If DNS is not reliable, then the IP address of the NFS server should be used instead of the FQDN. All XenServer hosts in a resource pool must be able to communicate with the shared storage, otherwise issues could arise when using XenMotion.
Resource Pool Overcommitment - Resource pool overcommitment occurs when a host server fails and the virtual machines running on that host server cannot be restarted elsewhere. A resource pool can become overcommitted if:
* A failover plan cannot be found.
* There is not enough free memory across the resource pool to run all of the virtual machines following a failure.
* Changes were made to Virtual Block Devices (VBDs) and networks, which affect the host servers where the virtual machines will be relocated.
If a virtual machine attempts to start or résume and that action causes the resource pool to become overcommitted, a warning alert is triggered. The alert is displayed in XenCenter and can also be configured to be displayed in the Xen API or sent as an e-mail.
Note: High availability for XenServer is only available with a Citrix Essentials for XenServer license
- A stop error due to the failure of a Windows virtual machine.
- An unresponsive console or failed shutdown of a Linux virtual machine.
Check the Workload Balancing log file for the following error message:
"dwmdatacolsvc.exe: Don't have a valid pool. Trying again in 10 minutes."
To correct this error:
- Force the virtual machine to shut down.
- Migrate all of the virtual machines to another XenServer host, then run the following command:
xe-toolstack-restart
For more information see Citrix XenServer Workload Balancing Administrator's Guide - http://support.citrix.com/article/CTX127330
Workload Balancing New Server Errors - If you change the Workload Balancing server that a resource pool references without first removing the Workload Balancing configuration on the resource pool, Workload Balancing will fail to monitor the resource pool properly. If this occurs, you can either uninstall the old Workload Balancing server or manually stop the Workload Balancing services (analysis, data collector, and Web service) to ensure that it will no longer monitor the resource pool. For the reasons stated above, Citrix does not recommend using the following command to change the Workload Balancing servers: pool-initialize-wlb XE
Trunked Network Switches - When NICs are bound together to form a NIC bond in XenServer, bandwidth is aggregated and load-balanced across the pair. However, bandwidth must be available for the backend network switch environment if the NICs are connected to trunked network switches. Trunked network switches provide redundancy and allow for separation of network traffic into several subnets. If NICs are connected across separate trunked network switches, the ability to aggregate bandwidth can affect the communication between the two switches and cause network congestion. Trunked network switches do not support as much bandwidth as a single-switch fabric.

VLANs - XenServer supports the use of multiple VLANs to mapped physical network interfaces on the host server. When creating a network, an engineer must properly configure the VLAN tag for the virtual NIC in XenServer to correspond with the VLANs on the physical switches. If a virtual machine attempts to start or résume and that action causes the resource pool to become overcommitted, a warning alert is triggered. The alert is displayed in XenCenter and can also be configured to be displayed in the Xen API or sent as an e-mail.
XenMotion - XenMotion is the name for XenServer live migration and allows for active virtual machines to dynamically move between XenServer hosts with little downtime.
Issues might occur when:
- The processor vendor on the XenServer host joining the resource pool is not the same as the processor vendors on the hosts already in the resource pool. To overcome this problem Citrix supports heterogeneous resource pools. Refer to the XenServer hardware compatibility list (HCL - http://hcl.vmd.citrix.com/) for details on mixing processor models.
- The XenServer host joining the resource pool is running a different XenServer software version than the hosts already in the resource pool.

Processor Affinity - The process of assigning a specific processing core on a XenServer host to a virtual machine is known as processor affinity. There are certain use cases for processor affinity, but it should be avoided if possible. Assigning a virtual machine to a processor on the host can affect the utilization of resources and make it a less dynamic system. Virtual machines with processor affinity configured cannot be moved between XenServer hosts using XenMotion.

Virtual Machine Templates - Before a virtual machine is converted into a XenServer template, Sysprep should be used to prepare the template for quick virtual machine deployment. Running the Sysprep tool ensures that each cloned virtual machine has a unique machine identifier. Sysprep assigns the following unique system elements to a virtual machine:
- Computer name
- Security Identifier (SID)
- Globally Unique Identifier (GUID)
- Driver cache
Some applications installed on a system prior to using Sysprep exhibit undesired behaviors after the cloning process. Testing the Sysprep process with the operating systems and applications used in production is recommended to ensure expected results.
Storage - You can provide either the hostname of the IP address of the NFS server when creating an NFS storage repository. Issues might arise if DNS is not properly configured and the hostname of the server is used. If the NFS storage repository (SR) has problems connecting to the NFS server, you should verify that DNS is configured correctly. If DNS is not reliable, then the IP address of the NFS server should be used instead of the FQDN. All XenServer hosts in a resource pool must be able to communicate with the shared storage, otherwise issues could arise when using XenMotion.
Resource Pool Overcommitment - Resource pool overcommitment occurs when a host server fails and the virtual machines running on that host server cannot be restarted elsewhere. A resource pool can become overcommitted if:
* A failover plan cannot be found.
* There is not enough free memory across the resource pool to run all of the virtual machines following a failure.
* Changes were made to Virtual Block Devices (VBDs) and networks, which affect the host servers where the virtual machines will be relocated.
If a virtual machine attempts to start or résume and that action causes the resource pool to become overcommitted, a warning alert is triggered. The alert is displayed in XenCenter and can also be configured to be displayed in the Xen API or sent as an e-mail.
Note: High availability for XenServer is only available with a Citrix Essentials for XenServer license