<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Cloud Ping-Pong: Passing VM Workloads from Cloud to Cloud Will Hurt</title>
	<link>http://thevirtualdc.com/?p=135</link>
	<description>A Virtual Team Blog about the VDC and How To Get There</description>
	<pubDate>Sat, 04 Sep 2010 18:33:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Rodos</title>
		<link>http://thevirtualdc.com/?p=135#comment-2248</link>
		<dc:creator>Rodos</dc:creator>
		<pubDate>Sat, 10 Jan 2009 11:41:05 +0000</pubDate>
		<guid>http://thevirtualdc.com/?p=135#comment-2248</guid>
		<description>These are certainly issues that will need to be addressed. 

From the bandwidth to the cloud side managing traffic quality is a mature technology. Industry already is doing this for much more difficult protocols such as VoIP. Also Internet may not always be the access medium to the Cloud, we will see a lot of dedicated networks too. This is also why we will see a greater reliance on WAN acceleration technologies which Cisco are pushing as import to pair with Cloud adoption.

Certainly very true on the bandwidth side and I don't want to distract from that. However in the early generations we are probably not going to see VMotion and dynamic and move of workloads around across clouds. This is certainly not what the vCloud API will provide. What we will see though is cloud providers who will may do it internally for you, for purposes of DR and their own backend scale. They can do it because they probably own the carriage. In future generations we may see this start to occur, but bandwidth is going to have to catch up. Just think back 5 years and what bandwidth we were all living with. Remember 128K frame relay links, don't see them much any more.

Great discussion.</description>
		<content:encoded><![CDATA[<p>These are certainly issues that will need to be addressed. </p>
<p>From the bandwidth to the cloud side managing traffic quality is a mature technology. Industry already is doing this for much more difficult protocols such as VoIP. Also Internet may not always be the access medium to the Cloud, we will see a lot of dedicated networks too. This is also why we will see a greater reliance on WAN acceleration technologies which Cisco are pushing as import to pair with Cloud adoption.</p>
<p>Certainly very true on the bandwidth side and I don&#8217;t want to distract from that. However in the early generations we are probably not going to see VMotion and dynamic and move of workloads around across clouds. This is certainly not what the vCloud API will provide. What we will see though is cloud providers who will may do it internally for you, for purposes of DR and their own backend scale. They can do it because they probably own the carriage. In future generations we may see this start to occur, but bandwidth is going to have to catch up. Just think back 5 years and what bandwidth we were all living with. Remember 128K frame relay links, don&#8217;t see them much any more.</p>
<p>Great discussion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Allender</title>
		<link>http://thevirtualdc.com/?p=135#comment-2225</link>
		<dc:creator>Scott Allender</dc:creator>
		<pubDate>Fri, 09 Jan 2009 16:54:51 +0000</pubDate>
		<guid>http://thevirtualdc.com/?p=135#comment-2225</guid>
		<description>Nice Post!  This does a great job describing the potential pitfall of moving virtual machines to the cloud.</description>
		<content:encoded><![CDATA[<p>Nice Post!  This does a great job describing the potential pitfall of moving virtual machines to the cloud.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
