<?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: Rack Area Networking: IOV</title>
	<atom:link href="http://blog.nigelpoulton.com/rack-area-networking-iov/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.nigelpoulton.com/rack-area-networking-iov/#utm_source=feed&amp;utm_medium=feed&amp;utm_campaign=feed</link>
	<description>with nigel poulton</description>
	<lastBuildDate>Wed, 28 Jul 2010 04:41:27 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: physical server - StartTags.com</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-704</link>
		<dc:creator>physical server - StartTags.com</dc:creator>
		<pubDate>Wed, 27 Jan 2010 01:37:10 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-704</guid>
		<description>[...] and a list showing physical servers and instances (ie SQL Servers grouped by their host machine) ...Rack Area Networking: IOV Technical Deep DiveYou no longer have to power down the server, open it up, install a new physical card and then wait [...]</description>
		<content:encoded><![CDATA[<p>[...] and a list showing physical servers and instances (ie SQL Servers grouped by their host machine) &#8230;Rack Area Networking: IOV Technical Deep DiveYou no longer have to power down the server, open it up, install a new physical card and then wait [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel Poulton</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-687</link>
		<dc:creator>Nigel Poulton</dc:creator>
		<pubDate>Fri, 15 Jan 2010 20:34:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-687</guid>
		<description>&lt;p&gt;Hi Frank,&lt;/p&gt;
&lt;p&gt;Thanks for stopping by and glad you like the blog.&lt;/p&gt;
&lt;p&gt;I personally try not to argue against UCS as I do not know the technology that well - I wish I did.&#160; But I know one thing for sure - I like it more than I like Flex-10 ;-)&lt;/p&gt;
&lt;p&gt;Thanks for the info on the UCS SR-IOV implementation.&#160; &lt;/p&gt;
&lt;p&gt;To me - and this is just my opinion - it makes more sense to disaggregate the I/O from the compute.&#160; &lt;/p&gt;
&lt;p&gt;I will probably say more on Cisco once I get my hands on some UCS, but for now, Im liking&#160; lot of what Ive seen and am told if coming in the pipeline form the likes of Xsigo, NextIO and VitenSys.&lt;/p&gt;
&lt;p&gt;Nigel&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Hi Frank,</p>
<p>Thanks for stopping by and glad you like the blog.</p>
<p>I personally try not to argue against UCS as I do not know the technology that well &#8211; I wish I did.&nbsp; But I know one thing for sure &#8211; I like it more than I like Flex-10 <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Thanks for the info on the UCS SR-IOV implementation.&nbsp; </p>
<p>To me &#8211; and this is just my opinion &#8211; it makes more sense to disaggregate the I/O from the compute.&nbsp; </p>
<p>I will probably say more on Cisco once I get my hands on some UCS, but for now, Im liking&nbsp; lot of what Ive seen and am told if coming in the pipeline form the likes of Xsigo, NextIO and VitenSys.</p>
<p>Nigel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frank DAgostino</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-684</link>
		<dc:creator>Frank DAgostino</dc:creator>
		<pubDate>Wed, 13 Jan 2010 18:49:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-684</guid>
		<description>This is a great discussion on technologies between now and the rainbow.&#160; The rainbow is never reached, of course, as it keeps moving as we get closer.&#160; I think the topics being addressed are somewhat forecasting the future of compute, IO and memory.&#160; The thought I have is if memory, cpu, and IO are completely distilled, then the topic of MR-IOV is much more relevant as the technical issues (addressing, bus number, blah), become more relevant when the IO hardware can be associated with any CPU.&#160; Brad and I share an affinity to UCS, but the key is the UCS today provides an SR-IOV implementation that provides a greater number of interfaces than can be provisioned than &quot;at least&quot; the Flex-10 solution mentioned previously.&#160; I do not know of the total number of VF functions being provided by SR-IOV capable solutions, but the UCS specifically provides up to 128 (some used for control channels), they can be FC or Ethernet, and they can be for virtualized or bare-metal deployments.
The key to understand however is that the SR-IOV mezzanine in UCS has a specific hardware relationship to the CPU and memory on the PCB.&#160; The construct of a server can move anywhere within the management domain, or be exported via its XML profile to another domain, and can use any physical hardware based on its profile.&#160; If my understanding is correct, the MR-IOV implementation removes the mezzanine / hw attachment from the cpu/memory on the blade and that is not provided in UCS today, as it is an SR-IOV implementation.&#160; Any logical adapter can be provided on a blade within the UCS construct today, but it is applied to the mezzanine associated with the compute hardware.
Great blog by the way - </description>
		<content:encoded><![CDATA[<p>This is a great discussion on technologies between now and the rainbow.&nbsp; The rainbow is never reached, of course, as it keeps moving as we get closer.&nbsp; I think the topics being addressed are somewhat forecasting the future of compute, IO and memory.&nbsp; The thought I have is if memory, cpu, and IO are completely distilled, then the topic of MR-IOV is much more relevant as the technical issues (addressing, bus number, blah), become more relevant when the IO hardware can be associated with any CPU.&nbsp; Brad and I share an affinity to UCS, but the key is the UCS today provides an SR-IOV implementation that provides a greater number of interfaces than can be provisioned than &quot;at least&quot; the Flex-10 solution mentioned previously.&nbsp; I do not know of the total number of VF functions being provided by SR-IOV capable solutions, but the UCS specifically provides up to 128 (some used for control channels), they can be FC or Ethernet, and they can be for virtualized or bare-metal deployments.<br />
The key to understand however is that the SR-IOV mezzanine in UCS has a specific hardware relationship to the CPU and memory on the PCB.&nbsp; The construct of a server can move anywhere within the management domain, or be exported via its XML profile to another domain, and can use any physical hardware based on its profile.&nbsp; If my understanding is correct, the MR-IOV implementation removes the mezzanine / hw attachment from the cpu/memory on the blade and that is not provided in UCS today, as it is an SR-IOV implementation.&nbsp; Any logical adapter can be provided on a blade within the UCS construct today, but it is applied to the mezzanine associated with the compute hardware.<br />
Great blog by the way -</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cam Ford</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-652</link>
		<dc:creator>Cam Ford</dc:creator>
		<pubDate>Tue, 15 Dec 2009 18:54:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-652</guid>
		<description>PS.....Xsigo can move the boot profile and boot device&#160;for a Server WITHOUT changing the BIOS....that is the beauty of the &quot;remote IO&quot; model......and BTW, our SAN boot actually works :-)</description>
		<content:encoded><![CDATA[<p>PS&#8230;..Xsigo can move the boot profile and boot device&nbsp;for a Server WITHOUT changing the BIOS&#8230;.that is the beauty of the &quot;remote IO&quot; model&#8230;&#8230;and BTW, our SAN boot actually works <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cam Ford</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-651</link>
		<dc:creator>Cam Ford</dc:creator>
		<pubDate>Tue, 15 Dec 2009 18:49:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-651</guid>
		<description>HI Nigel,&#160; Brad is absolutely correct.&#160; Customers do want an integrated mangaement platform for their virtual resources.&#160; That is exactly why Xsigo has integrated its Virtual IO management framework into VMware&#039;s VCenter for a single console to manage all of your virtual resources.&#160; Unfortunately, large system vendors like Cisco, HP, IBM ,etc. really want to lock you into their vertical solutions.....where as customers really want choice.&#160; Their &quot;single management platform&quot; locks you into managing your Cisco environment one way....and the rest of your servers a different way (HP, Dell, IBM, etc.).&#160; With Xsigo, we are platform indepdent, OS independent, Hypervisor independent, and vendor independent......so you can run us on existing rack or blade servers from any vendor.....and still manage your virtual server and virtual IO resources from a single pain of glass.&#160; Also, most people do their hardware monitoring and management through existing SNMP-based frameworks anyways....and will need to continue doing that.</description>
		<content:encoded><![CDATA[<p>HI Nigel,&nbsp; Brad is absolutely correct.&nbsp; Customers do want an integrated mangaement platform for their virtual resources.&nbsp; That is exactly why Xsigo has integrated its Virtual IO management framework into VMware&#39;s VCenter for a single console to manage all of your virtual resources.&nbsp; Unfortunately, large system vendors like Cisco, HP, IBM ,etc. really want to lock you into their vertical solutions&#8230;..where as customers really want choice.&nbsp; Their &quot;single management platform&quot; locks you into managing your Cisco environment one way&#8230;.and the rest of your servers a different way (HP, Dell, IBM, etc.).&nbsp; With Xsigo, we are platform indepdent, OS independent, Hypervisor independent, and vendor independent&#8230;&#8230;so you can run us on existing rack or blade servers from any vendor&#8230;..and still manage your virtual server and virtual IO resources from a single pain of glass.&nbsp; Also, most people do their hardware monitoring and management through existing SNMP-based frameworks anyways&#8230;.and will need to continue doing that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cam Ford</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-650</link>
		<dc:creator>Cam Ford</dc:creator>
		<pubDate>Tue, 15 Dec 2009 18:44:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-650</guid>
		<description>Nigel, Brad is absolutely correct.  Customers do want an integrated management platform for their virtual resources.  Xsigo integrates its IO Virtualization management platform (XMS) into Virtual Center as a plug-in, so customers can manage their virtual Servers and Virtual IO resources all from a single management console.

This allows users to select best in class servers, networking, and storage platforms just like they always have....and can centrally manage all fo their virtual resources......while monitoring all fo their physical hardware with their existing SNMP-based frameworks.

Unfortunately, Cisco&#039;s UCS solution doesnt quite get that customers want choice and they force you to purchase an an....almost end to end solution....and you are forced to manage your Cisco gear one way and your other servers another way.  With Xsigo, we can work across existing servers, both rack and blade....across vendor, and across OS and hypervisor.  Customers want choice.....while large system vendors want lock in (Cisco, HP, IBM, etc.).</description>
		<content:encoded><![CDATA[<p>Nigel, Brad is absolutely correct.  Customers do want an integrated management platform for their virtual resources.  Xsigo integrates its IO Virtualization management platform (XMS) into Virtual Center as a plug-in, so customers can manage their virtual Servers and Virtual IO resources all from a single management console.</p>
<p>This allows users to select best in class servers, networking, and storage platforms just like they always have&#8230;.and can centrally manage all fo their virtual resources&#8230;&#8230;while monitoring all fo their physical hardware with their existing SNMP-based frameworks.</p>
<p>Unfortunately, Cisco&#8217;s UCS solution doesnt quite get that customers want choice and they force you to purchase an an&#8230;.almost end to end solution&#8230;.and you are forced to manage your Cisco gear one way and your other servers another way.  With Xsigo, we can work across existing servers, both rack and blade&#8230;.across vendor, and across OS and hypervisor.  Customers want choice&#8230;..while large system vendors want lock in (Cisco, HP, IBM, etc.).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel Poulton</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-648</link>
		<dc:creator>Nigel Poulton</dc:creator>
		<pubDate>Fri, 11 Dec 2009 23:08:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-648</guid>
		<description>:-D

Yep, right now they only do the I/O portion of provisioning.  BUT....... the more complete integration will come as part of any of the following - 

1.  Design wins and integration with OEM Management software
2.  When they are acquired and integrated by server venors
3.  When Cisco provide hooks in to UCSM
4.  When Cisco do their own version (and obviously integrate with UCSM)

So I think we agree that the power of the Xsigo or VirtenSys solution with the power of the Cisco UCSM gives us the best solution :-P

Only playing - Have a good weekend.

Nigel</description>
		<content:encoded><![CDATA[<p> <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_biggrin.gif' alt=':-D' class='wp-smiley' /> </p>
<p>Yep, right now they only do the I/O portion of provisioning.  BUT&#8230;&#8230;. the more complete integration will come as part of any of the following &#8211; </p>
<p>1.  Design wins and integration with OEM Management software<br />
2.  When they are acquired and integrated by server venors<br />
3.  When Cisco provide hooks in to UCSM<br />
4.  When Cisco do their own version (and obviously integrate with UCSM)</p>
<p>So I think we agree that the power of the Xsigo or VirtenSys solution with the power of the Cisco UCSM gives us the best solution <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_razz.gif' alt=':-P' class='wp-smiley' /> </p>
<p>Only playing &#8211; Have a good weekend.</p>
<p>Nigel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Hedlund</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-646</link>
		<dc:creator>Brad Hedlund</dc:creator>
		<pubDate>Fri, 11 Dec 2009 21:42:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-646</guid>
		<description>Nigel,
&#160;
I&#039;m not biting my tongue at all. &#160;The current Cisco UCS offering is the new thinking here that effectively obsoletes these I/O only solutions. &#160;These players are further recognition of the market for changing the way customers provision services in the data center. &#160;Cisco responded to this market by creating a tight integration of the server, network, and virtualization platform with UCS. &#160;
&#160;
Players like Virtensys and Xsigo, on the other hand, since they cannot provide the complete server + network integration, they responded with an integration of just I/O + network, and they ask the customer to manage the rest of the server separately. &#160;This results in a disjointed service provisioning process with two or more different management tools that are not in lock step with one another. &#160;
&#160;
One simple example: You may be able to move a vNIC and vHBA from Server1 to Server5, but did you also move the UUID and BIOS boot settings? You wont need to worry about that with UCS, but this could become a real problem with the other I/O only based offerings. 
&#160;
This is exactly why I say Cisco will likely never acquire theses companies (in my opinion), because Cisco has already leap frogged their provisioning capabilities with UCS.
&#160;
&#160;
Cheers,
Brad</description>
		<content:encoded><![CDATA[<p>Nigel,<br />
&nbsp;<br />
I&#39;m not biting my tongue at all. &nbsp;The current Cisco UCS offering is the new thinking here that effectively obsoletes these I/O only solutions. &nbsp;These players are further recognition of the market for changing the way customers provision services in the data center. &nbsp;Cisco responded to this market by creating a tight integration of the server, network, and virtualization platform with UCS. &nbsp;<br />
&nbsp;<br />
Players like Virtensys and Xsigo, on the other hand, since they cannot provide the complete server + network integration, they responded with an integration of just I/O + network, and they ask the customer to manage the rest of the server separately. &nbsp;This results in a disjointed service provisioning process with two or more different management tools that are not in lock step with one another. &nbsp;<br />
&nbsp;<br />
One simple example: You may be able to move a vNIC and vHBA from Server1 to Server5, but did you also move the UUID and BIOS boot settings? You wont need to worry about that with UCS, but this could become a real problem with the other I/O only based offerings.<br />
&nbsp;<br />
This is exactly why I say Cisco will likely never acquire theses companies (in my opinion), because Cisco has already leap frogged their provisioning capabilities with UCS.<br />
&nbsp;<br />
&nbsp;<br />
Cheers,<br />
Brad</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel Poulton</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-645</link>
		<dc:creator>Nigel Poulton</dc:creator>
		<pubDate>Fri, 11 Dec 2009 20:47:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-645</guid>
		<description>Brad,

Sure these products only address I/O provisioning.  But they potentially do it better and with more flexibility than the way Cisco currently do it with UCS.

And when these companies either get acquired by or major design wins with the likes if HP and IBM then Im sure Cisco will come to market with something similar.  Either that, or Cisco take notice now and get there before HP, IBM and the likes.  Believe me, Flex-10 is a dog in comparison to the competition so is either due a refresh or replaced with one of these solutions....

Obviously on forums like this there is a need to defend what the company currently does.  But defending what you already do/already have is not a winning formula - moving with the times and implementing the best technologies is a winning formula.  I expect (and hope) that Cisco is all over stuff like this behind the scenes.  Obviously you/they cant come out and announce stuff like that here :-D

Im sure you&#039;re biting your tonigue :-D

Nigel</description>
		<content:encoded><![CDATA[<p>Brad,</p>
<p>Sure these products only address I/O provisioning.  But they potentially do it better and with more flexibility than the way Cisco currently do it with UCS.</p>
<p>And when these companies either get acquired by or major design wins with the likes if HP and IBM then Im sure Cisco will come to market with something similar.  Either that, or Cisco take notice now and get there before HP, IBM and the likes.  Believe me, Flex-10 is a dog in comparison to the competition so is either due a refresh or replaced with one of these solutions&#8230;.</p>
<p>Obviously on forums like this there is a need to defend what the company currently does.  But defending what you already do/already have is not a winning formula &#8211; moving with the times and implementing the best technologies is a winning formula.  I expect (and hope) that Cisco is all over stuff like this behind the scenes.  Obviously you/they cant come out and announce stuff like that here <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_biggrin.gif' alt=':-D' class='wp-smiley' /> </p>
<p>Im sure you&#8217;re biting your tonigue <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_biggrin.gif' alt=':-D' class='wp-smiley' /> </p>
<p>Nigel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad Hedlund</title>
		<link>http://blog.nigelpoulton.com/rack-area-networking-iov/comment-page-1/#comment-644</link>
		<dc:creator>Brad Hedlund</dc:creator>
		<pubDate>Fri, 11 Dec 2009 18:33:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nigelpoulton.com/?p=670#comment-644</guid>
		<description>Nigel,


Just my personal opinion here, but it&#039;s highly unlikely Cisco would acquire any of these players.  Why not?  Simply because these products do not fill any gap in the current Cisco data center offering.  In fact, these products only address I/O provisioning - whereas the Cisco offering provides total server provisioning, no just the I/O part.


Cheers,
Brad</description>
		<content:encoded><![CDATA[<p>Nigel,</p>
<p>Just my personal opinion here, but it&#8217;s highly unlikely Cisco would acquire any of these players.  Why not?  Simply because these products do not fill any gap in the current Cisco data center offering.  In fact, these products only address I/O provisioning &#8211; whereas the Cisco offering provides total server provisioning, no just the I/O part.</p>
<p>Cheers,<br />
Brad</p>
]]></content:encoded>
	</item>
</channel>
</rss>
