Sunday, November 30, 2014

VCAP-DCA 550 passed

So I took the VCAP-DCA550 exam the other day, and passed (just, but a pass is a pass). Awaiting the details to be updated to my Transcript, so kind of feel it’s always a little premature until this is complete, but in time honoured fashion, here’s the obligatory “What I did, and what I used” post.

Thoughts on the exam :
Fair - it’s actually not that difficult a set of questions, but as almost everyone else has said, time is your challenge. The setup I had to use was a 20” (I think) monitor. The actual booth I was in didn’t really have elbow space, so I had to put the marker boards you are given in front of the keyboard, not to the side. So it was cramped in that sense, and the use of a single monitor for flicking between question and RDP session is ok, but not ideal.

This actually impacts on the time factor (coupled with if you need to look something up in the documentation, this is where the latency hits home a bit). I’m of the view that if you had say a dual monitor setup with elbow space, so you could see the questions/documentation on one monitor, and RDP on another, then it would actually save you say 5-10 minutes of flicking back and forth. I ended the exam with 35 seconds left, so that 5/10 minutes actually would make a reasonable difference.

So as I mentioned, I think the exam is fair. The questions aren’t that difficult, but you need to get on and do them, not think too much about them. If you’ve got a few that you think you can get done quickly, then do it, as clearing those out of the way will give you a bit of thinking time on the questions you are a bit wary of. Don’t focus on what you can’t do, focus on what you CAN.

I started a marking scheme on my marker board which indicated confidence level in the question :-
C1 - confident,
C2 - yeah, think this will be ok,
C3 - ah, bugger, I knew I should have looked more at that :-)

This worked to an extent. There were some questions that initially fell into the C3 category, but when I re-read them, they weren’t that bad - a combination of them probably actually got me over the line in the overall score.

So don’t let yourself get downhearted if you see something you think you can’t do or are not confident on. Deep breath, relax and think logically - chances are you can figure it out, and it may make the difference between passing and failing. If you’ve reached the point where you felt you wanted and were ready to take this exam, you probably can do it - you just need to be relaxed and confident enough in yourself.

Work through the questions as you need to, it’s not necessarily a sequential exam. If you can do some later question before an earlier one, or while waiting on a task from another question, then do that. Be aware of what’s being asked - a question may require you to do something without explicitly stating it - no trickery involved, just read and think logically.

Try and pick up the points where you’re confident and come back to the others. I left one question completely (which really annoyed me as it was some area I’d been specifically practicing, but it was subtly different to what I’d practiced). I reckoned I knew it - I marked it as a C2, and would come back to it. I came back to it, and my mind was a total blank. I’m still as annoyed with myself for that one, (and one other question that was easy and I know I messed up), as I am pleased with passing.

One other looking back for me, is planning on when you’re going to do the exam - day and time. I booked the exam for early(ish) morning. In order to get a slot around the date I wanted, I had to go “out of town”, which meant a 90 minute drive, so I booked a hotel for the evening before to avoid the drive to the testing center on the day of the exam. I also knew that for me, it would have to be an early time - I prefer to get going early in the day, and I also knew if I waited towards the end of the day, I’d kind of be fretting all day, so better to get on and get it done, than hang around and letting the mind play tricks. But one thing I probably overlooked, is that I booked the exam for a Friday. This may have been a mistake, as it meant I spent the final week during work thinking/fretting about it, and as I’m in work, I can’t really do anything about this like practicing etc. So for me personally, I think booking for first thing on a Monday may have been a better plan - I would still have being thinking about things on the weekend prior to it, but I could’ve spent the time working on it and trying to practice. But that’s just me. The main thing is to know yourself - know how you work, how you react, how you prepare. And so then arrange things in a way that works for you.

