How To See Local RAID in ESXi 5.1

One of my work colleagues Mat Smith pointed out that when you install the generic ESXi hypervisor from the VMware site you get basic HP or Dell hardware information which is OK, but if you only have local storage you don’t know what state the underlying RAID configuration is in unless you have access to iLO or DRAC.

ESXi01 Hardware

This can be easily rectified by downloading the latest HP Custom Image for ESXi 5.1.0 ISO at the time of writing this blog post, the latest update is VMware-ESXi-5.1.0-799733-HP-5.34.23.iso

Once you have downloaded the ISO go into Update Manager > Admin View > ESXi Images and Select Import ESXi Image

ESXi Images 1

Select your the HP Custom Image for ESXi 5.1.0 ISO and click Next

ESXi Images 2

It should only take a minute or so and you will see the HP Custom Image for ESXi 5.1.0 ISO has been uploaded.  Once done hit next.

ESXi Images 3

Next we need to create a a baseline image, I’m going to roll with HP Custom Image ESXi 5.1.0 then click Finish

ESXi Images 4

Fingers crossed you should see the Imported Image

ESXi Images 5

Next we are going to go the Hosts and Clusters View and select the Update Manager Tab and then select Attach

ESXi Images 6

Select you Upgrade Baseline image and click Attach

ESXi Images 7

Next select Scan & choose Upgrades and then select Scan again

ESXi Images 8

Suprisingly enough after the scan completes you will notice that your ESXi Hosts are no longer compliant

ESXi Images 9

I tend to perform Baseline Upgrades on ESXi Hosts individual, rather than at Cluster level, just in case anything goes wrong.  With this in mind, go to your first ESXi Host and Select Remediate

Remediate 01

Select Upgrade Baseline and choose HP Custom Iage ESXi 5.1.0 and hit Next

Remediate 02

Accept the EULA and hit Next

Remediate 03

Woah, whats this message? ‘Remove installed third party software that is incompatible with the upgrade, and continue with remediation?  Word of warning you might want to check with your IT team to make sure that you aren’t going to lose any functionality.

Remediate 04

Enter a Task Name & Description and hit Next

Remediate 05

On the Host Remediation Options, make sure you tick ‘Disable any removable media devices connected to the virtual machines on the host’ as we don’t want an attached ISO to be the cause of our failure.  When you are ready hit Next

Remediate 06

On the Cluster Remediation Options, I tend to make sure that DPM is disabled and also Admission Control so that the ESXi Host can actually be patched.  Then click Next

Remediate 07

Once you are happy with your Upgrade Baseline, click Finish.  Time to go and make a brew as this is going to take along time!

Remediate 08

Awesome now that’s completed, we can see the Local Storage on the ESXi Host.

Storage View

Rinse and repeat for the rest of your ESXi Hosts.

10 Things To Check (Quickly) in vCenter

As part of my day job, I review vSphere infrastructures giving recommendations on areas which could be potential concerns.  Many of the business’s that I see engaged consultants to perform the initial installation and configuration and hand vCenter/vSphere back to the internal IT department.  Overtime, changes are made and settings are updated without consideration to what they mean.

So with this in mind, I decided to put together this blog post ’10 Things To Check Quickly in vCenter’

1. Admission Control

The whole point of admission control is to ensure that you have the redundancy within your infrastructure to tolerate a failure of some description, more often than not this is N+1.  So check your admission control is first of all enabled and secondary it is set correctly e.g. 2 x ESXi Hosts should be 50% CPU and 50% Memory

I have seen countless installations where this has been turned off to enable an new VM’s to be ran and the hosts where never upgraded to compensate for this increase in workload.

Admission Control

2. DAS Isolation Address

The default setting is a single isolation address which is your default gateway.  What happens if this goes down in a vSphere 4.1 environment? Well man down is the reaction!  Ensure that you specify numerous IP address, I commonly go for:

1. Layer 2 switch IP address used for vMotion/FT

2. SAN management IP address

3. LAN/Management  default gateway IP Address

DAS Isolation

3. VM Monitoring

Turn this on, I know the default is disabled, but that’s not an excuse.  Why wouldn’t you want vSphere to monitor your VM’s and restart them if it has no network or datastore activity?

VM Monitoring

4. VM Restart Priority

Let’s start with the premise that not all virtual machines are equal.  If you have virtualised Domain Controllers you would want these to be high priority restarts, followed by SQL and then application servers that connect to SQL.  I wrote a blog post on this a while back click me.

