UK North East vBeers

Interested in VMware?
Live in/or near the North East of England?
Like beer?

Then why not join the UK North East vBeers first meeting:

http://www.vbeers.org/2011/06/27/vbeers-%E2%80%93-north-east-england/

Time to start blogging again...

I've been pretty slack recently in blogging and I'm going to try and change going forward.  Work's been pretty hectic over the last few months with an Exchange 2003 to Exchange 2010 migrations (Which is nearly finished) and various other projects.  I now have a bit of time free to concentrate on rebuilding my home vSphere lab.  I'm planning on rebuilding the entire environment including all VM's due to the various changes that have been made to the over the years.  I'll hopefully keep you updated.

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.