WH IT E PAPER

ISV Licensing in Virtualized Environments

 VMware white paper

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Consider Virtualization Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Hardware resource pools and fractional use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Application mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

VMware Opinion: Considerations and Advice

for Licensing in Virtualized Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Licensing scalability and metric selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Clear virtualization rights and license keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Pros and Cons of Existing Metrics in Traditional and Virtual Environments. . . . . . . . . . 8

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2

By adopting the recommendations in this document,
Independent Software Vendors (ISVs) can create win-win
pricing models that preserve or enhance existing price-to-value
relationships when their products are deployed in virtualized
environments.
Key Take-Aways
• Virtualization alone doesn’t require ISVs to
necessarily adjust their pricing or licensing
models; however, it may upset the price/value
relationship and thus needs to be considered.
• Most ISVs have already addressed, or are
presently addressing, the unique licensing
issues created by virtualization. Fair, enforceable
and auditable options are available.
• ISVs, particularly those licensing based on
some form of hardware metric (core, processor
or server), need to consider that virtualization
is breaking the traditional bond between
hardware and software such that applications
are no longer tied to a particular physical host or
processor.
• Where possible, ISVs should use non-hardware
based metrics but if this isn’t possible, the metric
definition must equate virtual processors/
machines to physical.
Introduction
Industry pundits, analysts, resellers and most importantly,
software consumers have long argued that Software Licensing
is needlessly complex and more recently, doesn’t meet their
requirements for deployment in today’s dynamic, virtualized
IT environments. That said, ISVs have maintained that some
degree of complexity is necessary to provide customers with
scalable price points that correlate to the intended usage
entitlement thus matching received value to price. The
trick is finding the right balance, but the rapid adoption of
virtualization technology has made it even more important to
do so.
In the pre-virtualization / dynamic datacenter world, things
were somewhat simpler. Software was typically installed on a
particular piece of hardware and frequently would reside there
until the hardware was decommissioned. Although this model
didn’t necessarily optimize software and hardware utilization,
it did make software asset management and purchasing
decisions somewhat easier. Most ISVs built their pricing models
and licensing grants around this static model. Things have
changed.
VMware white paper
Customers have now embraced the numerous benefits of
virtualization (as evidenced by rapid adoption) and have
increasingly designed IT architectures that optimize their
investments through virtualization. Using virtualization
technology, customers are now achieving significantly higher
hardware utilization and are dynamically balancing workloads
across their physical resources while moving applications in real
time. However, while many ISVs have updated their policies to
accommodate virtualization use cases, some ISVs have not. In the
absence of a well defined policy, customers are left to interpret
their usage right which will inevitability lead to differences of
opinions between customers and ISVs. This strains what may
have been otherwise good relationships.
Relationships, however, don’t need to be strained. In fact, by
creating licensing models that specifically address virtualization
use cases, ISVs can create win/win pricing models and thus help
to ensure existing price-to-value relationships are maintained
or enhanced. Moreover, by removing ambiguity, customers will
have a clear understanding of their use rights in physical and
virtual environments.
In this paper, VMware will highlight key issues ISVs should
consider when developing their virtualization licensing
policies, industry best practices for licensing in today’s dynamic
environments and the pros and cons of existing models.
Consider Virtualization Use Cases
Virtualization does not, in and of itself, require ISVs or customers
to license software any differently. An application, database or
piece of infrastructure software that is licensed per instance,
physical host, processor or any other metric can still be licensed
using that same metric in a virtual versus physical environment.
An ISV who licenses per-user, for instance, may still provide
and receive fair value in a virtualized environment. However,
unless the ISV considers the following benefits of virtualization,
it may find that the connection between price and value is
changed when its solutions are running in virtual versus physical
environments. Specifically, its solution may be either more
expensive or, perhaps, more affordable than intended when
running in virtualized environments. Specifically, three concepts
must be addressed:
• Hardware resource pools and fractional use
• Application mobility
• Overall server consolidation
3
 VMware white paper

Hardware resource pools and fractional use

