Yellow Bricks

by Duncan Epping

Free E-Book: Operationalizing VMware vSAN

Leave a Comment

A while ago my colleague and friend Kevin Lees reached out to me and asked me if I could go over some material he wrote together with Paul Wiggett. He also asked me if I would be willing to write a foreword. When Kevin send the document over I literally finished it within a day. What I enjoyed most about this vSAN book was the fact that it wasn’t a deep dive, it wasn’t drilling down on technology, instead the people/process aspect of things are being discussed. This is an area which is often overlooked, and definitely an area that deserves more attention when people are looking to adopt software-defined storage, or the software-defined data center for that matter. Thanks Paul/Kevin for providing me the opportunity to write the foreword, I just downloaded my free copy and I have to say it looks great.

If you are interested, the book can be downloaded for free through the VMware Virtual Blocks blog, simply go here and download your copy.

 

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.

4 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.