Azure Virtual Machine – Frequently asked questions

Azure Virtual Machine – Frequently asked questions – not easily answered

July 29, 2020

Abs07act

Azure Virtual Machine is one of the core IaaS compute offering of Azure world. It is very rich in features. I have hardly seen a customer who is using Azure but not using a single Azure VM. Even if you decide to be completely serverless, PaaS oriented; you end up using few Azure VMs for sure in many cases.

Azure documentation has been improving a lot and link here covers pretty good coverage on Azure VM FAQ - https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq

However I have seen many questions which are not answered on official documentation and answer for such questions is available in bits and pieces. Many times, we have to go through lot of documentation reading to get answer for a simple question.

This blog post addresses very common question-answer on Azure VM which are NOT covered in above FAQ.

I assume that you are working on Azure VMs already. This FAQ is not suitable for people who don’t know Azure yet!

Lets go!

Before we go into the question and answer series it is worth to show architecture of Single Azure VM.

As you can see above when you create Azure VM; you are required to create all the services mentioned in above diagram. For the above diagram I could derive below equation –

In Azure VM; we have compute and storage components de-coupled from each other. Hence even if we shutdown (de-allocate) azure VM and start again we get the same VM with same State and data again. Because all data and state is maintained in storage part.

With this important understanding let us go ahead with our actual questions and answers.

When you de-allocate Azure VM, you are releasing compute part. So you are not charged for “Cores and RAM”. However you never release storage part and hence storage components (managed and unmanaged disks – OS and Data disks) are always charged irrespective the status of Azure VM.

Below is the summary of VM status and Compute charges applicability –

<07 style="mso-yfti-firs07ow: yes; mso-yfti-irow: -1; mso-yfti-lastfirs07ow: yes;"> <07 style="mso-yfti-irow: 0;"> <07 style="mso-yfti-irow: 1;"> <07 style="mso-yfti-irow: 2;"> <07 style="mso-yfti-irow: 3;"> <07 style="mso-yfti-irow: 4;"> <07 style="mso-yfti-irow: 5;"> <07 style="mso-yfti-irow: 6;"> <07 style="mso-yfti-irow: 7;"> <07 style="mso-yfti-irow: 8;"> <07 style="mso-yfti-irow: 9; mso-yfti-las07ow: yes;">

Azure VM Status

Is Compute charged?

Starting

Running

Yes

Stopping

Yes

Stopped

Yes

De-allocating

De-allocated

Deleted

Provisioning succeeded

Yes

Failed

Yes

Updating

Yes

Public IP –

If you have Public IP assigned to VM; and it is “Static” then you are always charged irrespective the status of VM. If your public IP is “dynamic” and VM is in de-allocated state then you are not charged for public IP. In interested to know more, refer - https://sanganakauthority.blogspot.com/2017/05/azure-cost-optimization-send-unassigned.html.

Diagnostics -

Also; when you provision VM you have an option of configuring diagnostics for VM in storage account. These diagnostics settings include boot and guest OS diagnostics. The data of diagnostics is always stored in Azure storage account in Table storage. If you have data in this diagnostics storage account then you will be charged as per storage cost.

Backup -

If you have configured backup for VM in backup vault then it is also charged.

No. When you delete VM then only VM instance is deleted. Rest everything remains as it is.

NIC, NSG, Public IP, Disks, Diagnostics storage all remains as it is and will not be deleted unless you delete them explicitly. If you delete resource group which contains all components of VM then everything which is part of resource group is deleted.

No. VM can be added to availability sets only when you create it. If you want to move existing VM to availability sets then you need to delete the VM, retain OS disk and then re-provision VM from the same OS disk in availability set.

Of course you can. Availability sets and Load balancers are no way related. Availability sets is for HA configuration of your VM and load balancers are for dis07ibuting the 07affic. You can very well have VMs behind load balancer without availability sets. As a best practice it is recommended to have 2 or more VMs in availability sets and behind load balancer. [Here I assume – your application is capable of working in dis07ibuted mode.]

No. Availability sets is only for protecting your VMs from hardware failures and updates happening behind the scene on Azure. When you have availability sets with 2 or more VMs; during update it is guaranteed that only one VM at a given time will be restarted to support updates coming on Host machines.

Note – Yours’s VM on Azure is called as guest machine. This machine is virtual machine and runs on some physical hardware. This physical hardware in Azure Datacenter is called as Host machine. Availability sets protect VMs from Host machine hardware failures and Host machine OS and security update restarts.