Take a few minutes and check with your server team to ensure that if you do have a failure then you have done your best to bring applications up in the right order.

VM Restart Priority

4. DRS Rules

Spend some time working with application team creating sensible DRS Anti Affinity and Affinity rules.  Some examples are:

  • Anti Affinity – Domain controllers to be running on the same ESXi host?
  • Anti Affinity – SQL Cluster with RDM
  • Anti Affinity – XenApp/Terminal Server farm members
  • Affinity – BES and SQL

Anti Affinity

5. VMware Update Manager

I quite often see environments where VMware Update Manager hasn’t been installed and if it has you can almost guarantee that the ESXi Hosts/VM/vApp haven’t been patched.

Without being flippant, there is a reason my VMware release patches/updates which is generally for bug fixes or security issues.


6. Alerting

Check to make sure that you have a valid SNMP/SMTP server setup, as after infrastructure migrations these settings can often be wrong.

Also take some time to configure alerting at ‘root’ level in vCenter to make sure they meet you business needs.  If you aren’t sure what to implement, I wrote a couple of blog posts on this subject to get you started:

Setting Up & Configuring Alarms in vCenter 5 Part 1

Setting Up & Configuring Alarms in vCenter 5 Part 2


7.  Time Configuration

Virtual Machines take there initial time settings from the ESXi host.  We all know what dramas can happen if your virtual machines are more than 15 minutes out of sync with your domain controllers.  Use your internal domain controllers as your NTP Servers for your ESXi Hosts, it stops unnecessary NTP traffic going traversing firewalls and ensures that you won’t be affected with time skew.

NTP Servers

8. Virtual Machines With ISO’s Attached

We all pop ISO’ onto Local Storage on ESXi Hosts as it’s not taking up valuable space on our SAN.  The worse thing we can do is forget that we have them attached as if HA needs to come into action, these VM’s are going to fail.

Either check your Local Datastores on a regular basis or if you have lots of ESXi Hosts, then use tools such as PowerGUI with the VMware Management pack installed to script it.

HA Failure

9. Hot Add Memory/CPU

Virtual Machine workloads change over time, why cause unnecessary downtime and potential evening or weekend work for yourself? Make sure that you enable Memory and CPU Hot Add on your templates.

Hot Add

10. Resource Pools

The golden rule is know what you are doing with resource pools as if you go into resource contention they are going to come into play. I have seen resource pools used as containers/folders, resource pools created at cluster level to protect ‘high importance’ VM’s which result in these VM’s having less resources to use! A quick explanation of this can be found over at Eric Sloof’s site NTPRO.NL

Resource Pools

Relay vCenter Alert Emails Externally

I was fortunate enough to have a second post published on the VMware SMB Blog site.  This particular post is an issue that I faced quite a while back, but it still holds true if you are trying to relay vCenter alerts externally.

From the Bloggers Bench: Relay vCenter Alert Emails Externally

When configuring your vCenter environment, most if not all VMware Administrators will set up email alerting. I covered the configuration of this in Setting Up & configuring Alarms In vCenter Part 1.

Unfortunately, if you leave Exchange 2010 using its Default Receive Connector, you will only receive alerts internally e.g. to the domains which Exchange 2010 is authoritative. This causes a problem if you need to send alerts to a third party e.g. Managed Service Provider.

To demonstrate the issue, I have connected to a vCenter server and then I’m going to telnet to an Exchange 2010 CAS Server on port 25 by issuing the command:

telnet VMF-EX01 25

Once in enter the following:

<Press Enter>
<Press Enter>

Read more over at the VMware SMB Blog

How To Configure WOL ESXi5

Distributed Power Management is an excellent feature within ESXi5, it’s been around for a while and essentially migrates workloads to fewer hosts to enable the physical servers to be placed into standby mode when they aren’t being utilised.

Finance dudes like it as it saves ‘wonga’ and Marketing dudettes like it as it give ‘green credentials’.  Everyone’s a winner!

vCenter utilises IPMI, iLO and WOL to ‘take’ the physical server out of standby mode.  vCentre tries to use IPMI first, then iLO and lastly WOL.

I was configuring Distributed Power Management and thought I would see if a ‘how to’ existed and perhaps my  ‘Google magic’ was not working, as I couldn’t find a guide on configuring WOL with ESXi5.  So here it is, let’s crack on and get it configured.

Step 1

