Bringing your own license with sole-tenant nodes

Compute Engine offers the ability to bring your own license (BYOL) using sole-tenant nodes to support licensing requirements that limit physical hardware usage. Specifically, you can use sole-tenant nodes to import a custom image into Compute Engine, use the image to start a VM, and enable in-place restarts so the VM restarts on the same physical server whenever possible. By using sole-tenant nodes to host your VMs, you ensure your VMs run on hardware fully dedicated to your use while limiting physical core usage. Compute Engine also offers server usage reporting so you can track physical hardware information for license usage.

For an overview of this feature, including requirements and workload considerations, read the Overview page.

Before you begin

Review supported OS and license requirements

Before you start this process, make sure your OS is compatible and that you have reviewed the Licensing and activation section. You are responsible for ensuring your licensing agreements permit the use of software in the BYOL environment as described in this documentation. Also, you must prepare your guest image for BYOL according to your agreements.

If you have questions or need additional support, please contact your licensing reseller for licensing questions and Google Cloud Support for questions about this feature.

Review supported regions

This feature is only available in certain regions. See Pricing and availability for the full list.

Consider your workload

Certain workloads are better suited for this feature than others. Review the Workload considerations for general recommendations.

Create a new project and request quota

If you don't already have a project, create a new project.

CPU quota for the new projects is restricted to 100 CPUs. This might not be enough for your needs. If you need more quota for your project, you can request quota adjustments through the Quotas page in the Cloud Console. You might also need quota increases for other resources such as IP addresses, depending on your setup.

Enable Cloud Build API

This feature uses the Cloud Build service to import and create Compute Engine images. You must enable the Cloud Build API to use this feature.

Enable the Cloud Build API

Compute Engine also grants the Cloud Build service account the following roles so it can import images into Compute Engine:

  • roles/iam.serviceAccountTokenCreator
  • roles/compute.admin
  • roles/iam.serviceAccountUser

Enable Stackdriver Logging for audit logging

If reporting physical server usage is required for licensing, enable the Stackdriver Logging API before launching VMs onto sole-tenant nodes. This gives you the ability to import and view server usage information using BigQuery (strongly recommended).

Enable the Stackdriver Logging API

By setting up logging, you can take advantage of BigQuery to track relevant information, such as physical core count usage, for your licensing needs. For more details, see Determining server usage.

Create a virtual disk file

You must have an existing virtual disk file (VMDK, VHD) to import the image into Compute Engine. You can't install an operating system directly to a VM from an installation image, such as iso, img, DVD, USB, and so on. You also can't do an in-place OS upgrade on a Compute Engine VM.

Steps to creating a virtual disk file differ depending on your environment; consult the appropriate documentation for your operating system.

Importing a virtual disk file

To start a VM with your own license, import a virtual disk that contains the OS you want to use. Use the gcloud command-line tool to import your file; the gcloud tool supports importing VHD or VMDK from a Cloud Storage bucket or from a local workstation. If the virtual disk is hosted on your local machine, the import process first uploads the file to a Cloud Storage bucket before importing the image into Compute Engine.

Before you import your virtual machine's disk, download and run our precheck tool inside your virtual machine. This precheck tool helps verifies that there are no incompatibilities when migrating over to Google Cloud.

For a full explanation of the image import tool, review Importing Virtual Disk.

When you are ready, run the following gcloud command to import your virtual disk:

gcloud compute images import [IMAGE_NAME] \
    --source-file [SOURCE_FILE] \
    --os [OS]


  • [IMAGE_NAME] is the name you want to give this image.
  • [SOURCE_FILE] is a virtual disk file, either hosted locally or stored in Cloud Storage. If your virtual disk is a local file, you can use an absolute or relative path. If your virtual disk file is already stored in Cloud Storage, the file must exist in a storage bucket in the same project that's being used for the import process, and you must specify the full path of the file in the gs://[BUCKET_NAME]/[OBJECT_NAME] format.

  • [OS] is the Windows operating system of the SOURCE_FILE. The following Windows OSes are supported:

    • windows-2008r2-byol
    • windows-2012-byol
    • windows-2012r2-byol
    • windows-2016-byol
    • windows-2019-byol
    • windows-7-x64-byol
    • windows-7-x86-byol
    • windows-8-x64-byol
    • windows-8-x86-byol
    • windows-10-x64-byol
    • windows-10-x86-byol

