<?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: &#8216;Motional reactions</title>
	<atom:link href="http://www.tripwire.com/state-of-security/bitbucket/motional-reactions/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/</link>
	<description>Debunking myths, analyzing trends and sharing best practices in IT security and compliance.</description>
	<lastBuildDate>Sat, 11 Feb 2012 01:47:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Mark Chuang</title>
		<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/comment-page-1/#comment-51</link>
		<dc:creator>Mark Chuang</dc:creator>
		<pubDate>Fri, 26 Sep 2008 23:42:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.tripwire.com/blog/?p=160#comment-51</guid>
		<description>Hi Dwayne, 

In speaking with IT admins who use VMware VMotion, they brought up another business value of VMotion - no more time-consuming scheduling of maintenance windows. Any migration technology that results in end-user visible downtime requires the IT admin to schedule a maintenance window. IT admins told us that they dreaded this process of having to contact (via repeated emails/phone calls) all application owners / line-of-business stakeholders / etc in order to schedule their maintenance windows. Based on some internal research we did with about 200 VMware users, they told us that it can easily take up them 30 to 40+ minutes (aggregate) to schedule a maintenance window for EACH application.</description>
		<content:encoded><![CDATA[<p>Hi Dwayne, </p>
<p>In speaking with IT admins who use VMware VMotion, they brought up another business value of VMotion &#8211; no more time-consuming scheduling of maintenance windows. Any migration technology that results in end-user visible downtime requires the IT admin to schedule a maintenance window. IT admins told us that they dreaded this process of having to contact (via repeated emails/phone calls) all application owners / line-of-business stakeholders / etc in order to schedule their maintenance windows. Based on some internal research we did with about 200 VMware users, they told us that it can easily take up them 30 to 40+ minutes (aggregate) to schedule a maintenance window for EACH application.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dwayne Melancon</title>
		<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/comment-page-1/#comment-50</link>
		<dc:creator>Dwayne Melancon</dc:creator>
		<pubDate>Fri, 26 Sep 2008 18:27:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.tripwire.com/blog/?p=160#comment-50</guid>
		<description>EJ and Mike, thanks for some great insight and education here.  It&#039;s clear that this topic touches nerves and that there are technical &quot;must haves&quot; to unlock the business potential even further - thanks for contributing to productive dialog. (and Mike I&#039;ll be watching for your script!)</description>
		<content:encoded><![CDATA[<p>EJ and Mike, thanks for some great insight and education here.  It&#8217;s clear that this topic touches nerves and that there are technical &#8220;must haves&#8221; to unlock the business potential even further &#8211; thanks for contributing to productive dialog. (and Mike I&#8217;ll be watching for your script!)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike DiPetrillo</title>
		<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/comment-page-1/#comment-49</link>
		<dc:creator>Mike DiPetrillo</dc:creator>
		<pubDate>Fri, 26 Sep 2008 15:16:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.tripwire.com/blog/?p=160#comment-49</guid>
		<description>Just a few notes on this post:

1) I&#039;m still baffled as to why Microsoft is having such a hard time with a fundamental building block of virtualization (Live Migration/VMotion). They first announced they would have this in 2006 and then stripped it out. Now it&#039;s 2010. 4 years to develop something that EVERY other virtualization vendor in the x86 space can do today. How can one vendor with the number of smart people that Microsoft has miss this one so badly? It&#039;s not rocket science.

2) Quick Migration from Microsoft still has some flaws. First, the 6 seconds you quote is probably doable with an idle VM and 512 MB of memory. The quickest I&#039;ve ever seen it is 8 seconds but now I&#039;m just splitting hairs so let&#039;s say 6 seconds. The average TCP Abort Connection time in a 10/100 network is 5 seconds. In GigE networks it&#039;s less (around 3 seconds). This means if the network connection is gone for over 5 seconds (which it is with Quick Migration) then anything using TCP has to re-establish a new connection. For some apps that&#039;s fine. For most apps that&#039;s bad. File copies stop. Outlook goes into offline mode. SQL ODBC connections drop and have to be manually re-established. It&#039;s bad. So bad that Systems Center Virtual Machine Manager throws up a nice warning box before you migrate a VM that tells you all users will be disconnected from the VM....do you want to continue? Bottom line is Quick Migration might be good enough for someone who has never experienced moving live from any other vendor in the industry.

3) Quick Migration has just as many requirements as live migration/VMotion. If you suspend a VM that&#039;s using SSE4 and migrate it and resume it on a host that does not support SSE4 then you will get a blue screen. That&#039;s one small example. This is why everyone requires like family and like brand of CPU. Microsoft may not write that down like everyone else but that doesn&#039;t prevent the issues from coming up. Maybe this is why they haven&#039;t implemented live migration yet - they don&#039;t understand virtualization.

I would absolutely agree that the value in virtualization is what goes on top of it. VMotion/live migration is simply an enabler. A previous comment highlighted that with DRS as a good that that VMotion has enabled.

For those that think Quick Migration is &quot;good enough&quot; and happen to be using VMware I showed off a PowerShell script that will allow Quick Migration in a VMware environment during one of my sessions at VMworld. I&#039;ll be posting the source and instructions to my blog shortly. http://mikedatl.typepad.com. Maybe that will take this conversation off the table and let us get back to the value adds on top of the infrastructure.</description>
		<content:encoded><![CDATA[<p>Just a few notes on this post:</p>
<p>1) I&#8217;m still baffled as to why Microsoft is having such a hard time with a fundamental building block of virtualization (Live Migration/VMotion). They first announced they would have this in 2006 and then stripped it out. Now it&#8217;s 2010. 4 years to develop something that EVERY other virtualization vendor in the x86 space can do today. How can one vendor with the number of smart people that Microsoft has miss this one so badly? It&#8217;s not rocket science.</p>
<p>2) Quick Migration from Microsoft still has some flaws. First, the 6 seconds you quote is probably doable with an idle VM and 512 MB of memory. The quickest I&#8217;ve ever seen it is 8 seconds but now I&#8217;m just splitting hairs so let&#8217;s say 6 seconds. The average TCP Abort Connection time in a 10/100 network is 5 seconds. In GigE networks it&#8217;s less (around 3 seconds). This means if the network connection is gone for over 5 seconds (which it is with Quick Migration) then anything using TCP has to re-establish a new connection. For some apps that&#8217;s fine. For most apps that&#8217;s bad. File copies stop. Outlook goes into offline mode. SQL ODBC connections drop and have to be manually re-established. It&#8217;s bad. So bad that Systems Center Virtual Machine Manager throws up a nice warning box before you migrate a VM that tells you all users will be disconnected from the VM&#8230;.do you want to continue? Bottom line is Quick Migration might be good enough for someone who has never experienced moving live from any other vendor in the industry.</p>
<p>3) Quick Migration has just as many requirements as live migration/VMotion. If you suspend a VM that&#8217;s using SSE4 and migrate it and resume it on a host that does not support SSE4 then you will get a blue screen. That&#8217;s one small example. This is why everyone requires like family and like brand of CPU. Microsoft may not write that down like everyone else but that doesn&#8217;t prevent the issues from coming up. Maybe this is why they haven&#8217;t implemented live migration yet &#8211; they don&#8217;t understand virtualization.</p>
<p>I would absolutely agree that the value in virtualization is what goes on top of it. VMotion/live migration is simply an enabler. A previous comment highlighted that with DRS as a good that that VMotion has enabled.</p>
<p>For those that think Quick Migration is &#8220;good enough&#8221; and happen to be using VMware I showed off a PowerShell script that will allow Quick Migration in a VMware environment during one of my sessions at VMworld. I&#8217;ll be posting the source and instructions to my blog shortly. <a href="http://mikedatl.typepad.com" rel="nofollow">http://mikedatl.typepad.com</a>. Maybe that will take this conversation off the table and let us get back to the value adds on top of the infrastructure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: E.J. Gregory</title>
		<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/comment-page-1/#comment-48</link>
		<dc:creator>E.J. Gregory</dc:creator>
		<pubDate>Fri, 26 Sep 2008 14:58:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.tripwire.com/blog/?p=160#comment-48</guid>
		<description>Quote