First things first, we need to check our BIOS supports WOL and enable it.  I use a couple of HP N40L Microservers and the good news is these bad boys do.

WOL Boot

Step 2

vCenter uses the vMotion network to send the ‘magic’ WOL packet.  So obviously you need to check that vMotion is working.  For the purposes of this how to, I’m going to assume you have this nailed.

Step 3

Check you switch config. Eh don’t you mean my vSwitch config Craig? Nope I mean your physical switch config.  The ports that your vMotion network plugs into need to be set to ‘Auto’ as for WOL to work the ‘magic’ with certain manufacturers this has to go over a 100Mbps network connection.


Step 4

Now we have checked our physical environment, let’s check our virtual environment.  Go to your ‘physical adapters’ to determine if WOL is supported.

This can be found in the vSphere Web Client (which I’m trying to use more) under Standard Networks > Hosts > ESXi02 > Manage > Networking > Physical Adapters


We can see that every adapter supports WOL except for vmnic1.

Step 5

So we need to check our vMotion network to ensure that vmnic1 isn’t being used.

Hop up to ‘virtual switches’ and check your config.  Good news is I’m using vmnic0 and vmnic2 so we are golden.


Step 6

Let’s enable Distributed Power Management. Head over to vCenter > Cluster > Manage > vSphere DRS > Edit and place a tick in Turn ON vSphere DRS and select Power Management.  But ensure that you set the Automation Level to Manual. We don’t want servers to be powered off which can’t come back on again!


Step 7

Time to test Distributed Power Management! Select your ESXi Host, choose Actions from the middle menu bar and select All vCenter Actions > Enter Standby Mode


Ah, we have a dialogue box appear saying ‘the requested operation may cause the cluster Cluster01 to violate its configured failover level for high availability.  Do you want to continue?’

The man from delmonte he says ‘yes’ we want to continue!  The reason for the message is my HA Admission Control is set to 50%, so invoking a Host shut down is violating this setting.


vCenter is rather cautious and quite rightly so.  Now it’s asking if we want to ‘move powered off and suspended virtual machines to other hosts in the cluster’.  I’m not going to place a tick in the box and will select Yes.


We have a Warning ‘one or more virtual machines may beed to be migrated to another host in the cluster, or powered off, before the requested operation can proceed’.  This makes perfect sense as we are invoking DPM, we need to migrate any VM’s onto another host.


A quick vMotion later, and we can now see that ESXi02 is entering Standby Mode


You might as well go make a cup of tea as it takes the vSphere Client an absolute age to figure out the host is in Standby Mode.


Step 8

Let’s power the host back up again.  Right Click your Host and Select Power On

WOL 10

Interestingly, we see the power on task running in the vSphere Web Client, however if you jump into the vSphere Client and check the recent tasks pane, you see that it mentions ‘waiting for host to power off before trying to power it on’

WOL 11

This had me puzzled for a minute and then I heard my HP N40L Microserver boot and all was good with the world.  So ignore this piece of information from vCenter.

Step 9

Boom our ESXi Host is back from Standby Mode

WOL 12

Rinse and repeat for your other ESXi Hosts and then set Distributed Power Management to Automated and you are good to go.

vSphere Web Client: No vCenter

Following on from previous blog post vSphere Web Client: Provided Credentials Are Invalid we have logged into the vSphere Web Client but we don’t actually have anything we can manage.  I think the words we are looking for are ‘man down’.

It all boils down to permissions, we need to logout from the vSphere Web Client and fire up our old trust friend the vSphere Client.

Login with the user credentials you would need to access vCenter Server Appliance, the defaults are U: root P: vmware

vCenter 1

Ah ha, now we see our vCenter (I’m sure you weren’t concerned that all your config had gone)

vCenter 2

Right Click the root level and Add Permission

vCenter 4

Select Assigned Roles and change this to Administrator and then Click Add

vCenter 5

Select your Domain, and change the View to Show Groups First and select Domain Admins and then Add.  Naturally you might not want Domain Admins to have access in the ‘real world’ so select the appropriate Security Group.

vCenter 6

You should see that your DomainDomain Admins appears under ‘Groups’ Hit OK

vCenter 7

Then Hit OK again to confirm

vCenter 8

TOP TIP: Make sure Propagate to Child Objects is ticked

Exit the vSphere Client and login to the vSphere Web Client using https://<IP Address>:9443/vsphere-client/

vCenter 9

Boom, we have a vCenter Server, Hosts and everything!