<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: vSphere 5 Licensing: A few things to consider.</title>
	<atom:link href="http://cartershanklin.com/blog3/index.php/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/feed" rel="self" type="application/rss+xml" />
	<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/</link>
	<description></description>
	<lastBuildDate>Wed, 08 Feb 2012 02:47:19 -0800</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.3</generator>
	<item>
		<title>By: How to Save With New vSphere 5 Licensing Model &#124; DoubleCloud.org</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-770</link>
		<dc:creator>How to Save With New vSphere 5 Licensing Model &#124; DoubleCloud.org</dc:creator>
		<pubDate>Mon, 25 Jul 2011 05:02:54 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-770</guid>
		<description>[...] the vRAM pooling simplifies the licensing model, as pointed out by Carter Shanklin. Money wise, some 10-% of existing customers are affected according to this official blog. I think [...]</description>
		<content:encoded><![CDATA[<p>[...] the vRAM pooling simplifies the licensing model, as pointed out by Carter Shanklin. Money wise, some 10-% of existing customers are affected according to this official blog. I think [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vidar</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-750</link>
		<dc:creator>Vidar</dc:creator>
		<pubDate>Mon, 18 Jul 2011 19:58:27 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-750</guid>
		<description>Too bad someone didn&#039;t do their job properly and got the ratios correct from the beginning then? Those numbers should have been doubled at the moment as they were only valid 3-4 years ago when we had slow 4-core CPUs with no hyperthreading.
It shouldn&#039;t take very high IQ to understand than looking at old environments with old hardware isn&#039;t representative of what customers are buying this year. Somebody at VMware need their heads examined or find something to do which they are better at.</description>
		<content:encoded><![CDATA[<p>Too bad someone didn&#8217;t do their job properly and got the ratios correct from the beginning then? Those numbers should have been doubled at the moment as they were only valid 3-4 years ago when we had slow 4-core CPUs with no hyperthreading.<br />
It shouldn&#8217;t take very high IQ to understand than looking at old environments with old hardware isn&#8217;t representative of what customers are buying this year. Somebody at VMware need their heads examined or find something to do which they are better at.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carter Shanklin</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-748</link>
		<dc:creator>Carter Shanklin</dc:creator>
		<pubDate>Mon, 18 Jul 2011 14:51:36 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-748</guid>
		<description>Hi Vidar,

I assume the ratios (24/32/48) will grow over time. I can&#039;t guarantee that but it seems plausible.

Misguidedly yours,</description>
		<content:encoded><![CDATA[<p>Hi Vidar,</p>
<p>I assume the ratios (24/32/48) will grow over time. I can&#8217;t guarantee that but it seems plausible.</p>
<p>Misguidedly yours,</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vidar</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-747</link>
		<dc:creator>Vidar</dc:creator>
		<pubDate>Mon, 18 Jul 2011 00:48:44 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-747</guid>
		<description>Oops! should have used 128MB in that calculation. so correct numbers would be that the &quot;future&quot; server would have 3.2TB RAM and with that require 68 enterprise plus licenses which is still very much more than the 24 required by the core-count.</description>
		<content:encoded><![CDATA[<p>Oops! should have used 128MB in that calculation. so correct numbers would be that the &#8220;future&#8221; server would have 3.2TB RAM and with that require 68 enterprise plus licenses which is still very much more than the 24 required by the core-count.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vidar</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-746</link>
		<dc:creator>Vidar</dc:creator>
		<pubDate>Mon, 18 Jul 2011 00:44:58 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-746</guid>
		<description>The new licensing seems to be someone at VMware trying to make more money without thinking through the consequences. Your assumption about cpu cores growing is just another of those not-so-well-through-through-items. If we in a few years from now grow to CPUs with 64 cores - how much memory do you think will be in a server per such CPU? Today I would say 128GB per 10-core CPU is a fair amount of memory. Let&#039;s not just multiply up cpu cores, as you do in your misguided blogpost. If I grow from 10 core to 64 cores per CPU - wouldn&#039;t it then be fair assumption that the memory in the server grows similarly? So 512GBx6.4=3.2TB
As 4-cpu server in your 64-core future will thus possibly have 13TB RAM.
How many vSphere 5 licenses will that require?
I&#039;ll tell you: 13000/48=271 vSphere licenses... Just because of RAM.
If you had been looking at cores like in vSphere 4 the same server would have only required 24 licenses.
That&#039;s a 11x cost difference.

Food for thought, eh?


A more realistic calculation for the not so distant future is with a very nice virtualization-server; HP DL580G7 with 4x E7-4870 cpus and 512GB RAM.
vSphere 4-licensing would mean 4 enterprise plus licenses.
vSphere 5-licensing means 11 enterprise plus licenses.</description>
		<content:encoded><![CDATA[<p>The new licensing seems to be someone at VMware trying to make more money without thinking through the consequences. Your assumption about cpu cores growing is just another of those not-so-well-through-through-items. If we in a few years from now grow to CPUs with 64 cores &#8211; how much memory do you think will be in a server per such CPU? Today I would say 128GB per 10-core CPU is a fair amount of memory. Let&#8217;s not just multiply up cpu cores, as you do in your misguided blogpost. If I grow from 10 core to 64 cores per CPU &#8211; wouldn&#8217;t it then be fair assumption that the memory in the server grows similarly? So 512GBx6.4=3.2TB<br />
As 4-cpu server in your 64-core future will thus possibly have 13TB RAM.<br />
How many vSphere 5 licenses will that require?<br />
I&#8217;ll tell you: 13000/48=271 vSphere licenses&#8230; Just because of RAM.<br />
If you had been looking at cores like in vSphere 4 the same server would have only required 24 licenses.<br />
That&#8217;s a 11x cost difference.</p>
<p>Food for thought, eh?</p>
<p>A more realistic calculation for the not so distant future is with a very nice virtualization-server; HP DL580G7 with 4x E7-4870 cpus and 512GB RAM.<br />
vSphere 4-licensing would mean 4 enterprise plus licenses.<br />
vSphere 5-licensing means 11 enterprise plus licenses.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-737</link>
		<dc:creator>Dave</dc:creator>
		<pubDate>Fri, 15 Jul 2011 15:45:38 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-737</guid>
		<description>I agree – for many users it will be a positive.

There are a few scenarios where it will hurt some users. Imagine users who want to use the large scale virtualization abilities in vSphere 5 (8 vCPU, 128GB RAM) VMs to do big databases. I just sat in on a meeting today all day with such a customer (and yes, they do really need such large DB machines).

Say they used a vSphere 4.1 license and filled a 2 socket, 16 core box with 256GB memory. With ESX 4.1 and Ent+ Licensing, they need to buy only 2 licenses (1 per socket). Done. With vSphere 5, the 96GB license they get doesn’t cover it. They need to buy 6 licenses for that very same host.

It almost seems to punish users who want to take advantage of the new awesome features. Thoughts?

Matt,

I&#039;m not sure I understand your math here. To license a vSphere 5 pool to use 128GB of vRAM under Ent+, wouldn&#039;t you need to purchase 3 licenses, not 6, unless you plan on using all 256GB of pRAM, leaving you with no headroom in the pool.</description>
		<content:encoded><![CDATA[<p>I agree – for many users it will be a positive.</p>
<p>There are a few scenarios where it will hurt some users. Imagine users who want to use the large scale virtualization abilities in vSphere 5 (8 vCPU, 128GB RAM) VMs to do big databases. I just sat in on a meeting today all day with such a customer (and yes, they do really need such large DB machines).</p>
<p>Say they used a vSphere 4.1 license and filled a 2 socket, 16 core box with 256GB memory. With ESX 4.1 and Ent+ Licensing, they need to buy only 2 licenses (1 per socket). Done. With vSphere 5, the 96GB license they get doesn’t cover it. They need to buy 6 licenses for that very same host.</p>
<p>It almost seems to punish users who want to take advantage of the new awesome features. Thoughts?</p>
<p>Matt,</p>
<p>I&#8217;m not sure I understand your math here. To license a vSphere 5 pool to use 128GB of vRAM under Ent+, wouldn&#8217;t you need to purchase 3 licenses, not 6, unless you plan on using all 256GB of pRAM, leaving you with no headroom in the pool.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frobe</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-730</link>
		<dc:creator>Frobe</dc:creator>
		<pubDate>Wed, 13 Jul 2011 22:09:15 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-730</guid>
		<description>How about people that use approximately zero cpu but 512GB of RAM, how is this beneficial?</description>
		<content:encoded><![CDATA[<p>How about people that use approximately zero cpu but 512GB of RAM, how is this beneficial?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lu</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-729</link>
		<dc:creator>Lu</dc:creator>
		<pubDate>Wed, 13 Jul 2011 20:39:55 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-729</guid>
		<description>Carter, your reasoning is sound and I can agree with your argumentation. 
Only problem I have is that the vRAM amounts &quot;...so that most common current hardware configurations would not be affected.&quot; seem to have been calculated quite some time ago.
Our boxes that use an Ent+ plus license tend to have substantially more than 48GB.</description>
		<content:encoded><![CDATA[<p>Carter, your reasoning is sound and I can agree with your argumentation.<br />
Only problem I have is that the vRAM amounts &#8220;&#8230;so that most common current hardware configurations would not be affected.&#8221; seem to have been calculated quite some time ago.<br />
Our boxes that use an Ent+ plus license tend to have substantially more than 48GB.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-728</link>
		<dc:creator>Andy</dc:creator>
		<pubDate>Wed, 13 Jul 2011 17:06:23 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-728</guid>
		<description>@Andreas is correct. &quot;Retail&quot; vSphere licenses do not allow you to provide hosting services for other organizations. You must be signed into their VSPP program.

As a VSPP this change is not too unexpected and already feels familiar. Our rental licensing model has already been based of $x per allocated vRAM per month. That is the only basis for us charging customers for their hosted consumption and has been like that for awhile. 

This will run some major alignments when customers need to hit the ROI worksheets as now there are some direct lines that can be drawn between what running their IT would cost in CAPEX vs OPEX since the pricing model for both is one step similar.</description>
		<content:encoded><![CDATA[<p>@Andreas is correct. &#8220;Retail&#8221; vSphere licenses do not allow you to provide hosting services for other organizations. You must be signed into their VSPP program.</p>
<p>As a VSPP this change is not too unexpected and already feels familiar. Our rental licensing model has already been based of $x per allocated vRAM per month. That is the only basis for us charging customers for their hosted consumption and has been like that for awhile. </p>
<p>This will run some major alignments when customers need to hit the ROI worksheets as now there are some direct lines that can be drawn between what running their IT would cost in CAPEX vs OPEX since the pricing model for both is one step similar.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: snorkel</title>
		<link>http://cartershanklin.com/blog3/2011/07/13/vsphere-5-licensing-a-few-things-to-consider/comment-page-1/#comment-727</link>
		<dc:creator>snorkel</dc:creator>
		<pubDate>Wed, 13 Jul 2011 15:07:51 +0000</pubDate>
		<guid isPermaLink="false">http://cartershanklin.com/blog3/?p=168#comment-727</guid>
		<description>I could get behind the new licensing model more easily if VMWare would actually sell vRAM licenses.  The fact that amount of vRAM you get is tied to the number of CPUs you license is what I find to be a mess.  I understand that they needed to provide an &quot;evolution&quot; path for existing customers.. That&#039;s fine.. Give me the one time conversion of my vSphere 4.1 licenses to vSphere 5&#039;s vRAM licensing, and then let me purchase additional GBs of vRAM going forward.  Let me buy 5 GB of Enterprise Plus vRAM if I find after the conversion that I am short 5 GB... Don&#039;t make me buy an entire addtional cpu license of Enterprise Plus to get 48 GB of additional vRAM when I only need 5.  Attaching vRAM to CPU licenses is just more confusing than necessary, and just stinks of forcing customers to buy more than they need.. Isn&#039;t one of the primary driving factors behind server virtualization the desire to get the most utilization out of physical hardware?  So we can consolidate our hardware to ensure we&#039;re not spending too much on wasted cycles, but are forced by a silly licensing policy to buy more licensing than we need.

Additionally, I think there is a bit of bait and switch going on here.  Since the beginning of production ready VMWare we&#039;ve been able to allocate as much vRAM as we wanted (within reason) to VMs knowing that VMWare will only use what is actually needed.  There has been incentive for admins to over provision the stuff both to avoid unseen memory utilization increases and to help sell doubting DBAs and the like on VMWare&#039;s ability to virtualize their workloads without performance impacts.  The result is that a lot of us have piles upon piles of VMs with more vRAM associated to them than what is really required.  Now all of a sudden we have a reason to pay attention to this and now need to go back and start trying to convince VM owners that they need to give up vRAM.  That&#039;s going to be a nightmare.  You tell an Oracle DBA that you&#039;re removing 2 Gigs of RAM from their server.  If you manage to convince them you can bet your behind that any real or perceived performance degradation on that server will be blamed on the RAM being removed.

Additionally, removing vRAM will require VM reboots.. So now we get to force downtime on people who ultimately allowed us to virtualize their environments on the promise of drastically improved uptime.  Yay!</description>
		<content:encoded><![CDATA[<p>I could get behind the new licensing model more easily if VMWare would actually sell vRAM licenses.  The fact that amount of vRAM you get is tied to the number of CPUs you license is what I find to be a mess.  I understand that they needed to provide an &#8220;evolution&#8221; path for existing customers.. That&#8217;s fine.. Give me the one time conversion of my vSphere 4.1 licenses to vSphere 5&#8242;s vRAM licensing, and then let me purchase additional GBs of vRAM going forward.  Let me buy 5 GB of Enterprise Plus vRAM if I find after the conversion that I am short 5 GB&#8230; Don&#8217;t make me buy an entire addtional cpu license of Enterprise Plus to get 48 GB of additional vRAM when I only need 5.  Attaching vRAM to CPU licenses is just more confusing than necessary, and just stinks of forcing customers to buy more than they need.. Isn&#8217;t one of the primary driving factors behind server virtualization the desire to get the most utilization out of physical hardware?  So we can consolidate our hardware to ensure we&#8217;re not spending too much on wasted cycles, but are forced by a silly licensing policy to buy more licensing than we need.</p>
<p>Additionally, I think there is a bit of bait and switch going on here.  Since the beginning of production ready VMWare we&#8217;ve been able to allocate as much vRAM as we wanted (within reason) to VMs knowing that VMWare will only use what is actually needed.  There has been incentive for admins to over provision the stuff both to avoid unseen memory utilization increases and to help sell doubting DBAs and the like on VMWare&#8217;s ability to virtualize their workloads without performance impacts.  The result is that a lot of us have piles upon piles of VMs with more vRAM associated to them than what is really required.  Now all of a sudden we have a reason to pay attention to this and now need to go back and start trying to convince VM owners that they need to give up vRAM.  That&#8217;s going to be a nightmare.  You tell an Oracle DBA that you&#8217;re removing 2 Gigs of RAM from their server.  If you manage to convince them you can bet your behind that any real or perceived performance degradation on that server will be blamed on the RAM being removed.</p>
<p>Additionally, removing vRAM will require VM reboots.. So now we get to force downtime on people who ultimately allowed us to virtualize their environments on the promise of drastically improved uptime.  Yay!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.321 seconds -->

