Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Azure Virtual Machines FAQ

Updated: June 24, 2015

This article will be removed from the Azure library in the coming weeks. The contents of this article are now available on the Azure website and will be updated there. See Azure Virtual Machines FAQ.

This article addresses some common questions users ask about Azure virtual machines, based on input from the Azure VM Support team, as well as from forums, newsgroups, and comments in other articles. For an overview of virtual machines and links to tutorials that help you create one quickly, see Virtual Machines.

All subscribers can run server software on an Azure virtual machine. Additionally, MSDN subscribers have access to certain Windows client images provided by Azure.

For server software, you can run recent versions of Windows Server, as well as a variety of Linux distributions, and host various server workloads and services on them. For support details, see:

For Windows client images, certain versions of Windows 7 and Windows 8.1 are available to MSDN Azure benefit subscribers and MSDN Dev and Test Pay-As-You-Go subscribers, for development and test tasks. For details, including instructions and limitations, see Windows Client images for MSDN subscribers.

Each data disk can be up to 1 TB. The number of data disks you can use depends on the size of the virtual machine. For details, see Virtual Machine and Cloud Service Sizes for Azure.

An Azure storage account provides storage for the operating system disk and any data disks. Each disk is a .vhd file stored as a page blob. You’re charged for the storage used in the storage account, rather than for available space on the disk. For pricing details, see Storage Pricing Details. For disk details, see About Virtual Machine Disks in Azure.

Azure supports fixed, VHD-format virtual hard disks. If you want to use a VHDX-format disk in Azure, convert it by using Hyper-V Manager or the convert-VHD cmdlet. After you do that, use the Add-AzureVHD cmdlet to upload the VHD to a storage account in Azure so you can use it with virtual machines. The cmdlet converts a dynamic VHD to a fixed VHD, but doesn’t convert from VHDX to VHD.

For instructions on uploading a data disk, see the Linux or Windows article and start with the steps for connecting to Azure.

In many ways they’re similar to “Generation 1” Hyper-V VMs, but they’re not exactly the same. Both types provide virtualized hardware, and the VHD-format virtual hard disks are compatible. This means you can move them between Hyper-V and Azure. Two key differences that sometimes surprise Hyper-V users are:

  • Azure doesn’t provide console access to a virtual machine.

  • Azure VMs in most sizes have only 1 virtual network adapter, which means that they also can have only 1 external IP address. (The A8 and A9 sizes use a second network adapter for application communication between instances in limited scenarios.)

Azure VMs do not support Generation 2 Hyper-V VM features. For details about these features, see Virtual Machine Specifications for Hyper-V.

You can use Azure Virtual Network to extend your existing infrastructure. The approach is like setting up a branch office. You can provision and manage virtual private networks (VPNs) in Azure as well as securely connect these to on-premises IT infrastructure. For details, see Virtual Network Overview.

You’ll need to specify the network that you want the virtual machine to belong to when you create the virtual machine. This means, for example, that you can’t join an existing virtual machine to a virtual network. However, you can work around this by detaching the virtual hard disk (VHD) from the existing virtual machine, and then use it to create a new virtual machine with the networking configuration you want.

You need to establish a remote connection to log on to the virtual machine, using Remote Desktop Connection for a Windows VM or a Secure Shell (SSH) for a Linux VM. For instructions, see:

If you’re having problems with Remote Desktop or SSH, try installing and using the VMAccess extension to fix the problem.

You can also use Windows PowerShell Remoting to connect to the VM, or create additional endpoints for other resources to connect to the VM. For information, see How to Set Up Endpoints to a Virtual Machine.

If you’re familiar with Hyper-V, you might be looking for a tool similar to Virtual Machine Connection. Azure doesn’t offer a similar tool because console access to a virtual machine isn’t supported.

You shouldn’t use the D: drive (Windows) or /dev/sdb1 (Linux). They provide temporary storage only, so you would risk losing data that can’t be recovered. A common way this could occur is when the virtual machine moves to a different host. Resizing a virtual machine, updating the host, or a hardware failure on the host are some of the reasons a virtual machine might move.

On a Windows virtual machine, you can change the drive letter by moving the page file and reassigning drive letters, but you’ll need to make sure you do the steps in a specific order. For instructions, see Change the drive letter of the Windows temporary disk.