Material used and preparation
VMware vSphere 5.5
Yeah, I know it’s obvious. Nothing here that everyone else hasn’t said, you need to be hands on in your practice. I work with VMware everyday - it’s my job, so I use it every day. However, we don’t use every feature. We have ways to do some things, I’ve written scripts to do some stuff, so my practice had to focus more on the things I don’t do/know well, and the alternative ways to do things.

I set up a nested environment at home and tried to practice scenarios and configurations - the official study guide (details below) helped here, in that it had some suggestions and “example scenarios”. Trying these and variations on the theme helped me. I also wrote a “task sheet” document - 1 task per page, just how to do some things in a manner that made sense to me. I did this partly as I often find writing stuff down helps me in learning/remembering, and partly so that I would then use those sheets as part of my practice.

Ultimately, I booked the exam 6 weeks before taking it - full of good intentions for my preparations (and because I read that there was a 20% off discount announced at VMworld Europe - hey, don’t judge me!). Unfortunately work got busier and more stressful, and firing up the lab each evening became harder to do, so that most of of the preparation work took place on the weekends instead. The final week before the exam, I did feel like cancelling, and my preparation wasn’t as good as it should be. But that’s entirely my fault - plus I’ve always hated and always will hate exams, so this was a bit par for the course :-)

Oh, and although the sheet tells you that it may take 15 days to receive your result, I had mine when I checked e-mail 2 hours later after driving home. Actually the e-mail itself arrived about 15 minutes after leaving the exam center, so the wait may not be as stressful as you think.

In supporting the practice, I used the following :

Documentation - All documentation on my iPad and Kindle - would read some on the train on the way home every day.

VCAP-DCA Official guide by Steve Baca and John A Davies, which I have as part of my Safari subscription. Again, I had a copy of this on the kindle and would read a bit every day on the way home from work.

Unofficial guide by Jason Langer and Josh Coen

CLI guide

Chris Wahl’s study sheet (5.5 edition) - although I didn’t fill this in, this is especially useful for checking/forcing yourself to do things in different ways to what you perhaps do every day. This sheet helped focus that I may need to confirm that I could complete tasks in multiple ways as opposed to just “yeah, I can do that”.

I also used resources from the VCP exam - the Safari library has pretty much all the VMware Press books available, along with other publishers, meaning there was a good selection available for checking different bits, and coming up with ideas on what to practice. But the resources listed above were the main basis, and just practice, practice and worry.

Ultimately, if you feel this is the exam for you, go for it. Sure, my passing score wasn’t great, but I do think that if you prepare well and show the exam the respect it deserves, then there’s a good chance you’ll be successful.

Then you continue learning …

Tuesday, October 16, 2012

Quick check on number of VMs powered on and off in multiple VCs

Recently there was a need to quickly report the number of VMs in all VCs, ideally with numbers for powered on and powered off VMs. We have multiple VCs (10 plus), not in linked mode, so it meant connecting to each and counting or exporting the information.

It’s fairly easy to get this information, but figured a script may be in order, in case the request was made again in the future, so this is what I came up with. It’s rough and ready, but did what I needed it to do. And yes, there are other scripts and tools (RVTools, PowerGUI with the VMware powerpack etc) that can do it, but this is partly an exercise in trying to get to grips with Powershell and PowerCLI.

It also spits out a couple of CSV files with a basic host report and VM report per VC in files named per VC. Assumes credentials are sorted in some way for conveniance - ie, credentials store.

The VCs to check are listed in the vclist.txt file

