True Cost Virtual Server Solutions Taneja Mar09

7/28/2019 True Cost Virtual Server Solutions Taneja Mar09

1/12

1 of 12

T E C H N O L O G Y V A L I D A T I O N

Copyright The TANEJA Group, Inc. 2009. All Rights Reserved87 Elm Street, Suite 900 Hopkinton, MA 01748 Tel: 508-435-5040 Fax: 508-435-1530 www.tanejagroup.com

The True Cost of Virtual Server Solutions

March 2009

In March of 2009, VMware contacted Taneja Group to conduct an assessment ofhow VMware ESXi 3.5 and Microsoft Hyper-V compare when it comes to hostingmultiple virtual machines what we refer to in this Technology ValidationReport as VM Density. At VMwares request, Taneja Group executed a set oftests to evaluate hypervisor performance under different types of workloads.

Our hands-on validation has revealed that VMware ESXi 3.5 can achieve a significantly higherVM density than Microsoft Hyper-V, allowing users to consolidate more servers on a VMwareplatform. While VMwares advantage may not be surprising, given its 10-year history ofleadership in this space, the magnitude of the difference is striking: VMware ESXi 3.5demonstrated at least a 50% (1.5 to 1) density advantage over Hyper-V across a variety ofapplication workloads, and in some cases achieved a 100% (2 to 1) advantage. Thus, for a givenapplication workload, if users can safely consolidate 8 servers on Hyper-V, they willcomfortably be able to consolidate 12 to 16 servers on VMware ESXi.

Why is this important? Because it has a considerable impact on virtual infrastructureacquisition costs. A higher VM density translates to a lower number of physical servers

required to support the virtual infrastructure. A higher VM density also leads to reduced guestOS licensing costs, which tend to be dependent on the number of hypervisor instances in aninstallation. Finally, a higher VM density can also reduce the cost of management servers andlicensing, which with some solutions can be complex and expensive, especially when they arelicensed per hypervisor host. Together, these costs outweigh any individual component orhypervisor costs, and paint a picture of total cost of acquisition.

Our Findings: Based upon our testing of VM density, and contrary to competitive claimsand some prevailing end user perceptions, the total solution cost of a VMware Infrastructure 3environment is not significantly higher than that of a Microsoft virtualization environment,which consists of Hyper-V and Microsoft System Center. Given the VM density advantages of

ESXi 3.5 demonstrated in this study, we found the cost per application to be between 5% and29% less expensive in a VMware Infrastructure 3 environment than in a Microsoftenvironment consisting of Hyper-V and System Center.

In this study, well first assess the relative VM density of VMware and Microsoft hypervisors.Then we will discuss a methodology for assessing acquisition cost or cost per application. Inour view, end users should look to cost per application to streamline and simplify theirassessment of the total acquisition costs of a server virtualization environment.


2/12

2 of 12



Charge of the HypervisorsWhile server virtualization has come toembody many of the most innovativecapabilities in todays IT infrastructures, thetechnologies are still evolving. Over the pastfew years, there has been a seeminglynever-ending charge of new hypervisors into themarket. Each newcomer comes with its ownarchitectural approach and set ofperformance characteristics. Today, most of

the hypervisors on the market are availablein a fully functional free version, but freedoes not mean they are the same.

Weve long held to our position that there aremarked differences between hypervisorarchitectures. Some of these differences arebased on maturity levels and others onfundamental choices in hypervisorarchitecture. In the end, the architecturaldifferences between hypervisors can have a

major impact on total solution cost.Hypervisor architecture will determineefficiency in processing workloads, andarchitecture plays an important role indetermining whether an infrastructure isflexible and adaptable.

Yet architecture isnt the entire story. Just asthere are differences in hypervisor efficiency,there are also significant differences inmanagement infrastructure efficiency.

Taken together, total differences in efficiency including how well a hypervisor solutionmakes use of supporting hardware andlicensing will drive the overall cost of aserver virtualization solution. What manyusers do not realize until time ofimplementation is that their choice of

