Apply today for a FREE subscription to CIO Magazine!
Tue, Feb 12, 2008 14:49 EST
|
Posted by: Laurianne McLaughlin in Best Practices Topic: InfrastructureBlog: Inside Tech
Current Rating: |
What are the management risks and problems hiding inside your virtualization effort? That's a question that David Lynch, VP of marketing for Embotics, tries to help IT groups answer. Embotics, part of CIO's recent list of 10 virtualization vendors to watch, provides what it calls VM lifecycle management. The company's V-Commander software (which integrates with VMware's VirtualCenter management suite) promises to help you track VMs from cradle to grave. The tool lets IT groups apply policies and automation to that tagging and tracking work.
Lynch recently shared with me a top 10 list that his staff uses when it meets with IT leaders to discuss common management risks and problems with virtualization. The list reflects actual problems that Embotics has found while helping multiple customers audit and secure virtualized server environments.
I find this list thought-provoking, realistic and worth sharing. Check out the below questions and ask yourself: Could any of these problems be hiding in my virtualized environment?
As for how these problems arose in the first place, virtualization bubbled up from a few people in the server or application development group at many companies, instead of being planned top down from the CIO. Then virtualization spread quickly, and spread further into the production IT environment, because IT and business teams liked the results. As that spread continues, IT finds itself now having to step back and get more formal about managing virtualization, to avoid management complexity and security risks.
"Most of our customers have been very busy operationally," Lynch says, "now they are starting to have to deal with issues of control."
Now, on to Embotics' top 10 list of potential troublemakers lurking in virtualized environments:
1. Rogue VMs
How tightly do you control who can create a virtual machine? It's a key security question. When you fire up inactive or suspicious VMs, you may find more than you expect. One Embotics customer fired up an offline VM to confirm what it was, and found a DHCP server which took down the production network, Lynch says.
2. Unpatched VMs
Remember, users can run VMs on their own PCs using downloadable software from VMware's website, for example. Audit all of your company's machines for such VMs and you may find what Embotics customers have, Lynch says: Unauthorized operating systems and a lack of security patches on those VMs.
3. VM Naming Messes
As you track all the VMs in your company, logical names will be helpful. But chances are, IT pros throughout your organization started naming VMs long before you realized how far virtualization would spread, long before anyone thought about imposing a naming system. Think about naming conventions now, Lynch advises.
4. Production Environment Border Problems
Most IT organizations run pre-production VMs (say for application development work, or
As always, speaking from an admittedly biased view (4+ years at VMware, 1.5 at Scalent), 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)?
thanks for bringing that up. agreed, IT must keep up physical security that houses virtual infrastructure. Your fish tank analogy is a good one. What do you see as the key mistakes or things that get overlooked now with regards to network, storage, plumbing, etc.?
Maybe we should get together and write another article on this topic, as these "reply" blog areas are a bit small...
Bias warning: I believe in the following -- which is why I work at Scalent, whose product solves the issues. That said, they are general problems.
My quick answer to "Got (Server) Virtualization, Now What?" is:
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 (unless running Scalent ;)
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?
That's a start...
- K
These risks is seem pragmatic but only focused on technology issues. How do you deal with these issues organizationally with process and policy? Especially when you think of a VM's that exist outside the data center (which is where you will likely run into issues like virtual appliances and rogue VM's). I've been following some of the startups (embotics, fortisphere, manageiq, etc) and VMware (with stage manager, lifecycle manager, lab manager) and they seem to have similar messaging on this issue. Is this issue going to take multiple products?