This link VMware Virtualization seems to be saying that running a virtual machine and spreading your applications between OS's is more efficient than otherwise. How can this be true? Doesn't a VM defeat the ability of the main OS to do its job unless it has its memory partitioned off like a normal application to be managed? Regardless, how could it possibly improve anything?

  • 2
    I think your and my failure to accept their writings stem from VMWare having this odd idea that a CPU which isn't flogged to death is inefficient. Many of us don't define efficiency that way. Sep 11 '09 at 23:12

This link VMware Virtualization seems to be saying that running a virtual machine and spreading your applications between OS's is more efficient than otherwise. How can this be true?

It's true because, if you look closely at most servers (but not all)...you'll see they are idle. Those are idle resources that are doing nothing other than costing money from electricity being used to keep the server idle.

If, however, you have underutilized hardware, you could maybe get a bit more out of it by increasing its workload. What's that I hear? You have both Windows and Linux workloads? Maybe an OS X workload too? Oh well, I guess you can only choose one class of workload - the one that is supported by the host OS - and the others are just out of luck.

Virtualization changes all of that. Now it doesn't matter what the OS environment is, it only matters that the hardware can accomodate the workload.

Doesn't a VM defeat the ability of the main OS to do it's job unless it has it's memory partitioned off like a normal application to be managed?

The purpose of the main OS at this point is just to service the guests. Come on now, you know as well as I do that the host should always provide a pleasant experience for their guests, right? ;) It's the same idea with VM's - the host is just there to shuttle I/O around and keep the guests from getting too unruly. It's up to the guests to get the gruntwork done.

Regardless, how could it possibly improve anything?

It improves it in the same sense that Mainframe LPARs have been around for a long, long time for roughly the same reason - it solves a class of problems that are frequently encountered. Even Sun thought it was a good idea "back in the day".

Here's what you might encounter:

  • the requirement to reboot a machine to satisfy one requirement, but rebooting would affect other requirements adversely (two services running on the same OS, one of which needs to keep running but the other requires a reboot - what do you do?) With VMs, you can segregate services in an independent fashion, which isolates them from each other in a very controlled way.
  • allocation of resources tends to be a fairly static situation with non-virtual setups. This changes dramatically when running a VM - now you can alter the amount of available memory, add storage, etc. with little impact.
  • you need to migrate a workload that's active from one server to another without the workload going down. How do you do that on a live setup? With VMs there are enterprise tools that migrate running setups in-place, resulting in no downtime. Very handy for upgrading or fixing hardware.
  • compatibility issues between software installs can cause nightmares. Separate VMs for each install resolves the issue completely (thanks to hurikhan77 for mentioning that one)

Not really. Some applications don't behave well when sharing with other applications. Exchange, for example, expects you to run Exchange on just the box, and installing anything else on it can have...consequences.

Other times it's easier for management since you compartmentalize functions. Your web server isn't sharing duties with your file server, or if you need to move or upgrade that one function then it doesn't impact other services or have unintended side effects.

Other times it's good for pushing "native" solutions. Your one machine can run Apache for web services on Linux and Exchange on Windows and another running SQL server (or MySQL) on the platform most native for that application without having to invest in multiple physical boxes.

Best, though, is that you can get snapshots and backups of the system state easily using a VM solution. If you need to you can set up another VM system (ESXi, for example) copy the virtual drives and setup to that computer and point VMWare to that copied "machine" and fire it up while the other machine is being repaired (or pay for the vMotion option so you can live migrate between physical machines); this increases availability and helps with maintenance chores. It's great to be able to upgrade hardware without worrying about unintended effects on the operating system or configuration of your applications since they're "virtual" and know nothing about the changes!

VMWare has saved us quite a bit on the electric and cooling bills for the server room and I'm using Virtualbox to emulate a machine to run Windows for managing certain functions of AD and run the VSphere client on my Linux machine. Last, it's wonderful for testing things. I don't need to create a new machine from the back room to test a forum server or test out an installation of an application. I just create a new virtual machine and fire it up.

The rediscovery of VM technology is one of the best things for the IT industry in a long time...ironically...