hypervisor may lead to sprawl in virtual hostsalong with a complex managementinfrastructure when compared to anotherchoice. A big picture view of the totalsolution hypervisor architecture andmanagement infrastructure often yields avastly different picture of cost than thatbandied about in public by emergingvendors.

The Customers Dilemma

Understanding Total Cost ofAcquisition

Server virtualization customers are facedwith a complex set of tradeoffs in evaluatingvirtual server infrastructures, along with alandslide of marketing noise that makesassessing true cost seem like a wild goosechase on a foggy day.

In recent years, virtualization vendors have

confused the marketplace by introducingfree hypervisors, surrounded by claims thatthey are cost leaders, while focusing littleattention on performance and management.Other vendors have claimed that the choiceof hypervisor is irrelevant. All of this hasmuddied the waters for IT buyers.

Marketing hype has convoluted not only thedifferences between hypervisor architectures,but between overall virtual infrastructure

management capabilities as well. As a result,users often have a difficult timeunderstanding what it takes to properly setup a functioning virtual server infrastructurein a real world data center.

Though the variation between hypervisorsand virtual server infrastructures is seldom


3/12

3 of 12



apparent in surface-level comparisons, it hasan enormous impact upon both Total Cost ofAcquisition (TCA) as well as Total Cost ofOwnership (TCO). TCO is often fuzzy andcomplex territory, but when it comes down tothe reality of todays hard dollars involved inTotal Cost of Acquisition, hidden costssimply must be understood.

To that end, we have carried out thisTechnology Validation exercise. We will first

examine the relative performance of twohypervisors VMware ESXi and MicrosoftHyper-V with a series of performance tests.Using our assessment of performance, wewill then examine how relative performancecontributes to total virtual infrastructurecosts, and conduct a comparative assessmentof TCA. But first, well discuss how theindustry is in need of a lens of simplificationwith which to view hypervisor selection, anddiscuss what we consider the best framework

for capturing total cost of acquisition virtual server infrastructure cost perapplication.

Cost Per App: Why VM DensityMatters

Administrators have long been used toevaluating new IT initiatives on a cost perapplication basis, but this practice hasseldom carried over to an evaluation between

virtual server infrastructures. Yet this samerigorous approach can easily be applied tocompare virtual infrastructures, once the

total components that make up a solution areunderstood.

With this in mind, weve distilled two coreelements that drive virtual infrastructuresolution cost. These are:1. Hypervisor efficiency, which

determines how many hypervisors will beneeded to support a given number of VMsrunning a particular applicationworkload.

2. Virtual InfrastructureManagement Efficiency, whichdetermines how much managementsoftware is needed to manage thehypervisor environment.

These two elements drive total solution costbecause they determine what anenvironment will require in the form of:1. Licensing. Hypervisor and management

infrastructure efficiency determine how

much licensing will be required tosupport hypervisors, operating systems,and management components.

2. Physical Infrastructure. Hypervisorefficiency determines how much physicalinfrastructure will be required to run thevirtual infrastructure, and in turn thisalso determines how much starting upthat virtual infrastructure will cost, in theform of power, cooling, and floor space.

The biggest influencing factor behind totalsolution cost is hypervisor efficiency, or whatwe call VM density in this TechnologyValidation report. VM density will determinethe total physical equipment, managementinfrastructure, and software licensingrequired for a virtual server infrastructure.

VM density: The number of guest VMsthat can be effectively consolidated on a

hypervisor without disruptive performanceimpact.


4/12

4 of 12



The reason VM density matters is simple. Inan infrastructure with as few as 30workloads, a hypervisor that can host even50% more workloads may have aconsiderable cost advantage. A 50%advantage in efficiency may allow a customerto reduce their number of hypervisorinstances by one-third or more. Sincemanagement infrastructures are oftenlicensed according to number of hypervisorinstances, and operating systems are licensed