Note that files stored on Cloud Storage and images in Compute Engine incur charges. After you verify that the image is imported correctly and that it boots correctly as a Compute Engine instance, you can delete the virtual disk file from Cloud Storage.

If a local file is specified for the --source-file, the upload operation can take tens of minutes to run, depending on the size of the virtual disk and the speed of the network connection.

After the image is created, you can share the image with users outside of your project or organization by using IAM roles or permissions.

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member user:[USER_EMAIL] \
    --role roles/compute.imageUser

In this case, [PROJECT_ID] is the project that owns the image for which you want to grant access.

Then, the user can access this image by specifying the project ID where the image lives in their requests. For example:

gcloud compute instances create my-vm \
    --custom-cpu 4 \
    --custom-memory 8 \
    --image[PROJECT_ID]/global/images/[IMAGE_NAME] \
    --zone us-central1-a \
    --node-affinity-file node-affinity-prod.json \
    --restart-on-failure \
    --maintenance-policy terminate

Starting a VM instance with your own license

After an image is imported, you can start a VM instance on a sole-tenant node by using the imported image, and enable the in-place restart feature by specifying the restart-node-on-minimal-servers property. This property ensures that if a maintenance event occurs, the VM restarts on the same physical server if possible. If the same physical server is not available, a new physical server is created and added to the node group. Compute Engine reports the server ID of the new server.

For BYOL workloads that aren't concerned with physical core or socket usage based on the nature of the licensing and product terms, you can use sole-tenant nodes and omit the in-place restart feature. This ensures your VM instances land on dedicated hardware but doesn't minimize the number of physical underlying servers used.

Follow these steps to start your VM instance (described in detail below):

  1. Create a node template and enable in-place restart, if required, using the Google Cloud Console, the gcloud command-line tool, or the API.

  2. Create a node group with the new template.

  3. Lastly, create VMs in the node group with your imported image.

After VMs are scheduled on a node, they adhere to the same physical affinity labels through restarts and maintenance events. This means that although the underlying physical server can change, you can use label selectors to ensure certain VMs are always on the same nodes (with corresponding node affinity), or that certain VMs never share the same node (node anti-affinity).

