Upgrade Azure CycleCloud Slurm Node OS Images Without Recreating the VM Scale Set
Overview Operating-system image updates in an Azure CycleCloud Slurm cluster are not the same as installing ordinary packages inside a running node. A CycleCloud Slurm node is typically an instance in an Azure Virtual Machine Scale Set (VMSS), and the VMSS model defines the image from which its OS disk is created. This distinction is especially important when the VMSS uses Manual upgrade mode. Changing an image setting does not automatically upgrade running instances. Likewise, reimaging a node without first changing the VMSS model can rebuild that node from the same old image. This article describes a controlled, node-by-node method for moving an existing CycleCloud-managed Slurm partition from one Ubuntu HPC image version to another without deleting and recreating the entire VMSS. NOTE: The same procedure can be used for other schedulers. The appropriate scheduler specific commands need to used for node servicing. The validated example changes the image reference from: microsoft-dsvm:ubuntu-hpc:2404:24.04.2026052601 to: microsoft-dsvm:ubuntu-hpc:2404:24.04.2026092501 These versions are examples from the validated procedure. Always select and validate an image appropriate for your region, VM size, kernel, drivers, scheduler integration, and application stack. Problem statement A CycleCloud Slurm cluster may have long-running compute or GPU nodes that require a newer OS image for reasons such as: Security and compliance updates Kernel fixes Updated device drivers Platform fixes Updated HPC libraries Standardization on a newer image baseline Application or container-runtime compatibility Supportability requirements The most straightforward lifecycle operation is often to update the image in CycleCloud, scale the partition down, allow CycleCloud to remove the old VMSS, and then scale the partition back up. CycleCloud then creates a new VMSS using the updated image. Although that method provides a clean deployment, it may be undesirable in a busy HPC environment because: The complete partition may need a maintenance window. All nodes in the partition may become unavailable together. Deleting the scale set deliberately releases the partition’s current VM allocations. Capacity must be acquired again when the partition is restarted. Azure capacity is dynamic and cannot always be guaranteed at the time of reacquisition. Validation happens after a larger infrastructure change instead of on a single canary node. A deployment problem can affect the entire partition rather than one selected instance. Large distributed workloads may take significant time to drain from the full partition. Administrators may therefore need a method that updates the OS image of selected idle nodes while the remaining nodes continue serving workloads. The challenge is that three separate states must be understood and managed: CycleCloud cluster configuration The image definition CycleCloud will use when it creates or recreates infrastructure. VMSS model The image reference currently defined on the existing scale set. VMSS instance state Whether a particular VMSS instance has applied the latest VMSS model. If these three states are not handled in the correct order, a reimage can complete successfully while leaving the node on the old image. Why reimage alone does not solve the problem A reimage replaces the node’s OS disk using the image and configuration associated with its current infrastructure model. Reimage does not, by itself, select a newer OS image. This creates a common failure pattern: The desired image is changed in the CycleCloud cluster configuration. The existing VMSS continues to reference the old image. A CycleCloud, Slurm, or VMSS reimage action is initiated. The OS disk is rebuilt. The node returns using the old image because the VMSS model still references that image. For a VMSS configured with Manual upgrade mode, the required order is: Drain the selected Slurm node. Change the image reference in the existing VMSS model. Confirm the new image in the VMSS model. Confirm that existing instances report LatestModelApplied=False. Apply the latest model to one selected instance using az vmss update-instances. Wait for the node to return. Confirm that the selected instance reports LatestModelApplied=True. Verify the new image from inside the VM. Validate the OS, scheduler, drivers, network fabric, container runtime, and workload. Resume the node. Repeat for the remaining instances. Update the CycleCloud node-array image configuration to prevent configuration drift. Advantages of this approach No full VMSS recreation The existing VMSS object is updated in place. The process does not intentionally delete the complete scale set and create a replacement. Node-level maintenance Only the selected VMSS instance is disrupted. Other nodes can remain available, provided that the workload and cluster architecture support node-by-node maintenance. Canary validation One idle node can be upgraded first. The new image can be tested against the actual scheduler, drivers, network, containers, and applications before expanding the change. Smaller failure domain If the first upgraded node fails validation, it can remain drained while the remaining nodes continue using the previous image. Reduced capacity exposure The procedure avoids deliberately scaling the entire partition to zero and releasing all current allocations at once. This can reduce exposure to capacity reacquisition risk. However, it should not be treated as a guarantee that host placement or capacity will never change during platform servicing. Controlled scheduling Nodes can be upgraded as they become idle. Slurm drain and resume operations create a clear boundary between: Workload evacuation Infrastructure servicing Technical validation Return to production Measurable rollout progress The latestModelApplied property provides an explicit signal showing which VMSS instances have received the updated model. Easier rollback control If the canary node fails, the rollout can stop before all nodes are changed. This is generally easier to manage than recovering an entire recreated partition. Important limitations This is a rolling infrastructure procedure, not a zero-downtime operation. The selected node becomes unavailable while its OS disk is serviced. Jobs running on that node must complete, migrate, be requeued, or be stopped. Multi-node MPI and distributed training jobs may make node-by-node maintenance impractical. A partition-wide maintenance window may be safer when jobs span most or all nodes. Data or configuration stored only on the OS disk may be lost during servicing. Node bootstrap should be reproducible and important state should be stored externally. Containers do not isolate applications from every host change. The host kernel, GPU driver, RDMA stack, device plugins, mounts, and scheduler integration remain important to containerized workloads. A direct VMSS update does not permanently update the CycleCloud cluster definition. CycleCloud must be updated after successful validation to prevent configuration drift. Prerequisites Before starting, confirm the following: The target node belongs to the expected CycleCloud-managed VMSS. The VMSS uses Manual upgrade mode. The target image has been selected and validated for the environment. The target image is available for the required region and VM size. You have Azure permissions to read and update the VMSS and its instances. (Contributor or Virtual Machine contributor role for the subscription) Azure CLI is installed and authenticated in the correct tenant and context. jq is available on the Linux node for metadata formatting. You have Slurm administrative permission to drain and resume nodes. Required application and configuration state is not stored only on the OS disk. A maintenance window has been approved. A rollback plan has been documented. The first target is an idle or noncritical canary node. Define placeholders instead of embedding environment-specific values: RESOURCE_GROUP="<RESOURCE-GROUP>" VMSS_NAME="<VMSS-NAME>" INSTANCE_ID="<INSTANCE-ID>" SLURM_NODE="<SLURM-NODE-NAME>" TARGET_IMAGE_VERSION="24.04.2026092501" PREVIOUS_IMAGE_VERSION="24.04.2026052601" Detailed upgrade procedure Step 1: Capture the current image from inside the HPC compute node Run the following on the target VM. curl -s -H Metadata:true --noproxy "" "https://169.254.169.254/metadata/instance/compute?api-version=2021-10-01" | jq '{publisher, offer, sku, version, osType}' Output: { "publisher": "microsoft-dsvm", "offer": "ubuntu-hpc", "sku": "2404", "version": "24.04.2026052601", "osType": "Linux" } Also record the current OS release and kernel: cat /etc/os-release uname -r Keep these results in the change record. They provide the baseline needed to prove that the image changed after the operation. vinil@”$SLURM_NODE”:~$ cat /etc/os-release PRETTY_NAME="Ubuntu 24.04.4 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.4 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://un5gmtkzgj1yfd5xrg1g.subtlesoundimmersion.net/" SUPPORT_URL="https://un5npc82gj1yfd5xrg1g.subtlesoundimmersion.net/" BUG_REPORT_URL="https://un5h2085w35k9d17vrbbfgr9.subtlesoundimmersion.net/ubuntu/" PRIVACY_POLICY_URL="https://un5gmtkzgj1yfd5xrg1g.subtlesoundimmersion.net/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo vinil@”$SLURM_NODE”:~$ uname -r 6.8.0-1054-azure Step 2: Confirm the VMSS upgrade mode and current image Run the following from Azure Cloud Shell: az vmss show --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --query "{UpgradeMode:upgradePolicy.mode,Image:virtualMachineProfile.storageProfile.imageReference}" --output json Sanitized output: { "Image": { "offer": "ubuntu-hpc", "publisher": "microsoft-dsvm", "sku": "2404", "version": "24.04.2026052601" }, "UpgradeMode": "Manual" } The important value is: "UpgradeMode": "Manual" With Manual upgrade mode, changing the VMSS model does not automatically update existing instances. Do not continue until the current image and upgrade mode match the change plan. Step 3: Map Slurm nodes to VMSS instance IDs List all instances in the scale set: az vmss list-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --query "[].{InstanceId:instanceId,ComputerName:osProfile.computerName,ProvisioningState:provisioningState}" --output table Output: InstanceId ComputerName ProvisioningState ------------ -------------- ------------------- 0 <NODE-000> Succeeded 1 <NODE-001> Succeeded Confirm the mapping carefully. A VMSS instance ID is not necessarily the same as a Slurm node name. For the first validation: INSTANCE_ID="0" SLURM_NODE="slurm-hpc-1" Only one instance should be selected for the canary upgrade. Step 4: Drain the selected Slurm node Prevent Slurm from scheduling new jobs on the node: SLURM_NODE="slurm-hpc-1" scontrol update NodeName="$SLURM_NODE" State=DRAIN Reason="VMSS OS image upgrade" Confirm the state: sinfo -N -n "$SLURM_NODE" Output: NODELIST NODES PARTITION STATE slurm-hpc-1 1 hpc* drain Check whether jobs are still assigned to the node: root@slurm01-scheduler:~# squeue -w "$SLURM_NODE" JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) root@slurm01-scheduler:~# Proceed only when: The node is DRAINING while existing work completes, or DRAINED when no work remains. squeue -w returns no active jobs for the node. Dependencies involving distributed jobs have been considered. The node does not hold application state required by active workloads. Do not continue while the node is still running a workload. Step 5: Update the OS image in the VMSS model Update only the image version in the existing scale-set model: az vmss update --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --set virtualMachineProfile.storageProfile.imageReference.version="$TARGET_IMAGE_VERSION" The command may return a large JSON object. The important sections should contain: { "upgradePolicy": { "mode": "Manual" }, "virtualMachineProfile": { "storageProfile": { "imageReference": { "offer": "ubuntu-hpc", "publisher": "microsoft-dsvm", "sku": "2404", "version": "24.04.2026092501" } } } } At this point: The VMSS model references the target image. Existing VMSS instances have not yet been upgraded. No node should be assumed to be using the target image yet. This separation is one of the most important concepts in the procedure. Step 6: Verify the target image in the VMSS model Query only the image reference: az vmss show --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --query "virtualMachineProfile.storageProfile.imageReference" --output json Output: { "offer": "ubuntu-hpc", "publisher": "microsoft-dsvm", "sku": "2404", "version": "24.04.2026092501" } Do not continue until the VMSS model shows the intended target image. Step 7: Confirm that existing instances have not applied the new model Run: az vmss list-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --expand instanceView --query "[].{InstanceId:instanceId,ComputerName:osProfile.computerName,LatestModelApplied:latestModelApplied,ProvisioningState:provisioningState}" --output table Output: InstanceId ComputerName LatestModelApplied ProvisioningState ------------ -------------- -------------------- ----------------- 0 <NODE-000> False Succeeded 1 <NODE-001> False Succeeded The important value is: LatestModelApplied=False This confirms that: The VMSS model contains the new image. The existing VMSS instances are still using their previous model. The model change has not automatically upgraded the nodes. Step 8: Apply the latest model to the canary instance Apply the updated VMSS model to only the selected instance: az vmss update-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --instance-ids "$INSTANCE_ID" This operation is disruptive to the selected node. Its OS disk is serviced and connectivity is temporarily unavailable. Do not start another node upgrade until this instance has: Returned to a successful provisioning state. Booted correctly. Completed CycleCloud initialization. Reconnected to Slurm. Passed the complete validation checklist. Step 9: Confirm that the canary applied the latest model Run the instance-view query again: az vmss list-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --expand instanceView --query "[].{InstanceId:instanceId,ComputerName:osProfile.computerName,LatestModelApplied:latestModelApplied,ProvisioningState:provisioningState}" --output table Expected result after upgrading instance 0: InstanceId ComputerName LatestModelApplied ProvisioningState ------------ -------------- -------------------- ----------------- 0 <NODE-000> True Succeeded 1 <NODE-001> False Succeeded This is the desired canary state: Instance 0 has applied the latest model. Instance 1 remains on the previous model. The VMSS continues to exist. The rollout can pause for detailed validation. Do not rely only on ProvisioningState=Succeeded. Confirm both the model status and the in-guest OS image. Step 10: Verify the image from inside the upgraded node After the VM becomes accessible, query its metadata again: curl -s -H Metadata:true --noproxy "" "https://169.254.169.254/metadata/instance/compute?api-version=2021-10-01" | jq '{publisher, offer, sku, version, osType}' Output { "publisher": "microsoft-dsvm", "offer": "ubuntu-hpc", "sku": "2404", "version": "24.04.2026092501", "osType": "Linux" } This confirms that the image changed from: microsoft-dsvm:ubuntu-hpc:2404:24.04.2026052601 to: microsoft-dsvm:ubuntu-hpc:2404:24.04.2026092501 Step 11: Verify the operating-system release Run: # cat /etc/os-release PRETTY_NAME="Ubuntu 24.04.5 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.5 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://un5gmtkzgj1yfd5xrg1g.subtlesoundimmersion.net/" SUPPORT_URL="https://un5npc82gj1yfd5xrg1g.subtlesoundimmersion.net/" BUG_REPORT_URL="https://un5h2085w35k9d17vrbbfgr9.subtlesoundimmersion.net/ubuntu/" PRIVACY_POLICY_URL="https://un5gmtkzgj1yfd5xrg1g.subtlesoundimmersion.net/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo Verify the running kernel: # uname -r 6.8.0-1067-azure The result should match the kernel expected for the approved target image and its driver stack. The actual kernel output should be recorded internally rather than copied into a public article if it contains environment-specific information. Step 12: Validate operating-system health # Check for failed services: systemctl --failed --no-pager # Check the overall system state: systemctl is-system-running # Review boot errors: journalctl -b -p err --no-pager # If cloud-init is used: cloud-init status --long Validation criteria should include: The node booted successfully. No unexpected failed services remain. Cloud-init or equivalent bootstrap completed. CycleCloud initialization completed. Required filesystems and application paths are available. DNS resolution works. Time synchronization is healthy. Identity and authentication components work. Monitoring and security agents are operational. No unexpected kernel or device initialization errors are present. Step 13: Validate CycleCloud and Slurm integration Confirm that Slurm can see the node: scontrol show node "$SLURM_NODE" Review the node’s: State Features Partitions CPU count Memory Generic resources Reason field Registration status The OS image upgrade may change bootstrap timing or host configuration. Confirm that CycleCloud applied the expected node configuration and that Slurm did not register the node with unexpected hardware or resource values. Step 14: Validate HPC and accelerator dependencies An OS image update can change the kernel, device drivers, user-space libraries, and bootstrap behavior. Validate every host-level dependency used by the partition. GPU validation For GPU nodes: nvidia-smi Confirm: All expected GPUs are visible. The driver initializes successfully. No unexpected device or driver errors are reported. The driver is compatible with the application and container stack. InfiniBand and RDMA validation For InfiniBand or RDMA nodes: ibv_devices ibstat Confirm: Expected devices are present. Ports are active. Link state is correct. The expected transport stack is available. Container validation For containerized environments, validate: Container runtime startup GPU device exposure RDMA device exposure Host-library injection Required mounts User namespace behavior Scheduler integration Application-specific plugins A container does not remove dependency on the host kernel, GPU driver, network device stack, or scheduler configuration. Workload validation Run representative tests such as: A single-node CPU job A GPU visibility and compute test An RDMA connectivity test An MPI or UCX smoke test A container launch test A small version of a production workload Do not treat a successful VM boot as sufficient proof that the node is production-ready. Step 15: Resume the validated node After all checks pass: scontrol update NodeName="$SLURM_NODE" State=RESUME Verify the state: sinfo -N -n "$SLURM_NODE" Confirm that: Slurm returns the node to the expected state. No unexpected drain reason remains. A small test job runs successfully. The node behaves as expected under scheduling. Step 16: Upgrade the next instance After the canary node has passed validation, select the next idle instance: INSTANCE_ID="1" SLURM_NODE="<NODE-001>" Drain it: scontrol update NodeName="$SLURM_NODE" State=DRAIN Reason="VMSS OS image upgrade" Confirm there are no jobs: sinfo -N -n "$SLURM_NODE" squeue -w "$SLURM_NODE" Apply the already-updated VMSS model: az vmss update-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --instance-ids "$INSTANCE_ID" After the operation completes, repeat all control-plane, operating-system, scheduler, driver, network, container, and workload validation. When both example instances have been upgraded, the expected state is: InstanceId ComputerName LatestModelApplied ProvisioningState ------------ -------------- -------------------- ----------------- 0 <NODE-000> True Succeeded 1 <NODE-001> True Succeeded Repeat the drain, update, validate, and resume cycle until every intended instance reports LatestModelApplied=True and passes workload validation. Update-instances versus reimage These operations address different layers of the upgrade. Operation What it changes Key point az vmss update VMSS model Existing instances remain unchanged in Manual mode. az vmss update-instances Selected VMSS instances Applies the latest VMSS model to the selected instances. az vmss reimage Selected instance OS disks Rebuilds the OS disk but should not be treated as a substitute for applying the latest model in this workflow. CycleCloud or Slurm reimage action Requests node reimage through the cluster workflow Does not itself change an old VMSS image reference to a new one. Scale down and scale up after changing CycleCloud Recreates infrastructure from the CycleCloud definition Provides a clean deployment but may require partition-wide downtime and capacity reacquisition. The most important rule is: A reimage can reproduce the old OS if the infrastructure model still references the old image. The validated sequence is therefore: Update VMSS model verify model confirm LatestModelApplied=False run update-instances confirm LatestModelApplied=True verify the image from inside the node Prevent configuration drift in CycleCloud Directly modifying the existing VMSS is not the final configuration-management step. CycleCloud remains the owner of the cluster definition. If CycleCloud later removes and recreates the VMSS, the replacement scale set will use the image configured in the CycleCloud node array. If the CycleCloud definition still points to the previous image, newly created nodes may return to that version even though the current VMSS was upgraded manually. After the canary and rollout succeed: Update the OS image in the corresponding CycleCloud node-array configuration. Use the same publisher, offer, SKU, and version validated in the VMSS. Review or export the cluster configuration to confirm the new value is persistent. Test a controlled scale-out or node replacement if the maintenance plan permits. Record the CycleCloud configuration change with the VMSS change. The desired end state is: CycleCloud node-array image = VMSS model image = Image reported by every upgraded VMSS instance Updating only the current VMSS should not be treated as a permanent CycleCloud configuration change. Rollback strategy A rollback plan should be prepared before the first node is changed. If the canary fails validation: Keep the node drained. Stop the rollout to all remaining nodes. Capture boot, extension, driver, scheduler, and application logs. Change the VMSS model back to the previous image. Apply the previous model to the affected instance. Revalidate the restored node. Resume it only after the previous service level has been restored. Example rollback: az vmss update --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --set virtualMachineProfile.storageProfile.imageReference.version="$PREVIOUS_IMAGE_VERSION" Apply the restored model: az vmss update-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --instance-ids "$INSTANCE_ID" Verify the model: az vmss show --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --query "virtualMachineProfile.storageProfile.imageReference" --output json Verify the instance status: az vmss list-instances --resource-group "$RESOURCE_GROUP" --name "$VMSS_NAME" --expand instanceView --query [].{InstanceId:instanceId,LatestModelApplied:latestModelApplied,ProvisioningState:provisioningState}" --output table Because a VMSS has one current model, coordinate rollback carefully if some nodes are already on the new image. Restore the intended VMSS model after the affected node has been recovered, and do not continue the rollout until the incompatibility is understood. Conclusion Updating the OS image of CycleCloud Slurm nodes without recreating the entire VMSS is possible when the scale set uses Manual upgrade mode. However, it requires a deliberate separation between: The CycleCloud cluster definition The VMSS model The model applied to each VMSS instance The core workflow is: Drain one node Update the VMSS image reference Verify the new VMSS model Confirm LatestModelApplied=False Apply the latest model to one instance Confirm LatestModelApplied=True Verify the image inside the VM Validate the complete HPC workload path Resume the node Repeat for the remaining nodes Align the CycleCloud configuration This approach provides a controlled canary rollout, limits disruption to selected nodes, avoids deliberate recreation of the full scale set, and makes validation and rollback easier to manage. Its success depends on disciplined scheduler operations, complete host-level validation, careful treatment of distributed workloads, and final synchronization of the CycleCloud cluster configuration.Generally Available: Automatic Zone Balance for Virtual Machine Scale Sets
We’re excited to announce the general availability of automatic zone balance for Virtual Machine Scale Sets. Automatic zone balance continuously monitors your scale set and redistributes VM instances across availability zones, reducing the risk that a single-zone failure disproportionately impacts your applications. Maintain optimal resiliency as your scale set evolves When you deploy a Virtual Machine Scale Set across multiple availability zones, Azure attempts to spread your VMs as evenly as possible for maximum resiliency. However, capacity constraints, scaling operations, and other factors can cause your scale sets to become imbalanced over time, with some zones holding more VM instances than others. This imbalance often goes unnoticed, but it means a zone failure could take down a larger share of your workload than expected. Automatic zone balance addresses these challenges by continuously monitoring your scale set for zonal imbalances and tracking capacity in under-provisioned zones. When capacity becomes available and safety conditions are met, Azure automatically creates replacement VMs in under-provisioned zones and removes VMs from over-provisioned zones, eliminating the need for manual operations. Rebalancing with built-in safeguards Automatic zone balance uses a create-before-delete approach, creating replacement VMs in under-provisioned zones before removing VMs from over-provisioned zones. Application health checks performed through application health extension or load balancer health probes help protect application availability during rebalancing by evaluating the health of replacement VMs before existing instances are removed. Built-in safety guardrails ensure rebalancing respects instance protection policies and doesn’t start during active or recently completed scale set operations. To minimize churn, rebalancing includes cooldown periods between operations and replaces only one VM at a time. Automatic zone balance also enables automatic instance repairs by default, providing instance-level health monitoring and zone-level resiliency out of the box, with the option to opt out of repairs if you prefer to manage instance recovery independently. Changes since preview Since the public preview announcement, we’ve introduced the following improvements on automatic zone balance: Coordination with Azure Autoscale: If Autoscale triggers a scale-in during rebalancing, the scale set will complete the rebalance operation first before performing the scale-in. However, scale-out operations and customer-initiated capacity changes will take priority, cancelling any in-progress rebalance operations so the scale set can update to the requested capacity. Zone-balance calculations across VM power states: Active, deallocated, and powered-off VMs all count toward zone distribution. Rebalancing proceeds only when total instance counts are imbalanced and moving an active VM would improve active-instance distribution. See examples of how deallocated and powered-off VMs affect rebalancing. How to Get Started To get started with automatic zone balance: Confirm workload suitability: Automatic zone balance is best suited for stateless workloads because rebalancing recreates VMs rather than preserving their identity, networking, and disks. Check prerequisites: Configure at least two availability zones, ensure all instances are zonal, and enable application health monitoring. Enable Automatic zone balance: Turn on the feature through the Azure portal, Azure CLI, PowerShell, or REST API. For detailed instructions and supported configurations, visit the Automatic zone balance overview and enablement guide.Build a Simple GPU-Enabled Kubernetes Cluster on Azure N-Series VMs
Audience: Platform engineers, ML engineers, and developers who need a small, understandable GPU development cluster without the abstraction of a managed Kubernetes service. Reference topology: Role Azure VM size Operating system Purpose Control plane Standard_D8s_v6 Ubuntu 24.04 LTS API server, scheduler, controllers, etcd GPU worker Standard_NC24ads_A100_v4 Ubuntu 24.04 LTS CUDA-enabled development workloads Software baseline: Kubernetes v1.33, containerd, Flannel CNI, NVIDIA Container Toolkit, and NVIDIA Kubernetes device plugin v0.17.0. Why Build This Cluster? A two-node kubeadm cluster is useful when you want direct access to Kubernetes internals while developing or debugging GPU applications. It keeps the control plane on a general-purpose VM and reserves the expensive N-series capacity for workloads that explicitly request a GPU. Development Use Case: Shared GPU Sandbox Imagine a small ML team validating a PyTorch service before moving it to a production platform. Developers build containers locally or in CI, deploy them to this cluster, request nvidia.com/gpu: 1, inspect CUDA behavior, tune resource requests, and test Kubernetes manifests. The same environment can exercise Jobs, model-serving Deployments, ConfigMaps, Secrets, storage mounts, and observability agents. This design is appropriate for experimentation, integration testing, workshops, and short-lived development. It is not a production blueprint: the control plane is not highly available, etcd has no redundancy, Flannel is intentionally simple, and operational safeguards are minimal. Architecture and Traffic Flow Control plane: runs the Kubernetes API server, scheduler, controller manager, and etcd. GPU worker: runs containerd, kubelet, the NVIDIA container runtime, and GPU workloads. Pod network: Flannel allocates pod addresses from 10.244.0.0/16. GPU discovery: the NVIDIA device plugin advertises nvidia.com/gpu to Kubernetes. Before You Begin Create both VMs in the same Azure virtual network and subnet. Use private IP connectivity between nodes. Confirm that the selected region has quota and capacity for Standard_NC24ads_A100_v4. GPU VM availability and quota are subscription- and region-dependent. Use trusted administrative source ranges for SSH. Ensure the nodes can communicate on the Kubernetes control-plane, kubelet, and Flannel ports required by your network policy. Avoid exposing the Kubernetes API server broadly to the internet. Disk requirement: Use 128GB disk as OS disk in Standard_NC24ads_A100_v4 as 32GB will be the default and it may not be sufficient to run the test job mentioned below. 1. Prepare Both Nodes Run the following commands on both the control-plane VM and the GPU worker. Use a non-root account with sudo access. Set Host Names and Name Resolution Assign a unique host name on each VM: Control plane sudo hostnamectl set-hostname controlplane GPU worker sudo hostnamectl set-hostname gpunode Add both private IP addresses to /etc/hosts on each node, replacing the placeholders: <CONTROL_PLANE_PRIVATE_IP> controlplane <GPU_WORKER_PRIVATE_IP> gpunode Disable Swap Kubelet expects swap to be disabled unless it is explicitly configured to tolerate it. sudo swapoff -a sudo sed -i '/ swap / s/^/#/' /etc/fstab swapon --show The final command should return no active swap devices. Load Required Kernel Modules cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter Configure Kubernetes Networking Parameters cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system Install and Configure containerd sudo apt-get update sudo apt-get install -y containerd sudo mkdir -p /etc/containerd sudo containerd config default | sudo tee /etc/containerd/config.toml > /dev/null sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml sudo systemctl restart containerd sudo systemctl enable containerd sudo systemctl status containerd --no-pager The SystemdCgroup = true setting aligns containerd with kubelet and systemd cgroup management. Install Kubernetes v1.33 Packages The repository minor version and the packages installed on every node must match. The commands below configure the v1.33 repository used by this guide. sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gpg conntrack socat sudo mkdir -p /etc/apt/keyrings curl -fsSL https://un5qfpanu6qx7axwh73d69mu.subtlesoundimmersion.net/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://un5qfpanu6qx7axwh73d69mu.subtlesoundimmersion.net/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl kubeadm version kubectl version --client If you choose another supported Kubernetes minor release, replace v1.33 consistently on every node and follow that release’s upgrade and version-skew guidance. 2. Initialize the Control Plane Run this section only on controlplane. Initialize Kubernetes Update the CIDR value as per your requirement sudo kubeadm init --pod-network-cidr=10.xxx.0.0/16 Save the kubeadm join command printed at the end. It contains a time-limited bootstrap token and the control-plane CA hash. Configure kubectl for the Administrator mkdir -p "$HOME/.kube" sudo cp -i /etc/kubernetes/admin.conf "$HOME/.kube/config" sudo chown "$(id -u):$(id -g)" "$HOME/.kube/config" kubectl get nodes The control-plane node may remain NotReady until the CNI is installed. Install Flannel kubectl apply -f https://un5q021ctkzm0.subtlesoundimmersion.net/flannel-io/flannel/releases/latest/download/kube-flannel.yml kubectl get pods -n kube-flannel -w Because Flannel’s default manifest uses 10.244.0.0/16, it matches the pod CIDR supplied to kubeadm. Generate a New Join Command if Needed kubeadm token create --print-join-command Treat the join command as a secret while it is valid. Run it only on the intended worker. 3. Configure the GPU Worker Complete the shared preparation steps first, then perform the following work on gpunode. Validate the NVIDIA Driver The Azure GPU VM must have a compatible NVIDIA driver. Confirm that the host can see the accelerator: nvidia-smi Do not continue until this command reports the GPU and driver successfully. Driver installation varies by Azure image and extension strategy, so standardize it before automating the node build. Install NVIDIA Container Toolkit curl -fsSL https://un5m4jpkwagx6vwhy3c869mu.subtlesoundimmersion.net/libnvidia-container/gpgkey | sudo gpg --dearmor -o /etc/apt/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://un5m4jpkwagx6vwhy3c869mu.subtlesoundimmersion.net/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/etc/apt/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=containerd --nvidia-set-as-default sudo systemctl restart containerd sudo systemctl status containerd --no-pager Join the Worker to the Cluster Run the exact command generated by the control plane. It will resemble: sudo kubeadm join <CONTROL_PLANE_PRIVATE_IP>:6443 --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH> Back on the control plane, watch the node registration: kubectl get nodes -o wide -w azureuser@controlplane:~$ kubectl get nodes NAME STATUS ROLES AGE VERSION controlplane Ready control-plane 84s v1.33.13 azureuser@controlplane:~$ kubectl get nodes NAME STATUS ROLES AGE VERSION controlplane Ready control-plane 111s v1.33.13 gpunode NotReady <none> 8s v1.33.13 azureuser@controlplane:~$ kubectl get nodes NAME STATUS ROLES AGE VERSION controlplane Ready control-plane 112s v1.33.13 gpunode Ready <none> 9s v1.33.13 4. Advertise the GPU to Kubernetes Run these commands on the control plane. Install the NVIDIA Device Plugin Pinning the manifest version makes the cluster reproducible. curl -fsSL -o nvidia-device-plugin.yml https://un5wjtjgu65aywq48vjur63bk0.subtlesoundimmersion.net/NVIDIA/k8s-device-plugin/v0.17.0/deployments/static/nvidia-device-plugin.yml kubectl apply -f nvidia-device-plugin.yml kubectl get daemonset -n kube-system nvidia-device-plugin-daemonset kubectl get pods -n kube-system -l name=nvidia-device-plugin-ds -o wide Verify GPU Capacity kubectl describe node gpunode | grep -A 10 -E 'Capacity:|Allocatable:' kubectl get node gpunode -o jsonpath='{.status.allocatable.nvidia\.com/gpu}{"\n"}' The expected allocatable value depends on the VM’s visible GPU count and partitioning configuration. Kubernetes schedules GPUs as integer extended resources. azureuser@controlplane:~$ kubectl describe node gpunode | grep -A 10 -E 'Capacity:|Allocatable:' Capacity: cpu: 24 ephemeral-storage: 128917488Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 226765912Ki nvidia.com/gpu: 1 pods: 110 Allocatable: cpu: 24 ephemeral-storage: 118810356745 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 226663512Ki nvidia.com/gpu: 1 pods: 110 System Info: Machine ID: ac82b1424d30473a86a3f22bb2c4ffa1 System UUID: 67d695c2-b663-4514-9952-9e6e29671e4e azureuser@controlplane:~$ kubectl get node gpunode -o jsonpath='{.status.allocatable.nvidia\.com/gpu}{"\n"}' 1 5. Run an End-to-End PyTorch GPU Test Create gpu-test-job.yaml on the control plane with the following content: apiVersion: batch/v1 kind: Job metadata: name: pytorch-gpu-test namespace: default spec: backoffLimit: 2 template: spec: restartPolicy: Never containers: - name: pytorch-trainer image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime command: ["python3", "-c"] args: - | import time import torch import torch.nn as nn import torch.optim as optim print("=== CUDA validation ===") if not torch.cuda.is_available(): raise SystemExit("CUDA was not detected by PyTorch") device = torch.device("cuda:0") print(f"Device: {torch.cuda.get_device_name(0)}") print(f"Capability: {torch.cuda.get_device_capability(0)}") model = nn.Sequential( nn.Linear(1000, 2048), nn.ReLU(), nn.Linear(2048, 1000) ).to(device) optimizer = optim.SGD(model.parameters(), lr=0.01) criterion = nn.MSELoss() inputs = torch.randn(128, 1000, device=device) targets = torch.randn(128, 1000, device=device) started = time.time() for epoch in range(1, 101): optimizer.zero_grad() loss = criterion(model(inputs), targets) loss.backward() optimizer.step() if epoch % 20 == 0: vram = torch.cuda.memory_allocated(0) / 1e6 print(f"Epoch {epoch}/100 | Loss {loss.item():.4f} | VRAM {vram:.2f} MB") print(f"Completed in {time.time() - started:.4f}s") resources: limits: nvidia.com/gpu: "1" requests: nvidia.com/gpu: "1" Submit and observe the Job: kubectl apply -f gpu-test-job.yaml kubectl get pods -l job-name=pytorch-gpu-test -o wide kubectl logs -l job-name=pytorch-gpu-test --follow kubectl get job pytorch-gpu-test A successful run prints the NVIDIA device name, CUDA capability, training progress, and completion time. azureuser@controlplane:~$ kubectl get pods -l job-name=pytorch-gpu-test -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pytorch-gpu-test-j5wh8 1/1 Running 0 109s XXXX gpunode <none> <none> azureuser@controlplane:~$ kubectl logs -l job-name=pytorch-gpu-test --follow === CUDA validation === Device: NVIDIA A100 80GB PCIe Capability: (8, 0) Epoch 20/100 | Loss 1.0461 | VRAM 51.37 MB Epoch 40/100 | Loss 1.0415 | VRAM 51.37 MB Epoch 60/100 | Loss 1.0371 | VRAM 51.37 MB Epoch 80/100 | Loss 1.0328 | VRAM 51.37 MB Epoch 100/100 | Loss 1.0287 | VRAM 51.37 MB Completed in 0.1250s Conclusion This compact cluster provides a transparent path from an Azure GPU VM to a Kubernetes-scheduled CUDA workload. It is small enough to understand, reset, and rebuild, yet realistic enough to validate container images, resource requests, device discovery, Jobs, and model-serving patterns before adopting a production-grade architecture.More EDA Job Sets per Volume: Azure NetApp Files Raises the Performance Bar
Azure NetApp Files raises the performance ceiling for cloud-based electronic design automation (EDA) with a new independently published SPECstorage® Solution 2020 EDA_BLENDED result for a single large volume in breakthrough mode: 5,340 job sets, 2.4 million operations per second, 38,776 MB/s peak throughput, and 0.54 ms overall response time. Delivering 1.85 times the job sets, operations, and throughput of the previous single-volume result while preserving sub-millisecond latency through most load points, the result enables more concurrent simulations, shorter regression cycles, and better utilization of compute and tool licenses without dataset sharding. Combined with proven linear scale-out and generally available Azure NetApp Files cache volumes that provide on-demand access to on-premises data, it gives EDA teams a practical foundation for high-performance cloud deployment and bursting.
Azure Delivers Strong MLPerf Inference v6.1 Results with NVIDIA GB300 & GB200
By Mark Gitau and Azin Heidarshenas In the MLPerf Inference v6.1 round, Azure demonstrated strong Deepseek-R1 performance on GB300 NVL72 and GB200 NVL72 platforms. Azure submitted GB200 results at 18-node (1-rack) and 72-node (4-rack) scale, and GB300 results at 18 nodes (1 rack), marking our first rack-scale and cross-rack MLPerf Inference submissions. According to results published by MLCommons, Azure achieved the highest reported Interactive score on GB300 NVL72 and the highest reported Server and Offline scores on GB200 NVL72 at both 1- and 4-rack scale, demonstrating the ability to sustain high throughput across latency-constrained and throughput-optimized deployment scenarios. DeepSeek-R1 is a large Mixture-of-Experts (MoE) model, making it an ideal benchmark for modern AI infrastructure. It stresses compute, networking (both NVLink and scale-out network), memory, and serving infrastructure under realistic large-scale deployment conditions. As a result, performance is determined by the effectiveness of the entire system stack rather than GPU capability alone. MLPerf Inference evaluates system performance across several deployment scenarios. Offline measures maximum throughput for batch-oriented workloads with no latency constraints. Server simulates production online serving, where requests arrive continuously and systems must maximize throughput while meeting latency targets, evaluating how efficiently a system balances responsiveness and utilization. Interactive focuses on user-facing AI experiences by measuring token generation performance under stringent latency requirements on metrics such as time-to-first token and token-to-token latency. Together, these scenarios provide a comprehensive view of both throughput and real-time serving performance. Results Summary Scenario Throughput (Tokens/second) Platform Interactive Offline Server ND GB300 NVL72 (18 nodes) 260,098 661,143 589,391 ND GB200 NVL72 (18 nodes) - 542,075 426,796 ND GB200 NVL72 (72 nodes) - 2,091,190 1,598,510 Beyond the top results on GB200, Azure's GB300 submission achieved 97.7% of the best reported Server performance and 95.8% of the best reported Offline performance while maintaining the highest Interactive performance among all reported submissions. Together, these results demonstrate competitive performance across diverse deployment scenarios and highlight the strength of Azure's full-stack AI infrastructure. Acknowledgments This submission was led by Mark Gitau and Azin Heidarshenas, who drove the benchmarking, performance characterization, and submission efforts across GB200 and GB300 platforms. MLPerf from MLCommons® MLCommons® is an open engineering consortium of AI leaders from academia, research, and industry where the mission is to “build fair and useful benchmarks” that provide unbiased evaluations of training and inference performance for hardware, software, and services—all conducted under predetermined conditions.Public Preview: Migrate your regional virtual machines to availability zones
This new capability enables you to move your existing regional (nonzonal) VMs and VMSS Flex deployments into specific availability zones while preserving the VM names, data disks, and other stateful properties. We're excited to announce the public preview of regional to zonal migration for Azure Virtual Machines and for VMs in Virtual Machine Scale Sets with Flexible orchestration. With a small number of API calls, you can take a VM that was originally deployed without a zone and assign it to availability zone 1, 2, or 3—keeping the same VM resource ID, name, OS and data disks, NICs, IP addresses, and scale set membership. For detailed instructions, see: Migrate a regional virtual machine to an availability zone Migrate from regional to a zonal Virtual Machine Scale Sets Why migrate from regional to zonal? Availability zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. Placing your VMs into zones gives you a meaningfully higher availability profile and protects you from datacenter-level failures. Capability Regional VM / VMSS Zonal VM / VMSS Datacenter-level fault isolation No Yes Single-VM SLA 99.9% (Premium SSD) 99.9% (Premium SSD) Multi-VM SLA 99.95% (availability set or fault-domain spread) 99.99% (across two or more zones) Protection from a zone outage No Yes Required for many compliance and DR architectures — Yes Until now, moving an existing regional VM into a zone meant rebuilding the VM: snapshot the disks, recreate the resource in the target zone, reattach NICs, update DNS, and so on. With this preview you can do it while preserving the resource IDs and all its dependencies. How it works The migration is a deliberate, in-place flow that you control end-to-end: Register the preview feature Microsoft.Compute/RegionalToZonalVMMigrationForDeallocatedVM on your subscription. Deallocate the VM. The VM must be in Stopped (deallocated) state—plan for downtime. Assign the zone. Update the VM's zones property to ["1"], ["2"], or ["3"]. Start the VM. It boots in the new zone immediately, even while background data migration of the disks is still completing. (Optional) Attach to a Flexible scale set for autoscaling, rolling upgrades, and instance protection. A few important properties of the flow: In place. The VM keeps its resource ID, name, NICs, private/public IPs, OS and data disks, tags, and extensions. Background data movement. Disk data is migrated transparently after the zone is assigned. You don't have to wait for it before starting the VM. One-way. A zonal VM can't be migrated back to a regional deployment. Per-VM granularity. For scale sets, you migrate one VM at a time so you can stagger the change across instances and validate between batches. Two migration paths Path 1: Single regional VM → zonal VM For standalone VMs (or VMs you want to leave standalone). Once the VM is zonal, you can optionally attach it to a Flexible scale set in the same region. # 1. Deallocate az vm deallocate -g <rg> -n <vm> # 2. Assign zone az vm update -g <rg> -n <vm> --set zones='["1"]' # 3. Start az vm start -g <rg> -n <vm> If the VM is in a Proximity Placement Group, remove the PPG association in the same update by adding --ppg "". Path 2: Regional VMSS Flex → zonal VMSS Flex For VMs running in a Flexible scale set, you first update the scale set model to include the target zones, then migrate each VM in place. VMs keep their names, disks, network configuration, and scale set membership. # 1. Add zones to the scale set model (no impact on running VMs) az vmss update -g <rg> -n <vmss> --set zones='["1","2","3"]' # 2. For each VM in the scale set: az vm deallocate -g <rg> -n <vm-instance> az vm update -g <rg> -n <vm-instance> --set zones='["1"]' az vm start -g <rg> -n <vm-instance> We recommend migrating in batches—for example, a third of the instances at a time—so the application stays healthy throughout the migration window. Spreading the instances across all three zones. Supported configurations Source Target Regional VM Zonal VM Regional VM Zonal VM in a Flexible scale set Regional VM in a Proximity Placement Group Zonal VM (PPG removed) Regional VM in a Flexible scale set Zonal VM in the same Flexible scale set Not supported in this preview You'll need to address these before migrating: Basic SKU public IP addresses — upgrade to Standard SKU. Basic SKU Load Balancer — upgrade to Standard Load Balancer. Unmanaged disks — convert to managed disks. The target zone must also support the VM's current size. You can check with: az vm list-skus --location <region> --zone --resource-type virtualMachines -o table How to get started Register the preview feature on your subscription: az feature register --namespace Microsoft.Compute \ --name RegionalToZonalVMMigrationForDeallocatedVM. Pick a non-production VM or scale set first. Walk through deallocate → assign zone → start, and confirm the VM comes up healthy in the new zone. Plan your zone strategy. For multi-VM workloads, distribute instances across zones 1, 2, and 3 so a single zone failure minimally impacts your workload. Roll out in batches for production scale sets, validating application health between batches.Announcing General Availability of Disable Multithreading and Configurable Constrained Cores
Today, we are announcing General Availability of two new capabilities: Disable Simultaneous Multithreading/Hyper-Threading (SMT/HT) and Configurable Constrained Cores. These features give customers control over virtual CPU configurations, enabling performance optimization and potential software licensing savings across a wide range of workloads. What's New: Disable Simultaneous Multi-Threading/Hyper-Threading (SMT/HT Off): Configure supported VMs to run with one thread per physical core, giving workloads improved performance and latency consistency. Custom vCPU Counts through Configurable Constrained Cores: Choose from a guided list of valid vCPU counts per VM size to match licensing rights or workload needs without changing memory, storage, or I/O capabilities. Why It Matters: The CPU options allow customers to tailor VM compute resources to their workload needs, improving both performance and cost efficiency. Performance-sensitive applications can leverage full-core isolation by disabling SMT/HT, while workloads such as SQL Server, Oracle, and SAP can reduce licensing costs by selecting the required vCPUs while maintaining the memory and bandwidth of larger VM sizes. The result is greater flexibility, simplified compliance, and lower total cost of ownership. "I'm really excited about the new Configurable Constrained Cores feature in Azure! Being able to run SQL Server on a larger memory and I/O footprint while only licensing the exact number of cores you need is a game-changer for right-sizing workloads and controlling costs without sacrificing performance." – Tim Radney, Data Platform MVP Getting Started: Disable SMT/HT and Configurable Constrained Cores are available in all Azure regions. Disable SMT/HT is supported on any VM series that has SMT/HT enabled by default. It is not applicable to VM families that have SMT/HT disabled by default. Refer to VM vCore Customization documentation to learn more and steps on getting started. Pricing: There are no VM pricing changes for these two features. Customers will be billed for the number of vCPUs defined in the original VM specification, not the number of threads of constrained vCPUs.Azure NCv6 Virtual Machines: Enhancements and GA Transition
NCv6 Virtual Machines are Azure's flexible, next generation platform enabling both leading-edge graphics and generative AI compute workloads. Featuring NVIDIA RTX PRO 6000 Blackwell Server Edition (BSE) GPUs, Intel Xeon™ 6 "Granite Rapids" 6900P series CPUs, and a suite of Microsoft Azure technologies, NCv6 VMs are available now in Preview. Today, we are pleased to share a series of exciting updates coming soon to Azure NCv6 that will: Enhance VM performance and capabilities Provide more VM sizes for customers to "right size" their usage Bring NCv6 to production readiness with a transition to General Availability, and Expand accessibility across the global Azure cloud New VM Sizes, Features, and Performance Enhancements In the coming weeks, Azure will debut seven new NCv6-series VM sizes and two different sub-families for customers to choose from. The standout features introduced with the new VM sizes include: 🧩 Fractional GPU support, enabling graphics workload customers to deploy VMs with as little as 1/2 or 1/4 of a RTX PRO™ 6000. VMs with fractional GPU support also feature reduced vCPU, memory, SSD, and networking to help customers optimize costs and right size their VMs to their workloads. ⚡ Increased vCPU per VM size (e.g. 288 vCPU instead of 256) to provide more performance for high-end VDI workstations and better align with the Intel Xeon 6900P's triple compute tile architecture. 🛠️ General Purpose and Compute Optimized VM sizes. The former provides larger amounts of CPU memory for demanding generative AI inference and ISV CAD/CAE simulations, while the latter offers reduced memory to enable customers with less memory intensive workloads to cost optimize their deployments. The new VM sizes will replace the existing three VM sizes offered in Preview, and be available as follows: NCv6 - General Purpose VM sizes: Size Name vCPUs Memory (GB) Networking (Mb/s) GPUs GPU Mem (GB) Temp Disk NVMe Disk Standard_NC36ds_xl_RTXPro6000_v6 36 132 22500 1/4 24 256 1600 Standard_NC72ds_xl_RTXPro6000_v6 72 264 45000 1/2 48 512 3200 Standard_NC144ds_xl_RTXPro6000_v6 144 516 90000 1 96 1024 6400 Standard_NC288ds_xl_RTXPro6000_v6 288 1032 180000 2 192 2048 12800 Standard_NC324ds_xl_RTXPro6000_v6 324 1284 180000 2 192 2048 12800 NCv6-Compute Optimized VM sizes: Size Name vCPUs Memory (GB) Networking (Mbps) GPUs GPU Mem (GB) Temp Disk NVMe Disk Standard_NC24lds_xl_RTXPro6000_v6 24 72 22500 1/4 24 256 1600 Standard_NC36lds_xl_RTXPro6000_v6 36 72 22500 1/4 24 256 1600 Standard_NC72lds_xl_RTXPro6000_v6 72 132 45000 1/2 48 512 3200 Standard_NC144lds_xl_RTXPro6000_v6 144 264 90000 1 96 1024 6400 Standard_NC288lds_xl_RTXPro6000_v6 288 516 180000 2 192 2048 12800 Standard_NC324lds_xl_RTXPro6000_v6 324 648 180000 2 192 2048 12800 Note that, until the new VM sizes are available, Microsoft Learn resources will continue to reflect the currently offered VM sizes and technical specifications. Transition to General Availability In the coming weeks, Azure will transition NCv6-series from Preview to General Availability (GA) status. With this transition, NCv6 VMs will become covered by the Azure Service Level Agreement (SLA) and thus ready to support production-grade deployments by customers, partners, and service providers. When the transition to NCv6 VMs occurs, they will be available in the Azure West US2 and Southeast Asia regions. Information on availability timing of additional regions is provided below. Regional Expansion Across the Azure Cloud At the beginning of Preview, NCv6 VMs debuted in the West US2 region. Since then, we have also added NCv6 VMs to the Southeast Asia region. Both regions will be part of the transition to GA status. We are pleased to share that in the proceeding months covering Q3 of 2026, NCv6 VMs will also become available in the following Azure regions: • East US • West Europe • East US 2 • North Europe • South Central US • Germany West Central • West US • Korea Central Ready to build for the future with Azure NCv6? NCv6 Virtual Machines are available now in Preview. Start your production-grade AI journey today and explore the next frontier of Azure AI infrastructure. Join the PreviewIncoming Changes for Window Server 2022 Marketplace Image Users
New Azure Marketplace Windows Server 2022 media images offer is available in March 2026 excluding .NET 6 packages. Migrate to the new images before June 2026. After June 2026, there will be no patch to .NET 6 on the legacy images, and the legacy image will start deprecation at the same time.Boost performance with NFS nconnect on Azure NetApp Files datastores for Azure VMware Solution
Azure VMware Solution now supports nconnect=4 with Azure NetApp Files datastores each ESXi host opens up to four parallel TCP connections to a single NFS datastore, raising throughput and lowering latency under load. Supported on both Gen 1 and Gen 2 private clouds, it makes Azure VMware Solution with Azure NetApp Files an even stronger home for databases and other storage‑intensive workloads.
