How To Increase Your "% Virtualized" Rates

The #VirtualizeDell tweet chat today got me thinking about what stops most virtualization implementations around 50-75%. These are just some thoughts on ways to kick things loose. @LethaW commented “[that some of them are] sneaky and underhanded, and I love it.” I took that as encouragement. Needless to say, your mileage may vary.

Problem: Physical hardware is required or requested by vendors.
Solutions:

• Actually check to make sure that a vendor does require physical hardware. For example, Oracle doesn’t require it for many things, but there’s this misconception out there that they do, and I hear it from DBAs a lot. Consultants will also tell you a wide variety of things, too. Check the facts. Get it in writing.
• Don’t do business with vendors that require physical hardware. Get your purchasing people to adjust their RFP process so that virtual infrastructure support is a requirement.
• Agree, then give them virtual servers anyhow and don’t tell them. Uninstall the VMware Tools if they notice (but put them back on later).*

Problem: App people want physical hardware because “it’s faster” or “it’s just easier.”
Solutions:

• Point out that it’ll be three months before they can have physical hardware (considering the ordering process, shipping, racking, installation, OS configuration, etc.) or three days for a VM.
• Make your chargeback scheme reflective of the additional costs associated with a physical server. If you’re doing it right a physical box should cost the requestor a lot more to operate than a VM.
• Test. Put their stuff in a virtual machine first, then if they can show that they aren’t meeting stated & quantifiable (with numbers) performance goals, and there’s nothing that can be done in the virtual environment to improve performance, then they can have physical hardware. Usually they don’t have quantifiable performance goals so you win.
• Agree, then give them virtual servers anyhow and don’t tell them. Refer to it as a “server” without the physical/virtual label.*

Problem: Physical hardware is “needed” because a vendor’s licensing is way more expensive for a virtual implementation.
Solutions:

• Call the vendor and educate them on how your brand of virtual machines work. I usually have to tell them that a VMware VM doesn’t have access to more than the configured number of vCPUs, so a 2 CPU license on a 2 vCPU VM would be the same as a 2 CPU physical host. Blow their minds by telling them that you can change the number of CPUs in a physical server, too, either by disabling cores in the BIOS or adding additional socketed CPUs after the fact, so there’s no difference between a VM and a physical host in that regard. Use the term “hard partition.”
• Don’t do business with technology vendors who know nothing about technology.
• Don’t tell them it’s a virtual machine. Refer to it as a “server” without the physical/virtual label. Ask for a 1/2/4 CPU license for a physical machine, remind them that you can disable cores if they tell you there’s no such thing as a 1 CPU server anymore, and don’t tell them otherwise.*

Problem: Physical hardware is needed because someone wants to use a custom piece of hardware, like a line card or a licensing dongle.
Solutions:

• Use DirectPath to assign the hardware directly to a VM.
• Use a networked USB hub for dongles, cameras, serial-to-USB adapters, etc.
• See if there’s another alternative that doesn’t require custom hardware. For example, do you really need a line card for your VoIP implementation, or can you just get a SIP trunk from someone?
• A dongle? Really? 1991 called and wants its licensing scheme back so it can party with MAC-based licenses in FlexLM’s basement.
• Custom hardware & DirectPath breaks things like vMotion/HA/etc. Consider just giving them a small physical host so they don’t mess up your whole support & infrastructure patching model. Change your % virtualized numbers to reflect “virtualize-able” apps, so you still have a 100% virtualization rate.*

Feel free to add more stuff in the comments. I always like conversations like this. :)

* Underhanded & sneaky. I take no responsibility for what happens if you use these ideas, but I suggest them wholeheartedly if the right way isn’t working.