vCenter Alarms not triggering

I’ve recently just finished upgrading our vSphere environment from ESX4.0 to ESXi4.0 and encountered a strange issue with alarms.  We have custom alarms for when a datastore is overprovisioned and when a snapshot exists.  When building our two new vCenter 4.1 servers I configured these alarms so they were ready for when I connected the ESX hosts ready to rebuild.  Once I connected all our ESX hosts and add the VM’s to the inventory none of the alarms would trigger.  I knew we had datastore’s that were overprovisioned and I also created a snapshot for a VM to see if the alarm would trigger.  None of the custom alarms would trigger.  In order to resolve this I had to go into the alarm definition, disable the alarm, OK the command and then re-enable:

Obviously this had something to do with me creating the alarms before having any VM to apply it to.  Just something to watch out for.

SRM 4.1 Installation Error – XML Document is Empty

After installing and configuring the array manager in SRM 4.1 I received the following error message:

I had installed SRM 4.1 and the EMC MirrorView Site Recovery Adapter version 1.4.01 as we have two EMC CX4-240 SAN’s.  After looking at the installed software on our current SRM 4.0 installation is looks like I needed the Solutions Enabler software from the EMC PowerPath site.  I uninstalled the EMC SRA and installed the x64bit version of the Solutions Enabler, reinstalled the SRA and restated the SRM service.  After this I was still receiving the error message listed above.  I noticed that the SRA was x86 so I installed the x86 version of the Solutions Enabler and this worked successfully.

Book Review – Maximum vSphere by Eric Siebert

I’ve just finished reading the excellent Maximum vSphere book by Eric Siebert.

The book is 14 chapters long with 363 pages and contains information regarding vSphere (mainly 4.0 but also references 4.1).  I found this book an extremely thorough and found a lot of information that I previously didn’t know.  I was extremely impressed with Chapter 7 which contains information on monitoring performance within vSphere.
Simon Seagrave also produced some content for the book which I think was Chapter 14 which was how to go about building your own vSphere lab.  Once again, another excellent chapter which contained a wealth of information.

Using vMA 4.1

In my previous post I showed you how to configure vMA 4.1 and integrate it into your existing network.  This post is all about actually using the vMA appliance and running commands against remote ESX/ESXi servers.
You can connect to your vMA server using either the vSphere client console or putty.  Putty is a free telnet/ssh client and is my preferred choice.  Download the .exe and connect to the IP address of your vMA appliance:

Login with the username vi-admin and password you configured in the previous post.  Once you have successfully authenticated you will see the vMA command line:

First thing we are going to do is enable the vi-user account.  This account has limited privileges on the ESX/ESXi systems and cannot run any vilogger commands or any commands that require sudo execution.
Run the following linux command to set a password for the vi-user account.  After you run the command you will be prompted to enter a new password and confirm it:
sudo passwd vi-user

After the vi-user account has been enabled it will have normal privileges on the vMA but it is not in the sudoers list.  The vi-user account will also have read only privileges on the target ESX/ESXi systems.  To make any configuration changes on target ESX/ESXi systems you will have to use the vi-admin account.
We are now going to add an ESXi system as a target for the vMA.  Login to the vMA as the vi-admin user account and enter the following command:
vifp addserver <Server>
When prompted enter the servers root password to authenticate.  The vMA will authenticate and add two users accounts to the host.  The vi-admin and vi-user will be added to the host and the encrypted password will be stored in the VMware credential store:

Connecting directly to the host using the vSphere client and viewing the Local Users & Groups shows that the two accounts have been added to the host:

To verify that the target server has been added issue the following command:
vifp listservers

To set the target as the default host for the current session issue the following command:
vifptarget –s <Server>

As you can see, the command prompt has changed to show that you are now under the context of the ESX1.m80arm.local host.  This shows that you are connected to that host and any command that you issue will be run on that host.  The command issued below lists the physical network cards of the ESXi host:

In order to remove a server as a target from the vMA simply issue the following command:
vifp removeserver <server>

This post is a simple guide on how to add a remote ESX/ESXi host as a target to your vMA and run a simple command against the host remotely.  Obviously this is more directed towards ESXi which doesn’t have service console rather than ESX.  You could, if you wish use Active Directory to authentication against your vMA and against you ESX/ESXi servers.  I recommend you read the vSphere Management Assistant Guide for more information and advanced options.  In the next post I’ll show you how to configure your vMA to retrieve logs files from ESX/ESXi servers.

Configuring vMA 4.1

In my previous post I showed you how to deploy vMA 4.1 into your Virtual Infrastructure Environment.  In this post I’m going to show you how to configure vMA and integrate it into your existing network.  If you followed my previous post you should have a powered off VM deployed from the vMA .ovf file:

Power on the VM, open a console session to the VM and wait for it to boot up:

Once the VM has booted you will be asked if you want to assign an IP address to the VM using DHCP.  Select your required option.  In this example I will be setting a static IP address up for the VM so I will be selecting No:

You will then be asked to enter the IP address for the server:

You will then be asked to enter the Subnet Mask for the server:

