Applies to: ✔️ Linux VMs ✔️ Windows VMs ✔️ Uniform scale sets
This article guides you through how to create an Azure dedicated host to host your virtual machines (VMs) and scale set instances.
Limitations
The sizes and hardware types available for dedicated hosts vary by region. Refer to the host pricing page to learn more.
Not all Azure VM SKUs, regions and availability zones support ultra disks, for more information about this topic, see Azure ultra disks.
Additional limitations would apply when using ultra disks on the following VM sizes: LSv2, M, Mv2, Msv2, Mdsv2, NVv3, NVv4 on a dedicated host.
The fault domain count of the virtual machine scale set can't exceed the fault domain count of the host group.
Users can not select hardware capabilities like accelerated networking when creating a dedicated host.
Users would not be able to create VMs/VMSS with accelerated networking enabled on a dedicated host.
Create a host group
A host group is a resource that represents a collection of dedicated hosts. You create a host group in a region and an availability zone, and add hosts to it. You can use one or both of the following options with your dedicated hosts to ensure high availability:
Span across multiple availability zones. In this case, you're required to have a host group in each of the zones you wish to use.
Span across multiple fault domains, which are mapped to physical racks.
In either case, you need to provide the fault domain count for your host group. If you don't want to span fault domains in your group, use a fault domain count of 1.
You can also decide to use both availability zones and fault domains.
Enabling ultra disks is a host group level setting and can't be changed after a host group is created.
Select Create a resource in the upper left corner.
Search for Host group and then select Host Groups from the results.
In the Host Groups page, select Create.
Select the subscription you would like to use, and then select Create new to create a new resource group.
Type myDedicatedHostsRG as the Name and then select OK.
For Host group name, type myHostGroup.
For Location, select East US.
For Availability Zone, select 1.
Select Enable Ultra SSD to use ultra disks with supported Virtual Machines.
For Fault domain count, select 2.
Select Automatic placement to automatically assign VMs and scale set instances to an available host in this group.
Select Review + create and then wait for validation.
Once you see the Validation passed message, select Create to create the host group.
It should only take a few moments to create the host group.
Not all host SKUs are available in all regions, and availability zones. You can list host availability, and any offer restrictions before you start provisioning dedicated hosts.
az vm list-skus -l eastus2 -r hostGroups/hosts -o table
You can also verify if a VM series supports ultra disks.
subscription="<mySubID>"
# example value is southeastasia
region="<myLocation>"
# example value is Standard_E64s_v3
vmSize="<myVMSize>"
az vm list-skus --resource-type virtualMachines --location $region --query "[?name=='$vmSize'].locationInfo[0].zoneDetails[0].Name" --subscription $subscription
In this example, we'll use az vm host group create to create a host group using both availability zones and fault domains.
az vm host group create \
--name myHostGroup \
-g myDHResourceGroup \
-z 1 \
--platform-fault-domain-count 2
Add the --automatic-placement true parameter to have your VMs and scale set instances automatically placed on hosts, within a host group. For more information, see Manual vs. automatic placement.
Add the --ultra-ssd-enabled true parameter to enable creation of VMs that can support ultra disks.
Other examples
You can also use az vm host group create to create a host group in availability zone 1 (and no fault domains).
az vm host group create \
--name myAZHostGroup \
-g myDHResourceGroup \
-z 1 \
--platform-fault-domain-count 1
The following code snippet uses az vm host group create to create a host group by using fault domains only (to be used in regions where availability zones aren't supported).
az vm host group create \
--name myFDHostGroup \
-g myDHResourceGroup \
--platform-fault-domain-count 2
The following code snippet uses az vm host group create to create a host group that supports ultra disks and auto placement of VMs enabled.
az vm host group create \
--name myFDHostGroup \
-g myDHResourceGroup \
-z 1 \
--ultra-ssd-enabled true \
--platform-fault-domain-count 2 \
--automatic-placement true
This example uses New-AzHostGroup to create a host group in zone 1, with 2 fault domains.
Add the -SupportAutomaticPlacement true parameter to have your VMs and scale set instances automatically placed on hosts, within a host group. For more information about this topic, see Manual vs. automatic placement .
Add the -EnableUltraSSD parameter to enable creation of VMs that can support ultra disks.
Create a dedicated host
Now create a dedicated host in the host group. In addition to a name for the host, you're required to provide the SKU for the host. Host SKU captures the supported VM series and the hardware generation for your dedicated host.
Select Create a resource in the upper left corner.
Search for Dedicated host and then select Dedicated hosts from the results.
In the Dedicated Hosts page, select Create.
Select the subscription you would like to use.
Select myDedicatedHostsRG as the Resource group.
In Instance details, type myHost for the Name and select East US for the location.
In Hardware profile, select Standard Es3 family - Type 1 for the Size family, select myHostGroup for the Host group and then select 1 for the Fault domain. Leave the defaults for the rest of the fields.
Leave the Automatically replace host on failure setting Enabled to automatically service heal the host in case of any host level failure.
When you're done, select Review + create and wait for validation.
Once you see the Validation passed message, select Create to create the host.
Use az vm host create to create a host. If you set a fault domain count for your host group, you'll be asked to specify the fault domain for your host.
If you would like to create a VM with ultra disks support, make sure the host group in which the VM will be placed is ultra SSD enabled. Once you've confirmed, create the VM in the same host group. See Deploy an ultra disk for the steps to attach an ultra disk to a VM.
Choose Create a resource in the upper left corner of the Azure portal.
In the search box above the list of Azure Marketplace resources, search for and select the image you want use, then choose Create.
In the Basics tab, under Project details, make sure the correct subscription is selected and then select myDedicatedHostsRG as the Resource group.
Under Instance details, type myVM for the Virtual machine name and choose East US for your Location.
In Availability options select Availability zone, select 1 from the drop-down.
For the size, select Change size. In the list of available sizes, choose one from the Esv3 series, like Standard E2s v3. You may need to clear the filter in order to see all of the available sizes.
Complete the rest of the fields on the Basics tab as needed.
If you want to specify which host to use for your VM, then at the top of the page, select the Advanced tab and in the Host section, select myHostGroup for Host group and myHost for the Host. Otherwise, your VM will automatically be placed on a host with capacity.
Leave the remaining defaults and then select the Review + create button at the bottom of the page.
When you see the message that validation has passed, select Create.
It will take a few minutes for your VM to be deployed.
Create a virtual machine within a dedicated host using az vm create. If you specified an availability zone when creating your host group, you're required to use the same zone when creating the virtual machine. Replace the values like image and host name with your own. If you're creating a Windows VM, remove --generate-ssh-keys to be prompted for a password.
If you create a virtual machine on a host which does not have enough resources, the virtual machine will be created in a FAILED state.
Create a scale set
You can also create a scale set on your host.
Important
Starting November 2023, VM scale sets created using PowerShell and Azure CLI will default to Flexible Orchestration Mode if no orchestration mode is specified. For more information about this change and what actions you should take, go to Breaking Change for VMSS PowerShell/CLI Customers - Microsoft Community Hub
When you deploy a scale set, you specify the host group.
Search for Scale set and select Virtual machine scale sets from the list.
Select Add to create a new scale set.
Complete the fields on the Basics tab as you usually would, but make sure you select a VM size that is from the series you chose for your dedicated host, like Standard E2s v3.
On the Advanced tab, for Spreading algorithm select Max spreading.
In Host group, select the host group from the drop-down. If you recently created the group, it might take a minute to get added to the list.
When you deploy a scale set using az vmss create, you specify the host group using --host-group. In this example, we're deploying a Linux image. To deploy a Windows image, replace the value of --image and remove --generate-ssh-keys to be prompted for a password.
If you want to manually choose which host to deploy the scale set to, add --host and the name of the host.
Reassign an existing VM
You can reassign an existing multitenant VM or dedicated host VM to a different dedicated host, but the VM must first be Stop\Deallocated. Before you move a VM to a dedicated host, make sure that the VM configuration is supported:
The VM size must be in the same size family as the dedicated host. For example, if your dedicated host is DSv3, then the VM size could be Standard_D4s_v3, but it couldn't be a Standard_A4_v2.
The VM needs to be located in same region as the dedicated host.
The VM can't be part of a proximity placement group. Remove the VM from the proximity placement group before moving it to a dedicated host. For more information about this topic, see Move a VM out of a proximity placement group.
The VM can't be in an availability set.
If the VM is in an availability zone, it must be the same availability zone as the host group. The availability zone settings for the VM and the host group must match.
Select a host group and a host from the drop-down menus.
When you're done, select Save at the top of the page.
After the VM has been added to the host, select Overview from the left menu.
At the top of the page, select Start to restart the VM.
Move the existing VM to a dedicated host using the CLI. The VM must be Stop/Deallocated using az vm deallocate in order to assign it to a dedicated host.
Replace the values with your own information.
az vm deallocate -n myVM -g myResourceGroup
az vm update - n myVM -g myResourceGroup --host myHost
az vm start -n myVM -g myResourceGroup
For automatically placed VMs, only update the host group. For more information about this topic, see Manual vs. automatic placement.
Replace the values with your own information.
az vm deallocate -n myVM -g myResourceGroup
az vm update -n myVM -g myResourceGroup --host-group myHostGroup
az vm start -n myVM -g myResourceGroup
Replace the values of the variables with your own information.
Move a VM from dedicated host to multitenant infrastructure using the portal.
Open the page for the VM.
Select Stop to stop\deallocate the VM.
Select Configuration from the left menu.
Select None under host group drop-down menu.
When you're done, select Save at the top of the page.
After the VM has been reconfigured as a multitenant VM, select Overview from the left menu.
At the top of the page, select Start to restart the VM.
Move a VM from dedicated host to multitenant infrastructure using the CLI. The VM must be Stop/Deallocated using az vm deallocate in order to assign it to reconfigure it as a multitenant VM.
Replace the values with your own information.
az vm deallocate -n myVM -g myResourceGroup
az vm update -n myVM -g myResourceGroup --set host.id=None
az vm start -n myVM -g myResourceGroup
Move a VM from dedicated host to multitenant infrastructure using the PowerShell.
Replace the values of the variables with your own information.
Restarting a host does not completely power off the host. When the host restarts, the underlying VMs will also restart. The host will remain on the same underlying physical hardware and both the host ID and asset ID will remain the same after the restart. The host SKU will also remain the same after the restart.
az vm host restart \
--resource-group myResourceGroup \
--host-group myHostGroup \
--name myDedicatedHost
To view the status of the restart, you can use the az vm host get-instance-view command. The displayStatus will be set to Host undergoing restart during the restart. Once the restart has completed, the displayStatus will return to Host available.
az vm host get-instance-view --resource-group myResourceGroup --host-group myHostGroup --name myDedicatedHost
To view the status of the restart, you can use the Get-AzHost commandlet using the InstanceView parameter. The displayStatus will be set to Host undergoing restart during the restart. Once the restart has completed, the displayStatus will return to Host available.
Moving a host and all associated VMs to newer generation hardware can be done through the host resize feature. Resize simplifies the migration process and avoids having to manually create new hosts and move all VMs individually.
Resize limitations:
Host can only be resized to an ADH within the same VM family. A Dsv3-Type3 host can be resized to Dsv3-Type4 but not to an Esv3-Type4.
You can only resize to newer generation of hardware. A Dsv3-Type3 host can be resized to Dsv3-Type4 but not Dsv3-Type2.
Resizing changes the 'Host Asset ID'. The 'Host ID' remains the same.
The host and all associated VMs become unavailable during the resize operation.
Warning
The resize operation causes the loss of any non-persistent data such as temp disk data. Save all your work to persistent data storage before triggering resize.
Note
If the source host is already running on the latest hardware, 'Size' page would display an empty list. If you're looking for enhanced performance, consider switching to a different VM family.
If a VM or the underlying host remains unresponsive after following all the potential troubleshooting steps users can trigger service healing of the host and not wait for the platform to initiate the repair. Redeploying a host will move the host and all associated VMs to a different node of the same SKU. None of the host parameters would change except for the ‘Host asset ID’, which corresponds to the underlying Node Id.
Warning
Redeploy operation involves service healing hence would result in loss of any non-persistent data such as data stored on ephemeral disks. Save your work before redeploying.
az vm host redeploy \
--resource-group myResourceGroup \
--host-group myHostGroup \
--name myDedicatedHost
PowerShell support coming soon.
Deleting a host
You're being charged for your dedicated host even when no virtual machines are deployed on the host. You should delete any hosts you're currently not using to save costs.
You can only delete a host when there are no any longer virtual machines using it.
After deleting the VMs, you can delete the host using az vm host delete.
az vm host delete -g myDHResourceGroup --host-group myHostGroup --name myHost
Once you've deleted all of your hosts, you may delete the host group using az vm host group delete.
az vm host group delete -g myDHResourceGroup --host-group myHostGroup
You can also delete the entire resource group in a single command. The following command will delete all resources created in the group, including all of the VMs, hosts and host groups.
You can also delete the entire resource group in a single command using Remove-AzResourceGroup. This following command will delete all resources created in the group, including all of the VMs, hosts and host groups.
Remove-AzResourceGroup -Name $rgName
Next steps
For more information about this topic, see the Dedicated hosts overview.
There's sample template, available at Azure Quickstart Templates, which uses both zones and fault domains for maximum resiliency in a region.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.