Training, Professional Services or Do I Try it Myself?

“If you don’t have time to do it right, when will you have time to do it over?”

-John Wooden

Training, professional service or do it yourself (DYI)? This is becoming a very common question for most of my clients and I would guess for the industry as a whole. While I am speaking specifically of virtualization (hypervisor), this of course could apply to many aspects of the current data center. So what is an IT team supposed to do? When does a system administrator admit he/she cannot complete task at head and in a way stick his own neck out? Where does budgets come into place vs. deliverables such as timelines, service levels etc? All very interesting questions, but answers are a bit complex.

 Training

Personally I am proponent of education in all aspect of like not just the technical side. However, training has some serious drawbacks and may not be a true option when looked at carefully. For one it is much more time consuming than most people realize or maybe want to admit. Plus ones absorption rate varies widely between individuals. I know people who touch something once and are “experts” while on the other hand people who have done the same thing a hundred times still needs reminders how to finish the task. Not to mention that the individual trainer/provider makes a huge difference. Lastly, classes usually require time away from the office and can put a person in a worst situation than before trying to catch up and learn new stuff at the same time.

With that said, there is a huge upside here. This learn to fish mentality provides higher adoption rate, customer satisfaction and allows the customer be less dependent on a particular partner or vendor. All in my opinion can be a huge value add for getting some classroom & lab time.

 Professional Services

Of course I want to be careful here since I work for a professional service (PS) company. The drawbacks are nothing new. It tends to be expensive and add up to 30% to projects budget. Managing the PS partner at times can be difficult and a time waste almost breaking even with doing it yourself. Plus, and it is a big plus, it puts the requestor in a vulnerable position with both his management and the PS partner. One, he/she s vouching for this service and in a way sticking their respected necks out while at the same time admitting they don’t have the capacity to do this themselves. The PS partner thinks they are dependent on them and lets be honest most of the time they are, and tend to use that to their advantage whether they do good work or not.

The good news if that you find a good partner most of these problems solve themselves. Value partners will not only do the work but train you as they move through the process meeting SLA’s and budgets. They will do their work in a timely manner putting your project ahead of schedule and make you the advocate look like a rock star. They are fair on price and try to work within your budget range and adapt as needed. Finally, someone else is on the hook and can, good or bad, be a scapegoat if the project ever goes sideways. Food for thought.

Do It Yourself

My favorite because it tends to be my motto but tends to get me in trouble more often than not. For one if you are lacking the base foundation of skillsets you could end up costing yourself a lot more time and money than expected.  With that I mean, It tends not to be a good use of company resources and your time could be better used doing the tasks you’re a good at.  And then the biggest negative, and I see this every working day of my career, is that it isn’t done right and causes huge headaches in the short or long term. Poor performance almost always boils down to bad infrastructure designs that a quality PS partner would have avoided in the beginning.

However there are some upside to the DIY approach. For instance people tend to learn best by doing and it pushes you to expand your knowledge. The cost aspect if avoiding the above mistakes can be huge and set up a dependence that is unmatched. You own the keys to your data center and no one is driving but you! This is a huge advantage when negotiating with vendors, partners, and even management. Lastly, It provides you the best job security I could imagine. As the designer and implementer you become almost irreplaceable as no one wants to reverse engineer your solutions.  Now granted this is only the case if it is done right and you don’t cause a huge outage.

Final Thoughts

In the end I tell clients a mixture of all of these tends to be the best fit. Of course depending on the scope and product I do recommend certain avenues. If it is tier 1 and 99.999 uptime application then by all means spending a few dollars here and there would be a great investment to ensure success. If it is a low priority project that needs little success and are not under a time crunch then it is great to roll up your sleeves and get to work. The one thing I will say is that education and classes should be included with every project. If you are not learning how things work you will always be susceptible to be vendor locked, and no one wants that except the vendors.

Using vCenter to Centralize User Authentication

A common issue I have seen lately is with smaller customers adopting a larger virtual environment is the use of individual host admins/users. When you only have a few starter ESX/ESXi hosts it can be easy to forgot to plan out a large deployment scenario as your environment starts to grow.

It really only takes a few moments to update an admin on a server or two. But what do you do when you have to manage 10 hosts? You would have to manually login and change all of these machines including adding users, changing your password, or making system changes. This can add a lot of time to simple tasks.

A good example of this: Lets say you currently have 2 hosts in their environment with 3 admins. Then add 3 more hosts and 2 more admins, now all of sudden you are managing 5 separate hosts and 5 admins. Imagine adding another 5 hosts?!

Fortunately managing individual login on separate ESX and ESXi hosts can be managed centrally with VMware vCenter Server.  This obviously greatly reduces the amount of time needed to manage multiple host and administrators on separate hosts.

Since vCenter Server is a Windows-based application it plays very well with Active directory and you can take the same approach of managing your user groups.  Once it is set-up, the authorized user can then login using the vSphere Client to either the vCenter Server that would connect to the ESX/ESXi host.

A thing to note about this set-up.

Once you have this process set-up, your organization should stick with it and be consistent. This is because the Wndows-based vCenter server doesn’t reconcile the user accounts with the local ESX/ESXi host’s database (they are completely separate).  This means if you create an account on a local ESX/ESXi host and then the admin tries to login with that through the vCenter Server it won’t recognize the user credentials the same is true if you made an account on the vCenter and you try and manage it through vCenter.

Hopefully this will save you some time!

vSphere installation Best Practice

How To: Changing The Name of a Virtual Machine While It Is Running

Did you know?

That if you change the name of a virtual machine while is powered on; the files that consist for that VM will not be changed.  This would mean that vCenter would display a different name that would be found in the file system level. To resolve this while the VM is running it is recommended that you:

  1. Change the name.
  2. Use VMotion to move the machine to a new datastore (This will rename the files that are copied).
  3. VMotion back.
  4. Done!

This will avoid confusion and having to shut down the VM for any scheduled downtime. On the flipside, you can do it the proper way:

  1. Make sure there is no snapshots etc.
  2. Shutdown the virtual machine.
  3. If you are using VirtualCenter, remove the virtual machine from the inventory but do not delete the files from disk.
  4. Connect to the ESX Server host on which the virtual machine resides over SSH.
  5. Unregister the virtual machine using command: vmware-cmd -s unregister <path to config file>
  6. Where <path to config file> is the path to the configuration file as determined by ‘vmware-cmd –l’ . ‘/vmfs/volumes/storage1/vm1/vm1.vmx’
  7. Rename the folder, .vmx file, and .vmdk (+ flat) file to match the new name.
  8. Edit the vmx file to reflect the name of the new descriptor file.
  9. Locate the scsi0:0.fileName line.
  10. Save the file and exit
  11. Edit the .vmdk file to reflect the name of the new flat file.
  12. Locate the Extent description section of the .vmdk file.
  13. Register the virtual machine.
  14. Add the virtual machine back into VirtualCenter inventory using the Virtual Infrastructure Client by browsing the data store, finding the .vmx file, right-clicking and adding it to inventory.

For more details.