per hypervisor instance, the number ofhypervisor instances will have a dramaticinfluence on the total solution cost.

Testing Density: Not AllHypervisors or VirtualInfrastructures are the Same

With this background in mind, we tested twoleading hypervisors to assess their efficiencyin hosting virtual machines. While

architectural differences between VMwareESXi and Microsoft Hyper-V hypervisors arenow generally well understood, the impact ofthese differences on achievable VM density isnot. Our goal is to determine the VM densitysupported by these two hypervisors based ona set of typical application workloads.

Once we have determined the differences inVM density at the hypervisor level, we willthen use these results to evaluate cost per

application differences between VMwareVirtual Infrastructure 3 and MicrosoftHyper-V plus System Center.

Our Methodology

To evaluate VM density between Hyper-Vand ESXi, we turned to two tests,

DBHammer and SPECjbb. The first test DBHammer simulated SQL Serverworkloads within multiple VMs in order toshed light on how total hypervisordifferences may show up when virtualizingcommon enterprise workloads. The secondtest SPECjbb used an atypical, extremelyaggressive workload to level the playing fieldaround memory management differences.By doing so, SPECjbb allowed us to peer intovCPU and driver efficiency to assess how

effectively Hyper-V and ESXi can deal withworst-case workloads.

We selected these two tests to validate howHyper-V and ESXi performed under a varietyof conditions. We intended to make sure nosingle set of optimizations or proprietarytechnology gave either hypervisor an unfairadvantage with a particular workload. Wellturn next to a discussion of the individualresults from these tests, and then with this

data in hand, we will discuss how VM densitydiffers between Hyper-V and ESXi.

Our Observations

Arriving at these tests, and rolling up andcomparing results between the selectedhypervisors was in fact no easy task.

The two hypervisors under consideration,Microsofts Hyper-V and VMwares ESXi, are

remarkably different in capabilities andfeatures. Since Hyper-V is a relatively younghypervisor, we routinely ran into Hyper-Varchitectural limitations (e.g. limited SMPvCPU support on older Windows OSs andLinux, and no memory oversubscription).Consequently, each of our tests was designed


5/12

5 of 12



specifically with the optimal configurationand performance of Hyper-V in mind.

Moreover, even when ESXi was faced withartificially limited test configurations, it stilldelivered markedly different levels ofperformance and scalability that madedistilling results a challenge. How do youfairly compare results when Hyper-V islimited to less than half the number of VMsthat ESXi can host due to the way it assigns

memory? Based on a broad collection ofdata, here are the salient points relevant toour VM density testing.

DBHammer Testing: Under typicalworkloads, ESXi can run twice as manyVMs as Hyper-V.

As illustrated in Figure 1 on page 6, undertypical workloads, VMware ESXi scaled wellpast twice the number of virtual machinesthat Hyper-V can host using the sameamount of physical memory.

As we tested Hyper-V we encountered a hard

limit to the number of VMs we could start up.Our test system was configured with 16physical gigabytes of memory, and once

A note on Server Core

Microsoft advertises Server Core and Hyper-V Server as the ideal platforms for Hyper-V, and bothhave smaller memory footprints than Windows Server 2008, which is the product we used in ourtesting. For the purposes of this exercise both Server Core and Hyper-V Server suffered from anumber of limitations that led us to stick with Windows Server 2008. Server Cores lack ofconfiguration tools was a major obstacle to carrying out testing, but it shouldnt be overlooked thatHyper-V Server also has several built-in restrictions that led us to conclude it is an unequal

competitor. Specifically, Hyper-V Server is more limited in memory and number of processors, andlacks common features such as Microsoft Cluster Services. Even so, we wanted to fairly consider anypotential advantages that Hyper-V Server may have had. Consequently, we assessed the impact of theHyper-V Server / Server Core memory footprint separately and we saw a difference of about 500MB.

Server Core with Hyper-V (left) and Windows Server 2008 with Hyper-V (right)

