Single Processor licenses and the VMware Virtualization Environment

[IT_Architect]

Consider the follwing:

• A 4 core processor is seen as a single processor for licensing purposes with Microsoft software.

• VMware virtualizes each core as a logical processor.

• Does Microsoft see these cores as coming from the same processor?
  
  

[IT_Architect]

*Craig said: "Unlike what you believe to be true, the FACT is (confirmed by testing)

that MSInfo does not "KNOW" nor "look up in a database" the true

core/logical processor configuration using the model number otherwise

it would be presenting the CPUs as dual/quad core regardless of whether

the OS was running on the physical server or in a VM on that server,

which is clearly does not (as previously noted in this thread)."*

LOL, Craig, re-read the thread. That's not what I believe nor ever inferred, in fact quite the opposite. We're having a violent agreement here. The thread is all about "Does VMware have a "rabbit in their hat" that enables them to run off-the-shelf software licensed by socket, the defacto standard today, without incurring a performance limitation in a multi-core environment?" I said that VMware has all the same information available to it that any OS has running on bare metal. That is undisputable. OSes on bare metal and their apps know how many sockets there are and are quite competent in limiting by socket to enforce compliance. You, I, and everyone else, agreed that we didn't see any evidence that this socket information is available to the virtual machines at present. Since this is of such huge importance to anyone anticipating running VMware in a busy environment, I didn't want the basis of such a decision to be based on speculation or testing using invalid methodology. It was very logical to me that this topic would have surfaced at VMware development since their mission is to run currently licensed operating system environments and their apps. VMware could have just as easily come back with, "For those environments we have an undocumented switch that we have had since version x.x that allows you to put ??? in the .vmx...", or something like "In version 4 we will have ??? and we would like to have someone like you in our beta who has a real-world environnment that could really whale on it..." and I end up in their version 4 beta program. I've had this happen several times in the past. As we all know, crossing my fingers didn't help. They were forthright about the limitation, which to the best of knowledge, is common to current virtualization environments. Their answer authoritatively defined the boundaries of their current technology, and I'm assured that I'm not making my decisions based on a false supposition. I will still be using VMware, and adjusting my strategy accordingly.

[Craig_Baltzer]

LOL! You need to look at the "In Response To" part of the post IT_Architect, it wasn't in reference to one of your posts (and yes we're in violent agreement ) but rather another poster that was stating that the OS did a "database lookup" based on the ID to find out the cores, etc. and since the ID was "available" inside the VM the VM OS would know the core/logical processor configuration, which clearly it is not.

[Craig_Baltzer]

Certainly there are some interesting cases where virtualization (multiple OS + application instances running on a single box vs a single instance running on raw hardware) may actually give some performance advantages. A very good example recently was testing that was done on a large IBM server with Exchange 2007 where they were able to support more users on a single box by running 4 OS + Exchange VMs than by running OS + Exchange on similar hardware.

[meistermn]

Yes you got it.

Same is for SAP and Websphere on ESX. Through the next cpu generation this will be get further.

How many Vm's are you run? We run over 1200 Windows 2003 in production.

Can you explain physical ID ?

<span class="jive-thread-reply-body-container">AffinityMask = 1; Initial APIC = 0; Physical ID = 0, Core ID = 0, SMT ID = 0
<span class="jive-thread-reply-body-container">AffinityMask = 2; Initial APIC = 2; Physical ID = 2, Core ID = 0, SMT ID = 0

[meistermn]

Better look at the Design model than the small part of licencing.

[Craig_Baltzer]

<snip>

They were forthright about the limitation, which to the best of knowledge, is common to current virtualization environments

This seems to be common across VMware's current virtualization environments (I just took a quick peek at VMware Workstation 6.5) but is not the case under W2K8 + Hyper-V. This is a 2 vCPU W2K8 VM being run under Hyper-V (I'm only posting the info from inside the VM as the "physical" info has been posted before). The red highlights are the interesting differences from the same VM configuration running under ESX...

Capabilities:
Hyper-Threading Technology: not capable
Multi-core: Yes
Multi-processor: No
Hardware capability and its availability to applications:
System wide availability: 1 physical processors, 2 cores,2 logical processors
Multi-core capabililty : Maximum 4 cores per package
HT capability: Maximum 1 logical processors per core
Not all cores in the system are enabled for this application.
Relationships between OS affinity mask, Initial APIC ID, and 3-level sub-IDs:
AffinityMask = 1; Initial APIC = 0; Physical ID = 0, Core ID = 0, SMT ID = 0
AffinityMask = 2; Initial APIC = 1; Physical ID = 0, Core ID = 1, SMT ID = 0

[IT_Architect]

Hi Craig: If I interpret the results of your test correctly,

