Bringing your own licenses

This document describes how Google Cloud supports bringing your own licenses (BYOL) that have dedicated hardware requirements to Compute Engine. Before attempting to bring images with existing licenses to Google Cloud, review your licensing terms and conditions.

Bringing your existing physical-core or physical-processor licenses that have dedicated hardware requirements requires you to bring your own media and to run that media on hardware configurations, such as sole-tenant nodes, that are compliant with your licenses. You can bring images with existing licenses in any region that supports sole-tenant nodes, and although there is no additional charge for bringing images with existing licenses, you must still pay for your licenses according to your agreements.

Licensing scenarios such as licenses related to Linux BYOS with RHEL or SLES, as well as Microsoft applications don't require sole-tenant nodes. If you are considering bringing licenses from Microsoft applications such as SharePoint Server and SQL Server, use Microsoft License Mobility.

Sole-tenant nodes are physical servers dedicated to hosting virtual machine (VM) instances for only your project. You can configure sole-tenant nodes to support various workload requirements, such as requirements for minimizing the number of physical servers and cores. Consult your licensing agreements to determine which configuration options are most suitable for your workloads.

To support bringing your own licenses, and to help you manage compliance requirements related to your licenses, Google Cloud provides tools for importing images, managing VMs on dedicated hardware by using sole-tenant nodes, minimizing physical core usage, and tracking usage of physical cores for reporting purposes.

To bring images with existing licenses to Google Cloud, you must do the following:

  1. Prepare the images according to your license agreements.

  2. Activate your licenses.

  3. Import virtual disk files and create images from those disk files.

  4. Create sole-tenant node templates.

  5. Create sole-tenant node groups from the node templates.

  6. Provision VMs on the node groups with the imported virtual disk files.

  7. Track the license usage of your VMs. To help you with reporting your license consumption, Google provides tools to help you track both license usage and physical core and processor usage.

  8. Report license consumption to your vendor.

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

  • Review the node group host maintenance policy: For BYOL there are two options for host maintenance policy that minimize the number of physical servers used for licensing purposes. These options are restart-in-place and migrate-within-node-group.
  • 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.
  • 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.
  • 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 Analyzing sole-tenant node usage.
  • If you haven't already, then set up authentication. Authentication is the process by which your identity is verified for access to Google Cloud services and APIs. To run code or samples from a local development environment, you can authenticate to Compute Engine by selecting one of the following options:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

    REST

    To use the REST API samples on this page in a local development environment, you use the credentials you provide to the gcloud CLI.

      Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init

    For more information, see Authenticate for using REST in the Google Cloud authentication documentation.

Importing and creating an image from an offline virtual disk

To provision VMs with your existing licenses, you must bring your own media. Images based on a premium image are not eligible for BYOL because premium images require pay-as-you-go licenses from Google. For information about premium images, see Operating system details.

If you have virtual disks (golden disks or golden images) in your on-premises environment with software configurations or licenses that you need, the import virtual disk tool can help you do the following:

  1. Import your customized virtual disks with a supported operating system and create images based on those disks.

  2. Set up the appropriate license configuration.

  3. Install the packages and drivers necessary for compatibility with Google Cloud.

Before you import the virtual disk file for your VM, verify that there are no incompatibilities in the file by downloading and running the precheck tool from inside your VM. Also, because software from third parties might interfere with the installation of Compute Engine drivers, Google recommends removing third-party software before importing your image.

To start a VM with your own license, import a virtual disk with the OS you want to use. You can import virtual disks from Cloud Storage buckets and local workstations. When importing a virtual disk file from a local workstation, 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 a bootable image from the virtual disk file.

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.

Console

  1. Go to the Images page.

    Go to Images

  2. Click Create image.

  3. Specify a name for the image.

  4. Under Source, choose Virtual disk (VMDK, VHD).

  5. Under Cloud Storage file, choose Browse and browse to the Cloud Storage location of the image to import.

  6. Under Operating system on virtual disk, choose the operating system of the image that you are importing.

  7. Make sure that Install guest packages is selected, so that the image you are importing is bootable.

  8. Expand License key options. Under OS License, choose Use your own license key.

  9. Click Create to import the image.

