Lately, I’ve been on phone calls with several companies to discuss whether they should run their applications on virtual machines or physical machines. Typically, some user or software person has been told the plan is to run their application on a virtual machine. They believe their application is “so special” and will not work properly if it runs on a virtual machine. In general, the concerns are:
- Vendor Support
To be frank, when possible, I don’t tell users if the machine is virtual or physical. I’m not hiding this, but I don’t volunteer non-relevant information. Part of planning an application has to do with the sizing of the production environment. You read the system requirements and prepare the infrastructure accordingly. The application requirements usually state memory, cpu and OS requirements. They don’t state that you must run the system on a Dell PowerEdge 2950 with dual Intel(R) XEON(R) E5420 @ 2.5 GHz quadcore cpus using “blue” network cables. Part of planning the application is taking the vendor’s information and adjusting it to account for your own infrastructure. Many companies run standard infrastructure such as: SNMP, VIRUS/MalWare protection and Systems Management software on all of their systems. They must account for this in terms of cpu and memory when sizing for a new application. Virtualization is “just” one more variable in the planning and sizing equation. Therefore informing the user that the machine is virtual is simply non-relevant.
- I’ve been told that at Cisco all new systems are virtual and you must convince John Chambers, the current CEO, to allow you to use a physical machine.
Many vendors have confusing support policies regarding virtual machines. I know of one vendor that does all of their development, testing and qa on virtual machines and then does not support running production on virtual machines.
In my mind, vendor support is an academic issue. I don’t volunteer the physical machine information to a vendor, so why would I volunteer hardware info about a virtual machine. If a vendor presses the issue, I can always reproduce the issue on a physical machine. To Date: I have never had to reproduce the issue on physical hardware.
Keep in mind that all major software vendors plan to support “Cloud Computing”. You can’t seriously support “Cloud Computing” without supporting virtualization. So if your vendor does not support virtual machines, they will begin to shortly or they will face technical obsolescence.
To be honest when it comes to performance, virtualization is your friend. That may come as a shock to you, so I’d better explain.
As I mentioned earlier, part of planning an application is sizing it for production. The sizing takes into account factors such as: memory, # of cpus, minimum recommended cpu speed, the number of concurrent users, the overhead of your common infrastructure and a “judgment factor”. The “judgment factor” attempts to account for business growth, typical usage patterns and historical vendor understatement of the hardware requirements :-). Over the years, I’ve seen many projects purchase way too much hardware. I’ve also seen projects that were struggling to run on the initial hardware within a year or two of the initial roll-out. This can be caused by a variety of reasons, including unexpected business growth or transaction volume due to a temporary business opportunity. Assuming that there are no application locking issues and that cpu or memory is holding the application back, then you are considering how to relocate the application to newer and more powerful hardware. When this happens physical machines become a “boat anchor” where virtual machines are a “lifeboat”.
- Why Physical machines become a “boat anchor”.
It is often difficult and sometimes impossible to move an existing application to new hardware. In the best case scenario, you have to procure new hardware, install and configure the operating system,OS, “clone” the application to the new hardware, test the application to ensure the configuration is working correctly and then plan an outage to relocate the application permanently to the new hardware. This is at best a several week project. There can be some show stoppers. You may not be able to relocate the current version of the application, if you must use a later version of an operating system. This can often be the case with new hardware in order to obtain the necessary drivers. Now, you are potentially having to update your entire software stack as well as the application to run on a later version of the OS. You will probably have to retrain users on the new version of the application.
What a nightmare!
By the time you are done, you may have missed any temporary business opportunity or the business growth may have been impeded.
- Why virtual machines are a “lifeboat”.
When you outgrow the virtual machine, you can allocate or dedicate more hardware to the virtual machine. If new hardware is required, then you simply migrate the virtual machine to the new hardware, intact. Often this migration can be performed live. Yes, it can be that simple. If you can’t perform a live migration, then an outage to copy the virtual machine from the old system to the new system will be required.
With virtual machines, you really can throw hardware a some performance problems.
There are cases where you still need to use physical machines, but these are uncommon. In my opinion, you should always use virtual machines first and then determine that you really need dedicated physical machine.
If after all of this, your user still insists on having a physical machine, then are they also insisting that all programs be written in assembly language?