Request, Change and Remove a Managed VM¶
All changes to managed VMs are standard changes: you describe what you want, the platform team changes the VM configuration in code, has it reviewed and deploys it. You do not change the VM size or disks in the portal, because the next deployment would undo it.
Which intake you use depends on your platform (Operating models). Two forms exist:
| Form | How it works |
|---|---|
| Request form | You answer the questions on this page in a ticket or work item. The platform team edits the VM configuration. |
| Pull request | You edit the VM configuration file for your spoke yourself and open a pull request, plus a ticket that links to it. The platform team reviews, merges and deploys. Only for teams that have been given access to the configuration repository. |
Request types¶
| Request | Needs an existing spoke | Notes |
|---|---|---|
| New Managed VM deployment | yes | One-off per spoke. Prepares the supporting infrastructure. |
| New VM configuration | yes, and a deployment | The VM or the group of identical VMs. |
| Change a VM configuration | See Change a VM configuration. | |
| Remove a VM configuration | Removes the VMs of that configuration. | |
| Remove a Managed VM deployment | Removes the supporting infrastructure of the spoke. Permanent. |
New Managed VM deployment¶
| Field | Required | Notes |
|---|---|---|
| Spoke | yes | The spoke the deployment goes to. |
| Workload short name | yes | Identifies all VM configurations of the deployment. Together with the configuration short name it is limited to a total length (for example 8 characters in non-production and 11 in production). Ask your platform team for the limit. |
New VM configuration¶
When a field is optional, the default applies.
| Field | Required | Default | Notes |
|---|---|---|---|
| Spoke | yes | ||
| Environment | yes | Production or non-production. Decides defaults such as the shutdown policy and reservation rules. | |
| Configuration short name | yes | See the length limit above. | |
| Display name | yes | A friendly name. | |
| Location | yes | Only regions your platform runs in. | |
| Size | yes | The VM SKU. See VM sizes. Check quota for large sizes. | |
| Instances | no | 1 | Number of identical VMs. |
| Owners | yes | People (as in Entra ID) who manage the configuration and who assign other users. | |
| OS type | yes | linux or windows. See Operating system. |
|
| OS SKU | no | latest Ubuntu LTS (Linux) or the latest Windows Server Datacenter | The module maps its own SKU names to Azure images. |
| OS disk size (GB) | no | 128 | |
| OS disk storage type | no | StandardSSD_ZRS |
Standard_LRS, StandardSSD_LRS, Premium_LRS, StandardSSD_ZRS, Premium_ZRS. |
| OS disk caching | no | ReadWrite |
None, ReadOnly, ReadWrite. |
| Data disks | no | none | Per disk: size in GB and type (Standard_LRS, Premium_LRS, StandardSSD_LRS, StandardSSD_ZRS, Premium_ZRS, PremiumV2_LRS, UltraSSD_LRS; default StandardSSD_ZRS). |
| Auto-shutdown hours | no | none | Time at which the VM configuration shuts down. See Cost optimisation. |
| Domain join | no | false | Windows only. |
| Public IP | no | false | Normally not wanted: use Bastion. Your platform's policy may forbid it. |
| Allow update reboots | no | false | Whether the VM may reboot in the maintenance window. See Updates and patching. |
| Use access packages | no | true | Owners assign users in the My Access portal. Some platforms no longer use access packages and prefer false. Ask your platform team which applies. |
| Entra ID login | no | false | You almost always want true. |
| Change Tracking and Inventory | no | false | |
| Maintenance window | no | weekly, Monday 03:00 to 05:00 | When updates may be installed. See Updates and patching for the platform-wide schedules. |
| Exclude package names | no | none | Linux packages to exclude from patching. Wildcard * allowed. |
| Exclude KB numbers | no | none | Windows updates to exclude. Specific KB numbers only. |
| Backup solution(s) | no | Recovery Services vault | See Backup and restore. |
| RPO and retention per solution | no | RPO 8 hours, retention 28 days | See Backup and restore. |
Check the cost before you ask
Disk tier and VM size drive most of the monthly cost. Run the disk review before you submit, see Cost optimisation. Production VMs that run all day need a reservation, see Cost and reservations.
Change a VM configuration¶
Send only the fields that change, plus the spoke and the configuration short name.
| Change | Extra fields | Remarks |
|---|---|---|
| Add or remove owners | Add or remove, list of owners | |
| Resize the VM configuration | Desired SKU | The VM restarts. Check quota first. |
| Change the number of instances | Number of instances | |
| Add a data disk | Size in GB, type (default StandardSSD_ZRS) |
|
| Remove a data disk | Which disk, as a 0-based index in the data_disks list of the configuration |
Data on it is gone after the change. |
| Resize an attached disk | OS disk or data disk (index), new size in GB | Disks can only grow, never shrink. |
| Change the maintenance window | The new window | |
| Change backup parameters | Backup solution(s), RPO, retention | The RPO of the Backup Vault can't be changed afterwards. |
| Change auto-shutdown time | The new time | |
| Switch features on or off | Public IP, update reboots, access packages, Entra ID login, Change Tracking and Inventory, domain join | Fields you leave empty stay as they are. |
Resize and disk removal restart or delete
Resizing a VM restarts it. Removing a data disk deletes the data on it. Agree a time with the users of the VM and take a backup first when the data matters.
Remove a VM configuration or a deployment¶
| Request | Fields |
|---|---|
| Remove a VM configuration | Spoke, configuration short name |
| Remove a Managed VM deployment | Spoke |
Removal is permanent. Ask your platform team whether the VM configurations have to be removed before the deployment. Check whether you need a final backup or restore point, and how long the vault keeps its recovery points after the VMs are gone (Backup and restore).
What happens after you ask (pull request form)¶
- You open a pull request with the new or changed VM configuration, and a ticket that contains the link to the pull request. Do not complete the pull request yourself.
- The platform team or your own architecture team reviews the pull request (design review).
- The platform operator reviews, merges and deploys the change.
- You are informed and the ticket is closed.
How to prepare the pull request, and what the reviewer checks, is described in Prepare a Managed VM pull request. Two practical points for the pull request form:
- Start from the template file for the environment in the configuration repository (one file per spoke and environment).
- For a new spoke folder, the spoke must also be added to the list of spokes in the deployment pipeline. Otherwise nothing is deployed. The platform team normally does this: mention it in the ticket.
See Support for what to include in a ticket and How to request for the general request process.