gcloud

Run gcloud compute images import to import a virtual disk file and to create a disk image from the virtual disk file:

gcloud compute images import IMAGE_NAME \
    --source-file VMDK_NAME \
    --byol

Replace the following:

  • IMAGE_NAME: name to give the image created from the virtual disk file.

  • VMDK_NAME: name of the virtual disk to import and create an image from. You can import a VMDK file from the following:

    • A local file: If importing from a local file, use an absolute path or a relative path to the file. Depending on the size of the virtual disk and the speed of the network connection, the upload might take tens of minutes.
    • Cloud Storage: If importing from Cloud Storage, the Cloud Storage bucket must be in the same project that you are using to import the virtual disk, and you must specify the full path to the file as gs://BUCKET_NAME/OBJECT_NAME. Replace BUCKET_NAME with the name of the Cloud Storage bucket and OBJECT_NAME with the name of the Cloud Storage object.

Activating licenses

After verifying that you are importing a compatible OS, you are responsible for checking that your licensing agreements permit you to bring your own licenses and that you are permitted to use the guest OS image and license import environment provided by Google. You are also responsible for preparing your guest OS image for import according to your licensing agreements.

To activate a license, use startup scripts with your Multiple Activation Key (MAK), or configure access to your organization's Microsoft Key Management Service. You can't activate images with existing licenses against the Compute Engine license server.

After importing your image and activating the license, provision a VM based on the imported image onto a sole-tenant node.

Creating a sole-tenant node template

After importing the image, create a sole-tenant node template. You will use this node template to create a sole-tenant node group to run your image on.

The node templates page doesn't list the region and zone of the template, but node groups must be created in a zone within the region where you created the node template. To create a template, you must first create a node group, but you only need to complete the steps as far as choosing the region and zone. After that, you can create the template and not continue on to create the node group if you want to.

You set node affinity labels in the sole-tenant node template when you create the template.

Console

  1. Go to the Sole-tenant nodes page.

    Go to Sole-tenant nodes

  2. Click Create node group.

  3. Enter a Name for the node group.

  4. Select the Region and Zone for the node group.

    Take note of the region and zone you used. When you later create a node group that is based on this node template, the node group must be in a zone within the region where you created the node template.

  5. Under Node template properties, select Create node template.

  6. In the Create a node template dialog, specify a Name, a Node type, a Local SSD, and a GPU accelerator.

  7. Under CPU overcommit, choose whether to enable CPU overcommit.

  8. Optional: Under Affinity labels, click Add affinity label to add a key-value pair as a node affinity label.

  9. Click Create to finish creating your node template.

  10. Click Cancel to cancel out of creating a node group.

gcloud

Create a sole-tenant node template by using gcloud compute sole-tenancy node-templates create.

gcloud compute sole-tenancy node-templates create TEMPLATE_NAME \
    --node-type NODE_TYPE \
    --region REGION

Replace the following:

  • TEMPLATE_NAME: name of the node template to create.
  • NODE_TYPE: type of sole-tenant node for the nodes in a node group. All nodes in a node group are identical and are created from the parameters specified by a node template.
  • REGION: region to create the node template in.

REST

Create a sole-tenant node template by using nodeTemplates.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/nodeTemplates

{
   "name": "TEMPLATE_NAME",
   "nodeType": "NODE_TYPE"
   "nodeAffinityLabels": {
      "KEY": "VALUE"
   }
}

Replace the following:

  • PROJECT_ID: ID of your project.
  • REGION: region to create the node template in.
  • TEMPLATE_NAME: name of the node template to create.
  • NODE_TYPE: type of sole-tenant node for the nodes in a node group. All nodes in a node group are identical and are created from the parameters specified by a node template.
  • "KEY": "VALUE": comma-separated list of affinity labels represented as key-value pairs. You can only specify affinity labels for a node template when you create the node template.

