<?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: Carefully planning ESX4 and HP Storageworks EVA</title>
	<atom:link href="http://tech.philipsellers.com/2010/01/06/carefully-planning-esx-and-hp-storageworks-eva/feed/" rel="self" type="application/rss+xml" />
	<link>http://tech.philipsellers.com/2010/01/06/carefully-planning-esx-and-hp-storageworks-eva/</link>
	<description>Philip Sellers&#039; random thoughts on technology</description>
	<lastBuildDate>Fri, 23 Jul 2010 14:14:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Philip</title>
		<link>http://tech.philipsellers.com/2010/01/06/carefully-planning-esx-and-hp-storageworks-eva/comment-page-1/#comment-959</link>
		<dc:creator>Philip</dc:creator>
		<pubDate>Wed, 07 Apr 2010 19:48:03 +0000</pubDate>
		<guid isPermaLink="false">http://tech.philipsellers.com/?p=659#comment-959</guid>
		<description>Yuri, sorry for the very slow reply.  That is interesting that you found that.  We are using EVA 6000 as our primary array and we&#039;ve had many problems with our 6400 array used as the replication destination at our secondary site.  The x400 series EVA&#039;s seem to have some issues in general, although the latest code for them seems to have helped sort out a lot of issues.  From our understanding the 8400 saw the least amount of problems because of faster controllers, etc.  The 6400 a few more and the 4400&#039;s a lot of problems.   Anyways, we have set our ESX hosts to use Round Robin in accordance with the HP Best Practices and so far see few problems - mostly just occasional &quot;failed on physical path&quot; errors in the vmkernel log.</description>
		<content:encoded><![CDATA[<p>Yuri, sorry for the very slow reply.  That is interesting that you found that.  We are using EVA 6000 as our primary array and we&#8217;ve had many problems with our 6400 array used as the replication destination at our secondary site.  The x400 series EVA&#8217;s seem to have some issues in general, although the latest code for them seems to have helped sort out a lot of issues.  From our understanding the 8400 saw the least amount of problems because of faster controllers, etc.  The 6400 a few more and the 4400&#8242;s a lot of problems.   Anyways, we have set our ESX hosts to use Round Robin in accordance with the HP Best Practices and so far see few problems &#8211; mostly just occasional &#8220;failed on physical path&#8221; errors in the vmkernel log.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tech Talk &#187; Blog Archive &#187; Best practices for VMware ESX4 with HP EVA storage</title>
		<link>http://tech.philipsellers.com/2010/01/06/carefully-planning-esx-and-hp-storageworks-eva/comment-page-1/#comment-958</link>
		<dc:creator>Tech Talk &#187; Blog Archive &#187; Best practices for VMware ESX4 with HP EVA storage</dc:creator>
		<pubDate>Wed, 07 Apr 2010 19:44:33 +0000</pubDate>
		<guid isPermaLink="false">http://tech.philipsellers.com/?p=659#comment-958</guid>
		<description>[...] In previous version of ESX, the desired storage setting was fixed path for the EVA.  In our case, we simultaneously presented the ESX3.5 and ESX4 hosts to the same LUNs, meaning some were fixed and some were set to the ESX4 default, which was MRU.  This caused problems.  After initial issues, we backed away and presented one LUN at a time, performed our VMotions and then unpresented the LUN from the old cluster.  This prevented any flapping issues between controllers.  (See my eariler post about our problems.) [...]</description>
		<content:encoded><![CDATA[<p>[...] In previous version of ESX, the desired storage setting was fixed path for the EVA.  In our case, we simultaneously presented the ESX3.5 and ESX4 hosts to the same LUNs, meaning some were fixed and some were set to the ESX4 default, which was MRU.  This caused problems.  After initial issues, we backed away and presented one LUN at a time, performed our VMotions and then unpresented the LUN from the old cluster.  This prevented any flapping issues between controllers.  (See my eariler post about our problems.) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yuri Semenikhin</title>
		<link>http://tech.philipsellers.com/2010/01/06/carefully-planning-esx-and-hp-storageworks-eva/comment-page-1/#comment-893</link>
		<dc:creator>Yuri Semenikhin</dc:creator>
		<pubDate>Tue, 12 Jan 2010 15:44:25 +0000</pubDate>
		<guid isPermaLink="false">http://tech.philipsellers.com/?p=659#comment-893</guid>
		<description>Hi,
i have problem to with EVA, i have deployment in one of our costumer on EVA 8400, so i have configured ESX4 to use RR path policy ( default PSPS for EVA is MRU), and result is to mach reservation ocure when EVA switch primary controlerfor some LUN&#039;s , after analyzing logs i have change PSP to MRU, and after this change no problem !!!</description>
		<content:encoded><![CDATA[<p>Hi,<br />
i have problem to with EVA, i have deployment in one of our costumer on EVA 8400, so i have configured ESX4 to use RR path policy ( default PSPS for EVA is MRU), and result is to mach reservation ocure when EVA switch primary controlerfor some LUN&#8217;s , after analyzing logs i have change PSP to MRU, and after this change no problem !!!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