For your convenience, an additional affinity label, similar to the node name and the node group name, is automatically added to all sole tenant nodes configured with the restart-node-on-minimal-servers option. You can include this label in your affinity file to ensure that your VMs only start on nodes with the restart-node-on-minimal-server feature enabled. The label looks like the following:

  • Key:
  • Value: restart-node-on-minimal-server


  1. Create a node template with the minimal server restart option.

    1. Go to the Create a node template page.

      Go to the Create a node template page

    2. Enter a name for the template.
    3. Specify the region where you plan to run your node group.
    4. Specify the node type that you want your node groups to use.
    5. Specify node affinity labels for your instances if desired. For example, you might specify workload=front-end and environment=prod labels.
    6. Expand Advanced node restart configuration.
    7. Select Minimal servers.
    8. Create your node template.
  2. Provision a node group using the node template.

    1. Go to the Create a node group page.

      Go to the Create a node group page

    2. Enter a name for the group.
    3. Specify the zone where you want to run your node group. You must have a node template in the same region.
    4. Specify the node template that you want to use.
    5. Specify the number of nodes you want to run in the group. You can change this number later.
    6. Click Create to finish creating your node group.
  3. Create an instance that runs within your node group or on specific nodes. If you used specific node affinity labels, you can create an instance using the normal process and specify node affinity under the Sole Tenancy settings. For this example, create the instances directly within your node group details page.

    1. Go to the Sole tenant nodes page.

      Go to the Sole tenant nodes page

    2. Click the name of the node group where you want to create an instance.
    3. Click Create instance to create an instance anywhere within this node group. If you want your instance to run on a specific node within the group, click the name of an individual node in this group to view the details for that individual node. Then, click Create instance to create the instance on that individual node.
    4. Configure the settings for your instance. Because you already selected your node group or a specific node, the region, zone, and default node affinity labels are already specified for you.
    5. Select the Management tab.
    6. Under Availability policy > On host maintenance, select Terminate.

    7. Under Automatic Restart, select On (recommended).

    8. Click Create to finish creating your instance.


  1. Create a node template and set the restart-node-on-minimal-servers flag. Choose node affinity labels for your instances if desired. For example:

    gcloud compute sole-tenancy node-templates create my-node-template \
        --node-type n1-node-96-624 \
        --region us-east1 \
        --node-affinity-labels workload=front-end,environment=prod \
        --server-binding restart-node-on-minimal-servers
  2. Provision a node group using the node template. For example, the following command creates a group of two instances using the node template that was created in the previous step:

     gcloud compute sole-tenancy node-groups create my-node-group \
         --node-template my-node-template \
         --target-size 2 \
         --zone us-east1-b
  3. Create a node affinity file that contains the corresponding affinity labels of the node group. This ensures that your the VM is created only on nodes that contain all of these labels. For example:

     cat > node-affinity-prod.json
       "key" : "workload",
       "operator" : "IN",
       "values" : ["front-end"]
       "key" : "environment",
       "operator" : "IN",
        "values" : ["prod"]
        "key" : "",
        "operator" : "IN",
        "values" : "restart-node-on-minimal-server"
  4. Start a VM instance and specify the affinity label file. For example, the following request creates a VM with 4 CPUs, 8 GBs of memory using the imported image, in the us-east1-b zone. In addition, it also sets the --restart-on-failure- flag and a maintenance policy of terminate, which is currently the only acceptable policy for VMs with your own license.

     gcloud compute instances create my-vm \
         --custom-cpu 4 --custom-memory 8 \
         --image my-imported-image \
         --zone us-east1-b \
         --node-affinity-file node-affinity-prod.json \
         --restart-on-failure --maintenance-policy terminate


  1. Create a node template and set the RESTART_NODE_ON_MINIMAL_SERVERS property. Choose node affinity labels for your instances as well. For example:

       "name": "[TEMPLATE_NAME]",
       "nodeType": "[NODE_TYPE]"
       "nodeAffinityLabels": {
          "[KEY]": "[VALUE]"


    • [PROJECT_ID] is your project ID.
    • [TEMPLATE_NAME] is a name for the new node template.
    • [NODE_TYPE] is the node type that you want to use for this template. For example, you can specify the n1-node-96-624 node type to create a node with 96 vCPUs and 624 GB of memory.
    • [KEY]:[VALUE] is a comma-separated list of affinity labels.
    • [REGION] is the region in which to use this template.
  2. After you create the node template, create a node group. Use the compute.nodeGroups.insert method:

     "nodeTemplate": "regions/[REGION]/nodeTemplates/[TEMPLATE_NAME]",
     "name": "[GROUP_NAME]"


    • [PROJECT_ID]is your project ID.
    • [ZONE] is the zone where this node group is located. This zone must be in the same region as the node template that you are using.
    • [TARGET_SIZE] is the number of nodes that you want to create in the group.
    • [REGION] is the region where the node template is located.
    • [TEMPLATE_NAME] is a name for the new node template.
    • [GROUP_NAME] is a name for the new node group.
    • [TEMPLATE_NAME] is the name of the node template that you want to use to create this group.
  3. After you create your node group, you can create instances within the node group by using the compute.instances.insert method. Specify a nodeAffinities entry that points to your node group name. For example, you might create an instance with a custom machine type:

     "machineType": "zones/[ZONE]/machineTypes/custom-[VCPUS]-[MEMORY]",
     "name": "[INSTANCE_NAME]",
     "scheduling": {
      "nodeAffinities": [
        "key": "",
        "operator": "IN",
        "values": [
     "networkInterfaces": [
       "network": "global/networks/[NETWORK]",
       "subnetwork": "regions/[REGION]/subnetworks/[SUBNETWORK]"
     "disks": [
       "boot": true,
       "initializeParams": {
        "sourceImage": "projects/[IMAGE_PROJECT]/global/images/family/[IMAGE_FAMILY]"


    • [PROJECT_ID]is your project ID.
    • [INSTANCE_NAME]is the name for the new instance.
    • [ZONE] is the zone where your node group is located.
    • [REGION]is the region where the node template and your subnetwork are located.
    • [IMAGE_FAMILY] is one of the available image families.
    • [IMAGE_PROJECT] is the image project to which that image family belongs.
    • [GROUP_NAME] is the name of the node group where you want to locate this instance.
    • [VCPUS] is the number of vCPUs that you want to use with this instance.
    • [MEMORY] is the amount of memory for the instance in MB. For example, you might specify 5376MB.
    • [NETWORK] is the name of the network to which you want to connect your instance.
    • [SUBNETWORK] is the name of the subnetwork to which you want to connect your instance.

What's next

Pomohla vám tato stránka? Ohodnoťte ji prosím:

Typ zpětné vazby...

Compute Engine Documentation