Business Demand
To maximize resource efficiency, VMware technology allows
customers to pool resources from multiple physical hosts1. As
App App App App App App App App App
illustrated in Figure 1, the resources may then be managed OS OS OS OS OS OS OS OS OS

independently of the physical servers that contribute the

resources.

Resource Pool

Business Unit
Figure 2. Resources are assigned to specific virtual machines in the resource pool as
needed.
App App App App

App App App App

OS OS OS OS
App App App App
OS OS OS OS

OS OS OS OS
DRS dynamically allocates and balances computing capacity
across a collection of hardware resources in a given resource
pool. VMware DRS continuously monitors utilization across
Resource Pool 2 Resource Pool 3 resource pools and intelligently allocates available resources
CPU 36 GHz, Mem 50 GB CPU 12 GHz, Mem 22 GB among the virtual machines based on pre-defined rules
Priority High Priority Low
that reflect business needs and changing priorities. When a
virtual machine experiences an increased load, VMware DRS
Agregate Resources
CPU 48 GHz, Mem 80 GB automatically allocates additional resources by redistributing
virtual machines among the physical servers within the network
Servers, Storage, Networking based on the parameters established when the virtual machine
was created.
Figure 1. Pooled resources from multiple physical hosts can be more easily managed. For instance, a virtual machine may be created using 1 GHz of
processing capacity from a resource pool with 8 GHz available
in total. The 1 GHz of required resource may be supplied from
one physical processor or fractions of one or more physical
processors within the resource pool. Moreover, the physical
resources supporting the application may dynamically vary and
Once the resource pools have been established, virtual
as the workload of that virtual machine increases, additional
machines are then created using the resources from a specific
computing resources may be easily allocated.
resource pool. When creating a virtual machine, the user defines
the amount of memory, disk and number of GHz it wants to At present, an estimated 40 percent of VMware® Virtual
dedicate to the virtual machine. The “size” of the virtual machine Infrastructure 3 customers are using DRS in production.
then remains static unless the user physically changes the
resources assigned to the VM or VMware® Distributed Resources
Scheduler (DRS) is in use. Technically, each virtual machine may
comprise fractions of, or multiples of entire physical processors.
The resources assigned to a specific virtual machine may be
easily increased or decreased as demand dictates.

1 Please note, even though resources may be pooled across multiple physical hosts, each unique virtual machine will entirely reside on one specific physical

4

Application mobility
The second concept ISVs must contemplate is that of
application mobility. Products like VMware® Vmotion™
technology enable customers to dynamically move a running
application, in real time, from one physical host to another.
Vmotion functionality allows users to, 1) perform live migrations
with zero downtime, undetectable to the user, 2) continuously
and automatically optimize virtual machines within
resource pools, 3) perform hardware maintenance without
scheduling downtime and disrupting business operations,
and 4) proactively move virtual machines away from failing or
underperforming servers.
At present, an estimated 62 percent of VMware Virtual
Infrastructure 3 customers are using Vmotion in production.
App App App
OS OS OS OS
VMotion Technology
ESX Server ESX Server
Hardware Hardware
Figure 3. VMotion technology lets you move virtual machines from one physical server
to the next without service interruption.
Consolidation
Finally, ISVs must consider the overall changes in hardware/
software deployment scenarios that virtualization enables. In the
past, for a variety of reasons, software programs were isolated
on specific physical hosts. However, in virtualized environments,
multiple programs run side-by-side on a single physical host,
each isolated from one another. Since virtualization enables
customers to use fewer servers to support a given workload,
ISVs licensing per physical node must contemplate this new
deployment scenario.
Virtualization allows customers to achieve server consolidation
ratios as high as 30+:1, but more typically in the neighborhood
of 4-6:1 per core, thus driving significantly higher utilization rates
out of their physical hardware resources.
To read more about the specific benefits of the products
mentioned above, please visit www.vmware.com.
VMware white paper
VMware Opinion: Considerations and Advice
for Licensing in Virtualized Environments
Given the large variety of software solutions available and
various deployment and usage scenarios, it is impossible
to identify an ideal, one-size-fits-all model for the industry.
However, common themes have emerged that are equally
applicable across each segment. In the following section, we
provide specific advice on how ISVs can maintain licensing price
scalability while ensuring that their license grant language and
key strategies are suitable for virtual environments.
Licensing scalability and metric selection
In most cases, software provides a different amount of value
when used by one user versus 20; when running on a small
server versus a large one; when running on a single core
processor versus multi-core; or when running on part of a
server versus the entire server. To ensure customers receive
compelling value in each possible deployment scenario, most
software vendors have selected granular pricing models that
allow their sales teams flexibility to easily customize pricing for
each situation. However, when hardware based metrics are used
to license software, unique challenges emerge in both physical
and virtual deployment scenarios.
Oracle, for instance, licenses the majority of its products on
a per-core basis. However, realizing that customers do not
necessarily receive twice the performance boost when running
their software on a dual-core versus a single-core chip, they
apply a ratio to determine the number of licenses required for
a specific environment. Symantec, on the other hand, licenses
many of its products on a tiered-processor or tiered-server
basis, charging more when their software is deployed on more
powerful chips, which effectively enables scaled pricing.
Both the Oracle and Symantec models achieve the same goal
and enable price scalability at the time of initial license sale.
However, changes in a customer’s environment after initial
deployment may upset this balance of fair value. Customers
often move software products to new platforms. Servers and/
or chips are replaced. Today, since software rarely lives and dies
on one piece of hardware, ISVs must consider the increasingly
mixed customer environments in which their software is
running. Virtualization is an additional element that must
be considered and as the example below illustrates, more
challenges arise for those ISVs who license their products based
on hardware metrics.
5
 VMware white paper

