<?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: Business Objects is Virtualization/MultiCore Stupid</title>
	<atom:link href="http://itsjustanotherlayer.com/2009/09/business-objects-is-virtualizationmulticore-stupid/feed/" rel="self" type="application/rss+xml" />
	<link>http://itsjustanotherlayer.com/2009/09/business-objects-is-virtualizationmulticore-stupid/</link>
	<description>Virtualization is a layer in software. What are you abstracting away from?</description>
	<lastBuildDate>Sat, 17 Jul 2010 12:16:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: iguy</title>
		<link>http://itsjustanotherlayer.com/2009/09/business-objects-is-virtualizationmulticore-stupid/comment-page-1/#comment-1596</link>
		<dc:creator>iguy</dc:creator>
		<pubDate>Sat, 17 Jul 2010 12:16:13 +0000</pubDate>
		<guid isPermaLink="false">http://itsjustanotherlayer.com/?p=291#comment-1596</guid>
		<description>I have an update to this that I will post on.   What we have finally gotten to the root here is to upgrade a contract from the CPU/core count to the virtualization rights by either User based or vCPU style based would cost us 2+x the maintenance fees.   Needless to say that is way over the cost of figuring out a rather ingenious way to stay within our CPU count AND still make them virtual with all the bonuses that come with that.  

I will revise my statement about BO not being entirely virtualization friendly.</description>
		<content:encoded><![CDATA[<p>I have an update to this that I will post on.   What we have finally gotten to the root here is to upgrade a contract from the CPU/core count to the virtualization rights by either User based or vCPU style based would cost us 2+x the maintenance fees.   Needless to say that is way over the cost of figuring out a rather ingenious way to stay within our CPU count AND still make them virtual with all the bonuses that come with that.  </p>
<p>I will revise my statement about BO not being entirely virtualization friendly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bernd</title>
		<link>http://itsjustanotherlayer.com/2009/09/business-objects-is-virtualizationmulticore-stupid/comment-page-1/#comment-1592</link>
		<dc:creator>Bernd</dc:creator>
		<pubDate>Tue, 13 Jul 2010 11:05:22 +0000</pubDate>
		<guid isPermaLink="false">http://itsjustanotherlayer.com/?p=291#comment-1592</guid>
		<description>I&#039;m a bit surprised to read this. Due to my understanding contracts signed in 2008 and later do have virtualization rights, means in a virtual environment SAP would count virtual CPUs/cores instead of physical. If you have an older contract, you can convert it to get virtualization rights.</description>
		<content:encoded><![CDATA[<p>I&#8217;m a bit surprised to read this. Due to my understanding contracts signed in 2008 and later do have virtualization rights, means in a virtual environment SAP would count virtual CPUs/cores instead of physical. If you have an older contract, you can convert it to get virtualization rights.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrea</title>
		<link>http://itsjustanotherlayer.com/2009/09/business-objects-is-virtualizationmulticore-stupid/comment-page-1/#comment-1394</link>
		<dc:creator>Andrea</dc:creator>
		<pubDate>Wed, 07 Oct 2009 00:13:34 +0000</pubDate>
		<guid isPermaLink="false">http://itsjustanotherlayer.com/?p=291#comment-1394</guid>
		<description>Or BO could tell you what they told us. CPU affinity on the VMs to bork the whole DRS/HA VI cluster. No thank you.</description>
		<content:encoded><![CDATA[<p>Or BO could tell you what they told us. CPU affinity on the VMs to bork the whole DRS/HA VI cluster. No thank you.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
