Dedicated hosts

A dedicated host is a physical server that is intended solely for hosting your VMs in Yandex Cloud. VMs on dedicated hosts have all features of regular VMs; additionally, they are physically isolated from other users' VMs. You can also distinguish your VMs used for different projects:

You can create a group of one or more dedicated hosts of the same type. To optimize the use of resources, you can host multiple VMs with different configurations on each dedicated host.

Dedicated hosts provide the following advantages:

• Security and compliance:
  You can use a dedicated host to physically isolate your VM in the public cloud if this is required by your company's information security service or industry standards, such as medical or financial ones.
• Using your own licenses:
  If your company has Microsoft or other vendor licenses that require linking to physical resources, you can use them in Yandex Cloud on a Bring your own license (BYOL) basis.
• Managing your VM allocation:
  You can choose which dedicated host to run your VM on or allow Compute Cloud to do it automatically.

By default, the cloud has a zero quota for using dedicated hosts. To change the quota, contact technical support.

To ensure fault tolerance of your infrastructure hosted on dedicated hosts, we recommend using at least two hosts.

Types of dedicated hostsTypes of dedicated hosts

The configuration of a dedicated host is determined by its type. Host types differ by their models and the number of available CPU cores, RAM size, and the number and size of local SSD disks.

You can specify the dedicated host type when creating a host group. This type will be assigned to every host in the group, and you will not be able to change it moving forward.

The number of free dedicated hosts of each type per availability zone is limited and changes with time. When a host group is created or resized, Compute Cloud checks that there are enough dedicated hosts of this type. If there are not enough hosts, you will get an error.

List of typesList of types

Current types: based on Intel^® Ice Lake

You can only create hosts of these types in the ru-central1-a, ru-central1-b, and ru-central1-d availability zones. For more information, see Discontinuation of the ru-central1-c availability zone.

The above lists of the current and archived types are provided for indicative purposes and may change. You can get an up-to-date list of types (both current and archived) in the following ways:

• In the management console, on the dedicated host group create page in Compute Cloud.

• Using the following CLI command:

  yc compute host-type list
  

  For more information, see the guide on creating host groups.

¹ This is the number of vCPUs you can use to run VMs. Other vCPUs of the host are allocated for system usage (see below for details): 20 vCPUs running on the Intel® Xeon® Gold 6338 processors, and 8 vCPUs, on Intel® Xeon® Gold 6354.

Using physical resources of a hostUsing physical resources of a host

Processor fragmentationProcessor fragmentation

There are two processors installed on a physical server. However, not all their cores are available for running VMs. Some cores are allocated for system usage.

For example, a dedicated host of the intel-6354-c56-m454-n3200x6 type has:

• Two Intel® Xeon® Gold 6354 CPUs.
• 32 vCPUs on each processor, where:
  • 4 vCPUs are allocated for system usage.
  • 28 vCPUs are available to run user VMs.

When creating a VM on a dedicated host, you may encounter resource fragmentation, when the number of free vCPUs is sufficient, but you are unable to run your VM.

For example, a dedicated host from this diagram has 56 vCPUs (2 × 28) available to a user, but you can use it to run only eight VMs with six vCPUs each. A VM cannot use vCPUs from different physical CPUs at once.

In this case, you can run two more VMs with four vCPUs each to fully use the dedicated host's vCPUs.

Local and network disksLocal and network disks

Each dedicated host has multiple local disks available. Their number and size depend on the selected host configuration (see above).

You can attach network and local disks to VMs on dedicated hosts. Make sure the configuration meets the following requirements:

• VM boot disk must be a network disk. Local disks can only be used as secondary ones.
• All network disks must be in the same availability zone as the group of dedicated hosts.
• You can only attach an entire local disk to a VM. For example, when attaching a disk to a VM on a host of the intel-6338-c108-m704-n3200x6 type, specify the exact disk size: 3198924357632.
• You cannot attach a single disk to two or more different VMs at the same time.

When working with local disks attached to VMs on dedicated hosts, you cannot:

• Change an existing VM's RAM and CPU. To modify these parameters, recreate the VM.
• Attach additional network disks to a stopped VM. You can only attach additional network disks to a running VM.
• Attach additional local disks to a VM or delete the attached ones. To change the local disks attached, recreate the VM. For more information about creating VMs with local disks on dedicated hosts, see the guides.

You can connect a local disk to a VM on a dedicated host only if you create the VM using the YC CLI or API. To connect multiple local disks, when running the yc compute instance create command, set the --attach-local-disk parameter as many times as you need, once for each disk you are connecting.

If a dedicated host fails, the data stored on local disks will be lost. To ensure data security, set up replication yourself, e.g., using Yandex Cloud Backup.

Host group sizeHost group size

When creating a host group, you need to specify the number of dedicated hosts. When updating the group, you can reduce or increase the number of hosts in it:

yc compute host-group create \
  --fixed-size <number_of_hosts> \
  ...

MaintenanceMaintenance

Compute Cloud performs host maintenance on a regular basis. Some maintenance activities run in the background without affecting user experience. Others require the host to be released of VMs. For the latter kind of maintenance:

• A new (replacement) host is added to the host group.
• The date for automatic release of the old host is calculated.