C o n s i d e r th e ch a ll e n g e s th a t a r i s e barriers. Each separated system acts as a physically independent,

w h e n lic e n s i n g p e r - p r oc e s s o r i n a self-contained server, typically with its own processors,
vi r tu a l e n vi r o n m e n t : operating system, boot area, memory, input/output subsystem
and network resources. It is impossible to read or write across
Software vendor XYZ licenses its products per-processor. This
a hard partition boundary, and there is no resource sharing
model has historically allowed the ISV to easily differentiate
between hard partitions. Examples of hardware partitioning
its price point for small vs. large software deployments of. In a
technology include: HP nPar, Sun Dynamic System Domains
physical world, this model works well. However, in a virtualized
(DSD), IBM LPAR.
environment, this pricing model may present a problem for that
vendor unless the proper considerations are made. The challenge The differences in partitioning technology are important
stems from the fact that at any given point in time, each virtual because each type of partitioning makes resources available to
machine on a physical host may be using resources provided by software applications differently. While hard partitioning makes
one, or fractions of all the physical processors on the host. all resources within a resource pool available to a particular
application, soft partitioning does not. Moreover, in an X86
If the ISV licenses per physical processor only, they may require
environment, soft partitioning is the dominant technology used,
the customer to purchase a license for every processor in the
because it allows for higher utilization rates.
resource pool. The rationale for doing so is the fact that technical-
ly, each physical processor, or fraction of a processor, may access To address these complexities, VMware suggests that ISVs move
the ISV’s software at any particular point in time even though the away from hardware based metrics where possible, and onto
virtual processors that were created out of this pool, may only more value-driven metrics such as user, concurrent user, or
use a fraction of the overall pool’s processing capacity. In this running instance (where physical or virtual instances are treated
case, that ISV’s price point no longer scales based on the value equivalently). Alternatively, offering a specific licensing model
provided and will usually make the vendor’s solution appear that is tailored to virtual environments may be appropriate.
extremely expensive relative to vendors who have adjusted their If non-hardware based metrics are not an option, at a minimum,
models to account for this deployment scenario. usage rights should address the concept of virtual processors
and resource pools. Specifically, we recommend that ISVs that
license per processor allow each processor to be defined as
either physical or virtual. To alleviate concern over the varying
processing capacity of the virtual versus physical processor and
to maintain the price / value relationship, we suggest adding
To address this issue, some ISVs have developed partitioning
wording such as the following:
policies to segregate specific processors into resource pools on
a large server. However, it is important for ISVs and customers to
carefully consider the various types of partitioning technology
and the implications on the scalability of the overall model.
“The licensing requirements for virtual processors shall be no different
There are two general categories of partitioning technology:
than for physical processors, provided that the virtual processor is no
Software (Soft) Partitioning: Software partitioning is technology more powerful than any physical processor on a given server. Moreover,
that allows multiple instances of an operating system (OS) to in the event that the number of virtual processors in a given resource pool
execute within a single server. Processor resources are allocated exceeds the number of underlying physical processors, the customer need
to programs running within a partition and other server only license the number of physical processors.”
resources such as memory, disks, network, and input/output
subsystems can be shared dynamically among the partitions.
This computing environment can be dynamically adapted to
changing application needs. Examples of software partitioning
technology include: VMware, HP Adaptive Partitioned
MultiProcessing (APMP), HP Process Resource Manager (PRM),
HP vPar, Solaris Processor Sets, IBM AIX Workload Manager.
Hardware (Hard) Partitioning: Hardware partitioning physically
segments a server, by taking a single large server and separating
it into multiple smaller systems that define the boundaries of
shareability of hardware resources. This physical separation of
computing resources is performed by hardware-enforced access

