az vm update retains conflicting Capacity Reservation state when switching assignment modes

[ryo-whaletech]

Describe the bug

az vm update can retain conflicting persisted Capacity Reservation state when switching an existing VM between an explicit Capacity Reservation Group and disabled Capacity Reservation assignment.

If the existing VM has a capacityReservationGroup and the command explicitly sets --disable-capacity-reservation-assignment true, the outgoing update payload retains the group while also setting disableCapacityReservationAssignment to true.

The inverse transition has the same problem: when the existing VM has disableCapacityReservationAssignment: true and a real --capacity-reservation-group is assigned, the outgoing payload retains both properties.

disableCapacityReservationAssignment: false is valid alongside a Capacity Reservation Group and is not part of the defect.

Related command

az vm update --resource-group <RESOURCE_GROUP> --name <VM_NAME> --disable-capacity-reservation-assignment true

az vm update --resource-group <RESOURCE_GROUP> --name <VM_NAME> --capacity-reservation-group <CAPACITY_RESERVATION_GROUP_ID>

Errors

No CLI error is raised. Azure CLI instead constructs an outgoing request payload containing conflicting Capacity Reservation state:

{
  "capacityReservationGroup": {
    "id": "<CRG_ID>"
  },
  "disableCapacityReservationAssignment": true
}

This report does not claim a particular service-side error or data corruption.

Issue script & Debug output

I reproduced the behavior locally through the standalone VM update path and the generated AAZ request serializer.

Before the fix:

Existing CRG -> disable=true

{
  "capacityReservationGroup": {
    "id": "CRG-A"
  },
  "disableCapacityReservationAssignment": true
}

Existing disable=true -> real CRG

{
  "capacityReservationGroup": {
    "id": "CRG-B"
  },
  "disableCapacityReservationAssignment": true
}

For comparison, existing disable=false -> real CRG remains a valid state:

{
  "capacityReservationGroup": {
    "id": "CRG-B"
  },
  "disableCapacityReservationAssignment": false
}

No live Azure request was sent as part of this local reproduction.

Expected behavior

• Setting --disable-capacity-reservation-assignment true should remove a persisted Capacity Reservation Group from the outgoing update state.
• Assigning a real --capacity-reservation-group should remove persisted disableCapacityReservationAssignment only when that persisted value is true.
• Persisted or explicitly supplied false should remain valid with a Capacity Reservation Group.
• Omitted Capacity Reservation arguments and unrelated VM updates should preserve the existing state.
• A real Capacity Reservation Group combined with explicit --disable-capacity-reservation-assignment true should continue to be rejected by the existing CLI validation.

Environment Summary

azure-cli                         2.90.0

core                              2.90.0
telemetry                          1.1.0

Dependencies:
msal                              1.36.0
azure-mgmt-resource               24.0.0

Python location '<LOCAL_REPO>/.venv/bin/python'
Config directory '<TEMP_CONFIG_DIR>'
Extensions directory '<TEMP_CONFIG_DIR>/cliextensions'

Python (Darwin) 3.13.11 (main, Dec  5 2025, 16:06:33) [Clang 17.0.0 (clang-1700.4.4.1)]

Legal docs and information: aka.ms/AzureCliLegal

Azure CLI 2.90.0 was the latest released version when this issue was reproduced.

Additional context

The behavior is in the standalone az vm update state transition. The generated API model exposes capacityReservationGroup and disableCapacityReservationAssignment independently, while generic update begins with the existing VM state, so the command-specific update layer needs to reconcile the conflicting persisted value when the user explicitly switches assignment modes.

The issue is reproducible through the final AAZ serialized request content without sending a live Azure request.

The relevant standalone update behavior was added as part of #33901.

[yonzhan]

Thank you for opening this issue, we will look into it.