When we ran into Hyper-Vs VM limits (discussed in the sidebar: The Usefulness of MemoryOversubscription), we had 1.3GB of free memory available. Nonetheless, this was not enough to startanother 1GB VM. But since an extra 500MB may have created enough headroom to host one morevirtual server, weve given Hyper-V unvalidated credit for being able to host 12 VMs instead of 11.Moreover, weve assumed that all 12 guests would deliver the same performance, since we did not seesignificant performance drop-offs in ESXi at this number of guests. Your mileage may vary.


6/12

6 of 12



16GB was used by the host OS or assignedtoa running VM no more VMs could be started.In our test case, this limited Hyper-V torunning 11 1GB-memory VMs at once. Butassigning memory to a VM does not mean itis being fully utilized. This in turn limitedVMs and created underutilization ofmemory, CPU, and IO. (See sidebar: TheUsefulness of Memory Oversubscription)

This hard limit was a surprise to us, as weve

long become accustomed to assigning morememory to VMs than is physically availableto the hypervisor. As an example, usingVMware ESXi we easily assigned over 24GBof virtual server memory (24 servers with 1GB allocations each) using only 16 physicalgigabytes of memory. Real utilization of

memory barely approached 16GB, and wecould have started more VMs until at somepoint we decided we were witnessingsignificant performance impact.

But the story doesnt end there. While Hyper-V was limited by a hard cut-off in the numberof VMs it can host, ESXi also demonstratedhow it leverages VMwares advanced memorymanagement technologies to further out-scale Hyper-V. When we virtualized

workloads, we wanted to assess the ability ofa hypervisor to host guests withoutperformance impact. What we found was thatESXi easily scaled to twice as many guests asHyper-V with no performance impact. Butfurther analysis beyond 2 times as manyguests (22) led to an intriguing conclusion:

Figure 1 : How VMs running DBHammer scaled in performance on Hyper-V and ESXi

0

2250

4500

6750

9000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

ESXi continuesscaling linearly

ESXi begins regular useof Memory Ballooning -observable performance

impact, but continuesscaling.

Taneja GroupWin2k8 Hyper-V test

server hosted 11VMs, but ServerCore may havescaled up to 12.

TotalDBBatchRequestspersecon

d

Number of VMs

Hyper-V ESXi


7/12

7 of 12



Key features in ESXi may enable muchgreater than 2:1 scalability with only aninconsequential drop-off in per-guestperformance.

As we scaled performance past 2 times asmany virtual guests, or 22 VMs, ESXiregularly employed a feature called memoryballooning. Memory ballooning works tokeep only active VM memory pages inmemory, and returns inactive pages to a free

pool that can be shared among other VMs.This feature helps increase VM density, andmakes a VMware infrastructure better able tovirtualize rapidly changing workloads. Ourtest results demonstrate that even with staticperformance loads, memory ballooning canpolice, clear out, and share enough memoryspace to make a substantial difference in theVM density of a hypervisor.

Once heavily used, memory ballooning

processes are not without overhead, andevidently created an 11% performance impacton per VM performance. But moresignificantly, the 11% performance impacthappened as soon as memory ballooningstarted, and did not change significantly withthe addition of more VMs. Memoryballooning allowed us to easily increase ourtotal VMs up to 24. Moreover, we did notstop at 24 VMs due to any detectable serverworkload impact. At 24 VMs we noticed

slightly increased vCenter GUI latency, butwe ran out of provisioned servers as well asthe time and patience to provision more. Wesuspect we could have added several moreVMs to this host without additionalperformance impact. But eventually moresignificant performance degradation will setin when memory oversubscription drives the

hypervisor memory system to turn to diskswapping to meet demands.Since our environment consisted ofunusually consistent workloads, we see theperformance impact associated with memoryballooning as inconsequential. Dense virtualinfrastructures have widely varyingworkloads that will only occasionally peak atthe same time, so reducing total systemperformance in favor of hosting moreworkloads that arent saturating system

