Bringing your own licenses

This page describes how to bring your own licenses (BYOL) to Google Cloud. Before bringing images with existing licenses, read the overview for bring your own licenses.

To bring physical-core or physical-processor licenses that have dedicated hardware requirements to Google Cloud, use sole-tenant nodes. With sole-tenant nodes, your VMs run on hardware that is dedicated to your project, and physical core usage is limited.

Bringing images with existing licenses requires the following:

  1. Importing a virtual disk file and creating an image
  2. Creating a sole-tenant node template
  3. Creating a sole-tenant node group based on the node template
  4. Provisioning a VM on the node group with your imported virtual disk file

If you need support or have questions regarding licensing, contact your licensing reseller. If you need support or have questions about bringing images with existing licenses to Google Cloud, contact Google Cloud Support.

Before you begin

  1. Request additional CPU quota: New projects receive a CPU quota of 72. Make sure you have enough CPU quota to support your node group. For example, the n1-node-96-624 node type contains 96 CPUs, and if your node group uses the minimum number of nodes (2), your CPU quota must be at least 192. Depending on your setup and the needs of your workloads, you might also need to request a quota adjustment for VMs or IP addresses.

  2. Enable the Cloud Build API: To import your OS image you must enable the Cloud Build API. When you enable this API, Compute Engine grants your project the appropriate IAM roles so that you can import images into your project. To list the roles granted to your project, use the gcloud projects get-iam-policy command. For information about how to grant roles to your project, see Managing access to Compute Engine resources.

  3. Enable the Cloud Logging API: Enable this API if your licensing agreements require you to track physical server usage. With this API enabled, you can import and view server usage information, such as physical core count, by using BigQuery, which Google strongly recommends. For information about how to determine the count of physical cores, see Determining server usage.

Importing a virtual disk file and creating an image

Before you import the virtual disk file for you VM, verify that there are no incompatibilities in the file by downloading and running the precheck tool from inside your VM.

To start a VM with your own license, import a virtual disk with the OS you want to use. You can import your file with the gcloud command-line tool, which supports importing virtual disks from Cloud Storage buckets and local workstations.

When importing a virtual disk file, the image import tool uploads your image file to Cloud Storage, and, if necessary, creates a new Cloud Storage bucket. Then, the import tool copies the file to Compute Engine and creates an image from the virtual disk file.

If you are hosting the virtual disk file on your local workstation, the image import tool uploads the file to a Cloud Storage bucket, and then imports the image into Compute Engine.

For a full explanation of the image import tool, see Importing virtual disks.

gcloud

  1. Run the following command to import your virtual disk file and create an image:

    gcloud compute images import image-name  --source-file file-name  --os os
    

    Replace the following:

    • image-name: Name to give the image.

    • file-name: Virtual disk file hosted locally or stored in Cloud Storage.

      • If your virtual disk is a local file: Use an absolute or relative path. In this case, the upload operation might take tens of minutes to run, depending on the size of the virtual disk and the speed of the network connection.

      • If your virtual disk file stored in Cloud Storage: Specify the full path of the file in the gs://bucket-name/object-name format, and the file must exist in a storage bucket in the same project that is used for the import process.

    • os: Operating system of the source-file. Must be one of the following:

      • rhel-6-byol
      • rhel-7-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
  2. After creating the image, you can share the image with users outside your project or organization:

    gcloud projects add-iam-policy-binding project-id  --member user:user-email  --role roles/compute.imageUser
    

    Replace the following:

    • project-id: Project ID of the project containing the image to grant access to.
    • user-email: Email of the user to share the image with.

    For information about how to access shared images, see Accessing shared images.

  3. Files stored on Cloud Storage and images in Compute Engine incur charges. After verifying that the image imports and boots correctly as a VM, you can delete the virtual disk file from Cloud Storage.

Creating a sole-tenant node template

Create a node template to base your node group on.

gcloud

gcloud compute sole-tenancy  node-templates create template-name  --node-type node-type  --region region  --server-binding server-binding

Replace the following:

  • template-name: Name of the node template which you are creating.
  • node-type Node type that you want to use for this template. For example, you can select the n1-node-96-624 node type to create a node with 96 vCPUs and 624 GB of memory.
  • region: Region in which to create the node template.
  • server-binding: Server binding policy for nodes using this template. Set to one of the following depending on your type of license:
    • restart-node-on-any-server
    • restart-node-on-minimal-servers

API

POST https://www.googleapis.com/compute/beta/projects/project-id/regions/region/nodeTemplates

{
   "name": "template-name",
   "nodeType": "node-type"
   "nodeAffinityLabels": {
      "key": "value"
   },
   "serverBinding":
   {
     "type": "server-binding"
   }
}

