Skip to main content
Matrix42 Self-Service Help Center

License mobility with virtual machines

Introduction

The concept of "License Mobility" is a common license term defined by software publishers like Microsoft. It applies to virtualization scenarios when the relevant software is installed in virtual machines that move from one physical machine to another, but the physical server is the eligible target for licensing.  

Publisher's license terms

Definition of "License Mobility in Microsoft's Product Terms: "Customer may move its licensed software from shared servers back to its Licensed Servers or to another party’s shared servers, but not on a short term basis (not within 90 days of the last assignment). Customer may also move Instances run or OSEs managed under a particular License from shared servers in one Server Farm to its shared servers in another Server Farm, but not on a short-term basis (not within 90 days of the last assignment)."

In Microsoft's License Terms (see copy of the October 2018 issue below) Microsoft clearly talks about a "Licensed Server", even when the publisher defines that licensing is "by Individual Virtual OSE": 

In the Glossary section of the Microsoft Product Terms the publisher defines what a "Server" is: 

SAM tool's business logic

The correct behavior of the SAM tool's business logic is configured in license models by the "License Assignment" setting. 

  1. If it is set to "Operating System", either physical or virtual machine can be used to assign licenses for entitlement. In this case there is no reason to think about license mobility.
  2. If this is set to "Device", any license must be assigned to a physical machine and license mobility must be considered if a minimum entitlement period is defined.

Device Based Assignment:

Operating the software in a virtual OSE (Operating System Environment) requires that the physical server that is hosting the virtual machine is licensed.  The Matrix42 SAM tool therefore creates license requirements for the current host and all other physical servers that have hosted the corresponding virtual machine during the minimum entitlement period (90 days).  This is necessary because license mobility is possibly granted only under certain prerequisites and thus, full transparency about the underlying configuration is needed to prove correct entitlements.

The illustration below explains a scenario with two physical machines (Hypervisor).

  • Host machine 1 currently runs VM 1 and VM 2.
  • Host machine 2 currently runs VM 3, VM 4 and VM 5.
  • VM 3 has been moved from machine 1 to machine 2 less than 90 days go. 

LoadBalancing and License Mobility.jpg

Following steps are processed from the SAM tool's business logic:

  1. All virtual machines that have the software installed lead to license requirements for the "Technical Consumers" (VM 1 - VM 5).  
  2. The system checks if the "License Assignment" setting of the license model used by the license requirements defines assignment to a "Device".
  3. If yes:
    • The system creates a license requirements for each physical machine that is currently hosting the virtual machines (eligible consumer).
    • The system creates license requirements for all former hosts that have hosted each VM during the minimum entitlement period (90 days).
    • The system consolidates all license requirements for the technical consumers (virtual machines) with reason "License Assignment" (i.e. they do not need entitlement).

The license model of the license requirements defines under which conditions license mobility is granted. This is usually explained in the name and description of the license model. If there is no hint about license mobility, it is granted. 

There are three possibilities:

  1. No license mobility is granted (No Mobility)
  2. License mobility is granted (Mobility) 
  3. License mobility is granted only if the license used for entitlement is under Software Assurance (Mobility on SA) 

Scenario 1: No license mobility

The type of the license used to entitle the licensed server has no impact.

  • Host machine 1 needs to cover VM 1, VM 2 and also VM 3 with the license assigned for entitlement.  
  • Host machine 2 needs to cover VM 3, VM 4 and also VM 5 with the license assigned for entitlement.

Depending on the metric of the License Model, the amount of required usage rights equal to the number of software instances (e.g. "per Server"), CPU (e.g. "per CPU") or Cores (e.g. "per Cores") inside every relevant OSE, considering the eligible "Virtualization Rights" (either "No Virtualization", "Limited Virtualization" or "Full Virtualization"). 

Scenario 2: License mobility is granted

The type of the license used to entitle the licensed server has no impact.

  • Host Machine 1 needs to cover VM 1 and VM 2 with the license assigned for entitlement. 
    VM 3 is not relevant for licensing, since the minimum entitlement period does not apply.
  • Host Machine 2 needs to cover VM 3, VM 4 and also VM 5 with the license assigned for entitlement.

Depending on the metric of the license model, the amount of required usage rights equal to the number of software instances (e.g. "per Server"), CPU (e.g. "per CPU") or Cores (e.g. "per Cores") inside every relevant OSE, considering the eligible "Virtualization Rights" (either "No Virtualization", "Limited Virtualization" or "Full Virtualization"). 

Scenario 3: License mobility is granted only under Software Assurance (Maintenance)

The type of the license used to entitle the licensed server decides if license mobility is granted or not.

License mobility is only granted if the license is under maintenance (i.e. the License Type is either "Full Version with Maintenance", "Maintenance" or "Maintenance Renewal").  Otherwise, the benefit of license mobility is not eligible.

The license models provided by the License Intelligence Service (LIS) include automatisms to calculate the benefit of license mobility. Hereby, there are two different variants.

Variant A: application of license mobility in eligible cases only

Calculation under automatic recognition of the link between the license requirement and a license that is under maintenance (software assurance). Prerequisite of a consideration of the license mobility presupposes thus that a license need is linked with a corresponding license and is therefore in the status "licensed". Accordingly, they do not calculate license mobility if the license requirement is in "License Required" or "Consolidated" status. You recognize such license models by the term "Mobility on SA" in its name.
Examples:

  • SQL Standard 2016 | Core (No Virtualization; Mobility on SA)
  • SharePoint | Server + CAL (No Virtualization; Mobility on SA)

When to use: Use license model of this kind, if you cannot predict, if the license requirement will actually be entitled under SA. This is usually the case, if you have available licenses with and without SA in your inventory. The system then automatically finds out, if the entitlement is eligible for license mobility SA-benefit and calculates accordingly. In this scenario, license requirements are not using license mobility until they are properly licensed, which could make it difficult to plan purchase of additional licenses that are under software assurance (e.g. True-up). Change the license model of all license requirement in scope of the planned purchase, so that the system calculates the effectively required usage rights, using the license mobility benefit.

Variant B: application of license mobility in all cases

Calculation with consideration of license mobility, without checking, a license requirement is linked to a corresponding license and is therefore in the status "licensed". Accordingly, they always calculate the license mobility, even if the license requirement is in the "License Required" or "Consolidated" status. You recognize such license models by the term "w/SA" in its name.
Examples:

  • SQL Standard 2016 | Core w/SA (No Virtualization; Mobility)
  • SharePoint | Server + CAL w/SA (No Virtualization; Mobility)

When to use: Use this type of license model when you can predict that the license requirement will actually be eligible under SA. This is usually the case when you have only available licenses in your inventory. The system will then always automatically calculate with the benefit of license mobility, even if a license need ends up being covered with a license that does not carry Software Assurance and therefore no license mobility.

Special Case: License mobility leads to "zero" license requirement for host

In example below you can see that Hypervisor #2 does not run any virtual machines with the software at the moment.
However, the VM history shows former guest system VM #3 which was relocated less then 90 days ago to Hypervisor #1.

LoadBalancing and License Mobility-2.jpg

The system creates license requirements for all VM and all hypervisors without regard to possible "license mobility," i.e., including VM/host history, as long as the minimum eligibility period has not elapsed. This approach allows downstream licensing to be calculated with or without license mobility.

Hypervisor #2 would not require any usage rights for its licensing needs in the case of granted license mobility. The amount of the license requirement is then consequently zero. However, if license mobility is not granted, it would have to show allocated usage rights for VM #3.

  • Was this article helpful?