resources is a reasonable tradeoff.

Our conclusion: Based on these typicalworkloads, in some situations ESXi canvirtualize twice as many VMs as Hyper-V.

SPECjbb Testing:ESXi delivers 24% moreperformance from the same hardware.

Figure 2 : Difference in the aggregate of SPECjbbperformance score running in 7 VMs on a single

host

When we turned to SPECjbb testing, weconfirmed that VMware does indeed delivermore performance through a more efficienthypervisor architecture. Using 7 VMsconfigured with 2 vCPUs and 2GB of memoryeach on an AMD Opteron 2384 8 core

0

50,000

100,000

150,000

200,000

250,000

300,000

7 VMs

253,499

204,523

Hyper-V ESX i

24% MorePerformance

AggregateofSPECjbbScoref

orVMs


8/12

8 of 12



system, our test results demonstrate thatESXi was 24% more efficient than MicrosoftHyper-V. But 24% is once again only part ofthe story. Looking back, the data gatheredfrom the SPECjbb testing demonstratesinteresting patterns.

As illustrated in Figure 3, optimalperformance was achieved at 4 VMs witheither hypervisor. With 4 VMs runningSPECjbb Hyper-V closes the performance

gap to only 20%. Our conclusion is that 42vCPU processors running on an 8-coresystem was the easiest workload to distributeand balance across all processors.

When looking at workloads that are harder tobalance across all processors, VMware ESXiwidens the performance gap. Moreover, thisdoesnt only occur with high numbers ofVMs. With only 1 VM ESXi turned inperformance that was 28% better.

Figure 3 : Difference in aggregate of SPECjbbrunning in VMs, at different number of

simultaneously running VMs

What this means to us, is that less optimallyload balanced infrastructures are moreinefficient on Hyper-V. We guess that if

0

50,000

100,000

150,000

200,000

250,000

300,000

1 VM 2 VMs3 VMs4 VMs5 VMs 6 VMs 7 VMs

Hyper-V ESXi

Hyper-V narrowsgap to 20% at 4

VMs

AggregateofSPECjbbScoreforVMs

The Usefulness of MemoryOversubscription

Many users take memory oversubscription for

granted while using it extensively. Based on ourdiscussions with end users, as many as 70% ofVMware customers make use of memoryoversubscription. Seasoned users of VMwarehave come to expect that they wont be restrictedby physical memory when starting VMs. Manyusers plan around their ability to temporarilyimpact performance by moving active machines

when they have already assigned 100% or moreof a hypervisors available memory - this is infact the premise of many virtual serveravailability and disaster recovery plans today.

At the time we encountered the error below, weseemed to have sufficient memory available tolaunch another VM. Task manager identified1.3GB free memory and our guest required 1GB.

Since memory is one of the most pressuredsubsystems in a virtual host, elegantly managingmemory use is an important aspect ofmaximizing system performance. Memory maybe occupied but not productively used, withlarge amounts of performance remaining on the

system. As a testament to this, we saw overallvirtual host performance increase on ESXi byanother 92% when additional machines werefired up beyond the 11 limit imposed byMicrosofts hard physical memory restriction.By this assessment, Hyper-V was utilizing only52% of total available system performance.


9/12

9 of 12



Hyper-V did not run into hard memory limitsand could run more VMs, we would see awidening gap in performance that would bemuch more than 24% in ESXs favor.

In real world virtual infrastructuresexperiencing constant peaks and troughs indemands, this difference betweenhypervisors will have significant impact.Hyper-V inefficiency means thatadministrators must more carefully allocate

resources and not place too many demandson Hyper-V. In turn, this limits VM densitywith Hyper-V.

Our conclusion: ESXis performance givesit a distinct edge in hosting more VMs withdynamic workloads.

Whats the real VM densityfactor?

