We once received an e-mail a while back asking if a specific vendor’s product supported virtualization. We quickly responded “No,” and we soon received a second e-mail telling us that we were wrong. We politely inquired just how virtualization could be supported, and we were told that it could occur through treating the virtual machine as just another client.
Of course, this is technically true. In fact, it works fine as long as there’s relatively little load on the host (physical) system and on the virtual machines (i.e., the guest instances) executing on the host system. There are also times that this approach is clearly the superior one based on the customer’s situation and goals.
Did you notice that phrase “…the customer’s situations and goals?” It’s pretty important here – because if you’re focusing only on your vendor’s goals, you’re going to end up being the puppet. How you support virtualization has to be the result of what the customer’s needs are – both at the time of purchase and in the future.
For example, vendors that advertise 15-minute snapshots and say that they support virtualization only via an agent in the host and guest operating system don’t tell you that they’re going to grind your system to an absolute halt due to the load placed on the system with just one or two virtual machines. Vendors that tell you to use this approach on a heavily loaded system aren’t telling you that you’re pouring gas on the fire in terms of compute, storage, and networking contention.
The support of virtualization means that you offer both simple solutions, such as agents in virtual machines, but it also means that your backup solution can scale to handle different approaches as the customer’s virtual infrastructure grows. These different approaches range from native VCM (VMware Control Block) types of solutions to interoperability with third-party backup solutions designed specifically for virtualization (e.g., Vizioncore, esXpress, and so on).