• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

hcl

What if the disk controller driver included in my vendor’s ESXi image is not on the vSAN HCL?

Duncan Epping · Jan 15, 2021 · 7 Comments

Sometimes unfortunately there are situations where a vendor’s ESXi image includes a disk controller driver that is not on the vSAN HCL/VCG (VMware Compatibility Guide). Typically it is a new version of the driver which is supported for vSphere, but not yet for vSAN. In that situation, what should you do? So far there are two approaches I have seen customers take:

  1. Keep running with the included driver and wait for the driver to be supported and listed on the vSAN HCL/VCG
  2. Downgrade the driver to the version which is listed on the vSAN HCL/VCG

Personally, I feel that option 2 is the correct way to go. The reason is simple, vSphere and vSAN have different certification requirements for disk controllers and the vSAN certification criteria are just more stringent than vSphere’s. Hence, sometimes you see vSAN skipping certain versions of drivers, this usually means a version did not pass the tests. Now, of course, you could keep running the driver and wait for it to appear on the vSAN HCL/VC. If however, you hit a problem, VMware Support will always ask you first to bring the environment to a fully supported state. Personally, I would not want the extra stress while troubleshooting. But that is my experience and preference. Just to be clear, from a VMware stance, there’s only one option, and that is option two, downgrade to the supported version!

Single socket vSAN ready node AMD EPYC Rome on the VCG!

Duncan Epping · Oct 8, 2019 · 3 Comments

Yesterday I tweeted something and I want to reiterate it to make sure that those who are just following the blog, and not my twitter account, also are aware. On the vSAN Compatibility Guide (VCG) there were already a number of single-socket servers, but most of these were limited in terms of CPU/MEM resources. Last week two new servers were added to the VCG. These servers are based on the AMD EPYC Rome CPUs and can have up to 64 cores. Yes, 64 cores per CPU. They can go up to 2TB worth of memory, depending on the DIMMS used, also while on the topic of memory, the NUMA implementation completely changed with AMD EPYC Rome, but I am sure Frank Denneman will have something to say about that soon. Why would I bring these servers up? Well, for those looking to do 2-node vSAN configurations or smaller vSAN clusters, they could be a great alternative solution! Heck, I would consider them in general I think.

Two new Dell – AMD EPYC Rome based ReadyNode configs were recently added to the vSAN HCL. Single socket, 32 or 64 cores. Pretty sweet! https://t.co/FwppsLfWMQ

— Duncan Epping (@DuncanYB) October 7, 2019

Startup update: Runecast 2.0

Duncan Epping · Aug 21, 2018 ·

Last week I was briefed by Runecast (together with Cormac) on the new version, Runecast 2.0, which was released/announced today. I always enjoy talking to Stan as every time we talk they have something new which surprises me, or he tells me about something cool on the roadmap. For those who did not read my previous articles, Runecast is a company which focusses on analyzing VMware environments and assess the environment on potential issues. These issues could be anything ranging from configuration issues, driver/firmware issue, to security issues. It reminds me very much of what we have with vSAN which is the health check. The big difference though is that this solution includes many more checks and doesn’t just focus on vSAN but on many different parts of the stack. Just to give you an idea, today Runecast can analyze your vSphere environment up to vSphere 6.7 and can also analyze vSAN and NSX-V. The cool thing is that it also does this “offline”, they have an appliance and regular updates (rules and features) and this means that even in a dark site this would work.

A lot of Runecast’s customers are either in the financial space or government space. I guess this is also why their focus for the 2.0 version was primarily on PCI-DSS. With over 200 technical checks, which map against PCI-DSS requirements, they (as Runecast told me) have by far the largest collection of requirements in an automated analyzer (for VMware) in the industry. Definitely, a smart enhancement, if you are not interested in PCI-DSS, you can simply disable the whole check and it will never show up in your interface. You can also, if only a limited number of clusters should be validated, filter out certain results.

The 20 version of Runecast also comes with a lot of updates around the appliance, now I consider these “internals” as for most customers it is not relevant in terms of the value it offers, but it is important to know from a security perspective I guess.

This version also introduces a historical perspective. Meaning that starting with Runecast 2.0 the historical information of checks is stored. This will allow you to see some form of trending when it comes to the different checks/validations. You could for instance now track if you do updates and maintenance if the number of potential issues is going down. You could also task someone with validating the reported issues and fixing those when or where possible. This should over time improve the availability, reliability, and security of your environment.

Last but not least the UI has been fully overhauled. They redesigned it just to make it easier to read and understand. Also, a couple of dashboards were added, which makes sense… a new release means new dashboards!

If you happen to go to VMworld, make sure to stop by their booth and have a look, I think you will find it interesting. Or simply read the Runecast blog, and download the appliance and try it out.

Startup update: Runecast

Duncan Epping · Feb 16, 2018 ·

