PowerCLI

There’s not a lot more to say than the title of this post – if you create a new Virtual Switch using PowerCLI without specifying the NumPorts parameter, it defaults to 64 ports. This strikes me as odd when the default for a standard switch is 120.

You can see in the screenshot below that when I create a Virtual Switch without the parameter, it creates it with 64 ports. Once you minus the 8 reserved for physical NIC ports (uplinks), CDP traffic, and network discovery it leaves you with 56 ports available for VMs.

Yesterday I attended my second ever #LonVMUG and did my first ever VMUG presentation! Generally it was a great day, with loads of really good sessions and some really cool community and vendor content.

As ever it was great day for socialising and networking with people who you interact with on twitter. For me one of the major benefits of the VMUG is learning from other people’s experience. Twitter was alive with the hastag #LonVMUG and it definitely adds something to the day to be active

The VM estate that I manage is large: there are more than 20 different clusters and over 300 hosts of varying ages and hardware levels – as a consequence there are various different versions of ESX and ESXi running. Upgrading the hosts is somewhat akin to painting the Forth Bridge, a never-ending task. So keeping the thousands of VMs at the correct hardware and VMtools versions can be a bit of a losing battle.

If you work in company with strict password compliance rules, for example under SOX, you might well have to change administrator passwords every month. Doing this on any more than a few hosts is tedious work – even on two hosts it seems like a waste of time logging on the host via SSH (or even enabling it first) before changing the password. Then we also need to audit the change, there’s no point making it for compliance reasons if we can’t then prove we did it!

I’ve previously posted around this topic as part of another problem but having had to figure out the process again I think it’s worth re-posting a proper script for this. VMware KB 1016106 is snappily titled “ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to boot or during LUN rescan” and describes the situation where booting ESXi (5.1 in my case) takes a huge amount of time to boot because it’s attempting to gain a SCSI reservation on an RDM disk used by MS Clustering Services. It also details the fix.

The process of requesting certificates for vSphere 5.1 is a fairly grim, manual process. It’s repetitive and easy to make a mistake on any step of the way. Since I’ve got to do this for quite a few VirtualCenter Servers, I thought I’d script the certificate generation if nothing else. I am following the excellent documentation provided in Implementing CA signed SSL certificates with vSphere 5.1 and more specifically in Creating certificate requests and certificates for vCenter Server 5.1 components.

I ran into this issue yesterday while reconnecting hosts in our vCenter Server following a complete reinstall - the reasons for which are a long story, but suffice to say that there were new certificates and the host passwords were encrypted with the old ones.

The LUNs had been unpresented at the hardware level by the storage team, but had not been unmounted or removed from vCenter. This is not the way to remove storage - let me re-iterate: remove storage properly . Unfortunately in this case the storage was removed badly - doing this can lead to a condition called “All Paths Down” or APD which is best explained by Cormac Hogan (@vmwarestorage) in the article Handling the All Paths Down (APD) condition .

In vSphere 5.1 “Tags” replace the old custom attributes to provide a way of adding metadata to vSphere objects. The “Tags” are organised into categories to “define how the tags can be applied to inventory objects”. The easiest way to think of the difference is that custom attributes are “free text” and the tags are statically defined properties.

There is a wizard for converting custom attributes to tags, but it can get a bit confusing and is pretty poor - let me explain. We use four custom attributes in my current environment: CreatedBy, CreatedOn, Owner and ServiceType. CreatedBy contains the user ID of the person who created the VM, CreatedOn is the timestamp of when the VM was created, Owner is the Business Unit who own the server and ServiceType is the type of service - e.g. Active Directory, or SQL.

Just a quick script to set the Path Selection Policy on any LUNs on a host that do not have your target policy enabled. The script sets the server to Maintenance mode first, evacuating any VMs if you are in a full DRS automated environment. While this is not strictly necessary, it was required for my production environment just to be safe.