Dear VMware Customer, Chances are, if you’re reading this letter, you’re already one of more than 125,000 customers using VMware virtualization technologies to save time, money and energy while achieving more with the hardware you already own. If you are, you also know that thousands of ISV applications “just run” on VMware Infrastructure, no modifications needed. Unfortunately, not all software vendors know what you know. You may even have experienced pushback from some of them, telling you they don’t support their application if you’re running it in a virtual machine. To help you get the support you need, VMware is asking customers like you to help us pursue official support statements from these vendors. Customers are the most influential factor in convincing ISVs to provide support for their applications in a virtual environment, and the kit you hold in your hands contains a wealth of tools and information to assist you in working with them on this issue: The ISV Applications on VMware Infrastructure presentation describes the advantages of the VMware Infrastructure platform. You should include the Addendum to the ISV License & Support Agreement in the Support Agreement at time of purchase. The VMware Technology Alliance Partner (TAP) Validation Pilot Guide describes VMware’s program to assist ISVs in validating their application on VMware Infrastructure. (ISVs must join the TAP program at the Select or Premier levels in order to participate in the validation program.) A white paper titled ISV Licensing in Virtualized Environments provides recommendations to ISVs for licensing models that specifically address virtualization use cases. The sample letter should be sent by your CIO to ISV executives to request support for their application on VMware Infrastructure. Resources are also available on the web: http://wwwa.vmware.com/isvrequest/ - Use the ISV Support Request Tool when you need explicit support from a particular vendor, and would like VMware’s assistance to secure it. http://www.vmware.com/technology/virtual-infrastructure-apps/ - This page explains why VMware is the best platform for enterprise applications and databases, and how to use VMware technology to optimize management and operation of enterprise applications. http://www.vmware.com/partners/alliances/vendors/ - Provides a list of software vendors that already have support policies for VMware environments in place. Note that some vendor sales and support personnel may not be aware that their company actually does have an official support policy, so this list can be an invaluable resource. We are requesting your help to let ISVs know how important it is that they support their applications on VMware Infrastructure. Please use the tools in this kit and on the web to encourage your software vendors to engage with VMware around this important issue.
Transcript
Dear VMware Customer,
Chances are, if you’re reading this letter, you’re already one of more than 125,000 customers using VMware
virtualization technologies to save time, money and energy while achieving more with the hardware you
already own. If you are, you also know that thousands of ISV applications “just run” on VMware Infrastructure,
no modifications needed.
Unfortunately, not all software vendors know what you know. You may even have experienced pushback from
some of them, telling you they don’t support their application if you’re running it in a virtual machine.
To help you get the support you need, VMware is asking customers like you to help us pursue official support
statements from these vendors. Customers are the most influential factor in convincing ISVs to provide
support for their applications in a virtual environment, and the kit you hold in your hands contains a wealth of
tools and information to assist you in working with them on this issue:
The ISV Applications on VMware Infrastructure presentation describes the advantages of the VMware
Infrastructure platform.
You should include the Addendum to the ISV License & Support Agreement in the Support Agreement at
time of purchase.
The VMware Technology Alliance Partner (TAP) Validation Pilot Guide describes VMware’s program to
assist ISVs in validating their application on VMware Infrastructure. (ISVs must join the TAP program at the
Select or Premier levels in order to participate in the validation program.)
A white paper titled ISV Licensing in Virtualized Environments provides recommendations to ISVs for
licensing models that specifically address virtualization use cases.
The sample letter should be sent by your CIO to ISV executives to request support for their application on
VMware Infrastructure.
Resources are also available on the web:
http://wwwa.vmware.com/isvrequest/ - Use the ISV Support Request Tool when you need explicit
support from a particular vendor, and would like VMware’s assistance to secure it.
http://www.vmware.com/technology/virtual-infrastructure-apps/ - This page explains why VMware is the
best platform for enterprise applications and databases, and how to use VMware technology to optimize
management and operation of enterprise applications.
http://www.vmware.com/partners/alliances/vendors/ - Provides a list of software vendors that already
have support policies for VMware environments in place. Note that some vendor sales and support
personnel may not be aware that their company actually does have an official support policy, so this list
can be an invaluable resource.
We are requesting your help to let ISVs know how important it is that they support their applications on
VMware Infrastructure. Please use the tools in this kit and on the web to encourage your software vendors to
Validate that performance is fine at my edge cases?
Just provide me with some comfort level, since virtualization is new to me?
SAP as an Example
Critical Success Factors in obtaining unqualified support from SAP:
1. Stable product that supported their needs (64-bit, large memory support)
2. Customer Demand: > 600 customer requests in their system for VI support
3. VMware Market Share: SAP realized the virtualization adoption curve and
VMware’s leadership
4. Partners: Intel, AMD, and OEMs influenced
5. VMware Enablements: We worked closely with their Linux and Windows
platform groups to run benchmarks. Successful completion of parallel
benchmarks on multiple virtual machines at the same time was a key factor
6. Today, SAP is convinced that VI is transparent to its applications, and
certification requirements have been lessened
Many smaller ISVs accept the transparency principle and readily support VI
VMware offers a variety of tools & assistance for ISVs
• Engaging 100s of ISVs via Alliances Program
• Application Validation Program for ISVs
• Virtualization Readiness Program for ISVs
• Joint Solutions & Reference Architectures
• Education & Training for ISVs: how to support, how to create best practices,
how to license software for virtualization
Microsoft
• Creating uncertainty and doubt
• Historically, Microsoft has taken an uncooperative stance with respect to VMware
• Technically, Microsoft apps run very well on VMware (example: Exchange)
• Microsoft Server Virtualization Validation Program (SVVP): VMware has joined SVVP and achieved support from Windows and over 30 Microsoft Applications
• If Microsoft Customer Service Representatives decline to provide support, point them to the Microsoft SVVP list of participating vendors and demand support for apps running on VMware. List is located at:
Double the Capacity of Exchange 2007 Infrastructure
Oracle
• Refusing to support other virtualization platforms
• Support for VMware intentionally ambiguous
• Oracle claims customers haven’t demanded support for VMware; however, VMware has directly channeled hundreds of requests from customers asking for support
• No technical issues in running Oracle database, middleware or applications on VMware
Ultimately, will respond only to direct customer pressure
DB requirements
(4-CPU Oracle DB)
VI
Capacity
Disk IO
per
Second
Database Requirements
vs. VI Capacity
Source: VMware Capacity Planner analysis of > 700,000 servers in customer production environments
VI supports 80x the
IO throughput
requirements of the
average 4-CPU
Oracle Database
Support Large Oracle Databases
20K
40K
60K
80K
100K
1,200
100,000
Licensing and virtual environments
Software licensing has not kept pace with changes
Multi-core chips, virtualization
Licensing models that create win/win already exist:
BEA and per instance Equivalency Ratios (vCPU : CPU)
SAP and per user IBM, Symantec, CA, others. . .
Some of the perceived ‘objections’ by ISVs may be overstated
Some of these issues occur in physical environments too (cloning, remote copies, etc)
Customers are putting controls in place (provisioning portals, consumption monitors)
• Customers have virtualized more critical applications than is commonly recognized
• ESX 3.x has been a watershed product for virtualizing critical applications
• I/O myths based on ESX2
• VMware Infrastructure is better than physical for applications
• Native scalability, DRS, better manageability & VI technology futures
• VMware is gaining momentum with ISVs for support & licensing
• Next step is to go from 100s to the 1000s
• ISVs beginning to appreciate the VMware proposition and are promoting it
• Microsoft and Oracle reluctance are competitively motivated, not technically
Thank You
1
Addendum to the ISV License & Support Agreement
VIRTUALIZATION SUPPORT AND SERVICE This Addendum is additive and no terms herein shall supersede the existing Support Agreement’s terms. The additive operating environments and related management processes defined herein will be supported and governed pursuant to the Licensor’s existing Support Agreement with the Licensee and all pre-existing terms shall apply, including but not limited to the support services, services levels and performance measures. The Licensor represents and warrants to the Licensee the service levels and performance measures contained within the existing Support Agreement relative to the additive operating environments and the related management processes defined herein. 1. Introduction The advent and wide spread adoption of Virtualization Technologies in the marketplace dictate that the existing Support Agreement between the Licensor and Licensee be adapted to address this new operating environment. The Licensor and Licensee agree that the introduction of Virtualization Technology is imminent and is already occurring as part of the Licensee’s normal course of business. The Licensor acknowledges its intent to support its products when they are running in a Virtualized Operating Environment, with the expectation that such products will function properly. 2. Definitions As used in this Agreement, each of the following capitalized terms shall have the meaning ascribed to it as set forth below.
2.1.1. “Virtualization Technology”: a framework or methodology of dividing the resources of a computer into multiple execution environments, by applying one or more concepts or technologies such as hardware and software partitioning, time-sharing, partial or complete machine simulation, emulation, quality of service, and many others.
2.1.2. “Virtualized Operating Environment”: Within the deployment of Virtualization Technology wherein the installation and operation of software occurs.
2.1.3. “Virtualization Layer”: That portion of the computing environment which contains the virtualization technology which also integrates with the resident applications.
2.1.4. “VDI”: Virtual desktop infrastructure is the practice of hosting a desktop operating system within a virtual machine (VM) running on a centralized server.
2.1.5. “MAV”: Acronym for Microsoft Application Virtualization which is software that provisions applications to the desktop operating system environment.
2.1.6. “Appliances”: A method for creating application suites by "packaging" a group of applications with their own operating system, each running within a virtual machine.
2.1.7. “Nonconformity”: A failure of any Services (to the extent applicable) to conform to the applicable specifications.
2.1.8. “Errors”: Any Nonconformity or the existence of a virus, worm, or disabling code in the Service
2
3. Scope of Support Services During the Term of the existing Support Agreement, the Licensor will provide to the Licensee unqualified support for the Licensor’s products deployed within a Virtualized Operating Environment. Nothing in this Addendum will in any way restrict the ability of the Licensee to purchase the same or similar services or applications from a third party. The Licensor and Licensee agree to engage the provider of the virtualization platform if required to successfully resolve any Errors or Nonconformity. The Licensor agrees to formally participate in those support programs provided by the applicable Virtualization Technology platform providers which are tailored to enabling independent software vendors, specifically including those provided by VMware and Microsoft. 4. Virtualization Error Resolution Process The Licensee will determine when an Error has occurred, and pursuant to the terms of the existing Service Agreement, the Licensee will classify the severity of the Error, and the Licensor will address the Error in the manner specified for the severity level. When reporting Errors to the Licensor, the Licensee shall provide a written description of the Error in reasonably sufficient detail to enable the Licensor to diagnose the problem. The Licensor will use commercially reasonable efforts to resolve errors in a timely manner as set forth in the existing Support Agreement, as reported by the Licensee or any other of the Licensor’s customers or those identified by the Licensor itself. When an Error has occurred with the Licensor’s product(s) within a Virtualized Operating Environment, both parties will participate in the following activity:
1. The Licensee will validate that the virtual machine and applications within the Virtualized Operating Environment are properly configured and that all available patches for the virtualization software have been installed.
2. The Licensor will diagnose the Error providing its findings to the Licensee, reporting on the
identified root causes consistent with manner as set forth in the existing Support Agreement.
3. If the Licensor determines that the Error has been caused by its software, then the Licensor
will provide to the Licensee a remedial plan of action designed to eliminate, prevent or reduce the future likelihood of recurrence of such root causes, immediately proceeding to carry out such remedial plan consistent with manner as set forth in the existing Support Agreement.
4. If the Licensor determines that the Error is being caused in part or in whole by the
virtualization layer, then the Licensor and the Licensee will jointly engage with the provider of the virtualization platform in joint diagnostic processes. Together the parties will put forth a good faith effort to determine and agree upon the underlying cause of the Error, proceeding to define and carry out a remedial plan consistent with manner as set forth within the applicable Support Agreement(s).
3
Exhibit A
Sample support statement and VMware resources available to ISVs VMware Technology Alliance Partner Program ISVs can obviously provide support for their applications running in a virtualized environment without any involvement of VMware. Alternatively, ISVs can join VMware’s Technology Alliance Program (TAP) which provides resources to assist the ISV in providing support, including: software licenses, technical enablement, and potentially access to VMware personnel to assist them with the support validation efforts. VMware Applications Validation Pilot VMware offers a service to ISVs to help them test & validate their applications on VMware Infrastructure. It provides ISVs with a suite of resources: testing labs, technical engineering personnel to assist with testing, test methodologies and frameworks, as well as VMware software. If an ISV chooses to have the validation done at its premises, VMware can provide onsite technical resources. ISV Support The ISV should be encouraged to provide a statement like the one below for all of their products. Example Support Statement (ISV) confirms that we will support customers running (Application Names) on supported Operating Systems in a VMware virtual machine environment. (ISV) will provide unqualified support for (Application Names) running in a VMware virtual environment in an identical manner as with (Application Names) running on any other major x86 based systems without requiring reproduction of issues on native hardware. Should (ISV) suspect that the virtualization layer is the root cause of an incident; the customer will be required to contact the appropriate VMware support provider to resolve the VMware issue. Support Process between ISV and Virtualization Provider We encourage the ISV to engage with the virtualization provider via a third-party support facilitation organization like TSA Net or a Joint Customer Support Agreement established directly with the virtualization vendor. Licensing In an effort to ensure software license compliance and reduce the effort by both the Licensee and Licensor to track license use accurately, we would encourage the ISV to adopt a virtualization-friendly licensing policy if it has not already done so. 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. For a better understanding of the underlying
4
technology that impacts traditional hardware-based licensing, the ISV may want to refer to the VMware White Paper, “ISV Licensing in Virtualized Environments.” 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) may have challenges with this key strategy if its software is deployed in virtual environments. Virtualization concepts, such as application mobility and resource pools, the node-locked license key may prevent the application from running as intended. 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. We believe that ISVs have multiple options. First, if piracy is a major concern, there are third-party vendors that offer license activation and registration solutions. A second option may be serial-based license keys and/or electronic license files that unlock product functionality yet do not limit deployment to specific physical hosts. Site-based or user-based licensing models and related key strategies may be applicable for some ISVs.
VMware Technology Alliance Partner (TAP) Validation Pilot Guide
ObjectivesThe VMware® Validation Pilot helps independent software vendors (ISVs) to better support their customers by providing jointly validated solutions. This packaged offering includes the infrastructure, methodology and tools required for ISVs to validate that their applications run optimally on the VMware® Infrastructure 3 platform. It is delivered by a team composed of VMware technical alliance managers and validation engineers who provide project management and VMware Infrastructure technical expertise.
As part of this program, the VMware Technical Alliances team will work with ISVs to explore one or more of the following areas:
• Basic testing and validation of applications running on VMware Infrastructure 3.
• Methodologies for application validation on VMware solutions, including how your application can take advantage of VMware solutions and features such as VMware® VMotion, VMware® High Availability (HA), VMware® Distributed Resource Scheduler (DRS), and VMware cloning.
• Performance characterization to help answer questions on application behavior on VMware Infrastructure and other VMware products.
• Development of an application deployment guide and reference architecture.
Phases of engagement and DeliverablesThe engagement is divided into four phases:
1. Requirements Gathering and Analysis
2. Application Validation Plan Review
3. Environment Setup and Test Execution
4. Documentation: Results and Recommendations
These phases are further detailed in the following sections.
Inputs Initial Discovery Call to Determine Application Fit and High Level Requirements.
Outputs ISV Application Validation Questionnaire Document, ISV Application Test Plan
Location Offsite (Phone/Webex)
Duration One Day
The focus of the Requirements Gathering phase is to collect together logical and physical architecture details, software/OS requirements, physical hardware requirements and performance characteristics of the ISV application(s) in a physical environment. Requirements gathering is typically done over the phone and requires two meetings between the VMware Technical Alliances team and ISV technical contacts. These sessions take between one and two hours each, depending on the complexity of the application and the availability of data required to complete the ISV Validation Questionnaire. VMware recommends one day for this phase if done onsite at the application vendor’s location. For multi-tiered application environments, this process can take more time.
• The VMware Technical Alliances team provides an Application Validation questionnaire to be filled out by the application vendor.
• The VMware TAM walks through the questionnaire with the ISV technical team to provide guidance on the kind of information needed.
• The ISV completes the questionnaire and provides addi-tional supporting documentation as needed (benchmark results, architecture diagrams, configuration guides etc.)
• The ISV provides existing application test plans including test cases that have been run against the application in a physical and/or virtual environment.
• The VMware Technical Alliances team reviews the questionnaire and test plan and schedules a follow up call to discuss any outstanding questions or clarifications that may be needed.
The Application Validation questionnaire and supporting documents provide the VMware Technical Alliances team with valuable information that is used to create the virtual environment and virtual hardware test configurations, depending on the characteristics of the application.
Inputs ISV Application Validation Questionnaire, Existing ISV Application Test Plans and Test Results obtained in physical or virtual environments
Outputs Ratified Application Test Plan, VMware Virtual Environment Plan and VMware Virtual Hardware Test Configurations, Statement of Work
Location Offsite (Phone/Webex)
Duration Two to Four Days
4
VMware p ilot guide
During this phase, the VMware Technical Alliances team reviews the ISV-provided application test plan and gives feedback on running the same tests in a virtual environment. Both parties reach agreement on the scope of the plan, which is documented in the statement of work generated by the VMware Technical Alliances team and signed by both parties.
The ISV provides application test plan including smoke • test scenarios and typical benchmarking test scenarios.
VMware TAM and validation engineers review the test • plan and suggest modifications if needed to suit tests in a virtual environment. For example, the VMware engineers might recommend that tests should be run against multiple concurrent instances of applications in virtual machines instead of a single instance of the application.
The VMware Technical Alliances team and the ISV agree • on the test cases to be run in the virtual environment based on existing ISV physical architecture performance test plans and desired results. Examples of test cases that might be created:
Run a 200 user test on application in a single virtual ∙machine with a single virtual CPU (vCPU).
Run a 200-user test on application in a single virtual ∙machine with a two vCPUs.
VMware validation engineers create a virtual • environment plan.
This plan translates the physical application ∙architecture to a virtual application architecture.
The VMware Technical Alliances team and the ISV agree • upon test environment and location of testing.
The VMware Technical Alliances team provides the state-• ment of work to be signed by both VMware and the ISV.
Test CategoriesFour categories of tests can be executed, based on the ISV requirement:
1. ISV application functional testing: Basic functionality tests using test cases provided by the ISV.
2. ISV application feature testing with VMotion, Ha and DrS: Reruns the basic functional test cases to test applications with VMware VMotion, HA, DRS and cloning to ensure that these features work seamlessly together.
3. Performance testing: Performance test scenarios developed by the ISV and VMware. These might include scale-up and scale-out test cases.
4. Sizing guide and reference architecture: Includes scale-up and scale-out testing to collect results leading to sizing guidance for the application running in a virtual environment. This testing is only done as an extended validation engagement between the VMware Technical Alliances team and the ISV.
ISV Team ISV Engineering Resources (Engineering Lead/Performance Lead/QA Lead)
Inputs ISV Application Test Plan and Expected Results (provided by ISV), VMware Virtual Environment Plan, Application Software, Test Harness Software and Scripts
Outputs Test execution results
Location Onsite (VMware Lab or Partner Lab)
Duration One to Two Weeks
VMware validation engineers and ISV Performance/QA engineers execute tests on the applications running in a virtual environment and document the results. VMware validation engineers monitor the tests and perform any changes to the VMware Infrastructure that may be necessary to run the tests for optimal results.
VMware validation engineers set up the physical • environment and the VMware Infrastructure to test the application.
ISV engineers install and configure the application • software in virtual machines.
VMware validation engineers and ISV engineers set up • the testing software and scripts being used to validate the application. The ISV provides the application software and testing software.
VMware and ISV engineers run the tests and record • the results. During testing, VMware engineers monitor and optimize the VMware Infrastructure configuration. In-depth tuning and performance analysis will be limited during this phase.
During this phase, the ISV engineers are expected • to contribute approximately 50 percent of the effort involved in completing the tests.
ISV Team ISV Engineering Resources (Engineering Lead/Performance Lead/QA Lead)
Inputs Results Gathered from Phase Three.
Outputs VMware Results and Recommendations Documents
Location N/A
Duration One to Two Days
5
VMware p ilot guide
Validation engineers who install and configure VMware • software and assist with running the tests.
Best practices for validating applications.•
ISV will provide:
Validation hardware (compatible with the VMware • Hardware Compatibility List).
All required application software components and • licenses.
Test software and licenses.•
Test scripts and seed data as needed.•
Resources to install and configure application software • and test harness.
Resources to assist with testing the application.•
Scope of engagement The scope of this engagement will be defined by the following terms and conditions:
This validation pilot is designed as a starter activity • that will provide ISVs with the infrastructure and resources to validate their applications running in virtual machines on VMware Infrastructure. While this pilot will satisfy most validation requirements, ISVs with multiple applications in their portfolio can work with VMware to customize this pilot.
The test execution phase of the engagement will • be limited to between five and ten business days as defined in the SOW. The tests executed will not cover the entire feature and performance tests executed by the ISV during regular QA of its applications, but will be limited to the tests required to validate applications running in a virtual environment.
ISVs are expected to provide documentation, software, • benchmarks and application expertise in a timely manner, as defined in the different phases.
The physical application architecture will be replicated • in virtual infrastructure for the tests; for example, if the application components typically run on four physical servers, four virtual machines will be created to mirror the physical environment.
Additional testing needed beyond the scope of the • Validation Starter pilot can be offered to the ISV as a paid services engagement.
The VMware Technical Alliances team produces a Results and Recommendations Document outlining the results of the testing. As a part of this pilot, the VMware team also provides:
Support statement templates.•
Recommendations for additional testing and • performance tuning as needed.
Delivery Models and resource CommitmentsThere are two delivery models for this validation pilot.
VMware Validation Lab (in Palo Alto, CA)
This model is appropriate for ISVs who do not have the hardware infrastructure, VMware expertise and/or resources for testing in-house.
In this model, the VMware Technical Alliances team will provide:
The hardware infrastructure.•
VMware software and licenses.•
Validation engineers for installation and configuration of • VMware software and hardware infrastructure and to run the required tests.
Best practices for validating applications.•
ISV will provide:
All required application software components and • licenses.
Test software and licenses if test tools available at VMware • are not suitable.
Test scripts and seed data as needed.•
Resources to install and configure application software • and test harness.
Resources to assist with testing the application.•
The VMware Validation Lab hardware infrastructure will suffice for most applications requiring dual core and quad core CPUs. If the number of virtual machines required for the tests exceeds the capacity of the VMware validation lab, the VMware Technical Alliances team can provide resources to run the tests at an alternate location such as the ISV data-center/QA Lab. Another option is for the VMware Technical Alliances team to provide third-party lab recommendations.
ISV Lab/Datacenter (onsite at ISV location)
This model is applicable for ISVs who do not have VMware expertise, but have the hardware and application expertise to perform testing in-house.
In this model the VMware Technical Alliances team will provide:
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.
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.
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:
•Hardwareresourcepoolsandfractionaluse
•Applicationmobility
•Overallserverconsolidation
4
VMware white paper
Hardware resource pools and fractional useTo maximize resource efficiency, VMware technology allows customers to pool resources from multiple physical hosts1. As illustrated in Figure 1, the resources may then be managed independently of the physical servers that contribute the resources.
Oncetheresourcepoolshavebeenestablished,virtualmachines are then created using the resources from a specific resource pool. When creating a virtual machine, the user defines the amount of memory, disk and number of GHz it wants to dedicate to the virtual machine. The “size” of the virtual machine 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.
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 pools and intelligently allocates available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. When a virtual machine experiences an increased load, VMware DRS automatically allocates additional resources by redistributing virtual machines among the physical servers within the network based on the parameters established when the virtual machine was created.
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 as the workload of that virtual machine increases, additional computing resources may be easily allocated.
At present, an estimated 40 percent of VMware® Virtual Infrastructure 3 customers are using DRS in production.
Figure 1. Pooled resources from multiple physical hosts can be more easily managed.
Figure 2. Resources are assigned to specific virtual machines in the resource pool as needed.
1 Please note, even though resources may be pooled across multiple physical hosts, each unique virtual machine will entirely reside on one specific physical
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
Business Unit
OS
AppOS
App
OS
App
Resource Pool 3CPU 12 GHz, Mem 22 GB
Priority Low
Resource Pool 2CPU 36 GHz, Mem 50 GB
Priority High
Agregate ResourcesCPU 48 GHz, Mem 80 GB
Servers, Storage, Networking
Business Demand
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
OS
App
Resource Pool
5
VMware white paper
application mobilityThe 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.
ConsolidationFinally, 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 Opinion: Considerations and advice for Licensing in Virtualized environmentsGiven 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 selectionIn 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,forinstance,licensesthemajorityofitsproductsona 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.
BoththeOracleandSymantecmodelsachievethesamegoaland 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.
ESX Server
Hardware
ESX Server
Hardware
VMotion Technology
OS OS OS OS
App App App
Figure 3. VMotion technology lets you move virtual machines from one physical server to the next without service interruption.
6
VMware white paper
To address this issue, some ISVs have developed partitioning 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. There are two general categories of partitioning technology:
Software (Soft) Partitioning: Software partitioning is technology thatallowsmultipleinstancesofanoperatingsystem(OS)toexecute within a single server. Processor resources are allocated to programs running within a partition and other server 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
C O n s I d e r T H e C H a L L e n g e s T H a T a r I s e w H e n L I C e n s I n g P e r - P r O C e s s O r I n a V I r T U a L e n V I r O n M e n T :
barriers. Each separated system acts as a physically independent, self-contained server, typically with its own processors, operating system, boot area, memory, input/output subsystem and network resources. It is impossible to read or write across a hard partition boundary, and there is no resource sharing between hard partitions. Examples of hardware partitioning technology include: HP nPar, Sun Dynamic System Domains (DSD), IBM LPAR.
The differences in partitioning technology are important because each type of partitioning makes resources available to software applications differently. While hard partitioning makes all resources within a resource pool available to a particular application, soft partitioning does not. Moreover, in an X86 environment, soft partitioning is the dominant technology used, because it allows for higher utilization rates.
To address these complexities, VMware suggests that ISVs move away from hardware based metrics where possible, and onto more value-driven metrics such as user, concurrent user, or running instance (where physical or virtual instances are treated equivalently). Alternatively, offering a specific licensing model that is tailored to virtual environments may be appropriate.
If non-hardware based metrics are not an option, at a minimum, 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 wording such as the following:
“The licensing requirements for virtual processors shall be no different than for physical processors, provided that the virtual processor is no more powerful than any physical processor on a given server. Moreover, in the event that the number of virtual processors in a given resource pool exceeds the number of underlying physical processors, the customer need only license the number of physical processors.”
7
VMware white paper
Finally, consider a hypothetical infrastructure ISV that licenses its software on a per physical server basis:
Software vendor ABC licenses its products per physical server. However, increasingly, customers are running ABC’s software within virtual environments, and they now realize that up to six virtual machines are now running on a server that once hosted one. More specifically, multiple instances of that ISV’s application are running side by side, providing the same workload benefit as the previous six physical servers. Due to server consolidation, the ISV that may once have been able to sell licenses for six servers now only sells one. Although customers would initially rally and claim success in driving down their software costs, this would be 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 simplisticlicensingmodel.BEAjustmovedtoaper-instancemodel 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 keysVMware 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)
may have challenges with this key strategy if its software is deployed in virtual environments. Given the concepts outlined in this paper, such as application mobility and resource pools, the node-locked license key may prevent the application from running as intended.
Again,theISVhasmultipleoptions.First,ifpiracyisamajorconcern, there are third-party vendors that offer license activation and registration solutions . Serial-based license keys and/or electronic license files that unlock product functionality yet do not limit deployment to specific physical hosts may be a second option. Site based licensing models and related key strategies may be applicable for some ISVs.
8
VMware white paper
Pros and Cons of existing Metrics in Traditional and Virtual environmentsAcrosstheindustry,themajorityofsoftwaretodayislicensedviaone 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
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 processorlicensingorper-instancemodels.Forexample,Oracletoday 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.
ConclusionThe 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.
These sample letters are provided for idea purposes only. Please draft a unique version of the message, and deliver to C‐level executive personally.
Customer Considerations
• ISV’s support issues for VMware are not technical Customers should feel confident knowing they are not asking the ISV to make a technical leap of faith. VMware has designed its virtual infrastructure suite so that applications that run on a supported guest operating system perform exactly as they do on a traditional unvirtualized system. (See http://www.vmware.com/pdf/GuestOS_guide.pdf.) All applications are expected to operate properly in a VMware virtual machine unless the ISV makes a specific statement indicating otherwise.
• ISV resistant to changes in licensing policies to accommodate VMware/virtualization VMware has made a number of suggestions to key ISVs, about how to modify their licensing to accommodate the advent of virtualization, without affecting derived customer revenue. The ISV Licensing in Virtualized Environments White Paper included in this kit makes recommendations to ISVs regarding licensing models that specifically address virtualization use cases.
• Customers leverage points with ISV for this communication: o ELA renewal cycle: if renewing agreements with ISV, it is clearly credible to bring this issue
of VMware support up as a point of negotiation o If applicable & credible, reference “supplier options” to move to a competitor that offers
VMware support. o If applicable, Customers can reference their “VMware first” policies, and note that from a
supplier standpoint, only those who can abide by such policies will be considered for strategic project going forward
o If applicable, Customers who have already received “one‐off” support from ISV can argue that broad support needs to be made available, so that Customer’s other business partners can take advantage of shared infrastructure, etc.
o STRESS POSITIVE BENEFITS TO ISV IF POSSIBLE Support of VMware means less $$ spent on infrastructure HW, and more capital
budget to allocate toward the purchase of ISV’s products. IF THIS COULD BE QUANTIFIED, THAT WOULD HAVE A MAJOR IMPACT FOR THE ISV
VMware support will afford more flexibility in deploying ISV’s products, and taking more ISV’s products to Customer end‐users more readily/quickly
ISV’s support of VMware will give Customer more platform choices for ISV’s products. Windows, Solaris and Linux become platform options for ISV’s products on VMware. This affords ISV more options & ways of serving the Customer
2
SAMPLE EMAIL‐/BLACKBERRY‐BASED MESSAGE
To: C‐Level ISV Executive
Fr: Office of the CIO
Subject: ISV’s support of VMware at <<Customer XYZ>>
Dear <<Executive>>,
I’d like to discuss <<ISV Name>>’s support of VMware at <<Customer XYZ>>. We value <<ISV Name>>’s role as a strategic supplier and would like to see your company support our decision to virtualize our datacenters with VMware.
We have chosen VMware as the virtualization platform for our x86 server infrastructure. Most of our key software technology suppliers appreciate this decision, as it has reduced our hardware footprint and associated software deployment costs – benefits that accrue to suppliers such as <<ISV Name>> by freeing up budget funds for key software projects.
If <<ISV Name>> openly supports VMware it will enhance my ability to execute to plan. Our relationship has been strong, and we depend on your products to help us succeed. Let’s talk about what needs to happen to make this support a reality.
Best regards,
<<Customer’s CIO Name>>
3
SAMPLE POSTAL‐BASED MESSAGE
John Q. Smith, CIO <<Customer XYZ>> 1 Corporate Place New York NY 10000 September 20, 2008 John Doe, President <<ISV Name>> 1 Technology Drive San Francisco CA 90000 Subject: <<ISV Name>> support of VMware at <<Customer XYZ>>
Dear John,
I’d like to discuss <<ISV Name>>’s support of VMware at <<Customer XYZ>>. We value <<ISV Name>>‘s role as a strategic supplier and would like to see your company support our decision to virtualize our datacenters with VMware.
We have chosen VMware as the basis of our x86 server infrastructure. Most of our key software technology suppliers appreciate this decision, as it has:
• Reduced our hardware footprint and associated software deployment costs
• Provided the flexibility to use multiple operating systems, including various flavors of Windows, Solaris and Linux
• Freed capital from reduced hardware and real estate costs to fund additional software projects ‐‐ which benefits our strategic software suppliers such as <<ISV Name.
If <<ISV Name>> openly supports VMware it will enhance my ability to execute to plan. Our relationship has been strong, and we depend on your products to help us succeed. Let’s discuss what needs to happen to make this support a reality.