A while ago I introduced Runecast on my blog. I have known these guys for a while and this week I had to pleasure to be briefed on their new release: Runecast 1.7. The big ticket item in this release for sure it the vSAN Support. You may ask yourself why you would need Runecast when you have things like the health check and the “online” health check, well it seems that Runecast’s implementation covers more detail. Anyway, what is Runecast? As a company they refer to themselves as the knowledge automation experts, and I think that is a fair statement.

Runecast has developed an appliance which can be connected to one or multiple vCenter Server instances. After linking these you can “scan” the environment and Runecast will tell you about the risks. Not just from a security perspective, but it will also assess logs, configuration and even best practices. Your whole environment will be assessed in a report will be provided in a simple HTML-5 interface, or in the Web Client or the vSphere H5 client even. I said “simple”, but the information provided and the detail is far from simple… When I say simple I refer to their user interface. It is slick, and very easy to use.

Since I discussed Runecast last they added some additional features, like for instance a VRO plugin, full rest API, improved log search, Web Client and H5 client plugins but more importantly for many government agencies: DISA STIG compliancy checks. Yes, Runecast can check your environment against DISA STIG and report on any potential issues. Nice right?

This new release, version 1.7, now brings vSAN support. It also includes a new dashboard widget, which provides faster insights in how your environment is behaving. For vSAN in particular they didn’t only include KB article checks, but also implemented all best practices from the Design and Sizing guide, Network Design guide and the Stretched Cluster white paper. And they even hinted about adding best practices which are listed in the Essential vSAN book Cormac and I wrote, how cool is that? What is also nice is that their appliance is supported with vSAN 5.x and 6.x, and requires no direct access to the internet. You can simply download the appliance and install, and then update with the latest dataset by downloading an ISO.

Oh and before I forget, of course they also provide all the guidance and info needed around Spectre/Meltdown. Where normally their trial is limited, they actually do provide ALL info needed for Spectre/Meltdown as they realized that this is very valuable to customers and felt they could not hold this back.

For the Runecast blog on the 1.7 release go here.

Check your VSAN disk controllers against the HCL with PowerCLI

Duncan Epping · Feb 24, 2016 ·

Every now and then customers ask if it is possible to check if disk controllers are on the VSAN HCL (Or VMware Compatibility Guide (VCG) as it is actually called these days) for a given set of hosts through PowerCLI. Alan Renouf figured he would knock something out, thanks Alan for sharing! (Next up would be validate drivers and firmware of all components, thanks!) What this script does is the following, note that you need internet access for this to work:

  • Connect to vCenter
  • Download latest VSAN HCL details (json file)
  • Compare controllers of each host against the VSAN HCL
  • Report the state of your infra

Here is the script, it can also be found in the VMware Developer Center repository by the way.

Connect-VIServer myvcenter -user Administrator -password MyPass23
 
 
Function Get-CompatibleVSANController {
    if (-Not $vSANHCL) {
        $vSANHCL = Invoke-WebRequest -Uri http://partnerweb.vmware.com/service/vsan/all.json | ConvertFrom-Json
    }
    $vSANHCL.data.controller
}
 
$HBAs = get-vmhost | Get-VMHostPciDevice | where { $_.DeviceClass -eq "MassStorageController" }
 
Foreach ($HBA in $HBAs) {
    $HBAFound = $false
    Write-Host "Looking for $($hba.name) from host $($HBA.VMhost)"
    Foreach ($entry in Get-CompatibleVSANController) {
        $vid = [String]::Format("{0:x}", $HBA.VendorId)
              $did = [String]::Format("{0:x}", $HBA.DeviceId)
              $svid = [String]::Format("{0:x}", $HBA.SubVendorId)
        $ssid = [String]::Format("{0:x}", $HBA.SubDeviceId)
        If (($vid -eq $entry.vid) -and ($did -eq $entry.did) -and ($svid -eq $entry.svid) -and ($ssid -eq $entry.ssid) ) {
            Write-Host " HBA in $($HBA.VMHost) is $($HBA.Name) which can be found in the HCL as $($Entry.vendor) - $($Entry.Model) at the following URL: `n $($entry.vcglink)" -ForegroundColor Green
            $HBAFound = $true
        }
    }
    If (-Not $HBAFound){
        Write-Host " $($HBA.Name) in $($HBA.VMHost) is not found!" -ForegroundColor Red
    }
}

If you run it the output will look like this:

  • Go to page 1
  • Go to page 2
  • Go to Next Page »

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007) and the author of the "vSAN Deep Dive" and the “vSphere Clustering Technical Deep Dive” series.

Upcoming Events

14-Apr-21 | VMUG Italy – Roadshow
26-May-21 | VMUG Egypt – Roadshow
May-21 | Australian VMUG – Roadshow

Recommended reads

Sponsors

Want to support us? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2021 · Log in