Thursday, 14 July 2016

Quite often the modern ESXi servers come with no local storage and ESXi is normally installed on SD card.

As per VMware KB1033696 the SD card can't be used to store scratch partition. The main purpose of the scratch partition is to store logging files and to provide space for vm-support output.

So, the normal practice is to use shared storage (VMFS/NFS) as a scratch location. The problem is that the configuration of the scratch location is not automated in the existing vSphere. So you have to manually create folder for each of the ESXi host and configure each ESXi host to use that folder.
This can be quite time-consuming and boring tasks when you have to do it for hundred of servers.

To make things worse Host Profiles do not let you configure scratch location too.

I had some time last week and thought it was a good chance to have fun with PowerCLI and automate the scratch configuration for ESXi hosts.

So here is overview of what the script does:

Connects to vCenter

Collects the list of ESXi hosts in the cluster. Very often storage is not shared across multiple compute clusters so I decided to use cluster, not a datacenter, as a configuration target.

Checks if there is a designated scratch folder for each of the clusters and creates if it doesn't exist

Checks if the ESXi host configured with scratch location and if it points to the right datastore and folder.

If ESXi is not configured yet or points to the wrong directory the correct setting will be applied.

Provides a list of the ESXi servers to be rebooted for the configuration change to take effect

There are a couple of thing you have to do before running the script:

Identify the datastore to be used to store scratch folders

In that datastore create a folder where the script will create a scratch folder per each host

Friday, 8 July 2016

Choosing between VMware and Cisco virtual switch products is not an easy tasks as it includes not only side-by-side feature comparison, but also numerous aspects of duty separations, operational overhead, current skill set and expertise. And not all of them can be compared directly.

Apart from all that it can be simply a political decision to a question "Who is going to manage virtual networks?".

In this article I am trying to provide essential information on things to help you make the right decision for your infrastructure.