Replace the following:

  • project-id: ID of your project.
  • template-name: Name of the node template which you are creating.
  • node-type Node type that you want to use for this template. For example, you can select the n1-node-96-624 node type to create a node with 96 vCPUs and 624 GB of memory.
  • key:value: Comma- separated list of affinity labels. Note that affinity labels are only set when the node template is created.
  • region: Region in which to create the node template.
  • server-binding: Server binding policy for nodes using this template. Set to one of the following depending on your type of license:
    • RESTART_NODE_ON_ANY_SERVER
    • RESTART_NODE_ON_MINIMAL_SERVER

Creating a node group from a node template

Create a node group from a previously created node template, and specify the VM maintenance policy.

gcloud

gcloud beta compute sole-tenancy node-groups create group-name  --node-template template-name  --target-size group-size  --zone zone  --maintenance-policy maintenance-policy

Replace the following:

  • group-name: Name of the node group to create.
  • template-name: Name of the node template from which to create the node group.
  • group-size: Initial size of the node group.
  • zone: Zone in which to create the node group.
  • maintenance-policy: Maintenance policy of the node group. Set to one of the following:
    • migrate-within-node-group
    • restart-in-place
    • default

API

POST https://www.googleapis.com/compute/beta/projects/project-id/zones/zone/nodeGroups?initialNodeCount=target-size

{
  "nodeTemplate": "/regions/region/nodeTemplates/template-name",
  "name": "group-name",
  "maintenancePolicy": "maintenance-policy"
}

Replace the following:

  • project-id: ID of the project in which to create the node group.
  • zone: Zone in which to create the node group. Must be in the same region as the node template that you are using.
  • target-size: Number of nodes to create in the group.
  • region: Region where the node template is located.
  • template-name: Name of the node template that you want to use to create this group.
  • group-name: Name of the new node group.
  • maintenance-policy: Maintenance policy of the node group. Set to one of the following:
    • MIGRATE_WITHIN_NODE_GROUP
    • RESTART_IN_PLACE
    • DEFAULT

Provisioning a VM on the node group

Provision a VM on the node group, and specify the VM's restart behavior. If you previously specified for your node groups to restart hosted VMs within the same node group during a maintenance event, when you create a new VM instance on that node group, specify that the new VM does one of the following:

  • Migrates after a restart due to a maintenance event.
  • Terminates and then restarts on the same host. If the same host is not available, a new server is provisioned, and the physical ID of the previous host is not reused.

gcloud

gcloud compute instances create vm-name  --custom-cpu num-cpus  --custom-memory gb-memory  --image image-name  --zone zone  --node-group group-name  restart-behavior  --maintenance-policy maintenance-policy

Replace the following:

  • vm-name: Name of the VM that you are creating.
  • num-cpus: Number of CPUs on the new VM.
  • gb-memory: Amount of memory in GB on the new VM.
  • image-name: Name of the image from which to create this VM.
  • zone: Zone in which to create the VM.
  • group-name: Name of the node group on which to provision the VM.
  • restart-behavior: Restart behavior of this VM. Specify one of the following:
    • --restart-on-failure
    • --no-restart-on-failure
  • maintenance-policy: VM behavior during maintenance events. Specify one of the following depending on your scenario:
    • MIGRATE
    • TERMINATE

API

POST https://www.googleapis.com/compute/v1/projects/project-id/zones/vm-zone/instances

{
  "machineType": "/zones/machine-type-zone/machineTypes/custom-num-cpus-mb-memory",
  "name": "vm-name",
  "scheduling": {
    "nodeAffinities": [
      {
        "key": "node-group",
        "operator": "IN",
        "values": [
        "group-name"
        ]
      }
    ],
    "onHostMaintenance": "maintenance-policy",
    "automaticRestart": "restart-behavior"
  },
  "networkInterfaces": [
    {
     "network": "/global/networks/network",
     "subnetwork": "/regions/region/subnetworks/subnetwork"
    }
  ],
  "disks": [
    {
      "boot": true,
      "initializeParams": {
        "sourceImage": "/projects/image-project/global/images/family/image-family"
       }
    }
  ]
}

Replace the following:

  • project-id: ID of the project in which to create the VM.
  • vm-zone: Zone in which to create the VM.
  • machine-type-zone: Zone containing the machine type.
  • num-cpus: Number of CPUs on the new VM.
  • mb-memory: Amount of memory in MB on the new VM.
  • vm-name: Name of the new VM.
  • group-name: Name of the node group on which to create this VM.
  • maintenance-policy: Maintenance behavior for this VM. Set to one of the following depending on your scenario:
    • MIGRATE
    • TERMINATE
  • restart-behavior: Restart behavior for this VM. Default value is true.
  • network: Name of the network to connect your VM to.
  • subnetwork: Name of the subnetwork to connect the VM to.
  • image-project: Image project containing the source image.
  • image-family: Image family of the source image.

What's next