Comments on: The Emotion of VMotion… http://www.rationalsurvivability.com/blog/?p=1391 Hoff's Ramblings about Information Survivability, Information Centricity, Risk Management and Disruptive Innovation. Oh, I have a fondness for virtualization and cloud computing security, too... Thu, 09 Sep 2010 02:54:50 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Ready for Just in Time IT? « ARCHIMEDIUS http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21862 Ready for Just in Time IT? « ARCHIMEDIUS Wed, 30 Sep 2009 23:11:50 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21862 [...] One’s natural inclination is then to ask: If this is so powerful then why aren’t most IT departments doing it?  Hoff a few days later discusses the technical hurdles to true VMotion in The Emotion of VMotion: [...] [...] One’s natural inclination is then to ask: If this is so powerful then why aren’t most IT departments doing it?  Hoff a few days later discusses the technical hurdles to true VMotion in The Emotion of VMotion: [...]

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Mark Cathcart http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21591 Mark Cathcart Tue, 29 Sep 2009 21:14:53 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21591 Ahh, now here's a subject close to my heart. Having come from IBM Power Systems where mobility was a big deal EXACTLY because you were running one honking great big physical server with potentially hundreds of virtual servers(really!) to Dell where its most normal x86 style workloads, I've been asking myself exactly this lately. What problem is vmotion trying to solve? It's another layer of complexity, which brings a layer of automation and complexity on top of it in order to make it work, to solve what? Generally application availability issues. First up x86 business class servers are no longer the keep failing, OS is full of bugs, that they once were. Both Windows and Linux have contributed to this, as has VMWare. Secondly, all the vendors have had to focus on quality of components and design, much more than they used to. Secondly, both in the open source and proprietary application lkandscape, software has significantly settled down and there is less churn. While its true that most commercial and open source software is on a drum beat of new releases every 12-15 months, users are less and less likely to install them. What they have mostly works and the new features are often less and less compelling. Result? Platform stability. Where the platform is stable and not failing all the time it becomes more and more interesting to look at workload distribution, equalizing workloads etc. Cloud has become more important in this space, and vMotion is really relatively uninteresting since it only allows you to move the whole workload either to another server, or to the cloud(notionally). Given it introduces a level of complexity that is not really giving anything else except the ability to move a whole VM, I think it won't be long before many users wake up and say they don't need it, or that it's just the emperors new clothes, another way for IT to sell their services. I'm going to reply to your Virtual Machines are the problem post via a trackback on my own blog. Ahh, now here’s a subject close to my heart. Having come from IBM Power Systems where mobility was a big deal EXACTLY because you were running one honking great big physical server with potentially hundreds of virtual servers(really!) to Dell where its most normal x86 style workloads, I’ve been asking myself exactly this lately. What problem is vmotion trying to solve? It’s another layer of complexity, which brings a layer of automation and complexity on top of it in order to make it work, to solve what? Generally application availability issues.

First up x86 business class servers are no longer the keep failing, OS is full of bugs, that they once were. Both Windows and Linux have contributed to this, as has VMWare. Secondly, all the vendors have had to focus on quality of components and design, much more than they used to.

Secondly, both in the open source and proprietary application lkandscape, software has significantly settled down and there is less churn. While its true that most commercial and open source software is on a drum beat of new releases every 12-15 months, users are less and less likely to install them. What they have mostly works and the new features are often less and less compelling.

Result? Platform stability. Where the platform is stable and not failing all the time it becomes more and more interesting to look at workload distribution, equalizing workloads etc. Cloud has become more important in this space, and vMotion is really relatively uninteresting since it only allows you to move the whole workload either to another server, or to the cloud(notionally). Given it introduces a level of complexity that is not really giving anything else except the ability to move a whole VM, I think it won’t be long before many users wake up and say they don’t need it, or that it’s just the emperors new clothes, another way for IT to sell their services.

I’m going to reply to your Virtual Machines are the problem post via a trackback on my own blog.