6
 VMware white paper

Finally, consider a hypothetical infrastructure ISV that licenses its may have challenges with this key strategy if its software is
software on a per physical server basis: deployed in virtual environments. Given the concepts outlined
in this paper, such as application mobility and resource pools,
Software vendor ABC licenses its products per physical server.
the node-locked license key may prevent the application from
However, increasingly, customers are running ABC’s software
running as intended.
within virtual environments, and they now realize that up to six
virtual machines are now running on a server that once hosted Again, the ISV has multiple options. First, if piracy is a major
one. More specifically, multiple instances of that ISV’s application concern, there are third-party vendors that offer license
are running side by side, providing the same workload benefit as activation and registration solutions . Serial-based license keys
the previous six physical servers. Due to server consolidation, the and/or electronic license files that unlock product functionality
ISV that may once have been able to sell licenses for six servers yet do not limit deployment to specific physical hosts may be
now only sells one. Although customers would initially rally and a second option. Site based licensing models and related key
claim success in driving down their software costs, this would be strategies may be applicable for some ISVs.
a nightmare for the ISV.
To address this scenario, the infrastructure ISV has a variety of
options. First, it could consider moving to a per-instance model
versus per physical server model, which will enable the ISV to
effectively maintain revenue neutrality while maintaining a
simplistic licensing model. BEA just moved to a per-instance
model specifically for this reason. Second, in situations where
the ISV’s application provides somewhat less value in a virtual
environment relative to a physical environment, the ISV
could offer a licensing option specifically tailored for virtual
environments and a per virtual machine licensing option in
addition to physical. Third, and perhaps most ideal, the ISV could
find a non-hardware based metric that correlates to the value its
product provides.
As the example above illustrates, with proper planning, both
ISVs and customers can create win-win solutions when licensing
and deploying software in virtual environments.

Clear virtualization rights and license keys

VMware believes that most customers want to comply with
their licensing agreements; but it is the responsibility of the
ISV to clearly communicate usage rights and, where possible,
help their customers maintain compliance. Customers must be
able to clearly understand their usage entitlement and track
deployments. Virtualization rights must be clearly articulated.
However, given licensing inconsistency across vendors and
the large number of metrics used to price products, the real
customer challenge lies with unintentional unauthorized
use. Pirates intent on stealing software will usually find a way;
however, most customers will only use software they didn’t pay
for if they don’t know they were doing so.
To help customers maintain compliance, ISVs must first clearly
articulate usage rights, including those for virtualization
deployment scenarios. Second, license enforcement strategies
must take into account virtualization use cases. Specifically,
an ISV that generates a license key that is tied to the physical
characteristics of a particular piece of hardware (node-locked)

7
 VMware white paper

Pros and Cons of Existing Metrics in Traditional

and Virtual Environments
Across the industry, the majority of software today is licensed via
one of the five metrics listed below. While all were well suited to
physical environments, non-hardware based metrics appear to
be appropriate for both.

