X
Business

VMware 5.0 Training Days Three and Four (Review)

VMware 5.0's Hump Day and Final Turn chronicled in living color. Grab some caffeine and focus.
Written by Ken Hess, Contributor

Any five-day training class is tough but technology classes are especially tough because of the intensity and depth of focus you need to remain engaged in the material. Days three and four are hard--four more so than three. There's a mental wall that you hit about halfway through the fourth day. And, that's not the time to hit the wall because of the topic: Snapshots.

Snapshots are confusing (to me) and then add in the fact that my ears are bleeding from listening and my mind is saturated in virtual machines and their associated terminology. Yes, I've taken both the vSphere 3.x and 4.x classes (both five days) but this one seems particularly laborsome for me. I think it might be because we take very few breaks and that the instructor digs into the material in an in-depth technical fashion. The vigilance required to keep up is quite high.

There are enough differences between vSphere 4.x and vSphere 5.x that a techie's typically short attention span is not well rewarded. It's certainly no time to 'zone out' (slight pun intended) on the instruction. Some of the most important material during the course is presented in day four: snapshots, resource allocation, and access control.

Don't get me wrong here; the material isn't boring--quite the contrary--but you'll need to release your screen stare at regular intervals during the module presentations. It isn't an easy thing to do because you might miss something. Fortunately, my instructor knows how tough the material is to get through so she engages us throughout the day to keep us challenged and to break up the long stretches of presentation.

Speaking of snapshots, I don't particularly like them. Not only are they confusing to work with but they're also a little dangerous--due in part to the confusion. I'll bet that, if you work with VMware, you have at least one "war story" based on a botched snapshot activity. I like the concept but the implementation seems poor to me. Of course, not everyone agrees with that statement. There are those (maybe you) who love snapshots and live by them.

I think their use in a test environment would be very appropriate but in production I'm not convinced. I prefer clones to snapshots. And, yes, I realize the time and disk cost involved but mistakes associated with reverting, consolidating and deleting snapshots don't occur. I've never botched a clone. Nor have I ever botched reverting to a clone. I think the costs are offset by the safety in a production environment.

Resource allocation is kind of another sore spot for me. I don't really like the whole resource over commitment shtick, especially when it comes to disk over commitment. Memory and CPU over commitments are less likely to have "page me in the middle of the night to fix it" consequences than disk over commitments.

But, virtual machine snapshots and resource over commitment are facts of life that we all live with regardless of the havoc they can wreak. I'm going to assume that, over time, both of these subtechnologies will improve.

Have you had any disasters associated with resource over commitment or snapshots? Talk back and let me know.

Editorial standards