Tag: XenServer 3 posts

Finding in the Wild | XenServer 9 + Windows Server 2025 – When a Boot Storm Becomes a Problem

An interesting detail from the current XenServer 9 known issues that may be particularly relevant to larger Citrix environments: XenServer documents a Windows Server 2025 issue under CP-51655. If many Windows Server 2025 VMs start simultaneously on the

An interesting detail from the current XenServer 9 known issues that may be particularly relevant to larger Citrix environments:

XenServer documents a Windows Server 2025 issue under CP-51655.

If many Windows Server 2025 VMs start simultaneously on the same XenServer host, some VMs may fail to start.

Why do I find this especially interesting in a Citrix context?

Because this scenario is completely normal there.

Citrix Power Management starts several workers in the morning.

An MCS catalog starts after a maintenance window.

Or PVS boots numerous targets almost simultaneously following a reboot schedule.

Initially, the symptoms may look like this:

Some of my Citrix workers will not start.

Troubleshooting will probably begin with MCS, PVS, the master image or the Delivery Controller.

But the cause may be one layer lower.

XenServer explicitly states that the issue can occur when a larger number of Windows Server 2025 VMs start simultaneously on a single host.

This also makes acceptance testing for new Server 2025 Citrix environments interesting.

A test with two or three VDAs may not be sufficient.

For XenServer 9 + Windows Server 2025, I would therefore also plan a realistic boot-storm test:

Start 5 VMs → 10 VMs → 20 VMs → 30+ VMs simultaneously.

Do not check only whether the VDAs are registered afterwards. Already at the XenServer layer, observe whether individual VM starts fail.

With Windows Server 2025 as a future multi-session platform in particular, this is a small detail with potentially significant consequences.

Known issue: CP-51655

Finding in the Wild | PVS + XenServer – Cores per Socket

A small detail that can lead to extended troubleshooting with Citrix PVS on XenServer. When provisioning VMs through the CVAD Setup Wizard, the number of vCPUs must match the CPU topology of the XenServer template. The vCPU count

A small detail that can lead to extended troubleshooting with Citrix PVS on XenServer.

When provisioning VMs through the CVAD Setup Wizard, the number of vCPUs must match the CPU topology of the XenServer template.

The vCPU count must be a multiple of Cores per Socket.

Example:

Cores per Socket: 4
PVS Wizard: 6 vCPUs ❌
PVS Wizard: 8 vCPUs ✅

With an invalid combination, the VM is provisioned but cannot subsequently boot.

XenServer may report:

VCPU_max must be a multiple of platforms:cores-per-socket

The tricky part:

The VM exists.
The PVS target exists.
The vDisk assignment looks correct.

Troubleshooting can quickly focus on PXE, BDM, streaming or the vDisk, although the actual issue is the VM’s CPU topology.

Citrix continues to track this as PVS-1126.

👉 So, for PVS targets that do not boot on XenServer, always check:

vCPU ↔ Cores per Socket.

A small setting with a big impact. 😉

Finding in the Wild | XenServer 9 – NUMA Node Drift

An interesting performance topic in the current XenServer 9 known issues that is easy to overlook, particularly in larger Citrix environments. When a XenServer host’s CPUs are fully utilized, so-called NUMA node drift may occur. What does that

An interesting performance topic in the current XenServer 9 known issues that is easy to overlook, particularly in larger Citrix environments.

When a XenServer host’s CPUs are fully utilized, so-called NUMA node drift may occur.

What does that mean?

Normally, XenServer tries to run a VM’s vCPUs on the NUMA node that also holds the associated memory.

Under heavy CPU saturation, this association may be lost:

vCPU → NUMA node 0
RAM → NUMA node 1

The CPU then has to access memory on the other NUMA node.

➡️ Higher latency
➡️ Worse performance
➡️ Citrix VDAs may become noticeably slower

The tricky part:

Inside the VDA, this may initially look fairly unremarkable.

You can quickly end up investigating Windows, Citrix policies, FSLogix, storage or the application even though the actual issue is at the hypervisor layer.

XenServer 9 provides a particularly useful performance counter for this:

NUMA non-affine vCPUs

If this value rises alongside high host CPU utilization, it is worth examining NUMA distribution.

The workaround documented by XenServer is also noteworthy:

👉 Leave at least one CPU free on the host.

This allows XenServer to restore NUMA affinity.

My learning for Citrix performance analysis:

Do not look only at the VDA’s CPU utilization.

Always check the NUMA layer on heavily utilized XenServer hosts.

Sometimes a VDA is slow not because it lacks CPU, but because its CPU is accessing the wrong memory. 😉