Is there something more particular you're wondering about?

  • 1
    +1 for mentioning the environmental issues (cooling, electricity) - it's cost factor, too, which is often underestimated. Besides: Green IT is cool today... ;-)
    – hurikhan77
    Sep 11 '09 at 22:53
  • Could you provide a bit more details about the issues of MS Exchange? Sep 16 '09 at 0:47
  • I remember Joel Spolsky on SO Podcast saying that Exchange assumes it is the only thing on the box and steals resources; I've also read cases where MS will not support or hesitate to support Exchange + other applications. I've had MSCE's cringe when I told them I had Outlook running on an Exchange box. If you're testing your deployment, try running the best practices tool to see how your server(s) stack up: msexchangeteam.com/archive/2004/09/21/232516.aspx Sep 16 '09 at 11:55

The VM host can distribute cpu usage, harddisk usage and memory usage based on predefined workload patterns. The whole point is that you usually buy a very strong machine to keep up with the peak of your application usage but most of the time it may sit there doing almost nothing and waste valuable free performance. So just spend a few bucks more for a real fat machine and combine your machines into one. It's about consolidating resources. To still guarantee the performance of your workload patterns you can set time shares and io shares for each guest machine and prioritize them to guarentee performance.

Migrating to new hardware is also easy: Dump the image of the machine and upload it to a new. It will still run and work without fiddling with drivers issues or reinstallations or data migrations.

Another big plus point is that some services installed concurrently in the same OS instance aren't very well behaving together - eg MSSQL and Exchange. It's good to limit both in their own OS instance and instead let a hypervisor distribute the service demands. You usually get a better performance and migrating to new hardware later is just a matter of "copy & paste".

  • +1 for mention of compatibility issues. That's one of those "we don't talk about the elephant in the room" issues that people overlook frequently, even when products are from the same vendor (such as your Microsoft example). Sep 11 '09 at 22:38
  • Yep we just deployed an MSSQL + Exchange setup today - and it feels amazingly fast using VMware while both services were struggling for every bit of free RAM and tried to claim that if installed in the same OS instance (as Windows SBS does). Also migrating machines from the staging VM to the live VM in the server room is a big big timesaver. You don't need to allocate resource from existing servers or even do harm to them by doing so.
    – hurikhan77
    Sep 11 '09 at 22:58
  • BTW: The same applies to MySQL + Apache/PHP. We are currently splitting our services from bundled to specialized machine instances optimized for each workload pattern - and the performance gain was really surprising.
    – hurikhan77
    Sep 11 '09 at 23:02

VMWare sales and marketing people will tell you lots of wonderful and amazing things. There are some certain benefits, but beware of being totally sucked in. Especially beware of anything relating to your free CPU and memory load, as there always seems to me to be a failure to recognise that free CPU and memory is headroom for transient heavy load conditions.

  • 1
    Very true. It depends on the workload that will exist on the server. I have seen machines that clearly need a little boost in the CPU dept. and transient load conditions factor into that. I've also seen machines that idle 95% of the time because they do timed workloads with no requirement for a time-to-complete (automatic downloads, etc.) that are prime candidates. +1 for "it all depends". Sep 12 '09 at 0:06
  • I don't know about getting sucked in, so to speak...the one nice thing is that you can dip your toes in to test some of the waters. Maybe not vmotion easily...I never try a paid-for app with a timeout if I don't know for sure I can afford to pay once I do come to rely on a feature. But something like ESXi is totally free and lets you test virtual machine configurations with minimal hassle. You really have nothing but time to lose in testing it out. We removed seven servers from the rack using ESXi; that's significant power and cooling there, saved on the UPS as well. Sep 12 '09 at 0:28
  • I'll also add that since moving to vSphere to monitor VM's, I've found it very easy to find certain anomalies in machine behavior. It's like having physical machines with CPU/memory/disk i/o graphed on the side of the case, viewed from the outside in. I never thought our printer server was having heavy spikes in processor or memory; turns out some stupid company-proprietary app is polling certain printers periodically and spiking everything way more than it needs to. Never would have caught it without watching vSphere stats. Sep 12 '09 at 0:30
  • I concur - the virtualization bandwagon is full of misinformation and over-promising. I rarely see a need for virtualization unless it is used to solve a high availability problem or to rapidly roll out new and nearly identical server configurations. I have found most tools on Linux to inter-operate just fine without requiring segregation at the OS level. If you have two apps running on a server with 4GB of RAM, those apps may very well make better use of the resources than spread out over two VMs with 2 GB each, especially if they are complementary in their resource usage. Sep 12 '09 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.