I haven’t seen many reviews of this class, so I thought I would share my experience for those thinking of registering for the VMware vSphere Troubleshooting course.
I was originally registered for Fast Track, but after I took a long, hard look at the course outline, I realized I already knew most of the material they would cover. I’m glad I changed my registration to Troubleshooting, especially since the requirements changed to include it as a prerequisite for VCP4 certification.
When I sign up for a technical class, I always worry that I’ll get a professional instructor with not much real world experience. My trainer for this course was John Davis from New Age Technologies. He was definitely well versed in the material, and since he had also spent considerable time in the field, he was able to share a lot of his real troubleshooting experiences. This was the most beneficial part of the class, so if you register, make sure you’re taking it with someone who has been in the trenches.
My intent is not to disparage the excellent VMware official curriculum, as it was very well put together, and quite thorough. I just learn much better when I can discuss with folks who have been where I am, and seen things I haven’t seen. I can read the book and do the labs anytime.
The first day, we jumped right into some CLI troubleshooting. Since I had been using ESXi, and the vMA, I was on somewhat familiar turf. In the first few labs, we configured the vMA, vi-fastpass, session files, and started right in with some vicfg commands. These are mostly network related commands in the first few labs.
We played around with tech support mode a bit, although this was a couple days before the 4.1 release where it became officially supported. In class we got the official “don’t try this at home” line from the instructor. We enabled SSH on ESXi and played around with Putty a bit. One of the coolest things I saw on day one was the vsish command on ESXi. For those who haven’t played with it, I recommend checking it out. It’s a bit like the Windows registry for ESXi. One can view tons of info about the system setup using this command.
We had an in-depth look at ESX, ESXi, and vCenter log files in the console, and in vSphere Client. We covered viewing, exporting, bundling, and even setting up log collection with the vMA. There were 5 labs on logging, and setting up the vMA to host the logs.
On day two, we jumped into network troubleshooting. We covered a lot of new info on the inner workings of the dvSwitch, including synchronization, and what happens when it breaks, which I found helpful. There were a few labs where the instructor broke our network setup, and we had to fix the problem. Some of these breaks surrounded dvSwitch timeouts, obsolete dvSwitch info, and uplink issues.
We played with CDP, port binding methods, and VLAN / PVLAN troubleshooting. I think the PVLAN stuff was most beneficial. Even understanding how those work, it’s great to get some hands-on troubleshooting with them, not having used them in my own environments.
Today we continued with networking, which is probably the most information packed module of the course, and with good reason. There were labs on Wireshark, tcpdump, net-dvs, and viewing / changing network configs from the vMA and CLI. As a CCNA, I had a pretty solid networking background going in, but I did notice some in the class struggled a bit with this. If you don’t have much networking experience, or at least a solid understanding of VLAN’s, I recommend brushing up before this course.
We went into management troubleshooting after wrapping up the network break / fix labs. Firewall configuration errors were something I really didn’t care about, but not everyone has the luxury of using ESXi exclusively. There was some database connectivity and lots of vCenter troubleshooting.
Storage was up next, and there was a ton of information on PSA, NMP, MPP, SATP, CHAP, and PSP. After we got all the acronyms out of the way, we did some great iSCSI break / fix labs. These were fun, and our sneaky instructor gave us some pretty hairy issues that may never happen in the real world, but provided fantastic troubleshooting opportunities.
VMotion, DRS, HA, and cluster troubleshooting was the topic of the morning on day four. Reservations and swap file space issues cropped up, as did VMotion failures and admission control policies.
My favorite part of the class was absolutely the break / fix labs. On day four, we got the chance to have as many of these as time would allow. Previously all the break / fix scenarios were related to the chapter we were on, so you’d have a good idea where to start troubleshooting. But on the last day, it could have been anything. I had a blast troubleshooting the breaks that our instructor did for us, and I probably learned the most during this exercise.
In summary, I found the troubleshooting course much more valuable than the ICM or Fast Track would have been for me. For someone with zero to only a few months of vSphere experience, ICM or Fast Track may be a better choice. If you’ve been playing with it at least in a lab for 6 months or more, read the books, and VMware Documentation Roadmap, you’d probably find Troubleshooting a more beneficial course.
Will it prepare you for the VCP4 exam? No. But, in my opinion, neither will the others. The only thing that can adequately prepare you for the exam is the Blueprint. I know that’s the standard response everyone gives, but it really is true. If you go through the Blueprint step by step, you’ll be good to go for the exam.