You will then have to enter the Gateway address:

You will then be asked for the Primary DNS address for the server:

You will then be asked for the Secondary DNS address (Leave blank if you don’t have one):

You will then be asked for the VM’s host name.  I personally try to keep this the same the VM name within the inventory:

You will finally be prompted to confirm that all the settings are correct:

The VM will then restart the eth0 interface and should now be pingable on it’s IP address.  You will be prompted to set a password for the vi-admin account (more on this later):

The vMA will finish it’s configuration and show the default logon screen:

You should also be able to SSH into the box by using something like putty.  Putty allows you to create an SSH session to the VM and run commands remotely rather than having to log onto the console:

In my next post I’ll go into using the vMA to connect to ESXi hosts and run commands on the hosts remotely.

Deploying vMA 4.1

vMA stand for vSphere Management Assistant and the current version is 4.1.  The vSphere Management Assistant (vMA) allows administrators and developers to run scripts and agents to manage ESX/ESXi and vCenter Server systems.  VMware have said that ESX4.1 will be the last version of ESX with a linux service console.  This guide will show you how to deploy the vMA appliance within your Virtual Infrastructure environment.
The vSphere Management Assistant 4.1 Guide document can be downloaded here and is well worth a read.  The vMA is downloaded as a 440mb zip file and can be found here.  A VMware account is required to download the software.
Once you have downloaded the .zip file extract it to a suitable location and log into your vCenter server with the vSphere client.  You can deploy the vMA directly through an ESX host if you don’t have vCenter.  The extracted .zip file contains the following files:

Once in the vSphere client select File and then Deploy OVF Template and then browse to the vMA .ovf template and click Next:

Review the OVF template details and click Next:

Read the EULA and click Accept and the click Next:

Enter a name for the virtual machine and select and inventory location and click Next:

Select a datastore for the .VMDK file to reside on and click Next:

Select the required disk format i.e. thin or thick provisioned and click Next:

Select the network that you would like this VM to be connected to and click Next:

Review the options and click Finish to start the deployment:

The appliance will start to deploy into your environment and should take a couple of minutes:

If the appliance has deployed successfully you will see the following:

You should now have a new VM in your inventory.  In my next article I will go through the set-up of the vMA appliance and how to use it to connect to host’s, specifically ESXi hosts, and perform various functions.

UK VCAP Testing Centre

The only location in the UK where you can sit the VCAP exam’s is in London:
Pearson Professional Centres-London Holborn
190 High Holborn
London
WC1V 7BH
United Kingdom
That’s 246.8 miles from my current location.  So in order to sit one exam I need to travel by train for 3 hours to London, commute to the testing centre via the tube, sit the 4 hour exam and then travel back on the train for another 3 hours.  That’s put a downer on things.

vCenter Linked Mode loss of connection

Occasionally when connecting to one of our vCenter servers I received the following error message:

We have two vCenter servers linked together in linked-mode as this is a requirement for SRM (Site Recovery Manager).  When pointing my vSphere client to one vCenter server I should be able to see both and manage both.  This has worked but it seems like everytime I change my admin account password I seem to lose the connection to the other vCenter.  This might just be a strange co-incidence.  I’ve tried logging into both vCenter’s as another user and clearing down all my sessions but still no joy.  The strange thing is when launching the vSphere client from the vCenter server I can see both – It just seems to be my machine.  Anyways, the only way to fix this is to reboot both vCenter servers and then I can access both vCenter’s again.
Anyone any ideas?
UPDATE #1
I’ve confirmed that when I launch the vSphere client directly from either of the two vCenter servers I can see both vCenter’s but when doing it from my local Windows 7 laptop I can only see one (the one I connected to)

UPDATE #2
Logged onto one vCenter from my laptop with another account and it worked fine.  I could see both vCenter servers.  Logged out and then back in with my admin account and then suddenly it started working.  I’m starting to think it’s a local cache issue with my laptop when I change my admin account permissions.  Anyways, I think I have a workaround.  I’ll see if it happens again next time I have to change my password.

Home Lab

I’ve seen a few posts recently about people’s home labs and thought I’d do the same.  I currently have a HP Proliant DL380G5 with 16GB RAM and 2 Intel Xeon E5245 processors @ 2.33Ghz.  The server runs ESXi4.1 and contains the following VM’s:

As you expect from a typical lab I have a Windows 2008 R2 Domain Controller and SQL 2008 R2 Database Server.  I run vCenter 4.1 and have the VMA for managing my ESXi hosts from the command line when needed.  I also run OpenFiler as a VM to provide iSCSI shared storage for my two virtual ESXi Servers which I primarily used for messing around with.  All in all the lab serves it purpose and allows me to do exactly what I need to.
There are a few changes that I would like to make to my lab if anyone would like to help out:

• Acquire another physical DL380G5 with a similar spec to add to the production cluster.
• Acquire an 8TB Iomega StorCenter IX4-200d NAS Server to provide shared storage to all ESXi hosts and backup my laptop and desktop.
• Acquire a MacBook Pro core I7 with 4gb RAM and a solid state hard drive.

All help much appreciated.