Yellow Bricks

by Duncan Epping

u2

Mixing versions of ESXi in the same vSphere / vSAN cluster?

· ·

I have seen this question being asked a couple of times in the past months, and to be honest I was a bit surprised people asked about this. Various customers were wondering if it is supported to mix versions of ESXi in the same vSphere or vSAN Cluster? I can be short whether this is support or not, yes it is but only for short periods of time (72hrs max). Would I recommend it? No, I would not!

Why not? Well mainly for operational reasons, it just makes life more complex. Just think about a troubleshooting scenario, you now need to remember which version you are running on which host and understand the “known issues” for each version. Also, for vSAN things are even more complex as you could have “components” running on a different version of ESXi. On top of that, it could even be the case that a certain command or esxcli namespace is not available on a particular version of ESXi.

Another concern is when doing upgrades or updates, you need to take the current version into account when updating, or more importantly when upgrading! Also, remember that firmware/driver combination may be different for a particular version of vSphere/vSAN as well, this could also make life more complex and definitely increases the chances of making mistakes!

Is this documented anywhere? Yes, check out the following KB:

Adding a fifth (virtual) ESXi host to vCenter Foundation

· ·

When running a 4 node stretched cluster environment it should be possible to use “cheaper” vCenter Server licenses, namely vCenter Foundation. One of the limitations of vCenter Foundation is that you can only manage 4 hosts with it. This is where some customers who wanted to manage a stretched cluster hit some issues. The issue occurs at the point where you want to add the Witness VM to the inventory. Deploying the VM, of course, works fine, but it becomes problematic when you add the virtual ESXi host (Witness Appliance) to the vCenter Foundation instance as vCenter simply will not allow you to add a 5th host. Yes, this 5th host would be a witness, and will not be running any VMs, and even has a special license. Yet, the “add host” wizard does not differentiate between a regular host and a virtual witness appliance.

Fortunately, there’s a workaround. It is fairly straightforward, and it has to do with the order in which you add hosts to vCenter Foundation. If you add the witness VM before the physical hosts then the appliance is not counted against the license. The license count (and allocation) apparently happens after the host has been added, but somehow vCenter does validate beforehand. I guess we do this to avoid abuse.

So if you have vCenter Foundation, and want to build a stretched cluster leveraging a 2+2+1 configuration, meaning 4 physical hosts and 1 witness VM, then simply add the Witness VM to the inventory as a host first and then add the rest. For those wondering, yes this is documented in the release notes of vSphere 6.5 Update, all the way at the bottom.

Getting a 404 error with the Host Client

· ·

Just a short post. I was getting a 404 error with the Host Client when hitting https://<ip of esxi host>/ui. No clue what it was caused by. I re-installed the latest version of the host client but that didn’t solve it. Then I noticed that my endpoints.conf had “/ local” missing. You can check that as follows when logged in through SSH:

cat /etc/vmware/rhttpproxy/endpoints.conf

I did the following (edit + restarted the HTTP reverse proxy) to get it working again:

Edit the config file:

vi /etc/vmware/rhttpproxy/endpoints.conf

add the following:

/ local 8309 redirect allow

Restart the service:

/etc/init.d/rhttpproxy restart

vMSC and Disk.AutoremoveOnPDL on vSphere 6.x and higher

· ·

I have discussed this topic a couple of times, and want to inform people about a recent change in recommendation. In the past when deploying a stretched cluster (vMSC) it was recommended by most storage vendors and by VMware to set Disk.AutoremoveOnPDL to 0. This basically disabled the feature that automatically removes LUNs which are in a PDL (permanent device loss) state. Upon return of the device a rescan would then allow you to use the device again. With vSphere 6.0 however there has been a change to how vSphere responds to a PDL scenario, vSphere does not expect the device to return. To be clear, the PDL behaviour in vSphere was designed around the removal of devices, they should not stay in the PDL state and return for duty, this did work however in previous version due to a bug.

With vSphere 6.0 and higher VMware recommends to set Disk.AutoremoveOnPDL to 1, which is the default setting. If you are a vMSC / stretched cluster customer, please change your environment and design accordingly. But before you do, please consult your storage vendor and discuss the change. I would also like to recommend testing the change and behaviour to validate that the environment returns for duty correctly after a PDL! Sorry about the confusion.

Disk.AutoremoveOnPDL

KB article backing my recommendation was just posted: https://kb.vmware.com/kb/2059622. Documentation (vMSC whitepaper) is also being updated.

Here you go, VSAN 6.2 GA!

· ·

We’ve been talking about if for a while now, but last night the moment finally arrived… VSAN 6.2 aka vSphere 6.0 Update 2 was released. I am not going to go in to any level of depth here, as I have written many posts on the subject of VSAN 6.2 already, and so has my friend Cormac, the best start is probably this blog though. You can read those if you want to get the nitty gritty details, or nerd knobs as apparently some like to call it. (I prefer to call it a healthy level of curiosity, but that is a different discussion.) Here is what is in 6.2:

  • Deduplication and Compression
  • RAID-5/6 (Erasure Coding)
  • Sparse Swap Files
  • Checksum / disk scrubbing
  • Quality of Service / Limits
  • In mem read caching
  • Integrated Performance Metrics
  • Enhanced Health Service

Now that is not it, there is also some new stuff in vSphere 6.0 Update 2, one which I feel is very welcome and that is the Host Client! A full HTML5 based client which comes as part of your ESXi host, very useful if you ask me! Also two-factor authentication was added for the Web Client, several enhancements to the vSphere APIs for IO Filtering and support for different databases for vCenter etc.

Okay, lets stop blabbing, start your download engines, find your bits here: