<?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: Private Isolated VSANs?</title>
	<atom:link href="http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/</link>
	<description>Random posts about unified computing and data center</description>
	<lastBuildDate>Sat, 11 May 2013 23:30:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: Dave Alexander</title>
		<link>http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/#comment-130</link>
		<dc:creator>Dave Alexander</dc:creator>
		<pubDate>Thu, 20 Jan 2011 22:07:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.unifiedcomputingblog.com/?p=158#comment-130</guid>
		<description><![CDATA[It wasn&#039;t a new problem, simply a random musing.   It doesn&#039;t solve any problem that zoning doesn&#039;t - in fact, in my post I even said that it would probably be implemented using zoning.   Zoning solves the access control issue, the concept of a private VSAN would simply automate the creation of those zones.

What got me thinking about this was some smaller environments where SAN administrators complain about the administrative overhead of single-initiator/single-target zoning.   While I (a long-time FC guy) don&#039;t think it&#039;s a big deal, some people do.]]></description>
		<content:encoded><![CDATA[<p>It wasn&#8217;t a new problem, simply a random musing.   It doesn&#8217;t solve any problem that zoning doesn&#8217;t &#8211; in fact, in my post I even said that it would probably be implemented using zoning.   Zoning solves the access control issue, the concept of a private VSAN would simply automate the creation of those zones.</p>
<p>What got me thinking about this was some smaller environments where SAN administrators complain about the administrative overhead of single-initiator/single-target zoning.   While I (a long-time FC guy) don&#8217;t think it&#8217;s a big deal, some people do.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brcdbreams</title>
		<link>http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/#comment-129</link>
		<dc:creator>Brcdbreams</dc:creator>
		<pubDate>Thu, 20 Jan 2011 20:01:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.unifiedcomputingblog.com/?p=158#comment-129</guid>
		<description><![CDATA[Hi Dave,

Interesting.  I&#039;m curious though about the problem that needs to be solved which zoning doesn&#039;t solve?  

I&#039;d also like to point out that SCSI (the application using Fibre Channel) isn&#039;t designed the same as a TCP socket (which is often the application running on top of Ethernet).  SCSI has a 1:Many, or Few:Many relationship. from initiator to targets and is a &quot;master-slave&quot; association.  Should multiple initiators access the same target, who is the master?  Get that wrong and you get data corruption.  Hence, zoning best practices.  And, as those of us who debugged switched Fibre Channel in the 90&#039;s know, early inititators would log into everything in sight, including other initiators so bad things happened.  Hence zoning best practices.

That said, I&#039;m not sure what the new problem is that we need to solve.  Thanks for any illumination on that you can share.]]></description>
		<content:encoded><![CDATA[<p>Hi Dave,</p>
<p>Interesting.  I&#8217;m curious though about the problem that needs to be solved which zoning doesn&#8217;t solve?  </p>
<p>I&#8217;d also like to point out that SCSI (the application using Fibre Channel) isn&#8217;t designed the same as a TCP socket (which is often the application running on top of Ethernet).  SCSI has a 1:Many, or Few:Many relationship. from initiator to targets and is a &#8220;master-slave&#8221; association.  Should multiple initiators access the same target, who is the master?  Get that wrong and you get data corruption.  Hence, zoning best practices.  And, as those of us who debugged switched Fibre Channel in the 90&#8242;s know, early inititators would log into everything in sight, including other initiators so bad things happened.  Hence zoning best practices.</p>
<p>That said, I&#8217;m not sure what the new problem is that we need to solve.  Thanks for any illumination on that you can share.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Technology Short Take #1 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers</title>
		<link>http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/#comment-128</link>
		<dc:creator>Technology Short Take #1 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers</dc:creator>
		<pubDate>Wed, 18 Aug 2010 05:38:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.unifiedcomputingblog.com/?p=158#comment-128</guid>
		<description><![CDATA[[...] Alexander does some &#8220;thinking out loud&#8221; with a post on private VSANs. In the post he asks why we don&#8217;t use PVSANs in the FC world in the same way we use PVLANs in [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Alexander does some &#8220;thinking out loud&#8221; with a post on private VSANs. In the post he asks why we don&#8217;t use PVSANs in the FC world in the same way we use PVLANs in [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy Waldrop</title>
		<link>http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/#comment-127</link>
		<dc:creator>Jeremy Waldrop</dc:creator>
		<pubDate>Mon, 14 Jun 2010 01:21:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.unifiedcomputingblog.com/?p=158#comment-127</guid>
		<description><![CDATA[Interesting idea, I like it. Would simply provisioning because you wouldn&#039;t have to create aliases and zones for new SAN attached hosts. 
something I would add to it is to have a way for the aliases and zones that get auto-created to have a specific prefix name based on what FC port they are on. I am thinking this would help simplify troubleshooting or if you wanted to temporarily remove a zone from a zoneset. In the case of UCS server blades all initiators coming off of ports connected to the FI would have specific alias/zone prefixes.
Maybe you should submit your idea to the Cisco FC team. :)]]></description>
		<content:encoded><![CDATA[<p>Interesting idea, I like it. Would simply provisioning because you wouldn&#8217;t have to create aliases and zones for new SAN attached hosts.<br />
something I would add to it is to have a way for the aliases and zones that get auto-created to have a specific prefix name based on what FC port they are on. I am thinking this would help simplify troubleshooting or if you wanted to temporarily remove a zone from a zoneset. In the case of UCS server blades all initiators coming off of ports connected to the FI would have specific alias/zone prefixes.<br />
Maybe you should submit your idea to the Cisco FC team. <img src='http://www.unifiedcomputingblog.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Onisick</title>
		<link>http://www.unifiedcomputingblog.com/2010/06/13/private-isolated-vsans/#comment-126</link>
		<dc:creator>Joe Onisick</dc:creator>
		<pubDate>Mon, 14 Jun 2010 00:52:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.unifiedcomputingblog.com/?p=158#comment-126</guid>
		<description><![CDATA[Dave,

Now that you&#039;ve spelled it out this makes a lot more sense than you&#039;re whacky IM ;-)  I do like the idea of simplifying the process.  To me there are two reasons for this:
1) Zoning doesn&#039;t do what we really think it does anymore and our zoning practices are outdated, expecially when virtualiztion is considered.
2) With more and more virtualized environments we need a clean way to zone multiple hosts to a single target without presenting too many devices to the &#039;SCSI bus&#039; the server thinks it sees.  An isolated VSAN or zone as you stated above would accomplich this in a sleek fashion minimizing overhead and clarifying things during admin/troubleshooting operations.

Great thoughts keep think out loud, next time brainstorm on ways to incorporate bacon, beer, and the shooting range without having to fly to Thailand to do it.]]></description>
		<content:encoded><![CDATA[<p>Dave,</p>
<p>Now that you&#8217;ve spelled it out this makes a lot more sense than you&#8217;re whacky IM <img src='http://www.unifiedcomputingblog.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />   I do like the idea of simplifying the process.  To me there are two reasons for this:<br />
1) Zoning doesn&#8217;t do what we really think it does anymore and our zoning practices are outdated, expecially when virtualiztion is considered.<br />
2) With more and more virtualized environments we need a clean way to zone multiple hosts to a single target without presenting too many devices to the &#8216;SCSI bus&#8217; the server thinks it sees.  An isolated VSAN or zone as you stated above would accomplich this in a sleek fashion minimizing overhead and clarifying things during admin/troubleshooting operations.</p>
<p>Great thoughts keep think out loud, next time brainstorm on ways to incorporate bacon, beer, and the shooting range without having to fly to Thailand to do it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