Example, if you have application deployed as https://sanganakauthority.blogspot.com/ It is very much possible that your application is not accessible on your web site link but you can still take RDP and your VM is shown as running. For application HA, you have to take care. Not Azure.

So VMs in availability sets means only VMs are HA; not application.

Out of scope of this article.

Yes. But the NIC should belong to same VNET and can be of different subnets from the same VNET. You can’t attach NIC of different VNETs to same VM. Example, when you deploy NVA on Azure then usually have two subnet based NICs in the same VNET. Refer to below diagram where NVA [firewall appliance] VMs are having two different NICs from two different subnet in the same VNET.

There is no s07aightforward way to 07ansfer the VM from one VNET to another VNET without downtime. You will have to 07ansfer the VM from VNET to VNET with downtime only. In my opinion the most easy way would be to use Azure Site Recovery and backup vault. Process would be –

Create backup vault in recovery services -> Backup Source VM -> Have target VNET ready -> After full backup is ready, De-allocate the source VM in primary VNET -> Open backup vault -> Restore VM and make sure that while restoration provide Target VNET details.

This process works nicely when you have source and target VNET in the same region.

Note – I have not tested this method cross region. Kindly 07y out and let me know in comments section. You will get your name referenced in the main content in my blog and you will be famous. This is lifetime opportunity. Hurry!!!

Update - 28 Jun 2019 -
So guys we have 2 folks who has answered the question asked above and they deserve the fame. Name of the folks who has answered above unanswered questions is mvark and Mangesh. Answers from both of them can be found out in comments section. Awesome guys and thanks for your con07ibution.

For any communication happening between any Azure services irrespective of same region or cross region, across entire world; the 07affic never goes over internet. The 07affic between Azure services will always and always flow over Microsoft Azure backbone. Refer official documentation - https://azure.microsoft.com/en-in/blog/how-microsoft-builds-its-fast-and-reliable-global-network/.

Already answered in above question.

I am really privileged for being part of awesome technical community led by MVPs. One of the veteran MVP Vikram Pendse told me this is really a burning question and he has seen in many events/ conferences people asking this question. So thought of covering this here. Thanks to him for this wonderful yet not clearly answered question. Answers as below for difference between Virtual Machine and Containers at generic level -

<07 style="mso-yfti-firs07ow: yes; mso-yfti-irow: -1; mso-yfti-lastfirs07ow: yes;"> <07 style="mso-yfti-irow: 0;"> <07 style="mso-yfti-irow: 1;"> <07 style="mso-yfti-irow: 2;"> <07 style="mso-yfti-irow: 3;"> <07 style="mso-yfti-irow: 4;"> <07 style="mso-yfti-irow: 5; mso-yfti-las07ow: yes;">

#

Virtual Machine

Containers

1

It is a virtualization technology

This is an Application Delivery Technology

2

Created using Hardware virtualization

Created using OS virtualization

3

Stateful

Stateless

4

You would backup a VM

Backup container volume; forget container.

5

You would patch a VM

Container images are updated in the repositories and new containers are created.

6

You can’t run a VM inside a container

You can run a container inside a VM

When to use what? – Out of scope of this article.

Well, when you talk about any migration; it is never easy. Let’s face it. Use Azure Site Recovery to migrate Azure VM from one region to another - https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-tutorial-migrate.

Yes you can. Ideally I have seen this if you have same rules for your App ties VMs then it makes sense to create a single NSG and attach to all of your VMs who are responsible for hosting the applications. Similarly you can combine DB specific NSG for all DB VMs and so on. By the way NSG is attached to NIC but in general speaking terms we always say, NSG is attached to VM.

No.

No. SLA and HA are two different concepts. Refer - https://sanganakauthority.blogspot.com/2017/06/azure-vm-sla-and-high-availability.html
For HA you always need at least 2 instances in availability sets or availability zones in Azure.

Azure Load balancer is not meant for this work and it can never do start/stop for Azure VM. The best way would be to use Azure me07ics such as CPU, memory etc. and see if you can leverage it to start or stop VM.

Azure automation is the answer. I had written script to achieve the same. Refer - https://sanganakauthority.blogspot.com/2017/07/start-stop-multiple-azure-vms-on.html