Creating a sole-tenant node group

To create a node group that is based on a node template, the node group must be in a zone within the region where you created the node template. A sole-tenant node group inherits properties specified by the sole-tenant node template. The sole-tenant node group has additional values that you must specify. For BYOL, depending on the license requirements consider the different options for host maintenance policy:

  • If the licenses are assigned per physical cores, then use the restart-in-place or migrate-within-node-group host maintenance policy to minimize the number of physical servers used.
  • If the licenses are assigned based on user/device, a model typically used for Virtual Desktop licenses, then use the default host maintenance policy. These licenses are not assigned per physical cores, and therefore do not need a special host maintenance policy to limit physical server usage.

Console

  1. Go to the Sole-tenant nodes page.

    Go to Sole-tenant nodes

  2. Click Create node group.

  3. Under Node group properties, enter a Name for the node group.

  4. Select the Region and Zone for the node group.

    If there are any templates available in that region or zone, the templates are listed under Node template properties after you click Continue.

  5. Click Continue.

  6. Under Node template properties, select the Node template to base the node group on. Node groups must be in a zone within the region where you created the node template, so when selecting the template for a node group, select a template from the region that contains the zone where you are creating the node group. If no node template exists, you can create one.

  7. Click Continue.

  8. Under Configure autoscaling, set the Autoscaling mode to one of the following values. For more information, see Autoscaling node groups.

    • On: Have nodes automatically added to or removed from the node group.
    • Only scale out: Add nodes to the node group when extra capacity is required.
    • Off: Manually manage the size of the node group.

  9. Specify the Minimum number of nodes for the group. If you enable the node group autoscaler, either specify a range (minimum and maximum number of nodes) for the size of the node group, or, specify the number of nodes for the group. You can manually change either value later.

  10. Click Continue.

  11. Optional: Under Configure maintenance settings, set the Maintenance policy to one of the following values. The maintenance policy lets you configure the behavior of VMs on the node group during host maintenance events. For more information, see Host maintenance policies.

    • Default
    • Restart in place
    • Migrate within node group

  12. Click Create.

gcloud

Create a sole-tenant node group by using the gcloud compute sole-tenancy node-groups create command.

gcloud 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 sole-tenant node group to create.
  • TEMPLATE_NAME: name of the node template to create the node group from.
  • GROUP_SIZE: initial size of the node group. The node group autoscaler automatically manages the size of sole-tenant node groups, or you can manage the size manually.
  • ZONE: zone to create the node group in. This must be in the same region as the node template.

  • MAINTENANCE_POLICY: maintenance policy of the node group. Set the maintenance policy to one of the following values. If no value is set, default is used for the maintenance policy.

    • default
    • migrate-within-node-group
    • restart-in-place

REST

Create a sole-tenant node group by using nodeGroups.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/nodeGroups?initialNodeCount=GROUP_SIZE

{
  "nodeTemplate": "/regions/REGION/nodeTemplates/TEMPLATE_NAME",
  "name": "GROUP_NAME",
  "maintenancePolicy": "MAINTENANCE_POLICY"
}

Replace the following:

  • PROJECT_ID: ID of the project to create the node group in.
  • ZONE: zone to create the node group in. This must be in the same region as the node template.
  • GROUP_SIZE: initial size of the node group. The node group autoscaler automatically manages the size of sole-tenant node groups, or you can manage the size manually.
  • REGION: region containing the node template.
  • TEMPLATE_NAME: name of the node template to create the node group from.
  • GROUP_NAME: name of the sole-tenant node group to create.

  • MAINTENANCE_POLICY: maintenance policy of the node group. Set the maintenance policy to one of the following values. If no value is set, DEFAULT is used for the maintenance policy.

    • DEFAULT
    • RESTART_IN_PLACE
    • MIGRATE_WITHIN_NODE_GROUP