You can get the host-id and server-id values and the auto release date for the new host in the management console on the List of hosts page or using this CLI command:

yc compute host-group list-hosts <host_group_ID>

Result:

+----------------------+----------------------+----------------------+--------------------------+
|          ID          |      SERVER ID       | REPLACEMENT HOST ID  |   REPLACEMENT DEADLINE   |
+----------------------+----------------------+----------------------+--------------------------+
| fhm1ab2mhnf3******** | fhmlabct12vp******** | fhmabcun12kb******** | 2023-10-24T12:36:14.321Z |
| fhmabcun12kb******** | fhm1a2bcsl13******** |                      |                          |
+----------------------+----------------------+----------------------+--------------------------+

Where:

• REPLACEMENT HOST ID: ID of the new (replacement) host.
• REPLACEMENT DEADLINE: Automatic host release date and time (UTC).

A host undergoing maintenance is not charged, not included in the host group size, and not used for deploying new VMs.

The auto release date and time are scheduled for the seventh day after dedicating the replacement host. Compute Cloud will start automatically releasing the host in the period from REPLACEMENT DEADLINE to REPLACEMENT DEADLINE + 1 hour. Depending on the type of your VMs:

• VMs with no local disks, GPUs, or affinity to host-id will be live migrated.
• VMs with affinity to host-id will be stopped. You will need to either remove host affinity or update it to a new host-id and then restart the VM.
• VMs with local disks will first be stopped and, in 12 hours, change their status to ERROR with their local disks cleaned.

The auto release date can be shifted backwards or forwards by as much as 21 days after dedicating the replacement host. You can change the date using this command:

yc compute host-group update-host <host_group_ID> \
  --host-id <host_ID> \
  --replacement-deadline <deadline>

Where --replacement-deadline is the date and time in UTC format (YYYY-MM-DDTHH:MM:SSZ).

VMs are automatically moved based on the VM host affinity rules. A VM will be moved to any host in a host group that has sufficient resources, including the replacement host. If there are no resources, the VMs will be stopped.

You can move your VMs from the old host yourself before the specified date:

• Using live migration: To migrate your VMs, contact support.

• By stopping and restarting your VMs in the management console or with these CLI commands:

  yc compute instance stop <VM_name>
  

  yc compute instance start <VM_name>
  

• By deleting and recreating your VMs (for VMs with local disks).

Use the command below to learn which dedicated host the VM is actually running on:

yc compute instance get <VM_name>

Result:

...
host_id: <host_ID>

Host issuesHost issues

If the physical server is restarted, the VMs running on it will be restarted automatically and linked:

• To the same host group if the VM was linked to a group. In this case, you can link the VM to a different host in the group.
• To a dedicated host if the VM was linked to a specific host.

If the physical server is completely stopped, Compute Cloud proceeds as follows:

• Removes the physical server from the host group.
• Replaces the failed server with a new one (with a new server-id). In this case, the IDs of the host group (host-group-id) and the dedicated host (host-id) stay the same.
• Runs the VMs from the failed server based on the VM host affinity rules. In this case, VMs with no local disks run automatically, while those with local disks get the ERROR status. The contents of the local disks from the failed server are not moved to the new one.

Linking a VM to a group or hostLinking a VM to a group or host

To uniquely map a VM and a physical server, you can create a VM that is linked:

• To a group of dedicated hosts:
  When the VM is stopped, it will not be available on the group hosts, and when it is restarted, it may be linked to a different host of the group.
• To the selected host of a group of hosts:
  When the VM is stopped, it will not be available on the host, and when it is restarted, it will be linked to the same host from the group.

Linking a VM ensures that it will run on the same physical server or group of servers even after scheduled maintenance.

To move a VM from one dedicated host to another:

1. Stop the VM.
2. Link the VM to a different host in the group.
3. Restart the VM.

When creating a VM, you can specify multiple host groups or specific hosts it can be linked to. Example of linking a VM to a host group:

yc compute instance create \
  --host-group-id <host_group_ID> \
  --network-interface subnet-name=default-ru-central1-a \
  --zone ru-central1-a

In this case, the VM will be linked to the specified host group:

done (33s)
id: abcdefghigkl********
folder_id: a1b23cd45efg********
...
placement_policy:                             # VM host affinity rules
  host_affinity_rules:
    - key: yc.hostGroupId
      op: IN
      values:
        - <host_group_ID>
host_group_id: <host_group_ID>  # Actual VM location
host_id: <host_ID>                # Actual VM location
...

Rules in host_affinity_rules are combined via OR. For example, the following rules allow you to run VMs on any host of the <host_group_ID> group or on <host_ID>:

placement_policy:
  host_affinity_rules:
    - key: yc.hostGroupId
      op: IN
      values:
        - <host_group_ID>
    - key: yc.hostId
      op: IN
      values:
        - <host_ID>

Placement groupsPlacement groups

We do not recommend using placement groups for VMs on dedicated hosts.

PricingPricing

For information about pricing for dedicated hosts, see Computing resources of dedicated hosts.

See alsoSee also

• Creating a group of dedicated hosts
• Creating a VM in a group of dedicated hosts
• Creating a VM on a dedicated host
• Configuring dedicated host group access permissions

Intel and Xeon are trademarks of Intel Corporation or its subsidiaries.