&quot;VMotion is definitely ahead of Live Migration from a technical standpoint, and VMotion will get even more powerful with IntelÃ¢â‚¬â„¢s next generation of processors that remove some of the restrictions on what can be VMotioned.&quot;

This refers to Intel &quot;flexmigration&quot; which is present in currently shipping 45nm processors and future processors. This feature allows backward compatibility with all Core2 Xeons (the ones we have been buying for the last few years). VMware&#039;s implementation of this feature is called &quot;Enhanced Vmotion&quot; and also supports the equivalent functionality in AMD processors. Basically, this IS NOT a future technology. It is available today (currently shipping products) in both Intel/Amd hardware as well as VMware&#039;s software.</description>
		<content:encoded><![CDATA[<p>Quote</p>
<p>&#8220;VMotion is definitely ahead of Live Migration from a technical standpoint, and VMotion will get even more powerful with IntelÃ¢â‚¬â„¢s next generation of processors that remove some of the restrictions on what can be VMotioned.&#8221;</p>
<p>This refers to Intel &#8220;flexmigration&#8221; which is present in currently shipping 45nm processors and future processors. This feature allows backward compatibility with all Core2 Xeons (the ones we have been buying for the last few years). VMware&#8217;s implementation of this feature is called &#8220;Enhanced Vmotion&#8221; and also supports the equivalent functionality in AMD processors. Basically, this IS NOT a future technology. It is available today (currently shipping products) in both Intel/Amd hardware as well as VMware&#8217;s software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dwayne Melancon</title>
		<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/comment-page-1/#comment-46</link>
		<dc:creator>Dwayne Melancon</dc:creator>
		<pubDate>Thu, 25 Sep 2008 17:28:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.tripwire.com/blog/?p=160#comment-46</guid>
		<description>Thanks, Joel - I am not questioning the power of VMotion - just saying that I think this battle will ultimately be won &amp; lost based on more than just VMotion vs. Live Migration.

VMotion is definitely ahead of Live Migration from a technical standpoint, and VMotion will get even more powerful with Intel&#039;s next generation of processors that remove some of the restrictions on what can be VMotioned.

Aside from the &quot;real time&quot; migration, it&#039;s my observation that the load balancing capabilities of both platforms are substantially the same.

And I&#039;ll grant you that there are other things (like VMware&#039;s memory overcommit capability) that give VMware the *technical* edge.

But I was around when OS/2 was technically superior to Windows (and I used OS/2 then), and I know that technical superiority doesn&#039;t always guarantee long-term triumph for the hearts &amp; minds of buyers.

BTW, I&#039;m watching VMware&#039;s new management initiative closely, to see what comes of it - I think that initiative, plus Maritz&#039;s more market-focused approach, is where the excitement will happen - and where VMware can launch an assault on MSFT in the battle for business value.</description>
		<content:encoded><![CDATA[<p>Thanks, Joel &#8211; I am not questioning the power of VMotion &#8211; just saying that I think this battle will ultimately be won &#038; lost based on more than just VMotion vs. Live Migration.</p>
<p>VMotion is definitely ahead of Live Migration from a technical standpoint, and VMotion will get even more powerful with Intel&#8217;s next generation of processors that remove some of the restrictions on what can be VMotioned.</p>
<p>Aside from the &#8220;real time&#8221; migration, it&#8217;s my observation that the load balancing capabilities of both platforms are substantially the same.</p>
<p>And I&#8217;ll grant you that there are other things (like VMware&#8217;s memory overcommit capability) that give VMware the *technical* edge.</p>
<p>But I was around when OS/2 was technically superior to Windows (and I used OS/2 then), and I know that technical superiority doesn&#8217;t always guarantee long-term triumph for the hearts &#038; minds of buyers.</p>
<p>BTW, I&#8217;m watching VMware&#8217;s new management initiative closely, to see what comes of it &#8211; I think that initiative, plus Maritz&#8217;s more market-focused approach, is where the excitement will happen &#8211; and where VMware can launch an assault on MSFT in the battle for business value.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel</title>
		<link>http://www.tripwire.com/state-of-security/off-topic/motional-reactions/comment-page-1/#comment-45</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Thu, 25 Sep 2008 16:57:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.tripwire.com/blog/?p=160#comment-45</guid>
		<description>I think you are going in the wrong direction here.
The power of vMotion is well known among all the VmWare administrators out there and they could not live without it.

Another aspect of this is the loadbalancing (DRS in vmware-speak) what will hyper-v do when there are two VM:s on the same host that requires a lot of processor and memory? They will have to share the capacity of that one host when there are plenty of capacity on the other hyper-v hosts standing next to it..</description>
		<content:encoded><![CDATA[<p>I think you are going in the wrong direction here.<br />
The power of vMotion is well known among all the VmWare administrators out there and they could not live without it.</p>
<p>Another aspect of this is the loadbalancing (DRS in vmware-speak) what will hyper-v do when there are two VM:s on the same host that requires a lot of processor and memory? They will have to share the capacity of that one host when there are plenty of capacity on the other hyper-v hosts standing next to it..</p>
]]></content:encoded>
	</item>
</channel>
</rss>

