Merge pull request #2492 from MicrosoftDocs/main

Auto Publish – main to live - 2025-10-24 22:00 UTC

Author: learn-build-service-prod[bot]

articles/virtual-machines/capacity-reservation-remove-virtual-machine-scale-set.md

@@ -19,10 +19,11 @@ This article walks you through removing a virtual machine scale set association
 
 Because both the virtual machine (VM) and the underlying capacity reservation logically occupy capacity, Azure imposes some constraints on this process to avoid ambiguous allocation states and unexpected errors.
 
-There are two ways to change an association:
+There are three ways to change an association:
 
 - Deallocate the virtual machine scale set, change the capacity reservation group property at the scale set level, and then update the underlying VMs.
 - Update the reserved quantity to zero and then change the capacity reservation group property.
+- Delete the virtual machine scale set
 
 ## Deallocate the virtual machine scale set
 
@@ -241,6 +242,11 @@ To learn more, see the Azure PowerShell commands [New-AzCapacityReservation](/po
 --- 
 <!-- The three dashes above show that your section of tabbed content is complete. Don't remove them :) -->
 
+
+## Delete the virtual machine scale set
+
+Deletion process of a scale set remove its association from a capacity reservation. The delete request must complete before Azure removes it from the capacity reservation. Some latency can occur between the delete request and the corresponding change in capacity reservation allocation state. See [Delete a VM](/azure/virtual-machines/delete?tabs=portal2%2Ccli3%2Cportal4%2Cportal5) for more information. Use [Capacity Reservation Instance View](/azure/virtual-machines/capacity-reservation-associate-vm?tabs=api1%2Capi2%2Capi3#view-vm-allocation-with-the-instance-view) to check the allocation status as needed.
+
 ## Upgrade policies
 
 - **Automatic upgrade**: In this mode, the scale set VM instances are automatically dissociated from the capacity reservation group without any further action from you.

articles/virtual-machines/capacity-reservation-remove-vm.md

@@ -17,10 +17,11 @@ This article walks you through the steps of removing a virtual machine (VM) asso
 
 Because both the VM and the underlying capacity reservation logically occupy capacity, Azure imposes some constraints on this process to avoid ambiguous allocation states and unexpected errors.
 
-There are two ways to change an association:
+There are three ways to change an association:
 
 - Deallocate the virtual machine, change the capacity reservation group property, and, optionally, restart the VM.
 - Update the reserved quantity to zero and then change the capacity reservation group property.
+- Delete a VM.
 
 ## Deallocate the virtual machine
 
@@ -230,6 +231,10 @@ To learn more, see the Azure PowerShell commands [New-AzCapacityReservation](/po
 --- 
 <!-- The three dashes above show that your section of tabbed content is complete. Don't remove them :) -->
 
+## Delete a VM
+
+The virtual machine deletion process will remove a VM association from a capacity reservation. A VM delete must complete before Azure removes it from the capacity reservation. Some latency can occur between the delete request and the corresponding change in capacity reservation allocation state. See [Delete a VM](/azure/virtual-machines/delete?tabs=portal2%2Ccli3%2Cportal4%2Cportal5) for more information. Use [Capacity Reservation Instance View](/azure/virtual-machines/capacity-reservation-associate-vm?tabs=api1%2Capi2%2Capi3#view-vm-allocation-with-the-instance-view) to check the allocation status as needed.
+
 ## Next step
 
 > [!div class="nextstepaction"]

articles/virtual-machines/extensions/agent-linux-fips.md

@@ -12,10 +12,13 @@ ms.date: 09/25/2025
 ---
 # FIPS 140-3 support for Azure Linux VM Extensions and Guest Agent
 
-[What is the Federal Information Processing Standards (FIPS)](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips)
+> [!NOTE]
+> This feature is currently in **Public Preview**, production workloads are supported.
 
 Linux Virtual Machine (VM) Extensions currently comply with FIPS 140-2 but updates to the platform were required to add support for FIPS 140-3. These changes are currently being enabled across the Commercial Cloud and Azure Government Clouds. Linux VM Extensions that use protected settings are also being updated to be able to use a FIPS 140-3 compliant encryption algorithm. This document helps enable support for FIPS 140-3 on Linux VMs where compliance with FIPS 140-3 is enforced. This change isn't needed on Windows images due to the way FIPS compliance is implemented.
 
+- [What is the Federal Information Processing Standards (FIPS)](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips)
+
 ## Confirmed Supported Extensions
 
 - MICROSOFT.AKS.COMPUTE.AKS.LINUX.AKSNODE
@@ -92,6 +95,9 @@ az feature list | jq '.[] | select(.name=="Microsoft.Compute/OptInToFips1403Comp
 
 There are different methods available for opting-in each VM. The changes can be made at deployment for a new VM, or an existing VM can be altered to add the FIPS 140-3 enablement on the Azure platform.
 
+> [!WARNING]
+> We do not recommend using the below Opt-In methods on RedHat 9.5 and 9.6 using version 2.7.0.6 of WALinuxAgent on production systems. This is due to an issue that will surface after rebooting, after the FIPS enablement and subsequent reboot. In these VMs the `waagent.service` will enter an internal loop and never come to a "Ready" state, and because of this error, no extensions are able to function. For testing you can try the below "RedHat 9 Workaround".
+
 #### Deploying a new VM
 
 In order to deploy a new VM with FIPS 140-3 enablement turned on immediately, use an ARM Template or CLI and add the `enableFips1403Encryption` property to the `additionalCapabilities` section of the `virtualMachines` object definition
@@ -196,12 +202,10 @@ Minimum [Goal State Agent](https://github.com/Azure/WALinuxAgent/wiki/FAQ#what-d
 AutoUpdate.Enabled=y
 ```
 
-> [!WARNING]
-> For RedHat 9 versions using version 2.7.0.6 of WALinuxAgent, there's an issue that will surface after rebooting, after the FIPS enablement and subsequent reboot. In these VMs the `waagent.service` will enter an internal loop and never come to a "Ready" state, and because of this error, no extensions are able to function.
-
 ##### RedHat 9 Workaround
 
-Updating the Azure guest agent outside of the RedHat repositories, such as downloading the agent code from GitHub, is not advised. Doing an 'out-of-band' update in this way will cause inconsistent behavior with future package updates. Instead use the following code modification to remove a single function call and restore functionality
+> [!NOTE]
+> This workaround is intended for testing purposes only and does not support all VM deployment scenarios. After enabling FIPS on a running VM, execute the following commands to proceed.
 
 ```
 systemctl stop waagent