If you developed your standard Windows or Linux operating system image for installation on on-premises computers, you might want to use the same image to deploy Azure virtual machines. This provides consistency of your hybrid environment, helping to ensure that the computers you manage comply with your standards, regardless of their location.
Follow these steps to use custom, on-premises operating system images to deploy Azure virtual machines:
- Ensure that the custom image configuration does not conflict with the Azure virtual machine requirements, including:
o Virtual machine generation. Azure virtual machines support only Generation 1. If you are running a Generation 2 virtual machine, you must reinstall it or use Azure Site Recovery to migrate it to Azure.
o Virtual machine disk size. Azure virtual machine disks cannot exceed 1,023 GB.
- Generalize the image. Start with an existing computer running your custom-configured operating system. If this is a Windows computer, run the Sysprep.exe utility with the /generalize, /oobe, and /shutdown switches. Sysprep.exe is one of the operating system files and resides in the %windir%\system32\sysprep folder. If this is a Linux computer, the process depends on the Linux distribution.
- Capture and prepare the disks for upload to Azure Storage. If you have a physical computer running Windows that you want to use as the image source, use the Disk2vhd utility. This utility allows you to convert individual physical disks into .vhd files, which you can subsequently upload to Azure Storage. If your source virtual machines reside on the VMware virtualization platform, use Microsoft Virtual Machine Converter 3.0, which supports converting .vmdk files to the .vhd format. If you use the Hyper‑V virtualization platform but your virtual disk files are in the .vhdx format, convert them to the .vhd format directly from the Hyper‑V Manager console. To streamline the conversion process, run the Convert-VHD Windows PowerShell cmdlet. In the case of a physical server running Linux, you must use third-party utilities.
- Additionally, you must ensure that the disk size in megabytes (MB) is a whole number. To accomplish this, use the Resize-VHD Windows PowerShell cmdlet.
- Create an Azure storage account. Choose the same deployment model that you intend to use to create Azure virtual machines based on your custom image. Classic Azure virtual machines cannot access the content of Azure storage accounts created with the Azure Resource Manager deployment model, and conversely, virtual machines created with the Azure Resource Manager deployment model cannot access classic Azure storage accounts.
- Upload the .vhd file to an Azure storage account. I recommend running the Add-AzureRmVhd cmdlet.
- When you create an Azure virtual machine, use the location of the uploaded .vhd file containing the image as the value of the –SourceImageUri parameter of the Set-AzureRmVMOSDisk Windows PowerShell cmdlet. Make sure to include the ‑CreateOption parameter with the fromImage value as part of the same cmdlet. You should also install the Azure virtual machine agent as part of the virtual machine provisioning. To accomplish this, include the –ProvisionVMAgent parameter when running the Set-AzureRmVMOperatingSystem Windows PowerShell cmdlet.
Note: When uploading images of on-premises virtual machines to Azure, ensure that the paging file is configured to reside on the D: drive. This way, you can automatically use the temporary disk that Azure provides for Azure virtual machines. This temporary disk maps to local storage on the Hyper‑V hosts rather than to Azure Storage. By using the local Hyper‑V storage, you avoid transactional charges for Azure Storage whenever the operating system that runs in the Azure virtual machine accesses the paging file.
Note: When deploying custom-image-based retail or volume licensed editions of Windows to Azure virtual machines, consider using the Azure Key Management Service (KMS). Set up the Windows installation with the Generic Volume License Key and ensure that kms.core.windows.net resolves to the Azure public IP address rather than your on-premises KMS instance.