# 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:

> ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769838756963/a2a138cd-abed-411c-a36f-f61abb17f4dc.png align="center")

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

```plaintext
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

```plaintext
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

```plaintext
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

```plaintext
# 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

```plaintext
# 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!