Andrew Hale: IT Talk & Other Topics

So, here at phase 2, I'm off to a rocky start out of the gate. Firstly, an update, no pun intended. We've decided on going to v6.0 rather than just going to v5.5 because there's no compelling reason not to. Normally, when I'm upgrading software, I go to the latest version unless there's a good reason not to. In this case, there's no big issues with v6.0 that I've seen. Yes, people have had problems but it seems like they're usually one-off issues.

Got an interview coming up? Interviews are two-way streets so don't forget to interview them back. I've written about this and you can read it  HERE . Talking about money is something we all dread but we all need to do at some point in our lives. There's a point in one's professional career where it's basically expected to negotiate pay during the offer stage of hiring. I never negotiated pay or asked for a raise until my more recent professional positions. I'd like to tell you what I've learned about it so it can help you too.

Inconsistent replicas. Studies show that nearly half of all backup admins suffer from inconsistent replicas. But backups don't have to be this way. With Chkdsk, you too can reduce replica inconsistencies. (Please see a Sr Admin if your replicas are consistent for more than 4 incremental jobs.) Joking aside, as far as DPM is concerned, an inconsistent replica is a deal-breaker and that means other backup jobs won't run until you fix it. A common issue with file-level backups in DPM is that it'll get tripped up on s corrupt file, usually one in a shadowcopy volume. I'd like to discuss how to get around it.

"Documentation saves time? How does it save time when it takes me $time to write it out?" You might ask. Allow me to explain. Good documentation helps you, your team, and new-hires inheriting your environment. Allow me to explain.

I was recently given a task of moving a VM used by our application development team from it's own little host to our production VMware infrastructure. This VM in particular has 12 disks, totaling 665Gb of data. Since this was sort of a chore, I figured I'd lay out the possible approaches for the next admin out there who isn't sure how do this. First, the basics. An option for the VM is to migrate using vMotion. You can migrate a VM between hosts and/or datastores with either vMotion or svMotion (Storage vMotion), respectively. This is really your best option if both of your hosts or datastores reside within the same vCenter environment. The main reason I'm writing this document is for the time(s) when you have to move a VM from a standalone host or from a host within a vCenter environment to a different standalone host or to a host within a different vCenter environment.