How to get the Firmware Version of your hardware

If you are looking to see if the Firmware on your ESXi 5.0 host is upto date, you need to find out what it is right now, so try these commands for the basic items.

1. In ESXi 5.0, run this command:
   
   # esxcli network nic list
2. or this still works

# esxcfg-nics -l

1. You will get something like this:

Name    PCI         Driver Link Speed    Duplex MAC Address
vmnic0  00:02:04.00 ACME   Up   1000Mbps Full   01:23:45:67:89:AB
vmnic1  00:02:05.00 ACME   Up   1000Mbps Full   01:23:45:67:78:AC

Now use the ethtool command to get the info:

# ethtool -i vmnic0

driver: ACME
version: 1.2.3a-1vmw
firmware-version: 7.8.9
bus-info: 0000:02:04.00

For HBAs: Check this link out Get Firmware Version

To obtain the driver version of a Host Bus Adapter on an ESX/ESXi host:

1. Obtain the driver type that the Host Bus Adapter is currently using:
   
   # esxcfg-scsidevs -a
   
   This will produce an output similar to:
   
   vmhba0  ata_piix          link-n/a  ide.vmhba0                              (0:7.1) Intel Corporation Virtual Machine Chipset
   vmhba1  mptspi            link-n/a  pscsi.vmhba1                            (0:16.0) LSI Logic / Symbios Logic LSI Logic Parallel SCSI Controller
   vmhba32 ata_piix          link-n/a  ide.vmhba32                             (0:7.1) Intel Corporation Virtual Machine Chipset
   
   Note: The second column shows the driver that is configured for the HBA.
2. Use the following command to see what driver version is being used:
   
   # vmkload_mod -s HBADriver |grep Version
   Taking the the mptspi driver as an example:
   
   # vmkload_mod -s mptspi |grep Version
   Version: Version 4.00.37.00.30vmw, Build: 721907, Interface: 9.0, Built on: May 18 2012
   
   From the above output you can see the driver version is 4.00.37.00.30vmw
3. To check to see what driver is recommended for that card we need to get the VID (Vendor Id), DID (Device Id), SVID (Sub-Vendor Id) and SDID (Sub-Device Id)
   
   # vmkchdev -l |grep vmhba1
   000:16.0 1000:0030 15ad:1976 vmkernel vmhba1
   In the above cases the VID=1000, DID=0030, SVID=15ad, SDID=1976
4. You can now search the VMware Compatibility Guide for VID (Vendor Id), DID (Device Id), SVID (Sub-Vendor Id) and SDID (Sub-Device Id) or in some cases you may need to do a text search here to narrow down the particular card. You can check the version of the ESX/ESXi with following command

# vmware -v

Prevent Admins from Doing Stuipd Things in vCenter

Role Based Access Controls, or RBAC is very useful in vCenter. I know many of you simply have your own vCenter server, it's only you and you aren't good at sharing. We all have kindergarten issues.

But it the real world you try and fork off as much of your own work on other people in your organization as you can. In this vein, you now have to realize that not everyoen is as smart or careful as you.

RBAC provides a granular role for each set of users. Think of the roles you may have:
- Close Support (Help Desk)
- System Admins
- Application Admins
- SuperUsers
- Root Admins

Close support is your "on the ground" people that have great proceedures that you have written up so that they can fix 75% of the basic problems without escalating to 2nd level tech support. (You did make proceedure guides for all your basic processes, right?) You may want close support to:
 - View server status
 - View server performance
 - Reboot a server
 - Power on/off a server

But you probably don't want them changing the number of vCPUs, changing memory, mounting other vmdk file to the server, deleteing the server, or creating a WoW server on your network.

System Admins may be assigned to all VMs at a hardware level. But for data security reasons, you may not want them adding existing disks to a server. They can create new VMs, but maybe only from a template. Creating from a template keep them from allocating too much space, or connecting a VM to the wrong network (Port group/VLAN). Using Templates and Customization Specifications, you can require them to provision new VMs only from templates and ask only for a few items when deploying the template. The rest would be hard coded into the template and the specification.


To do this you need a couple of roles created. We'll call them:

• CustomizationAccess
• DeployTemplate

For Deploy template we need several permissions.

• Datastore
• • Browse Datastore
  • Allocate Space (for vSphere 4.0)
• Virtual Machine
• Configuration
• Add new disk
• Interaction
• Select ALL options
• Inventory

• Create

Provisioning

• Customize
• Deploy Template

Resource

• Assign Virtual Machine to Resource Pool

For CustomizationAccess you will need

• Virtual machine
• Provisioning
• Modify customization specification
• Read customization specification

That is IT. Now you will assign the CustomizationAccess role at the vCenter level. That's top of the top. So go to Host and Clusters and right click on Your vCenter server name it will have the icon below next to it.

Choose Add Permission and select the CustomizationAccess role. Choose the group or groups that you want to have access and add the permission.
Now we have to give that group access to their resources. We will assume the group is called Tech. Assign the role DeployTemplate at the following locations.

• Hosts and Clusters
• Datacenter
• Resource Pool - Tech
• VMs and Templates
• Datacenter
• Folder - Tech
• Datastores
• Datacenter
• Folder - Tech

This will give them access to the resources that they need to deploy the VMs.

Pro Tip:

If you have DRS enabled on the cluster, but you have it set to MANUAL, then the VM will NOT be able to be powered up by the Tech Group. It will NOT show an error, it will just silently fail and stay off.