Whitepaper 'FinOps and cost management for Kubernetes'
Please consider giving OptScale a Star on GitHub, it is 100% open source. It would increase its visibility to others and expedite product development. Thank you!
Webinar 'FinOps and cloud cost optimization for ML/AI workloads.' Register here →
Ebook 'From FinOps to proven cloud cost management & optimization strategies'
OptScale — FinOps
FinOps overview
Cost optimization:
AWS
MS Azure
Google Cloud
Alibaba Cloud
Kubernetes
OptScale — MLOps
ML/AI Profiling
ML/AI Optimization
Big Data Profiling
OPTSCALE PRICING
Acura — Cloud migration
Overview
Database replatforming
Migration to:
AWS
MS Azure
Google Cloud
Alibaba Cloud
VMWare
OpenStack
KVM
Public Cloud
Migration from:
On-premise
Acura — DR & cloud backup
Overview
Migration to:
AWS
MS Azure
Google Cloud
Alibaba Cloud
VMWare
OpenStack
KVM

Detect incorrectly stopped Azure VMs

Problem description: 'Stopped' and 'deallocated' states of an inactive VM

How-to-detect-incorrectly-stopped-Azure-VMs

In clouds your VMs are temporarily leasing a part of the compute power of the hypervisor costs, and you pay money for that. It is obvious that you pay for them when your VM is powered on, but there are some cases where your VM may still consume money for сompute even if it is turned off.

The most annoying thing regarding charges for turned off VMs is the Azure’s difference between ‘stopped’ and ‘deallocated’ states of an inactive VM. The underlying mechanism is the following:

  1. When you stop your VM using Azure portal, it goes to “Stopped (deallocated)” state in the portal. This means that Azure has destroyed your VM instance on the hypervisor host and released all connected resources, like non-static Public IPs related to this. VM.You don’t pay compute costs for a VM in this state.
  2. When you stop your VM via Guest OS call, it goes to “Stopped” state in the portal. Unlike the previous case, the VM won’t be destroyed on its hypervisor host, so you still rent a part of the hypervisor and pay money for that. In most cases this is not what you want. Actually, the only scenario when you would like to have a machine in “Stopped” state is if you want to shut it down for some very short period of time and save non-static Public IPs connected to it.

How to detect not deallocated VMs

So, you want to scan the subscription for stopped, but not deallocated VMs. It can be done manually through the Azure portal, but as this task should be done periodically, Azure CLI is a much better way to perform this check. az vm list command is a very handy way to show VMs in some subscription (with –subscription parameter) and even to filter them by some condition and format output (using –query parameter). But machine state is not shown in this command output due to performance reasons. Therefore, we should use az vm show command with -d parameter set. The next thing to handle – we want to scan the whole subscription for such VMs while az vm show requires either the name of the VM or a list of the VM IDs as an input parameter. So, the first step is to make a quick az vm list query and format its output as IDs list. And at last, we filter output by VM’s powerState field, also noting that API response has a slight difference in VM state naming: “Stopped (deallocated)” in portal is shown as “VM deallocated”, while “Stopped” state is “VM stopped” in the API response. Polishing with some output formatting, and here is the command for detection of incorrectly stopped VMs:
az vm show -d --ids $(az vm list --subscription --query "[].id" -o tsv) --query "[?powerState=='VM stopped'].{Id:id, ResourceGroup:resourceGroup}" --output table

You can execute this command in Bash console integrated into Azure portal or set up a periodical job to check your subscriptions.

Max Bozhenko, FinOps enthusiast and practitioner, CTO at Hystax

Enter your email to be notified about new and relevant content.

Thank you for joining us!

We hope you'll find it usefull

You can unsubscribe from these communications at any time. Privacy Policy

News & Reports

FinOps and MLOps

A full description of OptScale as a FinOps and MLOps open source platform to optimize cloud workload performance and infrastructure cost. Cloud cost optimization, VM rightsizing, PaaS instrumentation, S3 duplicate finder, RI/SP usage, anomaly detection, + AI developer tools for optimal cloud utilization.

FinOps, cloud cost optimization and security

Discover our best practices: 

  • How to release Elastic IPs on Amazon EC2
  • Detect incorrectly stopped MS Azure VMs
  • Reduce your AWS bill by eliminating orphaned and unused disk snapshots
  • And much more deep insights

FinOps and cloud cost optimization for ML/AI workloads

Join our live demo on 27th 
March and discover how OptScale allows running ML/AI or any type of workload with optimal performance and infrastructure cost.