What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Azure VM lifecycle states tell you two different things: the VM’s current runtime condition (such as Running, Stopped (Allocated), or Stopped (Deallocated)) and the progress of a management operation (such as Updating or Succeeded). Read the power-state code to determine whether the guest can run workloads and whether compute billing continues. A provisioning status by itself does not prove that the VM is running.
For cost control, use deallocate, not merely a guest-OS shutdown. A deallocated VM releases its host allocation and does not incur VM instance usage charges, although its disks and networking resources can still be billed. Hibernation is a separate, supported form of deallocation that preserves memory on the OS disk but has stricter requirements and restart limitations.
Azure uses three separate status dimensions
The Azure portal and APIs can display several status codes at once. Treating them as one status is the source of many mistaken billing and troubleshooting decisions.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Power state
Microsoft describes the power state as “the last known state of the VM.” It describes the runtime transition: creating, starting, running, stopping, stopped, deallocating, or deallocated. The example code is PowerState/running. This is the status to use when you need to know whether the VM is available for workloads and whether compute allocation normally remains.
#1 Best Overall
Provisioning state
Provisioning state reports a user-initiated control-plane operation, not the guest’s current power condition. Documented values include Creating, Updating, Failed, Succeeded, Deleting, and Migrating. Starting, restarting, resizing, or changing a VM can leave provisioning in Updating while Azure completes the operation.
Provisioning succeeded means the requested management operation completed successfully. It does not mean the machine is currently powered on. Always read the power-state code alongside it.
OS provisioning state
OS provisioning is a substate used for VMs created from generalized OS images. It can show guest setup progress and extension installation. Specialized images and VMs that use an attached OS disk do not expose that separate OS-provisioning state. A healthy control-plane provisioning result and a completed OS-provisioning result still need to be interpreted together with the power state.
What each Azure VM power state means
| Power state | Meaning | VM instance usage charge |
|---|---|---|
| Creating | Azure is allocating resources while the VM is being created. | Not billed for VM instance usage during this state. |
| Starting | The VM is powering up and moving toward a usable running state. | Billed. |
| Running | The VM is fully up in its normal working state and can accept workloads. | Billed. |
| Stopping | Azure is transitioning the VM from running to stopped. | Billed until the transition reaches a non-running final state. |
| Stopped / Stopped (Allocated) | The guest is powered off, but the VM remains allocated on a host. This can result from an API power-off or a shutdown initiated inside the guest OS. | Billed. |
| Deallocating | Azure is releasing the VM’s underlying host allocation. | Not billed for VM instance usage during this transition. |
| Deallocated / Stopped (Deallocated) | The VM has released its lease on the underlying hardware and is no longer consuming a compute allocation. | Not billed for VM instance usage. |
“Not billed” in the table means no VM instance or compute usage charge. Managed disks, snapshots, public IP addresses, network interfaces, and other attached resources can continue to generate charges. Deallocation therefore reduces the compute portion of a bill; it does not remove every Azure resource charge.
Stopped versus deallocated: the distinction that affects cost
Stopped (Allocated)
A stopped-allocated VM is not executing guest workloads, but Azure keeps its host allocation. Because the allocation is retained, compute billing continues. This state can be useful when you want a quick return to service and intentionally accept the charge, or when an operation requires the VM to remain provisioned.
Stopped (Deallocated)
A stopped-deallocated VM has released its host lease. It cannot accept workloads until it is started and allocated again, but VM instance usage charges no longer apply. The practical cost-saving workflow is to request deallocation, wait for completion, and verify that the final status says PowerState/deallocated or the portal label Stopped (Deallocated).
A guest shutdown is not the same as deallocation
Shutting down Windows or Linux from inside the guest can leave the Azure resource in Stopped (Allocated). The operating system is off, yet the Azure compute allocation remains. If the objective is to stop compute billing, use Azure management tools to deallocate the VM and then check the resulting power state.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to check the current state
Azure portal
- Open Virtual machines in the Azure portal and select the VM.
- On the VM’s Overview page, read the displayed power status. Look for Running, Stopped (Allocated), or Stopped (Deallocated), rather than relying on a generic health indicator.
- Open the status or instance-view details when available to see power, provisioning, and OS-provisioning codes separately.
- After selecting Stop, Start, or another control, wait for the operation to finish and refresh the page before starting a dependent action.
Azure Resources Explorer is another Microsoft-documented interface for viewing Instance View data. It is useful when the portal’s summary label does not explain which status dimension is changing.
PowerShell
Retrieve the VM and its status codes with:
Get-AzVM -ResourceGroupName <group> -Name <vm> -Status
Inspect the returned status collection for the PowerState/... code and read provisioning entries separately. A result containing ProvisioningState/succeeded and PowerState/stopped, for example, means the last control-plane operation succeeded while the VM remains powered off.
Bulk checks with the Azure API
For inventory or scheduled checks, Microsoft’s Virtual Machines List All API supports statusOnly=true. That option returns status information without requiring a full resource inspection for every VM. Use the power-state value to identify machines that are still allocated and therefore still accruing compute usage.
Rank #3
How to change a VM’s state safely
Start a stopped or deallocated VM
- Confirm that the VM is not already in Starting, Stopping, or Deallocating.
- In the portal, open the VM and select Start, or run
az vm start -g <group> -n <vm>. - Wait for the operation to complete. Verify
PowerState/runningand a successful provisioning result before sending workloads to the guest.
A start from deallocated requires Azure to obtain capacity again. Deallocation lowers cost but does not reserve a future host or guarantee an immediate restart.
Stop while retaining allocation
Use this only when the intention is to power off the guest while keeping the VM provisioned. The portal’s stop action can leave the VM in Stopped (Allocated). PowerShell’s Stop-AzVM supports a -StayProvisioned option when retaining provisioning is specifically required. Because the host allocation remains, compute charges continue.
Stop and deallocate
- Initiate the deallocate action from the VM’s management controls, or use the Azure CLI command:
az vm deallocate --resource-group <group> --name <vm>- Wait until the operation leaves Deallocating.
- Check the final status and confirm Stopped (Deallocated) or
PowerState/deallocated.
Do not start a resize, disk change, or automation step that assumes deallocation until the final state has been confirmed.
Restart
Restart reboots the VM rather than releasing its host allocation. During the operation, provisioning may show Updating. A restart is appropriate for applying a reboot-required change or recovering a guest that is still allocated; it is not a cost-saving substitute for deallocation.
Redeploy
Redeploy shuts down the VM, moves it to a new physical node, and powers it back on. It is a recovery action for suspected host or allocation problems, not a normal stop/start method. Because it changes the underlying node, plan for a reboot and verify application behavior afterward.
Recommended Free Tools
Reapply
Reapply can rerun VM provisioning after certain failed state or network-resource operations. Use it only when the documented troubleshooting path for the specific failure calls for it, then inspect both provisioning and power status again.
Hibernated (Deallocated): a different kind of stop
Hibernation is a supported way to deallocate a VM while preserving the guest’s memory image. Azure signals the operating system to suspend to disk, stores memory contents on the persistent OS disk, and releases the underlying hardware lease. A hibernated VM does not incur VM instance usage charges, but its disks and networking resources can remain billable.
Requirements and limitations
- The VM size and operating system must support Azure hibernation.
- Hibernation must be enabled on the VM.
- The persistent OS disk must have enough space for RAM contents in addition to the operating system and applications.
- Hibernation must be initiated through Azure management tools. Suspending the guest from inside the OS alone does not place the Azure resource into the hibernated state and can leave compute billing in effect.
- Azure does not guarantee that sufficient capacity will be available when a hibernated VM is started later.
- Data on the temporary disk is not persisted through hibernation.
Hibernation versus ordinary deallocation
Ordinary stop-and-deallocate shuts the VM down without preserving memory. It gives you the broadest set of maintenance options while the VM is deallocated, including resizing and disk or network-interface changes when those operations are otherwise supported. Hibernation preserves memory for a faster-resume style workflow, but resizing and attaching or detaching disks or NICs are restricted until the VM reaches an appropriate running or stopped state.
| Consideration | Stopped (Allocated) | Stopped (Deallocated) | Hibernated (Deallocated) |
|---|---|---|---|
| Can accept workloads now | No | No | No |
| Host allocation retained | Yes | No | No |
| VM instance usage charge | Yes | No | No |
| Memory preserved | No | No | Yes, on the persistent OS disk |
| Temporary-disk data preserved | Not applicable to memory preservation | No | No |
| Future start capacity guaranteed | Allocation is retained while stopped | No | No |
| Resize or disk/NIC changes while in the state | Depends on the operation | Generally the flexible maintenance state | Restricted until the VM changes state |
Why a deallocated VM may not start
The most important distinction is between a power-state problem and an allocation or provisioning error. A VM can be correctly deallocated and still fail to start because Azure cannot place the requested size in the selected region or zone at that moment.
Capacity allocation failure
Azure may have insufficient capacity for the VM size in the chosen region or zone. Microsoft’s recommended remedies are to retry, select another size, or try another region or zone, depending on the deployment. A successful prior run does not guarantee capacity after deallocation.
Availability-set placement
For VMs in an availability set, deallocating only some members can require Azure to allocate a replacement on the original cluster. In cases documented by Microsoft, deallocating all applicable VMs and then starting them again can work around that placement constraint. This is a disruptive operation: plan for every affected VM to be unavailable and verify the application’s quorum and dependency requirements first.
Provisioning or resource errors
Read the activity log and deployment error associated with the failed start. Do not infer the cause from a stale PowerState label. A failed network-resource update, extension, disk attachment, or other control-plane operation can require reapply or a resource-specific fix before another start attempt.
A practical recovery sequence
- Capture the exact power-state, provisioning-state, and activity-log error.
- Check whether the requested size and zone currently have capacity.
- Retry once if the error is transient.
- If capacity is the issue, test an alternate size or approved region/zone.
- If the VM belongs to an availability set, evaluate the all-members deallocation workaround.
- After the VM starts, verify both
PowerState/runningand the guest’s application health.
Do not confuse VM runtime state with VM size-series lifecycle
Azure also uses “lifecycle” to describe the age of a VM size series. That is a product-family classification, not the moment-to-moment state of an individual VM.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Size-series stage | Meaning | What to do |
|---|---|---|
| Current | The newest series in a VM family. | Recommended for new deployments. |
| Extended | Fully supported, but a newer series exists. | Suitable for existing workloads while you evaluate migration. |
| End of Life | Retirement has been announced. | Plan modernization before the announced date. |
| Retired | The series is no longer available to create, resize into, or run. | Migrate to a supported series. |
Capacity-growth restrictions are separate from retirement. Microsoft’s 2026 lifecycle information lists Dv3, Dsv3, Ev3, and Esv3 sizes as subject to capacity-growth restrictions beginning in July 2026, with retirement on November 15, 2029. Those dates apply to the named series in that notice, not to every Azure VM. Check the current family and retirement pages before making a deployment decision because lifecycle schedules can change.
Quick Recap
Choose the state by operational goal
| Goal | Preferred action | Reason and caution |
|---|---|---|
| Keep the VM off but return quickly, accepting compute cost | Stop and retain allocation | Use Stopped (Allocated); host placement remains and compute billing continues. |
| Eliminate VM compute usage while idle | Stop and deallocate | Verify Stopped (Deallocated); disks and networking can still cost money, and a later start needs capacity. |
| Resume with memory contents preserved | Hibernation | Use only with a supported size/OS, sufficient OS-disk space, and acceptance of capacity and maintenance restrictions. |
| Apply a reboot-required change | Restart | Reboots the guest but does not release the compute allocation. |
| Investigate a suspected host problem | Redeploy | Moves the VM to another node and powers it back on; expect disruption. |
| Repair a failed provisioning operation | Reapply or follow the resource-specific fix | Use the activity/deployment error to select the remedy; status labels alone are insufficient. |
Operational checklist
- Read the power state, provisioning state, and OS-provisioning state as separate fields.
- Use Stopped (Deallocated) as the verification target when the goal is to stop VM instance usage charges.
- Remember that disks, public IPs, network interfaces, and other resources can remain billable after deallocation.
- Wait for Stopping or Deallocating to finish before issuing dependent commands.
- Before deallocating production systems, confirm that scheduled jobs, monitoring, backup, and startup automation will behave correctly.
- Assume that a future start can encounter regional or zonal capacity limits.
- For hibernation, verify support, OS-disk capacity, and the prohibition on temporary-disk persistence.
- Check VM size-series lifecycle notices independently from runtime status, especially before a resize or new deployment.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