Like or Dislike: Thumb up 2 Thumb down 0

]]> By: DC http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21542 DC Tue, 29 Sep 2009 17:28:29 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21542 Our customers tend to use vMotion in most deployments, even small ones. The reason for this is a bit ridiculous, in that the single largest driving factor behind purchasing the vMotion license is the need to be able to *patch* the ESX hosts without downtime. Basically to patch you need the ESX hosts to be in maintenance mode, which means vacating VM's. Which means downtime, unless you've got vMotion. It's a sad state of affairs when the only business case for buying fancy live migration capability is the need to resolve security and other issues in the host OS. Our customers tend to use vMotion in most deployments, even small ones. The reason for this is a bit ridiculous, in that the single largest driving factor behind purchasing the vMotion license is the need to be able to *patch* the ESX hosts without downtime.

Basically to patch you need the ESX hosts to be in maintenance mode, which means vacating VM’s. Which means downtime, unless you’ve got vMotion.

It’s a sad state of affairs when the only business case for buying fancy live migration capability is the need to resolve security and other issues in the host OS.

Like or Dislike: Thumb up 2 Thumb down 1

]]> By: Christofer Hoff http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21532 Christofer Hoff Tue, 29 Sep 2009 15:48:30 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21532 <blockquote cite="#commentbody-21526"> <strong><a href="#comment-21526" rel="nofollow">Matt Simmons</a> :</strong> VMotion is designed to allow reliability of a particular machine. What we should be concentrating on is <a href="http://www.standalone-sysadmin.com/blog/2009/09/modern-uptime-measured-from-the-outside-in/" rel="nofollow">reliability of the service</a>, and truly reliable infrastructure will tolerate the loss of a machine. </blockquote> TOTALLY! VM's are (I hope) the first level of reasonable abstraction that will allow us to once again focus on what service oriented architectures were supposed to deliver -- SERVICES. /Hoff

Matt Simmons :
VMotion is designed to allow reliability of a particular machine. What we should be concentrating on is reliability of the service, and truly reliable infrastructure will tolerate the loss of a machine.

TOTALLY! VM’s are (I hope) the first level of reasonable abstraction that will allow us to once again focus on what service oriented architectures were supposed to deliver — SERVICES.

/Hoff

Like or Dislike: Thumb up 1 Thumb down 0

]]> By: Matt Simmons http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21526 Matt Simmons Tue, 29 Sep 2009 15:32:01 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21526 The underlying reason for vmotion and the like are increased availability. "Availability of what" should be the question. VMotion is designed to allow reliability of a particular machine. What we should be concentrating on is <a href="http://www.standalone-sysadmin.com/blog/2009/09/modern-uptime-measured-from-the-outside-in/" rel="nofollow">reliability of the service</a>, and truly reliable infrastructure will tolerate the loss of a machine.

The underlying reason for vmotion and the like are increased availability. “Availability of what” should be the question.

VMotion is designed to allow reliability of a particular machine. What we should be concentrating on is reliability of the service, and truly reliable infrastructure will tolerate the loss of a machine.

Well-loved. Like or Dislike: Thumb up 6 Thumb down 1

]]> By: carl http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21523 carl Tue, 29 Sep 2009 15:24:35 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21523 <a href="#comment-21518" rel="nofollow">@Sam Johnston </a> Depends on the the jumping-off point, no? I talked to an ISV a few months ago that can wrap up a full-featured LAMP stack in 30MB and run your web app. They claimed they could get WinServ2003 down to about 600MB, which would be the other end of things. But who cares if it that's too drastic? Need more? Start over, drop your instance, pull up the bigger one, its not a big deal. Design considerations and implementation of such can now be done in hours, not weeks. Anyone planning for a product/app stack in the cloud can do it how ever they like, and fix it whenever they like. that's where i see really interesting changes in how people work. More to the larger point, who cares? plenty of cloud to go around, right? Its all free, endless and awesome, no? ;) @Sam Johnston

Depends on the the jumping-off point, no? I talked to an ISV a few months ago that can wrap up a full-featured LAMP stack in 30MB and run your web app. They claimed they could get WinServ2003 down to about 600MB, which would be the other end of things.

