This page describes how Google Cloud supports bringing your own licenses (BYOL) to Compute Engine. In addition to on-demand licenses, Google Cloud provides you with flexibility for bringing your existing licenses. Bringing your existing licenses 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.
Before attempting to bring images with existing licenses to Google Cloud, review your licensing terms and conditions. For instructions about how to bring images with existing licenses to Google Cloud, see Bringing your own licenses.
To support bringing your own licenses, and to help you manage compliance requirements related to your licenses, Google Cloud provides tools for the following:
- Importing images
- Managing VMs on dedicated hardware (sole-tenant nodes)
- Minimizing physical core usage
- Tracking usage of physical cores for reporting purposes
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.
Sole-tenant nodes are physical servers dedicated to hosting VMs 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.
There are other licensing scenarios that do not require sole-tenant nodes, for example, licenses related to Microsoft applications. If you are considering bringing licenses from Microsoft applications such as SharePoint Server and SQL Server, use Microsoft License Mobility.
Virtual disk import and image creation
To provision VMs with your existing licenses, you must bring your own media. Images based on a Google Cloud premium image are not eligible for BYOL because premium images require pay-as-you-go licenses from Google.
If you have virtual disks (golden disks or golden images) in your on-premises environment with customizations (software configurations, licenses, etc) that you need, the import virtual disk tool can help you do the following:
- Import your customized virtual disks and create images based on those disks
- Set up the appropriate license configuration
- Install the packages and drivers necessary for compatibility with Google Cloud
The import image workflows are customizable and available on GitHub. 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.
Google supports offline image import for the following operating systems:
- Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7
- Server: Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
- Client: Windows 7 SP1 x64, Windows 7 SP1 x86, Windows 8.1 x64, Windows 8.1 x86, Windows 10 x64, Windows 10 x86
In addition to importing operating system images that are offline, you can import images from VMs that are online and running.
Licenses and license activation
After verifying that you are importing a compatible OS, you are responsible for checking that your licensing agreements permit you to use the software in the manner described in this documentation and that you are permitted to use the guest OS image and license import environment provided by Google. Note that 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 activation keys, or set up the Cloud Key Management Service. You can't activate images with existing licenses against Compute Engine's license server.
After importing your image and activating the license, provision a VM based on the imported image onto a sole-tenant node.
Physical core and processor usage
If you use the image import process to bring images with existing licenses to Google Cloud, you must do the following:
- Prepare the images according to your license agreements
- Activate your licenses
- Track the license usage of your VMs
- Report license consumption to your vendor
To help you with reporting your license consumption, Google provides tools to help you track both license usage and physical core and processor usage.
Depending on your licensing scenarios and your workloads, you might want to limit the number of physical cores used by your VMs. Sole-tenant nodes provide the following configuration options, which vary based on how and whether VMs are live migrated during monthly maintenance events on the host:
VMs live migrate to any server: Physical core usage is not minimized during host maintenance events, and VMs are moved to a new host without regard for affinity to a certain set of servers. This is the default configuration option, and is recommended for per-user or per-device licenses.
VMs restart in-place: VMs are terminated and then restarted on the same physical server during a host maintenance event, which occur approximately every 4 to 6 weeks. This option is recommended for workloads that are fault-tolerant and must remain on the same physical server, or for licenses that are based on the number of physical cores or processors.
VMs live migrate within a sole-tenant node group: VMs are live migrated within a fixed pool of physical servers (sole-tenant node group) during host maintenance events. Unlike the default setting where VMs live migrate to any server, with this setting, nodes in a sole-tenant node group are pinned to a fixed set of physical servers to support server-bound licenses. To ensure capacity for live migration, Compute Engine automatically reserves one out of every twenty nodes (5 percent) that you provision. This option is recommended for high-availability workloads with licenses that are based on the number of physical cores or processors.
Rarely, a server might experience a critical hardware failure. If this happens, Compute Engine retires the physical server and its unique identifier, revokes access to the physical server, assigns a replacement node with a new unique identifier, and moves your VMs onto the replacement node. Depending on the configuration of your sole-tenant nodes, Compute Engine might restart your VMs.