We tested ESXi and Hyper-V tocomprehensively evaluate their architecturesand determine how many VMs each couldeffectively host with the same hardware. Oneof these tests yielded a VM density that was2:1 in ESXis favor. The other testemphasized a more performant hypervisorarchitecture and driver stack when memorymanagement technologies were factored outof the picture. While no infrastructurecontinuously runs at 100% utilization, the

point of this test was that VMwaresarchitecture makes more efficient use ofhardware resources, and performs betterunder duress.

Based on our observations during testing aswell as our familiarity with a broad range ofvirtual server infrastructures, we know there

are many realistic workloads under whichESXi will demonstrate a 2:1 VM densityadvantage when compared to Hyper-V. Evenso, we also realize that exceptionalworkloads, similar to our SPECjbb testing,will occur in the real world. Consequently,weve tempered our expectations for 2:1 VMdensity with the 1.25:1 processing advantageseen under the aggressive SPECjbb testing,and have selected a comfortable mid-point.Our conclusion is that a 1.5 VM density

advantage or 1.5 times as many VMs asHyper-V is simply a balanced point atwhich ESXi can easily consolidate serversunder a wide range of workloads.

Our Findings:VMware ESXi has at least a 1.5:1 VM

density advantage over Hyper-V.

The Next Step: Total Solution Cost awalkthrough of assessing Cost Per App

With our assessment of VM density in mind,we return to the goal of understanding howhypervisor density affects total virtualizationsolution cost, including physical equipment,licensing, and first yearpower/cooling/floorspace costs. Weexamined the Microsoft Hyper-V plus SystemCenter and VMware Infrastructure 3solutions with the help of a VMwarecalculator that fully captures a variable andcomplex Microsoft managementinfrastructure. This tool is applicable toenvironments of up to 1000 VMs, and is alsoavailable on the VMware website. Lets lookat what the total costs are for each solution.


10/12

10 of 12



With some time in the market, and aspecialized focus on virtual infrastructuremanagement, VMware supports ESXi with 3versions of their VMware Infrastructure 3platform. Those solutions today includeFoundation, Standard, and Enterpriseeditions, and each are licensed by thenumber of ESX or ESXi hypervisor CPUs (ona 2CPU basis). While these solutions vary incapabilities and cost, they have in commonan architecture that requires only two

management servers a vCenter Server anda VMware Update Manager database server.

Microsofts management infrastructure ismore complex in comparison. MicrosoftSystem Center requires several elements to

obtain similar functionality. Those elementsinclude System Center Operations Manager,System Center Configuration Manager, andSystem Center Virtual Machine Manager.While relatively recent MS licensing changeshave simplified client licenses virtual hostscan now get client licenses for all of thesemanagement components with a singleServer Management Suite Enterprise license the management servers themselves, andassociated database servers, each need their

own client licenses for the variousmanagement tools. In addition, the numberof management servers and database serverswill change with the size of the hypervisorenvironment.

Figure 4 : Breakdown of Microsoft Hyper-V plus System Center and VMware Infrastructure 3 solutioncosts for a 50 VM environment, using 18 VMs per server for VI3, and 12 VMs per server for Microsoft.


11/12

11 of 12



Using cost-optimized, best practicemanagement infrastructures for each of therespective vendors, and our validated VMdensity that in turn determined the numberof hosts, amount of hardware, and the size ofthe management infrastructure, we assessedthe costs of a variety of different sizedenvironments.

Based on our assessment, Microsoft Hyper-Vplus System Center only has a cheaper cost

per application when a single hypervisor isrequired. Once more than a single hypervisoris needed, the difference in hypervisordensity and licensing immediately moves thebalance to VMware Infrastructure 3s favor,by as much as 5% to 29% in our calculations.A variety of factors influence the outcome ofthese calculations, the most significant ofwhich are: Whether management servers are

virtualized or physical

The total size of the environment (thisdrives up the number of components in aMicrosoft infrastructure)

The cost of data center space and powerand cooling, which we factored in for thefirst year