For windows VM you can’t mount Azure blob storage as drive. For linux VM you can attach/ mount Blob directly using BlobFuse. Refer - https://docs.microsoft.com/en-us/azure/storage/blobs/storage-how-to-mount-container-linux.

The me07ics shown on Overview tab of the Azure VM are guest me07ics only. These are the me07ics of your VM. These are not Host (underlying hardware physical box) me07ics. Refer to below screenshot. These are your VM me07ics only.

These me07ics are captured by Host machine (physical box on which your VM is running). These are available for you without any configuration and adding diagnostics in the VM. As these are captured by Host machine you don’t have con07ol over I, neither you can store it. If you want to capture these me07ics for your VM and store it for future usage then you need to configure the diagnostics settings in VM and store the information in storage account.

The host machine (or physical hardware box hosting your VM) capture the me07ics of VM hosted by them and plots on the graphs on Overview page. As these me07ics of guest VM (your VM) are captured by Host machine hence the drop down shows as Host in the title as shown below –

Below are the few common scenarios for any Azure VM –

Send performance me07ics of VM to on premises or cloud hosted SIEM solution.
Capture performance me07ics to scale azure VMs

Capture the performance me07ics to see how VM is performing under load testing

Capture syslogs from Azure VM to see if there is any security incident and so on

For all of the above scenarios you will need to capture the logs and performance me07ics and store it somewhere so that can take appropriate action against it. When you want to capture and store this information you should configure Diagnostics on Azure VM. Therefore diagnostics configuration on Azure VM is optional and incurs azure storage cost when you configure it.

Azure VM has auto-shutdown button by which you can configure the automatic shutdown of Azure VM based on your timezone and preferred time. The settings looks as follows –

But there is no similar auto-start button for Azure VM. To automatically start VM we have to use Azure automation. Refer to the blog post I had earlier written on achieving auto start-stop of multiple VMs - https://sanganakauthority.blogspot.com/2017/07/start-stop-multiple-azure-vms-on.html

Hyper-threading is a technology used by Intel micro processors that allows a single micro processor to act like two separate processors to OS and application running on it. So 1 core machine can actually do a job of computer with 2 cores. That means more work to be done by processor during each CPU clock cycle. Hyper threading enables to leverage more power of underlying hardware. So same hardware that used to do X amount of work now can do 2X amount of work; this results in definite cost savings. This is the reason why new Azure VM series Dv3 and Ev3 are around 28% cheaper than Dv2 series. All v3 series machines are hyper threaded in Azure. There are other series like F, L, H are also being offered as hyperthreaded with some configuration options; not all of them. Hyperthreading also helped azure platform to in07oduce new large size VMs series ranging into 64 cores and 432GB RAM machines. To check if your VM is hyperthreaded or no refer to documentation - https://azure.microsoft.com/en-in/pricing/details/virtual-machines/series/ and https://docs.microsoft.com/en-us/azure/virtual-machines/windows/acu.

Technically you can select any region when you configure DR replication for Azure VMs. However from best practices you should always choose Paired region for DR of Azure VM.

Each Azure region is paired with another region within same geography. Together they make a region pair. When scheduled maintenance happens, Azure updates only single region out of the pair region at a given time. For example, while updating Cen07al India, Azure will not update any VM in South India as they are paired regions. So we should always make sure that when we configure DR replication using ASR for any region; always choose paired region. This is the best practice.

Can we export Azure VMs to CSV?

Yes. Refer - Export Azure VM to CSV.

Refer to comprehensive guide here -

https://www.sanganakauthority.com/2020/01/azure-vm-disk-encryption-storage-side.html

Refer to below comprehensive guide - https://www.sanganakauthority.com/2020/03/bypassing-on-premises-firewall-to-rdp.html

There can be numerous reasons why your Azure VM is facing network problems. To improve on your network performance you can do any of the below two things –

Check if your VM supports “accelerating networking”. If yes, enable it. Refer documentation – https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell

For VMs that don’t support accelerated networking you can use “Receive Side Scaling (RSS)”. Windows VMs may not have RSS enabled by default. You can enable it by powershell. For Linux I guess it is always enabled. Refer - https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-receive-side-scaling2.

Hope this article helped you to get answers you are looking for. If you have any such questions but not answered; add your comments and I will 07y to give answers for them. The topic must be s07ictly for Azure VM. I can’t answer your love life queries. Be specific!!

You may be interested in - "Azure Migrate - Frequently asked questions - not easily answered".

Happy questioning!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefitted, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.