But who cares if it that’s too drastic? Need more? Start over, drop your instance, pull up the bigger one, its not a big deal. Design considerations and implementation of such can now be done in hours, not weeks. Anyone planning for a product/app stack in the cloud can do it how ever they like, and fix it whenever they like. that’s where i see really interesting changes in how people work.

More to the larger point, who cares? plenty of cloud to go around, right? Its all free, endless and awesome, no? ;)

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Sam Johnston http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21518 Sam Johnston Tue, 29 Sep 2009 15:12:19 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21518 Meh, even if you have the kernel and just enough libraries to make your app run you still have a hell of a lot of bloat in there. Worse, much of it is doing funky things to talk to esoteric hardware - the virtual equivalent of which must do funky things in response (think of a read/write passing unnecessarily through IDE!?!). Sure paravirtualisation solves some of that but how many of us are using paravirtualisation (properly) today and even then how much overhead is left? JeOS still sucks (only marginally less than full OS). It's not about the size of the image - if files go unused then they're benign except for taking up space. And if you remove them and later find that you've got NeOS (not enough OS) then you're up the creek without a paddle. Sam Meh, even if you have the kernel and just enough libraries to make your app run you still have a hell of a lot of bloat in there. Worse, much of it is doing funky things to talk to esoteric hardware – the virtual equivalent of which must do funky things in response (think of a read/write passing unnecessarily through IDE!?!). Sure paravirtualisation solves some of that but how many of us are using paravirtualisation (properly) today and even then how much overhead is left?

JeOS still sucks (only marginally less than full OS). It’s not about the size of the image – if files go unused then they’re benign except for taking up space. And if you remove them and later find that you’ve got NeOS (not enough OS) then you’re up the creek without a paddle.

Sam

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: beaker http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21517 beaker Tue, 29 Sep 2009 14:06:27 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21517 <a href="#comment-21516" rel="nofollow">@Steve Todd </a> Great point, Steve. I had wished others had brought that up in the other post, but I think it's a great point. FastScale markets their capability to provide automagic building on-demand JeOS stacks: With patent-pending Application Blueprint™ technology, FastScale Stack Manager can automatically identify the precise operating system dependencies of your application and build a lightweight server with JeOS, on-demand. Configuring your logical server for JeOS results in a server build that is up to 95% smaller utilizing 75% or less system resources. And with fewer system services deployed, lightweight server builds are more secure by design. Application Blueprinting can also be used as an insurance policy against deploying legacy software stacks with missing file dependencies by comparing the server build to an Application Blueprint — missing files can be added with a simple mouse click. ...that is a good thing. I think it is a step in the right direction but we'll have to see how Cloud providers follow suit in their roll-outs to enable this sort of capability. /Hoff @Steve Todd

Great point, Steve. I had wished others had brought that up in the other post, but I think it’s a great point. FastScale markets their capability to provide automagic building on-demand JeOS stacks:

With patent-pending Application Blueprint™ technology, FastScale Stack Manager can automatically identify the precise operating system dependencies of your application and build a lightweight server with JeOS, on-demand. Configuring your logical server for JeOS results in a server build that is up to 95% smaller utilizing 75% or less system resources. And with fewer system services deployed, lightweight server builds are more secure by design. Application Blueprinting can also be used as an insurance policy against deploying legacy software stacks with missing file dependencies by comparing the server build to an Application Blueprint — missing files can be added with a simple mouse click.

…that is a good thing. I think it is a step in the right direction but we’ll have to see how Cloud providers follow suit in their roll-outs to enable this sort of capability.

/Hoff

Like or Dislike: Thumb up 0 Thumb down 0

]]> By: Steve Todd http://www.rationalsurvivability.com/blog/?p=1391&cpage=1#comment-21516 Steve Todd Tue, 29 Sep 2009 13:48:40 +0000 http://www.rationalsurvivability.com/blog/?p=1391#comment-21516 Hoff, Any thoughts on technologies such as FastScale and the potential to reduce VM bloat? Steve Hoff,
Any thoughts on technologies such as FastScale and the potential to reduce VM bloat?
Steve

Like or Dislike: Thumb up 1 Thumb down 0

]]>