1. In the Hyper-V environment, operating systems and applications can run to the full potential of their license, which can be huge, especially if you don't have a VLA. Hyper-V actually has some merit in this case.

2. VMware has overcommit of resources and can float them between VMs based on need, while Hyper-V cannot. That is also huge.

3. VMware will likely be able to virtualize more work for the given amount of hardware resources.

4. The Hyper-V cost of admission is the cost of the OS. It's only free if you needed the OS anyway. The ESXi cost of admission is always zero.

5 VMware supports many operating system flavors while Hyper-V supports a very limited number outside of Windows. Netware and Suse are the only ones I see. I don't know how well or which others it can reliably do.

6. VMware has Live Migration and Hyper-V has only Quick Migration. At this level you pay money for either unless you needed the MS OS anyway.

*I've seen plenty of fruitless attempts to introduce cost comparisons of the two environments. I don't want to go there. By adjusting the requirements, one can make a case for either.

[meistermn]

I disagree to same points:

1.) This will be solved by the industry, because virtualization is a big architecture change.

The man competitor for vmware is not Hyper-V it is citrix xen 5 (has already live migration, 8 VCPU per VM support, FT through Marathon).

In linux only enviroments Virtual Iron , Suse, Red Hat are the competitiors. Not Hyper-V.

In big SUN environments it is hard to convince to pay for an other hypervisor. Only if you can reduce people it will work or in some later years consolidate several hypervisors on one platform (Long picture Mainframe verus Sparc versus Intel/Itanuim platform). SUN has Virtualizaion for Sparc and X86 architecture.

Main points are:

1.) Messure the Application in the VM (Customer must be satisfied)

Messure CPU, Mem, Disk IO , Net IO, Graphic ,Latency

Make Application Design changes in projects : IIS Farms , SQL Farms , IBM Cognos , IBM Rational Farms, any so on

2.) Cost of Vmware can be ignored. SAN , Network is much expensiver.

3.) Look at the Architecture of SAN, X86-Server, Network Switches

4.) Virtualization a Datencenter has to be made in steps. Best approach is to use cpu , san and network roadmaps. When is why to buy a physical component!

[Craig_Baltzer]

Hi. I don't want to turn this thread into a "VMware vs Hyper-V vs Xen" thread as its highlighted some useful things about ESX and has been very useful. Doing "feature x vs feature y" comparisions of the technologiies just turns into a "Betty Crocker bakeoff" and boils down to whether you like your brownies with frosting and chocolate chips or just plain, hot out of the oven or cooled in the fridge. Lots is changing soon, VI4 will be coming out with neat new stuff I'm sure, as is W2K8 R2 Hyper-V with real "vMotion-style" live migration in addition the "pause-move-resume" thing it has now.

1. I'm not sure how significant the licensing issue will be in practice. The smaller shops are typically the ones without an Enterprise or VL agreement. How many of those "need multiple vCPUs in the SQL VM" and "have enough clients (or few enough SQL Servers) that user/device CALs don't make sense". Even for those that do how many will just go ahead and enter "2 CPUs" in the SQL Server licening manager dialog box if they are running SQL in a 2 vCPU VM on a multi-core box and figure they are "following the spirit" of the MS license agrement? For Enterprise agremeent customers I suspect it will be a non-issue and I can't see MS getting sticky about it and taking the bad press it would bring on.

2. Overcommit of resources is interesting, but frankly the only place I ever see it having much effect is in lab and dev environments which usually lack any kind of formal capacity planning. I've not seen any decent tools for assessment and capacity planning that factor in what resource overcommitment I can expect to get for a given workload

3. Likely ESX will be able to virtualize more work for the given amount of hardware, but the difference would have to be dramatic to make a significant difference in costs (server hardware is cheap, SAN is what tends to be expensive)

