CPU resize failure for onboarded virtual machines

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

This article explains a specific scenario where CPU resize operations fail for virtual machines onboarded into VMware Aria Automation. This is expected behavior related to vSphere's automatic CPU topology feature and how it is supported within Aria Automation.

A CPU resize operation fails if all of the following conditions are met:

• Onboarding State: The virtual machine was onboarded while in a Powered-On state.
• Original Configuration: The virtual machine's original cpuid.coresPerSocket at the time of onboarding was a value other than 1 (e.g., 2, 4, 8).
• Execution Method & Omitted Parameter: The resize operation is triggered via a custom Day-2 action or API, and the cores per socket (coreCount) parameter is not included in the request. In this case, Aria Automation refers to the information from the time the virtual machine was onboarded.

 

Error Message:

The operation Resize failed. cpuCount needs to be evenly divisible by coreCount in order to have the same number of cores per socket. cpuCount:## coreCount:##

 

Note: Virtual machines onboarded while in a Powered-Off state are not affected, as Aria Automation defaults the coreCount to 1 when hardware metadata cannot be retrieved in the powered-off state.

Environment

VMware Aria Automation 8.18

Cause

This is expected behavior. Aria Automation manages virtual machine metadata primarily using the following two tables.

compute_description (Table holding static records)
Holds the initial configuration captured during onboarding. The coreCount stored in this table is not updated by data synchronization. If a virtual machine is onboarded in a powered-off state, coreCount = 1 is stored.

compute_state (Table holding dynamic resources)
Reflects the configuration in vSphere. The coreCount stored in this table is updated by data synchronization.

 

In a custom Day-2 action, if a resize operation is executed without specifying coreCount, Aria Automation refers to the static compute_description to check the coreCount, rather than the dynamic compute_state. Therefore, if the number of CPUs is not evenly divisible by the number of cores at the time of onboarding, an error will occur, and the resize operation will ultimately fail.

 

Resolution

To resolve this issue for existing virtual machines, the number of CPUs must be updated to a value that is evenly divisible by the coreCount.

Action Steps:

1. Check the currently configured CPU and memory values.
2. Check for a coreCount value that is a compatible divisor of the target number of CPUs.
3. Perform a resize operation (via the standard Day-2 Resize action or API) by explicitly specifying the number of CPUs, coreCount, and memory.

 

Selection Case	Benefit	Considerations / Risks
Case A: coreCount = 1	Since any requested cpuCount is evenly divisible by 1, resize operations will no longer fail with this error.	Creates a 1-core-per-socket topology. Some guest OSes have limitations on socket support. Example: Windows 10/11 Pro supports only up to 2 sockets. A 16 vCPU virtual machine with coreCount=1 would only recognize 2 CPUs.
Case B: Specific Divisor	Sets the coreCount to a divisor of the CPU count. Example: CPU count = 9, coreCount = 3	Future resize operations must maintain a value that is evenly divisible by this specific number. Example: Resizing to 12 CPUs is possible, but resizing to 10 CPUs is not.

 

Best Practices for Custom Day-2 Actions
When executing resize operations in custom Day-2 actions, always implement coreCount as an explicit input.