$currVC = Get-Content "vclist.txt"
foreach ($targetVC in $currVC) {
        Connect-VIServer $targetVC
        $hostCount = Get-VMhost
        write-host "Total number of hosts in $targetVC :" ($hostCount).count
# VM's, powered on and memory count
        Write-Host "Collecting VM information"
        $OutputFile = $targetVC + ".csv"
        $totalvms = get-vm | where{$_.powerstate -eq "PoweredOn" } |`
                select name, powerstate, numcpu, memorymb | `
                export-csv -NoTypeInformation $outputFile | out-null
        $pvms = Get-VM
        write-host "Powered on: " ($pvms | where {$_.PowerState -eq "PoweredOn"}
        write-host "Powered off: " ($pvms | where {$_.PowerState -eq "PoweredOff

# VMhost details
        Write-Host "Collecting host information"
        $HostOutputFile = $targetVC + "-vmhost.csv"
        $totalHosts = get-vmhost | select name, numcpu, CPUTotalMHz, MemoryTotal
MB, MemoryUsageMB, Parent |`
                Export-Csv -NoTypeInformation  $HostOutputFile | out-null
Disconnect-VIServer -Confirm:$false

Monday, October 15, 2012

Using PowerCLI to retrieve IP from VM annotations

In our environment, we have a lot of VMs on NAT’d addresses. On occassion, I need acccess to their public IP - eg, for pinging to verify guests are still running if we put a host into maintenance mode. Grabbing the address from the internal system for each VM is time consuming and somewhat annoying. vSphere reports the private IP in the GUI which isn’t what I want. You can extract the info from the VM with PowerCLI, but again, it’s a little awkward (for my skill level). And we don’t label the VMs by their DNS name, it’s more an internal system, which again, makes identifying a particular machine harder than I would like, but that’s the way the system is.

Luckily, when we create VMs, we add annotations. One of which contains the public IP (or it should if people fill in the details :-)

That allows a way to grab the public IP with a one liner (here the assumption is the annotation field is called Public IP).

For VM called “foo” :

get-vm  foo|  get-annotation | where-object {$ -eq "Public IP"}

For all VMs in a VC :

get-vm | get-annotation | where-object {$ -eq "Public IP"}

Or, if we want just the powered on VMs :

get-vm | where-object {$_.powerstate -eq "PoweredOn"} | get-annotation | where-object {$ -eq "Public IP"}

I export them to .csv, and now have a more manageable way of quickly being able to call upon the relevant IPs

New role …

Recently started a new position, as a VMware guy in a managed service provider.

There are various challenges involved (mainly process oriented), but one challenge is scale. It’s a much larger environment than I had previously administered.

So, it means different ways of doing things, and makes me appreciate more the value of automation and the use of PowerCLI.

Problem is, I suck at coding. Always have, always will. But still, I feel I need to do it to make the role manageable. So, I’m going to start posting some bits and pieces I’ve been writing to try and help me and solve problems as they arise or as I see them. The code will almost invariably suck, but hey ho.

I use a lot of the “standard” resources. Google, Alan Renouf’s site, the PowerCLI book (I have it through my OReilly Safari account). Pretty much anything I do has (almost certainly) been done before (and better), but future entries will have some of my dabblings (primarily for my reference).

Monday, November 29, 2010

VMware Troubleshooting course review.

A review of the VMware troubleshooting course. This is a 4 day course. The very notion of which I find interesting. Invariably the “troubleshooting” module on almost all courses I’ve ever done is the Friday afternoon, last or last but one module, when everyone wants to get away.

Yet troubleshooting is arguably one of the most important tasks of an IT pro. It’s when the spotlight falls on you (along with blame). But it’s hidden away on courses. As though nothing ever goes wrong. I know it’s partly a time constraint, but still, it’s just so important and yet it’s invariably glossed over.

So here we have 4 days dedicated to it. It’s also a recommended course for the VCAP-DCA (another reason for taking it, as I aim to have a stab at this early 2011). So, onwards, into the breach (or something) …

This course took place at Global Knowledge in Wakefield, Nov 23-26 2010.

Day 1
Intros, and understanding people’s experience and expectations. We get 3 manuals. Course notes, labs and a troublshooting reference guide which outlines procedures eg, “vCenter Server system cannot migrate a virtual machine with vMotion”.

As ever with courses, it’s not just the content that will determine the success or not of the course. It’s also the instructor and the fellow delegates. Fortunately the instructor is Scott, who was the instructor on my fast track course for 3.5 nearly 2 1/2 years ago, and I know he knows his stuff and it will be good.

The majority of the first day modules are in essence setting you up for being able to troubleshoot. We spend time understanding and configuring vMA and log files. vMA is basically going to allow you to do the work in ESXi that you did in the service console in ESX (given the absence of a service console in ESXi). It can also be used with ESX. It would appear at this stage it’s the future for this type of work, so good to spend time and have an understanding of it. Plus of course for ESXi, it can be used for logging and also resxtop.

Most of the labs today are standard procedural labs - ie, you follow the instructions, and you should be good at the end of it all.

Day 2
Networking today. First it’s a review - the things VMware expect you to know, but (again, where the experience of the instructor comes in from having taught the course previously), you may be rusty on. So we run through this. It’s a good refresher for me in parts, and highlights that I REALLY need to do more work with distributed virtual switches (especially to prepare for the DCA). A straw poll showed that 3 of the 7 of us on the course were using dVS switches in production!

More procedural labs, and then break-fix. Basically, the core of the course, the instructor has scripts at his disposal which will “do things” to your environment. You’re given a user report “vmotion doesn’t work”, and you fix it. I think that it’s likely the instructor has various degrees of difficulty at his disposal, so the course will kind of shape and evolve to fit the needs of the course. This may mean skipping some labs, may mean fiendishly difficult or relatively simple.

Day 3
Finish the networking module - setting up a packet sniffer, setting switches/port groups to promiscuous mode to allow it to work etc. And then more break/fix on networking.

Afternoon is management and then storage. Following a similar pattern of relatively brief notes, which really are going over things people already know, then some more break/fix.

Day 4

Finish storage module, and a procedural set of labs configuring different iSCSI LUNs - CHAP, digest, then adding multipathing and using claimrules.

Then it’s into the final stretch with modules on vMotion, storage vMotion HA/DRS, FT, DPM and general VM troubleshooting. Stay on at the end for a couple more labs as I’ve frankly been dreadful at them, and I need more.

Overall Impressions

So, lessons learnt? Well, networking really is key, and I need to do much much more with dVS - a lot of the course kind of hinges on these.

My troubleshooting was dreadful. It was kind of a mix of embarassing and humbling really. But in a way, that was probably the BEST part of the course for me. I’ve come out of it with a good idea on areas I really need to get focussed on, and it’s not something that I can’t overcome. I guess it’s like this, my work environment is sufficiently small and reliable, that I’ve never had to truly troubleshoot the VMware setup. That could be seen as a testament to the quality of the software and also the hardware in use. Maybe a small element can be attributed to what I’ve done in the setup and maintenance. But when you don’t do something frequently (fixing things in this instance) you can get rusty.

On the other hand, if you do troubleshoot every day, the course may not be as eye opening - there was clearly one guy who excelled - often getting the problem within a few minutes.

I guess my main complaint is that we’re paired up on labs. Personally I prefer to work alone as I can work at my own pace. I tend to work quite quickly, and so find myself waiting for my lab partner, which disrupts my flow (though of course working fast is no guarantee of working smart). Plus in the context of this course, I don’t want my mistakes to disrupt my lab partner. It’s not fair on them. And on these types of courses, I like to try stuff (it’s an opportunity to do so, without breaking production kit AND where you have the safety net of an experienced VMware vExpert to help you out when you basically have a brainfart). But that’s how the labs are designed, so, so be it. Oh, and of course I’d love to have access to the scripts for my testlab, but that’s not to be. Still, there’s enough suggestions within the manuals that I’m sure I can at least work back from those and create various scenarios.

So, recommend the course? Yep, I think so. As I said above, I was embarrassed and humbled by my performance, but you need to learn from these things, and set aspirations and goals accordingly. As preparation for the VCAP-DCA, well, I’ll let you know when I’ve tried it. My suspiscion is it will be valuable, if for no more than it emphasises once again that you have to get hands on - build, break, learn, repeat.