Tackling "Invalid Configuration" - XCP-ng Core Per Socket Mismatch with Apache CloudStack

The Scenario: A Frustrating "Invalid Configuration" Error

Imagine you're deploying a new Ubuntu VM via Apache CloudStack on your XCP-ng hypervisor. Everything seems to go smoothly, but then you check the VM's properties in XCP-ng Center (or Xen Orchestra), and there it is – a red flag indicating "Invalid configuration" next to your CPU topology.

You scratch your head. You've set the vCPUs in CloudStack, and the VM is running (or trying to), but this error persists. This is precisely the situation our user encountered, as seen in their screenshot:

Notice the "Topology: 2 cores per socket (Invalid configuration)" message. This isn't just a visual nuisance; it can prevent VMs from starting, especially after migration or reboot, and it can mislead guest operating systems about their CPU resources.

Understanding the Root Cause: CPU Topology Mismatch

The core of the problem lies in how XCP-ng (and its underlying XAPI) enforces CPU topology rules, and how Apache CloudStack communicates these rules (or sometimes, doesn't) when creating VMs.

XCP-ng's Golden Rule: XCP-ng requires that the Max number of vCPUs must always be perfectly divisible by the Cores per socket. If this mathematical relationship isn't met, XCP-ng flags it as an "Invalid Configuration."

CloudStack's Default Behavior:

• High Max vCPUs: CloudStack often sets Max vCPUs to a very high number (e.g., 80 in our example) in the XCP-ng VM metadata (VCPUs-max). This is done to facilitate CPU hot-plugging, allowing you to scale vCPUs upwards without a reboot.

• Cores per socket Defaults: Unless explicitly told otherwise, CloudStack frequently defaults to telling XCP-ng that a VM should have 1 core per socket (or sometimes 2, as in our user's case).

The Conflict: When CloudStack deploys a VM with, say, 6 Virtual CPUs (VCPUs-at-startup) and a Max number of vCPUs of 80, but the platform:cores-per-socket parameter is set to 2:

• For VCPUs-at-startup (6): 6/2=3 (Valid!)

• For VCPUs-max (80): 80/2=40 (Still mathematically valid!)

So, why the error? The issue often arises because:

1. Missing or Implicit Platform Key: CloudStack might not explicitly set the platform:cores-per-socket key when provisioning, or XCP-ng Center's stricter validation logic flags a potential future conflict if VCPUs-at-startup doesn't match the cores-per-socket rule in the context of hotplugging.

2. XCP-ng Center's Sensitivity: XCP-ng Center can be particularly sensitive to these settings, sometimes flagging configurations that Xen Orchestra or the XAPI might tolerate.

The most common real-world impact is when the guest OS sees many "sockets" (if cores-per-socket is low), potentially impacting software licensing (like Windows Server, which is often licensed per socket or core).

Step-by-Step Solutions

Let's fix this, starting with the immediate remedy for an existing VM, and then moving to the preventive measure in CloudStack.

1. The Immediate Fix: Correcting a Running VM via XCP-ng CLI

If you have a VM already deployed and showing this error, you can fix its cores-per-socket value directly on the XCP-ng host.

Access Your XCP-ng Host: SSH into the XCP-ng host where the problematic VM is running (in our example, DHCLD-AZ1C2-XCPH01).

Identify the VM's UUID: You can see the UUID in the XCP-ng Center screenshot (0d5821cf-99c6-ab7c-0415-8dd3921d9a09). If not, find it with:

Bash

xe vm-list name-label="i-716-14647-VM" --minimal
# This will output just the UUID, e.g., 0d5821cf-99c6-ab7c-0415-8dd3921d9a09

Apply the Fix: The safest and most compatible value for cores-per-socket is 1. This ensures that any VCPUs-at-startup or VCPUs-max value will be divisible by 1, satisfying XCP-ng's rule.

Bash

xe vm-param-set uuid=0d5821cf-99c6-ab7c-0415-8dd3921d9a09 platform:cores-per-socket=1

Replace the UUID with your VM's actual UUID.

Verify the Change: You can check the updated platform parameters:

Bash

xe vm-list uuid=0d5821cf-99c6-ab7c-0415-8dd3921d9a09 params=VCPUs-at-startup,VCPUs-max,platform

You should now see cores-per-socket: 1 in the output. The "Invalid configuration" message in XCP-ng Center should also clear after a refresh.

2. The Permanent Fix: Updating CloudStack Service Offerings

To prevent this issue for all future VMs deployed from a specific Service Offering, you need to configure CloudStack to explicitly set cores-per-socket when provisioning.

Log into CloudStack UI: Navigate to Service Offerings under the Service Offerings or Compute section.

Edit Your Service Offering:

• Select the Service Offering you use for XCP-ng deployments (e.g., your "Ubuntu 16.04 LTS" offering).

• Click View Details or Edit.

Add a Custom Detail:

• Find the Details section.

• Add a new custom detail:

  • Key: cpu.corespersocket

  • Value: 1 (Recommended for broadest compatibility and to avoid this specific error)

Considerations for cpu.corespersocket Value:

• 1 is Safest: As mentioned, 1 will always satisfy the divisibility rule. The guest OS will see many sockets, each with one core.

• Matching Physical Topology: If you have specific licensing requirements or want to optimize for NUMA awareness, you might choose a value that reflects your physical host's core count per socket (e.g., 4 or 8). Just ensure this value evenly divides into your Max vCPUs and your Virtual CPUs set in the offering.

• Example: If your Service Offering provides up to 16 vCPUs and you set cpu.corespersocket=4, the VM will be presented with 4 sockets, each with 4 cores.

3. (Optional) Bulk Update Service Offerings via CloudStack API

If you have many Service Offerings that need updating, doing it manually is tedious. You can use the CloudStack API to perform a bulk update.

First, you'll need to find the id of your Service Offering. You can do this by using the listServiceOfferings API call:

Bash

# Example: Replace your-cloudstack-api-url and api-key/secret-key
curl "http://your-cloudstack-api-url/client/api?command=listServiceOfferings&name=Your%20Offering%20Name&response=json&apiKey=YOUR_API_KEY&secretKey=YOUR_SECRET_KEY"

Once you have the id, you can use the updateServiceOffering command, specifying the custom detail:

Bash

# Example: Replace your-cloudstack-api-url, offering-id, and api-key/secret-key
curl "http://your-cloudstack-api-url/client/api?command=updateServiceOffering&id=OFFERING_ID&details[0].key=cpu.corespersocket&details[0].value=1&response=json&apiKey=YOUR_API_KEY&secretKey=YOUR_SECRET_KEY"

Remember to replace OFFERING_ID, YOUR_API_KEY, and YOUR_SECRET_KEY with your actual values.

Why is CPU Topology Important Beyond Just "Fixing the Error"?

• Operating System Licensing: Many older Windows Server licenses are socket-based. Presenting a VM with 16 vCPUs as 16 sockets (1 core/socket) could hit a 2- or 4-socket OS license limit, causing the OS to ignore most of its assigned vCPUs. Setting cores-per-socket to a higher value (e.g., 4 or 8) makes the OS see fewer sockets with more cores, aligning better with licensing models.

• Performance: While modern hypervisors are very good at abstracting CPU resources, aligning the VM's perceived CPU topology with the underlying physical host's NUMA (Non-Uniform Memory Access) architecture can sometimes yield minor performance benefits by optimizing cache utilization.

• Guest OS Awareness: Some applications or monitoring tools within the guest OS might behave differently based on the reported CPU topology.

Conclusion

The "Invalid configuration" error regarding CPU topology between Apache CloudStack and XCP-ng is a common integration challenge. By understanding XCP-ng's strict divisibility rule and explicitly configuring cpu.corespersocket in your CloudStack Service Offerings (or directly on the VM via XCP-ng CLI), you can ensure smooth VM deployments, avoid frustrating errors, and potentially optimize guest OS behavior.

Don't let a small configuration detail derail your cloud infrastructure – a simple platform:cores-per-socket=1 can save you a lot of headaches!