Yellow Bricks

by Duncan Epping

Device X is not listed on the vSAN Compatability Guide, can I still use it?

Leave a Comment

I get this question almost daily, and I am pretty sure I have said this various times, but just in case it wasn’t clear I figured I would share the answer to the question whether a device should be used in a vSAN cluster when it is not listed on the vSAN Compatibility Guide? if you have not looked at the components variant of the VCG for vSAN please take a look here: http://vmwa.re/vsanhclc. Of course, we also have an easier route, which is the ReadyNode VCG. But some may want to tweak based on performance, cost etc. I get that, and so does VMware, that is why we have listed all supported and tested components. Can you use a device which is not listed? Sure you can. Will VMware support the environment? Maybe they will, maybe they won’t! Should you use a device which is not listed if the previous answer is maybe? No!

So let’s be clear and let’s answer the two most asked questions:

  • Device X is not listed on the vSAN Compatability Guide, can I still use it?
    • No, you should not. If any problem arises chances are you will not get the support you need as a result of an unsupported configuration. Sure, usually VMware Support will do their best to help, but if it appears the unsupported device is causing the problem then it becomes difficult. Please do not use devices which are not listed
  • Device X is listed with Firmware version Y, but the OEM says I should use Z, what to do?
    • Ask the OEM why the version is not listed on VMware’s VCG website. Vendors are responsible for certifying components and the software (drivers / firmware) associated with it. If it is not listed then it has either not been submitted yet, it has not been tested, or it has not passed the test. Please only use tested and listed versions, the only exception is when both VMware GSS and the OEM points you to a new version.

Hope that helps,

This host has no isolation addresses defined as required by vSphere HA

Leave a Comment

I had a comment on one of my 2-node vSAN cluster articles that there was an issue with HA when disabling the Isolation Response. The isolation response is not required for 2-node as it is impossible to properly detect an isolation event and vSAN has a mechanism to do exactly what the Isolation Response does: kill the VMs when they are useless. The error witnessed was “This host has no isolation addresses defined as required by vSphere HA” as shown also in the screenshot below.

This host has no isolation addresses defined as required by vSphere HA

So now what? Well first of all, as mentioned in the comments section as well, vSphere always checks if an isolation address is specified, that could be the default gateway of the management network or it could be the isolation address that you specified through advanced setting das.isolationaddress. When you use das.isolationaddress it often goes hand in hand with das.usedefaultisolationaddress set to false. That last setting, das.usedefaultisolationaddress, is what causes the error above to be triggered. What you should do in a 2-node configuration is the following:

  1. Do not configure the isolation response, explanation to be found in the above-mentioned article
  2. Do not configure das.usedefaultisolationaddress, if it is configured set it to true
  3. Make sure you have a gateway on the management vmkernel, if that is not the case you could set das.isolationaddress and simply set it to 127.0.0.1 to prevent the error from popping up.

Hope this helps those hitting this error message.

Unexpected VMware Update Manager (VUM) baseline creation failure. Please check vSAN and VUM logs for details.

3 Comments

I had a customer asking about an error they received after upgrading to 6.7 U1. The message they saw was the following: “Unexpected VMware Update Manager (VUM) baseline creation failure. Please check vSAN and VUM logs for details.” I had seen some folks on VMTN also complaining about this a couple weeks ago, and I knew a KB article was in the makings. Just to ensure people know where to get it, and to make it easier for myself to find it I want to share KB 60380 with you. I am not going to copy/paste the resolution, as I prefer to have the KB being leading on this, just in case it gets updated. I don’t want to provide potentially outdated info. So just go to KB 60380 if you are hitting the “Unexpected VMware Update Manager (VUM) baseline creation failure. Please check vSAN and VUM logs for details.” error.

Disable Dark Mode for Outlook in OSX?!

9 Comments

Yes, after the latest update MS Office is now also capable of supporting the OSX Dark Mode. Nice, but rather annoying for MS Outlook I must say, the dark mode just makes reading the different panes very challenging. I went looking for an option in the UI that allowed me to change the default, I couldn’t find it, unfortunately, but I did find a way to disable it through the command line. For MS Outlook, in particular, this is how you do it:

defaults write com.microsoft.Outlook NSRequiresAquaSystemAppearance -bool yes

You can do this for other apps as well if you want, simply change the identifier string of Outlook (com.microsoft.Outlook) with the string of the app you want to disable it for. If you don’t know the string you can do the following to find it:

osascript -e 'id of app "Outlook"'

In the above example, I am looking for the identifier of Outlook, but this could be “Spotify” or anything else as well of course. Figured I would share this, as I found myself searching for half an hour. Note that you need to close/open the app after making the change!