Yellow Bricks

by Duncan Epping

ESX

Definition of the advanced NFS options

· ·

An often asked question when implementing NFS based storage is what do these advanced settings represent you are recommending me to change?

VMware published a great KB article which describes these. For instance:

NFS.HeartbeatMaxFailures
The number of consecutive heartbeat requests that must fail before the server is marked as unavailable.

The KB article does not only explain the separate NFS settings but also how you can calculate how long it can take before ESX marks a NFS share as unavailable. Good stuff, definitely highly recommended!

vSphere Security Hardening Guide script by @lamw

· ·

A couple of weeks ago I blogged about the vSphere Security Hardening Guide. Just a couple of days later William “the king of Perl” Lam already produced a script that checks the Hardening Guide best practices against your environment. It produces a great html based report.

Source

While going through the COS/HOST and VM documentation, I noticed there were quite a few checks that might benefit from having a script to validate the guidelines and that was the motivation for this script. Not all sections can be validated using the vSphere APIs and will require some manual validation and I’ve seperated the types of passes whether it’s a fail, pass or manual (which requires user intervention).

The script allows you to run the current existing guides as of (01/29/2010) against vCenter 4.0 hosting ESX(i) 4.0 hosts/virtual machines OR run it against an individual ESX(i) 4.0 host. The script allows you to run a subset of the checks and against different type of validation (ENTERPRISE,DMZ or SSLF). Upon completion, a report is generated including a grade for your environment.

A couple of details on the features:

  • Email report
  • Ability to execute subset of the checks (COS,HOST,VCENTER,VNETWORK,VM)
  • Ability execute specific test suite (ENTERPRISE,DMZ,SSLF)
  • Detail HTML summary report with letter grade

You can find an example report here. Great work again William, keep it up!

Storage Masking?

· ·

I received a bunch of questions around storage masking over the last couple of weeks. One of them was around VMware’s best practice to mask LUNs on a per cluster basis. The best practice has been around for years and basically is there to reduce conflicts. More hosts accessing the same LUNs means more overhead, just to give you an example every 5 minutes a rescan of both HBAs takes place automatically to check for dead storage paths. You can imagine that there’s a difference between 64 hosts accessing your storage or limiting it to for instance 16 hosts. Also think about things like the failure domain you are introducing, what if an APD condition exists, this now doesn’t just impact 1 cluster… It could impact all of them.

For vSphere 5.1 read this revision…

The obvious next question is, won’t I lose a lot of flexibility? Well in a way you do as a simple VMotion to another cluster will not work anymore. But of course there’s always a way to move a host to a different cluster. In my design I usually propose a so called “Transfer Volume”. This Volume(NFS or VMFS) can be used to transfer VMs to a different cluster. Yes there’s a slight operational overhead here, but is also reduces overhead in terms of traffic to a LUN and decreases the chance of scsi reservation conflicts etc.

Here’s the process:

  1. Storage VMotion the VM from LUN on Array 1 to Transfer LUN
  2. VMotion VM from Cluster A to Cluster B
  3. Storage VMotion the VM from Transfer LUN to LUN on Array 2

Of course these don’t necessarily need to be two separate arrays, it could just as easily be a single array with a group of LUNs masked to a particular cluster. For the people who have a hard time visualizing it:

RVTools 2.8

· ·

Rob de Veij just released a brand new version of RVTools. Download it while it is still hot! Please note that this application supports ESX(i) Server 3.5 and vCenter 2.5. vSphere 4 is in experimental support.

Latest Version: 2.8 | January 31, 2010
Download | Documentation

  • On vHost tab field “# VMs” now only powered on VMs are counted.
  • On vHost tab field “VMs per core” now only powered on VMs are counted.
  • On vHost tab field “vCPUs per core” now only powered on VMs are counted.
  • On vDatastore tab field “# VMs” now only calculated for VM’s which are powered on.
  • Health check “Number of running virtual CPUs per core” now only powered on VMs are counted.
  • Health check “Number of running VMs per datastore” now only powered on VMs are counted.
  • During Installation there will be an application event source created for RVTools. This to fix some security related problems.
  • Some users run into a timeout exception from the SDK Web server. The default web service timeout value is now changed to a higher value.
  • New fields on vHost tab: NTP Server(s), time zone information, Hyper Threading information (available and active), Boot time, DNS Servers, DHCP flag, Domain name and  DNS Search order
  • New Health Check: Inconsistent folder names.
  • Improved exception handling on vDisk, vSwitch and vPort tab pages.

Draft version of the vSphere Security Hardening Guide available

· ·

VMware published the draft version of the vSphere Security Hardening Guide. Keep in mind that it’s still draft and needs tweaking. The Team needs your feedback, so if you have any comments please don’t hesitate to reach out and leave a comment on the community forums.

Overall, there are more than 100 guidelines. The guide itself is split into the following major sections:

Please bare in mind the following:

Another new aspect of the guide is the desire to create it with input from the VMware community. This draft is available for public comment for a period of approximately one month. VMware’s intention is to incorporate public feedback into the next revision of the guide, which will be the final version. However, this current revision is the result of a private review of an initial draft, and so we believe that the final version will not differ too significantly. This revision can therefore be used for customer production deployments today, with the caveat that some new guidelines might be added and some existing ones slightly modified.

Thanks Charu for posting these! They contain really valuable info.