Virtualization is an amazing and valuable tool for so many reasons. I’ve been a proponent of the concept since GSX server, and early Workstation products. In the early days, I used to use it as a fresh image to load on a workstation for a development crew who required a pristine testing environment for a specific environment. When their code inevitably blew up the image, all we did was recreate that test machine OS with the existing image already located on that machine.

vMotion was a huge plus for us. We created a POC for a large soft drink company wherein we had two hosts vMotioning a file-server every 30 minutes for 2 weeks. When we arrived back in to discuss the viability of vMotion, they’d experienced no headache, and were not even yet aware that we’d done anything. When we showed the logs of the vMotion taking place 48 times a day for two weeks, they were completely convinced.

Things have only gotten better, with additional capacities in terms of disc size, processor capacities and amount of RAM that could be added to an individual machine. Fault tolerance, DRS, and many other technologies have taken away any doubt that most any X86 platform app is a viable target for the virtual world.

But, are there circumstances wherein a device should NOT be virtualized? Perish the thought!

I can envision only a few cases.

For example, one might say that a machine that requires all the resources that a host might have to offer shouldn’t be virtualized. I still say though, that in this case, a VM is preferable to a physical machine. Backup and recovery is easier, uptime can be far more viable, in that DRS allows the movement of the virtual machine off the host and onto another one for hardware maintenance, etc. However, licensing may just find this unacceptable. When you’ve an ELA in place, and can virtualize as much as you want, this actually does become a great solution.

Maybe, in another case, the application hosted on that server is not approved by the vendor? Well, it’s my experience that the OS is the key, and while the app may not have approval by the creator, but testing often makes that a non-issue. However, there may be circumstances wherein the app is tied to a physical hardware entity, and the process of virtualizing it makes it truly not function. I would call this poor application development, but these things are often hard to get around. Another similar case here is when, as in many older apps, the server requires a hardware dongle, or serialized device connected to a physical port on the server. These create challenges, which often can be overcome with the assistance of the company who created the app.

I would posit that in some cases, when a VM relies on a time-sync specific concerns may pose an issue. An example of this machine is a Radius or RSA Server device, in which the connecting device must sync with the connection device as part of its remote access. Assuming that you’ve configured all hosts to connect to an authoritative NTP source, and connection to this is both consistent and redundant, there still exists some small possibility of a time drift. Most importantly, one must be aware of this issue and ensure all efforts to resolve it have been made before virtualizing that server.

And, finally, operating system interoperability. I recently, and remember this is the latter half of 2015, had a customer ask me to virtualize their OpenVMS server. It’s generally not an X86 Operating system, as, for example, OpenSolaris is a port of the original Risc based OS to be able to run on X86. This may be virtualized, but OpenVMS is still a proprietary hardware reliant OS, and thus is, as well as some but few others cannot virtualize into X86 architectures. I am aware that there is a way to virtualize this, but the tech on the Hypervisor is not at all standard.

Generally, any X86 based operating system, or application today is fair game. While we’ll be unlikely to achieve 100% Virtualization Nirvana anytime soon, but, believe me, there are benefits beyond the obvious to ensuring that an application resides within a virtual environment.