Metric Traditional Environment Virtual Environment

Components Pros Cons Pros Cons

Server / Host • Simple pricing • Limited scalability • Simple pricing • Lack of granularity may
drive high price perception
• Simple tracking • Limited correlation to • Simple tracking
usage / value • Limited scalability
• Simple compliance • Simple compliance
• Constantly changing • Limited correlation to usage
H/W may require pricing / value
updates
• Under/over pricing in
virtualized environments

Processor / • Simple pricing • Limited correlation to • Simple tracking • Doesn’t contemplate the
Socket usage / value virtual processor concept
• Simple tracking • Simple compliance
• May drive perception of
• Simple compliance
high price
• Limited scalability
• Limited correlation to
usage / value

Core • Granular, simple • Core performance
pricing
• Scalable pricing
• Simple tracking
• Simple compliance
• Simple tracking • Doesn’t contemplate the
doesn’t scale linearly virtual processor concept
• Simple compliance
• May drive perception of
high price
• Limited scalability
• Limited correlation to
usage / value

User • Simple pricing • May not be easily Metric is equally applicable to traditional vs. virtual
applicable to environments
• Simple tracking
infrastructure software
• Simple compliance
• Scalable

Instance • Simple pricing • Limited scalability Metric is equally applicable to traditional vs. virtual
environments
• Simple tracking
• Simple compliance

8
 VMware white paper

Looking at the key ISV segments, a few models may be

particularly appropriate for virtualized environments. Please
note, however, these comments are generic and specific
consideration must be given to the products value driver,
position within the software stack and pricing scalability.
Applications
Applications are best suited to non-hardware based metrics as
it is much easier to correlate value to the number of users or
related metric. Where this isn’t possible, per-instance licensing is
most appropriate given that even in a virtualized environment,
the value provided may closely match the value that would
have been otherwise provided in a more traditional non-virtual,
physical server-based licensing model. The simplicity of per-
instance licensing is equally suitable to physical and virtual
licensing scenarios.
Databases
Databases are best suited for either per-processor/virtual
processor licensing or per-instance models. For example, Oracle
today licenses per core because there is a correlation between
the number of cores (and type) supporting a particular solution
and the value provided to the customer. That said, this model
may be easily extendable to a virtual environment, assuming
that the licensing model covers both virtual and physical
processors. Alternatively, a much more simplistic, per-instance
model may be appropriate as well, assuming that the size or
capacity resource requirements of the database are not the
primary value drivers.
Infrastructure software
Given its close tie to driving the performance of underlying
hardware, infrastructure ISVs may find that licensing per physical
server, processor or instance is best, assuming that fractional
use is not a concern; that is, of course, unless there is a non-
hardware based metric available that directly correlates to the
value the product provides. However, if a server or processor
price point is chosen, as this paper explains, to the ISV should
take into account the scalability of its price point and consider
using mobility and fractional server / processor licensing.

Conclusion
The world has changed. Software is deployed, moved and
redeployed. Companies are consolidating services and
allocating resources dynamically to Resources to meet workload
requirements. Given our new environment, ISVs must adapt their
models to ensure they maintain their value / price correlation
and, most importantly, provide the flexibility customers demand.

9
VMware, Inc. 3401 Hillview Ave Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com
Copyright © 2008 VMware, Inc. All rights reserved. Protected by one or more of U.S. Patent Nos. 6,961,806, 6,961,941, 6,880,022,
6,397,242, 6,496,847, 6,704,925, 6,496,847, 6,711,672, 6,725,289, 6,735,601, 6,785,886, 6,789,156, 6,795,966, 6,944,699, 7,069,413,
7,082,598, 7,089,377, 7,111,086, 7,111,145, 7,117,481, 7,149,843, 7,155,558, 7,222,221, 7,260,815, 7,260,820, 7,268,683, 7,275,136,
7,277,998, 7,277,999, 7,278,030, 7,281,102, 7,290,253; patents pending. VMware, the VMware “boxes” logo and design, Virtual SMP
and VMotion are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other
marks and names mentioned herein may be trademarks of their respective companies.