Managed Virtual Machines¶
Some workloads need virtual machines (VMs): software that does not run on a platform service, lifting-and-shifting an existing application, or a tool that needs full control of the OS. The Managed VM module is an optional building block of the platform that deploys such VMs in your spoke with a fixed baseline: security settings, access through groups, monitoring, backup and patching.
Optional offering
The Managed VM module is not part of the core MCP hub and spoke. Whether it is available, which version your platform runs and which options are enabled depends on your platform. Ask your platform team. The names, defaults and schedules on these pages are the usual values of the module; your platform may differ. Operators: see Managed VM module (platform side) and the pull request review runbook. For the scope of the service and its boundaries, read the service description.
Terminology¶
| Term | Meaning |
|---|---|
| Managed VM deployment | The supporting infrastructure the module deploys in a spoke so that managed VMs can exist (for example the backup vaults, a Key Vault and alert rules). One per spoke. |
| VM configuration | The description of one or more identical VMs: size, OS, disks, owners, backup, maintenance window. |
| VM configuration set | All VM configurations of one Managed VM deployment. |
| Workload | The business solution the VMs belong to. A workload usually maps to one spoke. |
| Spoke | The Azure subscription of your workload, see What you get. |
What you get¶
| Area | What the module does | Page |
|---|---|---|
| Service description | What is offered, how changes are made, and the boundaries | Service description |
| Request and change | Standard requests for a new deployment, a new or changed VM configuration, and removal | Request and change |
| Pull request | Prepare the change yourself, and what the reviewer checks | Prepare a Managed VM pull request |
| Operating system | Linux or Windows images, and where support ends | Operating system |
| Backup | Recovery Services vault (and optionally Backup Vault) with a default policy | Backup and restore |
| Updates | Azure Update Manager with maintenance configurations selected by a tag | Updates and patching |
| Cost | Auto-shutdown schedule by tag, reservations, disk review | Cost optimisation |
| On-premises servers | Optional onboarding with Azure Arc | Azure Arc |
Security defaults¶
| Setting | Effect |
|---|---|
| Encryption at host | Encrypts data on the VM host, including temporary disks and disk caches. Needs the feature to be registered on the subscription (Microsoft Learn). |
| Secure Boot | Only trusted, signed boot software runs during startup. |
| vTPM | A virtual TPM 2.0 chip for keys, certificates and measurements (for example BitLocker). |
| Storage account of the deployment | Public network access and shared access keys are disabled. |
| Boot diagnostics | Enabled, cannot be switched off. |
| Defender for Cloud plans | CloudPosture and VirtualMachines by default. The platform can change the plans. |
Secure Boot and vTPM are settings of the VM configuration that should be true.
Access¶
- Two groups per VM configuration are created: one gives the role Virtual Machine Administrator Login, the other Virtual Machine User Login.
- One or more owners are named in the VM configuration (people in Entra ID). Owners are administrators, can use the Serial Console, and decide who else gets access.
- Owners add members to the administrator or user group (in the portal: open the group in Microsoft Entra ID and add members). Members are eligible and activate the role in PIM, as described in Access, groups and PIM.
- Alternatively, the module can create access packages, so that owners assign users and administrators in the My Access portal of Microsoft. This is an option of the VM configuration.
- The local administrator credentials are stored in the Key Vault that is deployed with the VM.
- Entra ID login (
AAD Login) lets users sign in to the VM with their Entra ID identity. It is an option per VM configuration.
Connect¶
Use the central Azure Bastion host: no VM gets a public IP address unless you explicitly enable that option and the platform allows it. The generic steps are on Connect to virtual machines.
With Entra ID login enabled, use --auth-type "AAD" with the Azure CLI native client:
az login
az account set --subscription "<bastion subscription id>"
az network bastion ssh --name "<bastion name>" --resource-group "<bastion resource group>" \
--target-resource-id "<vm resource id>" --auth-type "AAD"
az network bastion rdp --name "<bastion name>" --resource-group "<bastion resource group>" \
--target-resource-id "<vm resource id>" --auth-type "AAD"
You find the resource ID in the portal: open the VM, then Settings → Properties → Resource ID.
Known limitation: RDP file for VMs with a long name
A Windows computer name is limited to 15 characters. If the Azure resource name of the VM is longer, the computer name differs from the resource name. The RDP file that the Azure CLI generates uses the resource name and then fails to connect.
Workaround: add --configure to the az network bastion rdp command, open the generated RDP file in a text editor
and replace the values of full address and alternate full address with the computer name (shown on the
Overview tab of the VM in the portal).
Monitoring¶
The module configures alert rules for CPU usage, memory usage, disk usage and availability of the VM. Backup job failures are alerted through the Recovery Services vault (Backup and restore). Other options of the VM configuration:
- Change Tracking and Inventory: tracks software and file changes on the VM.
- Custom alert rules on Log Analytics data.
Who receives the alerts is set per platform. Ask your platform team. Alerts about your application remain yours, see Operate your workload.
Responsibilities¶
| Platform team | Workload team (VM owners) | |
|---|---|---|
| Module, baseline, defaults, new versions | Yes | |
| Deploy, resize or remove VMs after a request | Yes | Requests |
| Patch schedule and tooling | Yes | Chooses the maintenance window and priority, checks that the application works after patching |
| Backup vault, policy and alerts | Yes | Decides retention, runs and tests restores |
| Inside the OS (disks, services, software, antivirus) | Yes | |
| Application, data and users on the VM | Yes |
The generic split is described in Responsibilities. The module and its support end at the boundary of the OS: partitioning a disk or mounting it, for example, is yours.