Conflicting Capacity Reservation States

“az vm update retains conflicting Capacity Reservation state when switching assignment modes ## 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 ```text 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: ```json { "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 ```json { "capacityReservationGroup": { "id": "CRG-A" }, "disableCapacityReservationAssignment": true } ``` Existing disable=true -> real CRG ```json { "capacityReservationGroup": { "id": "CRG-B" }, "disableCapacityReservationAssignment": true } ``` For comparison, existing disable=false -> real CRG remains a valid state: ```json { "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 ```text 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 throu”