4. There is no "cost of adminission" to Hyper-V. MS released a free veersion back in October that included W2K8 core to position against ESXi (do a search for "ServerHyper_MUIx2-080912.iso" if you want to see it as I don't want to put links to competitors products in a forum that VMware provides to us)

5. The wider guest support may be important in some shops (Netware support is very useful for some of the work I do). MS will continue to focus on Windows and SUSE is their "Linux of choice" by virtue of their mutual support agreements with Novell.

6. This is one of those "point in time" things; W2K8 R2 Hyper-V is purported to have "vMotion-like" migration

Agreed on the cost equation, and the "free" versions are just marketing noise from my perspective when it comes to production implementations. No one is going to do anything serious with ESXi without having Virtual Center, or with Hyper-V without System Center Virtual Machine Manager, and at that point they aren't "free" anymore. Ditto for fault tolerance, disaster recovery, etc., etc., etc.

[mreferre]

IT_Architect,

I think that at the end of the day you want to get an answer from the entity that is going to fine you if you did things wrong. If I was VMWare and you asked me how much ($$$) I should give MS in a given situation I would probably say "x" (where "x" is between 0 and the least expensive alternative). If MS comes by and decide to fine you because you are not compliant and you should have paid "y" (where "y" is way more than "x") .... what do you do? Why not trying to understand (from MS) what "y" is upfront? It's in their interest to tell you exactly what they want for not fine you .... a model where your competitor can decide how to license your software doesn't work....

Massimo.

[IT_Architect]

I think that at the end of the day you want to get an answer from the entity that is going to fine you if you did things wrong.

You did not comprehend this thread. The presumption, and ultimately the outcome was, under VMware the app would be under-licensed when using the common physical processor licensing model with multi-core processors. It would be illogical to ask Microsoft about how VMware represents hardware to virtual machines. We already know how processor licensing works. For your edification, the way things shook out is, under VMware currently, applications interpret cores as physical processors, meaning that the software license would be under-utilized in this environment. MS and no other vendor can fine somebody for that.

[mreferre]

I guess we will continue to disagree...

I don't personally think it matters, from a licensing perspective, "how VMware represents hardware to virtual machines"..... but rather .

In early 2000 there have been numerous discussions regarding whether or not a single Windows license would cover all VMs on a single physical server for example. One could have argued (and someone argued) that since VMware represents a fraction of the processor to each VM it would have been fair to use one single Windows license to license a single (althought "fractioned") physical system.

As I said VMware could always build a legal practice to argue how they "represents" things so that the least amount of money flows towards Redmond (so that they free more budget to flow towards Palo Alto)... but the last word on that is going to be on the ISV that gets the money...

Just my 2 cents.

Massimo.

[IT_Architect]

so that the least amount of money flows towards Redmond

You are still missing it. Redmond gets 6 times as much money in a VM environment.(Soon to be 8 times) Assume a 2 PHYSICAL CPU license, a common way to license software.

1. Physical Box: An application/OS licensed for two physical CPUs will only use two PHYSICAL processors no matter how many PHYSICAL processors the motherboard has. The application will not use more PHYSICAL processors than the license allows. The program or OS won't let you. It's impossible to violate the license. Each PHYSICAL processor however may have 6 cores. It is legal, expected, capable, and will use all 12 cores as long as they are only coming from 2 PHYSICAL CPUs.

2. VMware Virtual Machine: Because of the current method VMware uses in VMs to fool the application/OS into thinking it is running on a real computer, the same application or OS running in a VM sees each CORE as a PHYSICAL processor. Thus, the OS and/or application WILL NOT use more than 2 CORES. It's impossible to violate the license. The program and/or OS won't let you. However, since in a VM you can now only use 2 cores, instead of 12, as in the case of a physical box, you will only have available 1/6th of the capability of the license. Therefore, you would need to send Redmond 6 TIMES as much money to get the same capability because to get the same capabilities of a Physical box, you would need to buy 6 licenses instead of 1.(And actually more due to the performance penalty of virtualization itself.)

If in a VM the application or OS could see the threads were coming from the same physical CPU, you would be able to run more cores, and would not be violating the license (You can't anyway) because you would only be getting what you paid for from the software. Currently, you are getting 1/6th what you paid for. Microsoft, Oracle, etc. wrote their software and licences for physical computers. VMware uses sleight of hand to make it think it's running in its native environment. Because people get less performance from Microsoft's, Oracle's, etc. software by electing to run it in a VMware VM, doesn't provide the basis for any rational conversation with Microsoft, Oracle, etc. about the problem.

[mreferre]

I have to apologize. I was in a rush and I only surfaced this thread very quickly. I went through it again and ..... yes you have a good point.

Sorry for the misinterpretation.

Massimo.

[IT_Architect]

yes you have a good point.

You got it. Cool!

[Dave_Mishchenko]

What sort of deployment of VMs do you plan (i.e. how many VMs per core). I'd agree with you in that if I purchase a standard windows license, I can take advantage of up 4 CPU sockets (with W2K8) but as a VM I would be limited to just 4 vCPU (or the equivalent today of 1 CPU with 4 cores). However, if you plan on say 4 VMs (single vCPU) per CPU core then you'll have 16 Windows VMs per CPU socket. That'll be either 16 standard licenses or a single datacenter CPU license and MS's virtualization rights will have saved you a bit.

But again, this isn't VMware setting the licensing rights - if you'd like to see it change you'll have to convince MS as they set the rules for their software on whatever virtualization platform you use.

[IT_Architect]

But again, this isn't VMware setting the licensing rights - if you'd like to see it change you'll have to convince MS as they set the rules for their software on whatever virtualization platform you use.

Licensing by physical CPU has been the market defacto standard. It's not logical to single out Microsoft. It is not rational to expect VMware customers set up meetings with Microsoft, Oracle, and every other software vendor that uses this method to convince them to change their licensing to fit VMware. Their software works fine as licensed on a physical machine. What is rational is for the market to challenge the VMware value proposition which only holds up if the comparison is performed using single core processors, which hasn't been commonplace for awhile. If anyone should be making the sales pitch to all the various software vendors, it is VMware. However, that's like the tail wagging the dog. A better approach would be for VMware to make their VMs present their environment like a physical machine does so that the software or OS can use all the cores. Then it wouldn't matter how they license and limit their software. That is the change I'd like to see and will also serve in VMware's best interest since it would defend their value proposition. The ball is clearly in VMware's court. They are the ones promoting their virtual environment over the physical environment and other virtual environments. I'm just part of their potential market asking obvious questions about the value proposition during the evaluation process. I didn't know it would unwind like this. I was hoping there was a more positive explanation to what I was seeing.

[Dave_Mishchenko]

Licensing by physical CPU has been the market defacto standard.

Things change - if they didn't we'd be talking about VMware mainframe server :).

It's not logical to single out Microsoft.

It's not my intent to single them out, nor do I have any particular gripe about their licensing rights. Using them in an example it beneficial because we can analyze the costs. With Windows DC proc licenses you're talking about $5K for 2 CPU slot host which will cost you how much when you included storage, IT costs, etc? But we can switch the names around to not put MS in a bad light which was not my goal. Feel free to substitute Citrix Xenserver or whatever x86 virt platform you want (I would guess besides Parallels)

Let's say "What is rational is for the market to challenge the Microsoft Hyper-V value proposition which only holds up if the comparison is performed using single core processors, which hasn't been commonplace for awhile. If anyone should be making the sales pitch to all the various software vendors, it is Microsoft Hyper-V. However, that's like the tail wagging the dog. A better approach would be for Microsoft Hyper-V to make their VMs present their environment like a physical machine does so that the software or OS can use all the cores. Then it wouldn't matter how they license and limit their software.

VMware hasn't deliberately created the vCPU architecture to create licensing issues and the 1 vCPU per physical core is what you'll find in all the x86 virtualization products (I'm sure someone will mention the exception if one exists). Perhaps down the road the architecture will change and well see the vCPU become a vSocket, but for today pick your virtualization vendor and they're all doing a vCPU and the rules are thus set by the OS / application venders to match what is available.

It is not rational to expect VMware customers set up meetings with Microsoft, Oracle, and every other software vendor

Actually, this is a great way to change things. When customers complain, vendors have to listen or the take a chance at losing revenue. A lot of people raised a big stink about licensing OSes in VMs and we've seen changes (Windows Ent / DC rights for example). And it's not that we have to speak to every vendor. Once one vendor changes (say Oracle DB licensing) then the rest have to follow to remain competitive.

[IT_Architect]

...A better approach would be for Microsoft Hyper-V to make their VMs present their environment like a physical machine does so that the software or OS can use all the cores.

I was avoiding putting this fine a point on it, but you're forcing my hand. Hyper-V does, and VMware doesn't. Craig further up on this thread tested it for us. The results of the VMware test was confirmed by the official world from VMware. Hyper-V sells Windows The per-socket licensing in a multi-core world is to the customer's advantage. Customers know that. Microsoft forced Oracle to cave to the processor model not all that long ago. That's the direction. So where are the complaining customers going to come from? In which vendor's best interest is it to see VMware do well? That leaves VMware with no allies, and in no position to influence licensing.

I'd like to see VMware continue to be a player. In order to do that, their value proposition needs to work under current licensing practices. It's their market to hang on to or lose. If it were my company, I'd have people burning some midnight oil.

[mreferre]

I have to agree with IT_Architect (what the h&%ll is your name?) here.

Unless things change dramatically (and they will ... but in the long run) as to how sw is licensed.... currently VMware customers might be paying a software penalty simply because VMware is not exposing the actual CPU structure into the VM.

Software licensing caveats is sometimes being used by VMware to demonstrate it's advantageous to use ESX Vs Hyper-V. This is a good example: http://blogs.vmware.com/virtualreality/2008/12/do-i-really-need-to-upgrade-all-my-windows-server-200...

As far as I can say this thread is pointing to a scenario where deploying on VMware a given application licensed per-socket (I don't think we are talking about the basic Windows OS itself here which has a number of licensing methods that could overcome the issue)....... is more expensive than deploying the same scenario on Hyper-V (not just a physical system).

I don't have any vested interest in VMware or MS ..... but I don't think it's fair to claim your advantages if the way it works right now favors you..... and ask the ISVs to change their (de facto standard) licensing models when things don't favor you.

As I said things will change anyway over time (per usage charges etc etc) but as of 09/01/2009 this is the way it works ....

Massimo.