Tag Archives: vSphere

Perkins-Tryon High School Graduation 2010 (c) Paul Robinson

VMware Certified Professional Recertification

VCP5VMware has announced a Recertification Policy for it’s VMware Certified Professional program, effective as of March 10, 2014.

In short, it means that you are no longer a VCP(x) for life, but need to recertify every 2 years, unless you take a VCAP exam during the same period. If you do not upgrade your certification, your VCP status is revoked. For all the details, have a look at Recertification Policy: VMware Certified Professional.

It also means that anyone currently holding a VCP certification, needs to recertify before March 10th 2015, regardless of when the initial VCP was obtained.  Those obtaining a VCP after March 10th, will have to recertify within two years of obtaining the initial VCP.

I think this is a good move, and is on par with other technical certifications like ones offered by HP, Cisco and CompTia (A+). After all, we live in an ever evolving technical market where continuous change happens and if you are not able to keep current, the certification holds no real merit.

This change from VMware also means that as long as you recertify your VCP exam within the two year period, there will not be a course requirement to upgrade; schedule your exam and you are ready to go. Previously you would get a grace period, after a new major release of vSphere, where you could re-certify without having to attend a new class. With this change, you have two years, and that is it.

In a way, this also means that VMware will have to commit to major releases, with upgraded VCP versions, more frequently than every 2 years.

Looking at the last two vSphere releases, this seems to indicate a change in release cycles for major versions:

  • vSphere 4 was released  May 21st 2009.
  • vSphere 5 was released July 12th 2011
  • vSphere 5.5 was released September 22nd 2013.

Remember, vSphere 5.5 is covered by the VCP5 (ok, there is a VCP510 and VCP550 version) certification, so if this policy was in place in 2011 when vSphere 5 was released, there would not be any upgraded VCP certification to take within the two year validity period.

Update:What if VMware had called an old VCP certification “retired” instead of “expired”, would that cause less outrage and emotion?

Header image used under Creative Commons License (c) Paul Robinson

IMG_3811

Automatically Name Datastores in vSphere?

William Lam posted “Why you should rename the default VSAN Datastore name” where he outlines why the default name for VSAN data stores should be changed. Of course, I completely agree with his views on this; Leaving it at the default might cause confusion down the line.

At the end of the post, William asks the following:

I wonder if it would be a useful to have a feature in VSAN to automatically append the vSphere Cluster name to the default VSAN Datastore name? What do you think?

The answer to that is quite simple too; Yes. It would be great to be able to append the cluster name automatically.

But this got me thinking, wouldn’t it be even better would be to use the same kind of naming pattern scheme we get when provisioning Horizon View desktops, when we provision datastores? In fact, this should also be an option for other datastores, not just when using VSAN.

Imagine the possibilities if you could define datastore naming schemes in your vCenter, and add a few variables like this, for instance: {datastoretype}-{datacentername}-{clustername/hostname}-{fixed:03}.

Then you could get automatic, and perhaps even sensible, datastore naming like this:

local-hqdc-esxi001-001
iscsi-hqdc-cluster01-001
nfs-hqdc-cluster01-001
fc-hqdc-cluster01-001
vsan-hqdc-cluster01-001 

And so on… I’m sure there are other potentially even more useful variables that could be used here, perhaps even incorporating something about tiering and SLA´s (platinum/gold/silver etc.) but that would require that you knew the storage characteristics and how it maps to your naming scheme when it gets defined. But yes, we do need to be able to automatically name our datastores in a coherent matter, regardless of storage type.  

After all, we’re moving to a model of policy based computing, shouldn’t naming of objects like datastores, also be ruled by policy, defined at a Datacenter level in vCenter?
(wait a minute, why 
don’t do the same for hosts joined to a datacenter or cluster?)

 

Zappa-SSD-Failure

Fixing “Could not create vFlash cache” error when powering on a VM

During some way overdue housekeeping in my HP Microserver-based “Homelab” today, I ran into a rather annoying issue that prevented me from starting one of my more important VMs; namely my home Domain Controller.

In short, I removed an old SSD drive that I’ve used for vFlash Read Cache (vFRC) testing and installed a new 1TB drive instead. Since I have a rather beefy work lab now, I need space more than speed at home, so this seemed like a good idea at the time.

A good idea that is, until I tried starting my DC VM, which also is my DNS and DHCP server, and got greeted with this little gem:

Zappa-SSD-Failure

The “Could not create vFlash cache: msg.vflashcache.error.VFC_FAILURE” error is understandable, the SSD drive was removed, but I honestly did not think that even if a VM was configured to use it, that it’s absence would prevent a power-on operation on that VM. I would have expected it to throw a warning about the cache location missing, and warn me that acceleration was not happening, not a flat out “cannot power on“.

Normally the fix for this would be quick and easy, edit the VM and remove the vFRC configuration, but since my host has a whopping total of 8GB of memory I don’t have vCenter running at all times.  Editing the VM settings through the vCenter Legacy Client (C#) does not work, since vFRC requires Virtual Hardware Version 10, which it cannot edit.

Once I got the vCenter Server Appliance (vCSA) fired up, I realised that I have somehow forgotten the admin AND root passwords, and was completely unable to log-on. How that has happened is beyond me, but for the life of me I was not able to log on.

Next step was to try and edit the VM from VMware Workstation 10 installed on one of the Windows boxes in my network. Sadly Workstation has no concept of vFRC, and it is not possible to edit that particular VM setting, even if you connect it to the vSphere host. I later on also realized that VMware Workstation 10 is also unable to host connect  USB peripherals, like printers, to a VM, but that’s beside the point right now.

So, either trying to hack the VM Hardware Version to a value that the vSphere Client can handle, of  deploying a new vCSA instance, I was left with editing the VMs vmx file directly.

Thankfully this was an easy way to fix the problem, and get the VM powered on. For each vmdk file that is configured to use vFRC, there is a corresponding entry in the vmx file, that controls vFRC.

In order to turn off vFRC acceleration for a given disk, download the vmx file, and change the value for <device>.vFlash.enabled from

sched.scsi0:2.vFlash.enabled = "TRUE"

to

sched.scsi0:2.vFlash.enabled = "FALSE"

Re-upload the vmx file, and try to power on. In my case, this fixed the problem of powering on the VM.

This problem again highlights one of the problems with the dependancy on the new vSphere Web Client. In a real production environment, the vCenter would be up and running at all times, and editing the VM would have been a small task, but what if you had used vFRC to speed up vCSA itself, and you had a failed SSD drive?

Of course, in this case the fault is mostly mine. I removed a “production SSD”, without first removing the vFRC configuration. I did not have a working vCSA with Web Client up and running when this was done, and I had forgotten my passwords. A pretty specific error generating procedure if there ever was one.

It’s an easy fix to edit the vmx file, but it does at times feel a little bit like you are now able to cut of the branch you are sitting on with the new vSphere Web Client. In simpler days, you could pretty much fix anything by connecting the vSphere Client to the host and fix any errors there, but now the dependancy on the vCenter Server is stronger than ever.

Before upgrading your VMs to Hardware Version 10, make sure you understand the implications of going all-in with dependancies on the Web Client and vCenter. It might just come back and bite you if you haven’t thought through your design.