Most technology downfalls are technical in nature but with virtualization it's the non-technical aspects that could hinder your success.
There is no denying that virtualizing your production network will shower you with benefits – significant cost savings, streamlined disaster recovery, immediate snapshot functionality – BUT unlike most technology advances it’s NOT the ‘technical gotchas’ that companies need to brace themselves for, it’s the non-technical logistical downfalls that are so devastating. Network security practitioners typically bash virtualization because of the inability to easily ‘police’ data on the wire or preach about how a successful hypervisor attacks will pwn the ESX and ALL its VMs; but the true ‘black plague’ of virtualization is the casual documentation.
In my experience, if you’re in IT…you do everything in your power to evade creating documentation material! The documentation process is commonly viewed as a management punishment, however, virtual environments are so unique that in most cases they warrant separate corporate policies to ensure a smooth implementation/transition. Undocumented ESX environments are prone to VM sprawl and ambiguous separation of duties resulting in fingerpointing and a lot of pissed off people.
VM sprawl is a potentially deadly nightmare for virtual environments because if it becomes too rampant snapshots consume all the diskspace and without diskspace down goes the ESX network. Historically, to image a server a sysadmin would execute a backup which might take several hours, on the other hand, a virtual snapshot takes roughly seconds and creates a ‘point in time’ image. It’s no surprise vmadmins quickly begin to rely on how easy it is:
- applying a patch…snapshot!
- applying a service pack…snapshot!
- upgrading SQL versions…snapshot!
- need to sneeze…snapshot!
- just hired a college intern…snapshots every 30 minutes!
Companies transitioning from physical to virtual really really need to pay attention to whom and under what circumstances their vmadmins create snapshots and how those snapshots are administered/maintained.
A broad clarification of the separation of duties is developers create the application, system administrators maintain the health of a network, and security analysts police the network (including the sysadmins and developers). Idealistically, each role knows what they are responsible for and there is minimal overlap between the different positions. In a physical network this is simplified by physical devices – sysadmin maintain this server, network admin maintain this switch, and security analyst monitor this firewall. But in the virtual atmosphere everything resides on software…so who is responsible for what?! This lack of boundary creates more tension throughout the IT staff and drives the unspoken spike between departments (fess up…developers, sysadmins, network admins, and security folks rarely co-mingle well). Managers really need to pay attention to this and draw a line in the sand when it comes to boundaries!
In conclusion, it’s fairly obvious how casual documentation can really put a company’s virtual network in jeopardy. And unfortunately to make matters worse, virtual policies aren’t very commonplace and for once we [the IT industry] can’t even rely on Google to find a basic “online template” to plagiarize from! Sorry vmadmins…your turn to document!