In Figure 4 on page 10, the advantage ofvirtualizing management servers reduces thecost of Microsofts managementinfrastructure licensing, but even so, the

virtual server sprawl created by an inefficienthypervisor drives the cost of just the OSlicensing to almost 167% that of the VMwareInfrastructure 3 environment.

While our experimental calculations includedthe first year cost of data center space andpower and cooling, even with these figures

factored out, VMware Infrastructure 3 stillcame out cheaper in every configurationrequiring more than one virtual host. In theabove example, without power, cooling, anddatacenter costs, VMware Infrastructure 3would still retain a cost advantage of $582per application, making it 17% cheaper thanHyper-V plus System Center.

Taneja Group Opinion

As we have found in this TechnologyValidation exercise, the rush of hypervisorsinto the marketplace, and the predominanceof free hypervisors does not mean thehypervisor is becoming commoditized.Reality is in fact far from this as weveobserved, there are distinct differencesbetween hypervisors. Clearly VMwares timein the market has led to a level of hypervisormaturity that pays off in performance andefficiency with hardware.

Moreover, while in this case testingdemonstrated that VM density andperformance limitations are related to thearchitecture and design of Hyper-V, webelieve that similar limitations are likely tosurface in other hypervisors that use a parentpartition-like approach to virtualization.

Meanwhile, observers should realize that VMdensity is based not just on the hypervisor,

but also on the total capabilities of thesurrounding virtual infrastructure. While wedid not test other virtual infrastructurecapabilities nor factor them into our VMdensity evaluation, as one example, VMwareInfrastructure 3 includes DistributedResource Scheduler (DRS). Across a pool ofhypervisors, DRS ensures that each virtual


12/12

12 of 12



server is allocated sufficient resources on anongoing basis to meet its performance needs.By constantly juggling resources among VMsbased on utilization and user defined rulesand policies, DRS allows users to safely runmore VMs per server without compromisingthe performance of critical applications, evenat high utilization levels. DRS thus enablesusers to safely increase VM density inVMware Infrastructure 3 environments.Microsoft virtual infrastructures currently do

not have an equivalent capability, preventingthem from offering this benefit. Due to thelimited scope of our testing efforts, we didnot model the impact of VMwareInfrastructure capabilities such as DRS, butthey should be considered as importantfactors in further increasing VM density.

VM density ultimately determines totalsolution cost, and today has VMwareInfrastructure 3 in the lead. As weve

reviewed in this Technology Validation,

hypervisor efficiency can yield total costdifferences of up to 29% in VMwareInfrastructure 3s favor. Even in smallimplementations, this is a difference of manythousands of dollars.

In an economic environment that isrepeatedly heralding the message do morewith less the efficiency of hypervisors are anoft-overlooked aspect of virtualinfrastructure acquisition that has massive

impact on total price. We recommend everyorganization undertaking a servervirtualization initiative sharpen their pencilsand review our VM density findings in thisreport. Then use our findings, along with theassociated cost per application assessmentapproach weve reviewed in this report toidentify the true cost of the virtualizationsolutions you are considering. Viewing themultitude of virtualization solutions on themarket through this lens will help you figure

out how to do more with less.

.

. NOTICE: The information and product recommendations made by the TANEJA GROUP are based upon public information and sourcesand may also include personal opinions both of the TANEJA GROUP and others, all of which we believe to be accurate and reliable.However, as market conditions change and not within our control, the information and recommendations are made without warranty ofany kind. All product names used and mentioned herein are the trademarks of their respective owners. The TANEJA GROUP, Inc. assumesno responsibility or liability for any damages whatsoever (including incidental, consequential or otherwise), caused by your use of, orreliance upon, the information and recommendations presented herein, nor for any inadvertent errors which may appear in this document.

True Cost Virtual Server Solutions Taneja Mar09

Documents

Transcript of True Cost Virtual Server Solutions Taneja Mar09