Telematique, water and fire.

Virtualization Risk and the Fishtank

I missed this article in CIO (Top Ten Virtualization Risks Hiding in Your Company) when it was published about a month ago. After running through a believable list, I looked at one of the comments and couldn't help but smile:

... I think the comments above missed risk #11, the physical world outside any hypervisor host.

All hypervisors still depend on underlying physical machines being correctly connected to network and storage -- in multiple paths, to allow access for all VMs correctly.

In other words, all the above article comments apply to moving around the virtual machine "fish" inside the hypervisor OS "fishtank" -- but who moves and manages the associated fishtanks (with associated network & storage I/O plumbing etc)?

Kevin Epstein (of Scalent) then goes on to set out a number of additional problems, and although he makes sure to inform the reader that (in his opinion) Scalent solves these problems, I have to agree with the problem identification (if not completely with his solution):

1. Network connectivity matters
All hypervisor hosts in a group or "cluster" who are going to share virtual machines -must- share a LAN subnet.

2. Storage access matters
All hypervisor hosts in a group or "cluster" who are going to share virtual machines -must- share storage access.

3. Hardware failover must be anticipated
VMs will fail to another clustered hypervisor... if, and only if, one exists and has cycles! (See point 1 and 2)

4. Movement between Physical and Virtual (and back, repeatedly) is a necessity in real data centers, and is -not- usually seamless ...

5. Non-x86 Hardware
Not all hardware is x86! Sun now has LDOMs, AIX too, how to manage workloads between those and the rest of the virtual universe?

VMsafe and the Network Stack

Gabe has collected information from various sources about VMware's VMsafe API. The post makes clear VMware's approach to "opening up" access to the hypervisor for third-party security products provided by carefully vetted partners. In a comment to the post, the reader is pointed to VMCI as a the means by which VMsafe gains access to memory and other hypervisor resources. Gabe then makes this rather telling response:

I’m missing the network stack in this, because I read that the network virtual switches can also be monitored with VMsafe. I’m wondering if for example McAfee can build an appliance that does some kind of virus scanning, checkpoint builds a network inspection appliance, etc. You would then have multiple security appliances per host. Not sure if this is what is desired.

Is this the case? Does VMsafe offer up access of this kind to the vswitch? Does that mean that the as-yet-unannounced, but rumored third-party virtual distributed switch would offer up the same access through VMsafe?

Adjusting the risk/reward dial.

Running a small (... OK, Oren... tiny) startup means that during the week I run windsprints.  On Saturday mornings, catching up on Google Reader (1000+), I get to stroll leisurely through the RSS, while (in the background) all my machines backup to the NAS.

Reading this reminds me of the times I've thrown my lot in with a bare-metal startup. The post mentions serendipitous moments, and I can attest to the fact that you'll never encounter more of them than while doing a startup. It's one of the great pleasures. 

All stages of a company have benefits.  I continue to be most thrilled, enjoyably challenged, and most engaged at this stage.  This is the phase in which I learn most, and for which I have the warmest memories.  Wecome, Oren.

Link: Ontic Oren � Modifying my own risk/reward.