The term upgrade generally means moving to a more recent release of your operating system, while staying on the same hardware. For Azure VMs, the process for moving to a more recent release differs for Linux and Windows:

  • For Linux VMs, use the package management tools and procedures appropriate for the distribution.

  • For a Windows virtual machine, use Windows Server Migration Tools. Don’t attempt to upgrade the guest OS while it resides on Azure. It isn’t supported because of the risk of losing access to a virtual machine. If problems occur during the upgrade, you could lose the ability to start a Remote Desktop session and wouldn’t be able to troubleshoot the problems. For general details about the tools and process, see Migrate Roles and Features to Windows Server. For details on upgrading to Windows Server 2012 R2, see Upgrade Options for Windows Server 2012 R2

The images provided by Azure don’t have a pre-configured user name and password. When you create virtual machine using one of those images, you’ll need to provide a user name and password, which you’ll use to log on to the virtual machine.

If you’ve forgotten the user name or password and you’ve installed the VM Agent, you can install and use the VMAccess extension to fix the problem.

Some additional details are:

  • For the Linux images, if you use the Management Portal, ‘azureuser’ is given as a default user name, but you can change this by using ‘From Gallery’ instead of ‘Quick Create’ as the way to create the virtual machine. Using ‘From Gallery’ also lets you decide whether to use a password, an SSH key, or both to log you in. The user account is a non-privileged user that has ‘sudo’ access to run privileged commands. The ‘root’ account is disabled.

  • For Windows images, you’ll need to provide a user name and password when you create the VM. The account has administrator-level access.

Azure offers several options for anti-virus solutions, but it’s up to you to manage it. For example, you might need a separate subscription for antimalware software, and you’ll need to decide when to run scans and install updates. You can add anti-virus support with a VM extension for Microsoft Antimalware, Symantec Endpoint Protection, or TrendMicro Deep Security Agent when you create a Windows virtual machine, or at a later point. The Symantec and TrendMicro extensions let you use a free limited-time trial subscription or an existing enterprise subscription. Microsoft Antimalware is free of charge. For details, see:

A variety of solutions are available from certified partners. To find out what’s currently available, search the Azure Marketplace. Some additional options are as follows:

For Windows virtual machines, one option is to use Azure Backup to back up files and folders from within the guest operating system. For details, see Azure Backup Overview.

An option that applies to both Linux and Windows virtual machines is to use the snapshot capabilities of blob storage. To do this, you’ll need to shut down the VM before any operation that relies on a blob snapshot. This saves pending data writes and puts the file system in a consistent state.

Azure charges an hourly price based on the VM’s size and operating system. For partial hours, Azure charges only for the minutes of use. If you create the VM with a VM image containing certain preinstalled software, additional hourly software charges may apply. Azure charges separately for storage for the VM’s operating system and data disks. Temporary disk storage is free.

You are charged when the VM status is Running or Stopped, but you are not charged when the VM status is Stopped (De-allocated). To put a VM in the Stopped (De-allocated) state, do one of the following:

  • Shut down or delete the VM from the Management Portal.

  • Use the Stop-AzureVM cmdlet, available in the Azure PowerShell module.

  • Use the Shutdown Role operation in the Service Management REST API and specify StoppedDeallocated for the PostShutdownAction element.

If you use operating system commands or features to shut down a VM, it remains allocated and Azure continues to charge for the compute time.

Generally, you can start, stop, or restart your VM whenever you need to. (For details, see About starting, stopping, and restarting an Azure VM.) Azure sometimes restarts your VM as part of regular, planned maintenance updates in the Azure datacenters. Unplanned maintenance events can occur when Azure detects a serious hardware problem that affects your VM. For unplanned events, Azure automatically migrates the VM to a healthy host and restarts the VM.

For any standalone VM (meaning the VM isn’t part of an availability set), Azure notifies the subscription’s Service Administrator by email at least one week before planned maintenance because the VMs could be restarted during the update. Applications running on the VMs could experience downtime.

To provide redundancy, put two or more similarly configured VMs in the same availability set. This helps ensure at least one VM is available during planned or unplanned maintenance. Azure guarantees certain levels of VM availability for this configuration. For details, see Manage the availability of virtual machines.

© 2015 Microsoft