How Azure can quietly break your SQL Server VM during a resize, and how to fix it without rebuilding.
TL;DR
Seeing only 2 vCPUs on your Azure VM after a resize? This is likely why.
After resizing an Azure VM, often a SQL Server VM, a hidden setting (vmSizeProperties) can be applied automatically. The VM still shows the expected SKU, but inside the OS you only see 2 vCPUs available.
Check this:
az vm show -g <rg> -n <vm> --query "hardwareProfile"
If you see:
{
"vmSizeProperties": {
"vCPUsAvailable": 2,
"vCPUsPerCore": 2
}
}This is why Azure reports multiple CPUs, but the OS only sees 2.
Fix it by restoring the full core count:
az vm deallocate -g <rg> -n <vm>
az rest `
--method patch `
--url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>?api-version=2024-03-01" `
--headers "Content-Type=application/json" `
--body '{"properties":{"hardwareProfile":{"vmSizeProperties":{"vCPUsAvailable":8,"vCPUsPerCore":2}}}}'
az vm start -g <rg> -n <vm>No rebuild required.
The pattern we keep seeing in SQL Server environments
We have seen recent cases where vCPU constrained VMs, often SQL Servers that need a lot of memory but not the associated vCPUs, are resized and are now stuck on only 2 vCPUs. While in Azure the selected SKU still shows 4, 16, or 32 vCPUs. Deallocating the VM doesn’t do anything, resizing to a different SKU doesn’t solve the issue. Even redeploying and reapplying seems to not solve this problem. Azure reports many CPUs, the OS sees only 2.
Constrained vCPU sizes for database workloads
Often these VMs use a popular SKU like the Standard_E32-8s_v5, where the VM has 256GB RAM, but only 8 out of 32 vCPUs enabled. This saves a lot of money when running Memory intensive workloads like SQL Server that are billed by processor.
A normal large VM in the E SKU is the E32ds. This VM has 256 GB RAM and 32 CPUs. The Memory size is great for memory intensive workloads, but 32 vCPUs is often not needed. The pay as you go price for this VM running SQL Enterprise is €10.290,53 per month in the West Europe region.
By switching to the exact vCPU constrained SKU, the E32-8ds, we keep the 256GB RAM, but now 24 of the 32 vCPUs are disabled (note: they do count towards your quota). The price of this VM when running SQL Enterprise is: €4.587,65 per month. A whopping 55% saving.
How to solve the problem
As mentioned the default way to handle deployment issues in Azure is to resize or redeploy the VM. But all these attempts will not resolve the issue where you end up with a 2 vCPU VM.
If you follow Microsoft documentation, Google results, or your usual AI helper, you will likely end up trying one of the following:
- Redeploying
- Rebooting
- Updating drivers
- Removing hidden CPU devices in Device Manager
- Checking NUMA or affinity
Or worse:
- Recreating the VM
- Deploying a new one from disk
- Migrating workloads
All of this is unnecessary. Recreating the VM will work, but it is a major change to fix a minor problem.
Understanding and solving the problem
The reason your VM seems to be locked to only 2 vCPUs is a new feature in Azure called VM vCore Customization. This allows you to limit active vCPU and even disable hyper-threading. Which is very useful for SQL Server licensing. There are also the constrained vCPU SKUs, where this is built into the SKU. And the new and more dynamic Configurable Constrained Cores feature. The problem is how Azure, and especially the Azure Portal, handles this during a resize.
After resizing to or from a constrained vCPU SKU, you notice the OS is limited to 2 vCPUs. This is not an OS issue, nor an Azure capacity or policy issue. The reason is that the following is added to the VM configuration:
"hardwareProfile": {
"vmSize": "Standard_E32ds_v5",
"vmSizeProperties": {
"vCPUsAvailable": 2,
"vCPUsPerCore": 2
}
}The problem with these settings is that once they are set, they cannot be removed afterwards. Even writing directly to the hardware profile using a command line: az vm update –resource-group we-rg-np-vm-sqldev –name ecprsvg17app12 –set hardwareProfile.vmSizeProperties=null
Or by directly updating using the REST API
az rest --method patch `
--url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>?api-version=2024-03-01" `
--body '{\"properties\":{\"hardwareProfile\":{\"vmSizeProperties\":{}}}}'Will not solve the problem. The interesting part is the old and trusted Resource Explorer doesn’t see these values and hence can not remove the vCPU limitation.
While removing is not an option, modifying these values is. The example below restores an 8 vCPU configuration. Set vCPUsAvailable to the full vCPU count of your VM size, otherwise you may still be limiting the VM.
az rest --method patch `
--url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>?api-version=2024-03-01" `
--body '{\"properties\":{\"hardwareProfile\":{\"vmSizeProperties\":{\"vCPUsAvailable\":8,\"vCPUsPerCore\":2}}}}'Examples:
– Standard_E8ds → vCPUsAvailable=8
– Standard_E16ds → vCPUsAvailable=16
– Standard_E32ds → vCPUsAvailable=32
Note: vCPUsPerCore controls hyper-threading; keep it set to 2 unless you explicitly want to disable it.
Prevention checklist
Always check “Customize cores” during resize and validate after every resize. Keep using constrained SKUs for SQL licensing but add validation to your IaC pipelines and runbooks.
Closing note
This is a good example of how small platform details can have a real impact once you are running production workloads.
Nothing was misconfigured in the OS and the VM size looked correct. The platform behaved exactly as configured. But one setting, applied quietly during a normal operation, changed how the system performed.
These are the kinds of issues that do not show up in architecture diagrams or best practice documents, but they do show up in real environments.
