Empty powerState while deleting in vm list -d

[gcormier]

The VM list has an empty power state, sometimes, for VM's, while the VM is being deleted.

(Same issue with AzureRM)

Command Name az vm list -d

To Reproduce:

Delete a VM, and while it is deleting, list VM's

Environment Summary

Linux-4.15.0-1063-azure-x86_64-with-debian-stretch-sid
Python 3.6.5
Shell: bash
azure-cli 2.0.76

az cli

az vm list -d -g HPC-FVCOM-RG --query '[].[name,powerState,provisioningState]'
[
  [
    "hpc-fvcom-vm1",
    "VM running",
    "Deleting"
  ],
  [
    "hpc-fvcom-vm2",
    "",
    "Deleting"
  ]
]

AzureRM

PS Azure:\> Get-AzureRmVM -Status

ResourceGroupName          Name Location          VmSize OsType            NIC Provisioning Zone         PowerState MaintenanceAllowed
-----------------          ---- --------          ------ ------            --- ------------ ----         ---------- ------------------
HPC-FVCOM-RG      hpc-fvcom-vm1   eastus Standard_Hc44rs  Linux hpc-fvcom-nic1     Deleting                 running
HPC-FVCOM-RG      hpc-fvcom-vm2   eastus Standard_Hc44rs  Linux hpc-fvcom-nic2     Deleting      Info Not Available

[fengzhou-msft]

@qwordy please take a look.

[qwordy]

@qwordy please take a look.

OK

[yungezz]

hi @gcormier could you pls share more what's expectation here? deleting is an state that vm is under deleting, powerstate could be different based on deleting progress. The powerstate is from service, that's also reason why az cli and AzureRM has consistent output.

[gcormier]

@yungezz "Power State not available" shouldn't be there. It must have a state, either on, off, powering on, powering off...

[yungezz]

this need to be improved at service side.

[Drewm3]

NULL is a valid response for power state. There are instances where the control APIs are unable to get the authoritative power state from the underlying services which will result in NULL being returned for the power state. This is never a long term expected response, but clients must be able to support NULL being returned for the power state. Please see the related issue for additional details: https://github.com/Azure/azure-libraries-for-net/issues/630

[yungezz]

thanks @Drewm3 for the info. what's the suggested status to be showed to end user if NULL from service?

[gcormier]

I have some VM's in an unknown state for 20-30 minutes while de-provisioning. If this is working as intended, the billing documentation needs to be updated to clarify if you are charged for unknown powerstate or not

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/states-lifecycle

[Drewm3]

@yungezz, for NULL state the end user should be shown unknown as the string.

@gcormier, the billing of the VM is not driven from the powerstate, but they are both from the same source. The billing result depends on if the VM is actually deployed to the physical host server. If it is deployed to the server in any state (running, stopped, starting, stopping/deleting, etc) that is using the physical server resources, then the VM is billed. These states also drive the result of powerstate, but the path for the data to get to the customers for billing is a different path than how a customer gets the powerstate. So if the path to get the powerstate has issues then unknown may be returned. However, the billing path is separate and may still function correctly. Therefor there is not a specific billing statement that can be made for the VM if the status is unknown through the control plane APIs.

[gcormier]

The customer experience here is undefined and needs improvement, probably on the documentation side?

From that page, "The power state represents the last known state of the VM.". In this case, the API doesn't know the last state of the VM. Although programmatically that doesn't make sense to me - this status should reflect the last known state - if the current state is unknown, it shouldn't return this information - it should return the last known state.

(If destroying a VM took seconds, this point would be moot, but I have Hc44RS instances that can take 30 minutes to destroy, and I don't know if I'm being billed during that time. I know it seems trivial, but we're running dozens of instances for HPC at the moment but that can grow to hundreds once the testing is complete)

I'll also tag the documentation team.