Provisioning a sole-tenant VM

Provision a VM on the node group and specify its host maintenance policy. Be aware of the following requirements:

  • To provision in node groups with restart-in-place host maintenance policy, make sure that the VM has the value TERMINATE for the on host maintenance option.
  • To provision in node groups with migrate-within-node-group maintenance policy, make sure that the VM targets a single node group with the node-group-name affinity label, and that it does not target single nodes with the node-name affinity label. Any type of host maintenance option is valid, but the recommendation is to use MIGRATE.

Console

If you used node affinity labels in the template, you can create multiple VMs by using managed instance groups (MIGs) and specifying the node affinity labels under Sole-tenant nodes settings, or, create individual VMs from the node group details page:

  1. Go to the Sole-tenant nodes page.

    Go to Sole-tenant nodes

  2. Click the Name of the node group to provision a VM on.

  3. Create a VM on a sole-tenant node by doing one of the following:

    • To create a VM anywhere in the sole-tenant node group, click Create instance.
    • To create a VM on a specific sole-tenant node, click the Name of a sole-tenant node group, then click the Name of a sole-tenant node, then click Create instance.

  4. Configure the sole-tenant VM. Because you already selected your node group or a specific node, the Region, Zone, and Node affinity labels are already specified by the template.

  5. Select a Machine configuration by specifying the Machine family, Series, and Machine type. Choose the Series that corresponds to the sole-tenant node type.

  6. Select the Boot disk for the sole-tenant VM, which is the previously imported virtual disk image.

  7. Select the Management tab:

    • Under Availability policy > On host maintenance, select the restart behavior of the VM.
    • Under Automatic Restart, select On (recommended) or Off.

  8. Click Create.

gcloud

Provision a sole-tenant VM on a sole-tenant node group by using the gcloud compute instances create command.

gcloud compute instances create VM_NAME \
    --machine-type MACHINE_TYPE
    --image IMAGE_NAME \
    --zone ZONE \
    --node-group GROUP_NAME \
    RESTART_BEHAVIOR \
    --maintenance-policy MAINTENANCE_POLICY

Replace the following:

  • VM_NAME: name of the VM to create.
  • MACHINE_TYPE: machine type for the new VM.
  • IMAGE_NAME: image to create a VM from. This is the image created during the import process.
  • ZONE: zone to create the VM in.
  • GROUP_NAME: name of the node group to provision the VM on.

  • RESTART_BEHAVIOR: restart behavior of this VM. Set the restart behavior to one of the following values:

    • --restart-on-failure
    • --no-restart-on-failure

  • MAINTENANCE_POLICY: VM behavior during maintenance events. Set the maintenance policy to one of the following values:

    • MIGRATE
    • TERMINATE

REST

Provision a sole-tenant VM on a sole-tenant node group by using the instances.insert method.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/VM_ZONE/instances

{
  "name": "VM_NAME",
  "machineType": "/zones/MACHINE_TYPE_ZONE/machineTypes/MACHINE_TYPE",
  "scheduling": {
    "nodeAffinities": [
      {
        "key": "node-group",
        "operator": "IN",
        "values": [
        "GROUP_NAME"
        ]
      }
    ],
    "onHostMaintenance": "MAINTENANCE_POLICY",
    "automaticRestart": "AUTOMATIC_RESTART"
  },
  "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 to create the VM in.
  • VM_ZONE: zone to create the VM in.
  • VM_NAME: name of the new VM.
  • MACHINE_TYPE_ZONE: zone containing the machine type.
  • MACHINE_TYPE: machine type to provision the VM on.
  • GROUP_NAME: name of the node group to provision the VM on.
  • MAINTENANCE_POLICY: VM behavior during maintenance events, set to either MIGRATE or TERMINATE.
  • AUTOMATIC_RESTART: specifies whether the VM is automatically restarted if Compute Engine stops the VM. The default value is true.
  • NETWORK: name of the network to connect the 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