Posts Tagged ‘vSphere’

Unable to connect to the MKS – VMware vSphere Console Fix

VMware

Here’s an old favourite of mine.  When trying to open a console session to a virtual machine within the VMware vSphere Client you may receive a black screen and the following error message: “Unable to connect to the MKS: Host address lookup for server”, “failed: No such host is known”.

Although there are a couple of things that can cause this error the most common reason is that the host is unable to resolve the name of the VMware ESX or ESXi host on which this VM is running.  As you’d expect this is often caused by a DNS issue or lack of an entry for the ESX/ESXi  host which is stopping the host’s name from being resolved.

VMware vSphere Host address lookup errorFirst of all you may be wondering what the ‘MKS’ part of the error message stands for, well you’ll be disappointed to know that it isn’t an acronym for something high tech and very complicated but rather is stands for; mouse, keyboard, screen.

When you go to request a console session of a VM by clicking ‘Open Console’, the client machine from which you are running the vSphere Client will receive a response back from the ESX or ESXi host providing it’s (ie: the ESX/ESXi host) name to the client machine.  At this point the client then uses the name of the ESX/ESXi host (as provided by the host) to establish communication through to the ESX/ESXi host for the purposes of viewing the VM’s console.

Of course, as you’d expect, if the client machine running the vSphere Client can’t resolve the ESX/ESXi’s host name then the console session cannot be established, hence the “Unable to connect to the MKS”, “Host address lookup” error message.

Troubleshooting & the Fix (not the drug variety):

So how do you resolve this issue I hear you say?  Well, this part is also quite straight forward as all you have to do is enable the PC/laptop running the vSphere Client to resolve the name of the ESX/ESXi host(s).  As you probably know a Windows based PC or laptop will use a local host file or DNS (also WINS with earlier versions of Windows OS) to resolve host names.

To resolve or not to resolve?  That is the question….

Your first step should be to open a command prompt (CMD) on your client and perform a ping to the name of the ESX/ESXi host.  Don’t forget to use the fully qualified domain name (FQDN) of the ESX/ESXi host if this is how the host is registered in the vSphere client.  To avoid any confusion look at the error message as this will contain the name of the ESX/ESXi host, in my example (see below) the name of my ESXi host is ‘esx5-01.domainname’.

 

Unable to connect to the MKS

The ping should, in theory, successfully resolve the ESX/ESXi’s host name to an IP address, if this doesn’t happen then you should ensure that your client PC or laptop is pointing to the correct, and working, DNS that contains an entry for the ESX/ESXi host. Hint: Your internet service provider (ISP) isn’t going to have the names of your ESX/ESXi hosts in their global DNS Smile so ensure you are running a local DNS service (eg: on a Windows Server OS VM) with the names of your ESX/ESXi host(s) entered into it or ….

… You could do the following, which is much easier for small vSphere lab environments, and will get you around needing to install a DNS service….  Note: Most people know about the local hosts file on a Windows OS, though I have included a little more detail to benefit those who weren’t aware of it.

Every modern Windows OS will have something called a local hosts file, which can be found in the following directory: C:\Windows\System32\drivers\etc

Strangely enough this file is called ‘hosts’ – the clue’s in the name. Winking smile

The contents of this hosts file will by default look like this:

VMware vSphere Unable to connect to the MKS

This local hosts file provides you with the ability to add in your own host names and associated IP addresses to your PC or laptop, which are then used by your Windows OS.  When trying to resolve a host name the Windows OS will by default look at this local hosts file first before using alternative name resolution services such as DNS to resolve a host name.

So, all you need to do is enter, and save, into this local host file the name and IP address of the ESX/ESXi host(s) in your vSphere environment.  Just to be on the safe side ensure you create an entry using the ESX/ESXi host’s FQDN and non-FQDN.  After making these changes make sure you save your changes to the local hosts file.  Here is an example of what the formatting would look like:

192.168.1.10    esxhost1
192.168.1.10    esxhost1.yourdomain

Now from a command prompt (CMD) perform a ping to the ESX/ESXi host making sure you use the same name (ie: FQDN or non-FQDN) as seen in the original error message.  Everything going well your client PC/laptop should now be able to successfully resolve the name of the ESX/ESXi host.  If not, take a closer look at your local hosts file again.  Hint:  without the correct read/write permissions set on the hosts file you can’t always save it as it is located in a Windows OS systems directory.

Some people have reported that if the line below has been un-commented (ie: there is no # in front of that line) in the local hosts file then this also causes an issue when trying to establish a console session to a VM:

“# ::1        localhost.localdomain localhost”

At this point you should now be able to open a successful console session via the vSphere Client to your VM.

Other things…

The resolution to the “Unable to connect to the MKS: Host address lookup for server”, “failed: No such host is known” as outlined above is one of the most common fixes though as with anything in IT there are other things that can cause the same or similar issue.

At this point I should also point out that having a firewall block the TCP/UDP port 902 used by the ‘console’ will also provide you with connectivity issues so double check to see if the firewall on your local PC/Laptop or any other firewall in between your client and the ESX/ESXi are blocking this port.  Check out this useful KB article from VMware for a list of all used ports

 

I hope this post has helped resolve your console connectivity issue, though if you have any alternative hints, tips or fixes for the “Unable to connect to the MKS: Host address lookup for server”, “failed: No such host is known” error then please share with others by leaving a comment below. Thanks.

 

Running VMware vSphere ESXi 5.0 on the HP Proliant Microserver

VMware

HP Proliant Microserver & VMware vSphere 5Those of you that have bought an HP Proliant Microserver for your work or home VMware vSphere lab are probably wondering whether it will work with VMware vSphere 5.0?  Well, the good news is that it does and that even the installation  process goes through without a hitch both to local internal USB pen drive or local disk.  I have tested this with the final RTM version of vSphere ESXi 5.0, not just the beta builds, and can confirm that the CPU, storage controller, memory and network card are detected without a problem meaning that you’re all set to go for when VMware make available the VMware vSphere ESXi 5.0 download available sometime soon. 

With the free downloadable version of ESXi 5.0 the amount of physical memory accessible in the host has been reduced to 8GB so this combined with the fact that the HP Microserver can only take 8GB anyway won’t leave you feeling like you’ve wasted your money on adding extra memory.  Those of you, like myself, that also have an HP Proliant ML110 G6 with 16GB will either have to look at only using 8GB of it’s memory, keep installing the eval license on a regular basis (too much hassle) or purchasing an entry level vSphere license to allow me to access the full 16GB of memory in the server.  Either way, the new exciting features (see my post here for more details) found in VMware vSphere 5.0 is too much of a temptation to leave my vSphere lab servers at vSphere 4.1.

 

HP Proliant Microserver & VMware vSphere 5 - Summary

VMware vSphere and HP Proliant - CPU

HP Proliant and VMware vSphere 5 - Memory

HP Proliant Microserver & VMware vSphere 5 - Storage Adapters

HP Prolian Microserver & VMware vSphere 5 - Network Adapters

Iomega PX4 NAS Device – Hands on Review

VMware

With Iomega’s recent release of their exciting new PX series of NAS devices I have been fortunate enough to get my hands on one of these funky new units. I have been a happy Iomega IX4 owner for the past two years and run two of them 24×7 in my home VMware vSphere lab.  In this time the only issue I’ve had is a single disk failure in one of the units which in my view isn’t bad going since they’re permanently left on and have live VMs running on them.

Iomega PX Review

There are three models in the Iomega PX series the most notable differences between them being the number of maximum drives, the form factor (ie: free standing versus rack mount) and some minor differences in CPU speed and memory in the device.

The Iomega PX series of NAS devices offer a number of improvements and enhancements over the IX series which makes a compelling reason to take a serious look at the PX if you’re in the market for a NAS for either home, a remote office or a SMB.  One of the most notable improvements for me is the increase in CPU and memory along with the inclusion of removable disk caddies which allows for 2.5” form factor SSD disks – great for adding that extra IOPS horsepower, and yes you can have a mix of conventional 3.5” SATA disks and 2.5” SSDs – cool !

You can’t beat hands on time with a product so here is a quick sub-6 minute overview of the actual physical PX4 product itself including comparisons with the older IX4 model.  Hope you find it of use.  Smile

 

 

 

** Update: 28/06/2011 – Thanks to Mike Foley for pointing out that the USB on the front of the PX is in fact USB 3.0 and not just a USB 2.0 as I mention in the video.  Smile

The following is a high level summary of some of these features and the specification of the Iomega PX devices:

  • High performance through optional solid state drives, dual Core Intel processor, 2GB memory and dual GbE NICs.
  • Multiple RAID levels – 0, 1, 10, 5, 5+1 (hot spare) and 6, all with automatic RAID rebuild and hot swap functionality.
  • Scalable configurations include fully populated, partially populated and diskless options. 7200 rpm SATA HDDs and SSD Drives are available from Iomega or may be purchased from the approved vendor list.
  • Active Directory Support and remote access for anytime, anywhere data availability.
  • Certified for VMware® vSphere 4.0, Citrix® XenServer™, and Windows Server 2003/2008/2008 R2.
  • Cross-platform file sharing with Windows®, Mac® and Linux computers, and simultaneous iSCSI block access for the most efficient storage utilization.
  • All major network file protocols supported.
  • Iomega Personal Cloud technology, a revolutionary web-based computing architecture that connects your Iomega network storage device to other individuals and/or devices via the Internet.
  • Windows Active Directory Trusted Domains, MSCS and Hyper-V Live Migration Support.
  • Data replication and device-to-device copy jobs keeps your data backed up and secure.

I will be putting the Iomega PX4 through its paces in the coming weeks so expect a couple of blog posts here on the performance and usability of the PX NAS device.

 

Technorati Tags: ,,,,,

VMware ESX “I moved it” or “I copied it” – What’s the difference?

VMware

When you copy or move the data store location of an existing VM you will be presented with a message box (as seen below) in the vCenter Client asking if your VM has either been ‘moved’ or ‘copied’.  As you can see the message box also mentions “msg.uuid.altered: This virtual machine may have been moved or copied”, but what does this actually mean?

VMware ESX msd.uuid.altered

Figure 1. Has the VM been moved or copied?

What is a VM’s UUID?

Firstly, it is important to have an understanding of what a ‘UUID’ (universally unique identifier) is.  As the name suggests the UUID is a ‘identifier’ (128 bit integer) which is ‘unique’ to that VM, and effectively gives it a digital fingerprint to differentiate it from other VMs.

The UUID is automatically generated when a VM is first powered on or moved, with the UUID value being based on the physical host’s identifier and also the path to the VM’s configuration (vmx) file.  Within this configuration file the UUID value is stored in two places:

  • uuid.bios
  • uuid.location (hash based on the current path of the VM)

For example: uuid.bios = "56 4d 5e 58 66 f5 2d 04-03 31 0a bd 6f a7 19 88"

The UUID is also stored in the SMBIOS system information (ie: the BIOS of the VM) descriptor.  When the VM is started or moved the location UUID (ie: uuid.location) which is hashed from the VM’s data store path is compared to the UUID location hash which already exists in the configuration file.  At this point if the new and existing location UUID value differs then ESX knows that the VM is now running from a different data store location and will present the ‘Virtual Machine Message’ in figure 1 above.

But why do we care if the VM has the same or a new UUID? 

We saw in the message above provided by ESX informing that the UUID has in someway been altered but why does this really matter?  The answer to this you’ll be pleased to know is quite The vmx file contains important VMware ESX UUID informationsimple.  A VM’s unique UUID is used to generate other unique values used by the VM such as the unique MAC (media access control) address of the network card(s).  For example if you had multiple copies of the same VM/Guest OS running in your vSphere environment all with the same (ie: non-unique) network MAC address you will likely receive duplicate MAC address error messages within the guest OS which can cause a number of issues.

Another potential point to be mindful of is that some software licensing can be linked to a MAC address of a guest OS’s network card.  This includes software such as Microsoft Windows where changing the MAC address and some other key hardware components (eg: moving from an Intel based ESX host to a AMD based ESX host) can mean you have to re-activate the software again.  The changing of a VM’s MAC address will occur when you select “I copied it”, the next couple of sections will go into more detail on what exactly is altered.

 

Should I Select “I Moved It” or “I Copied It”?

So what is the difference between selecting “I_moved it” or “I_copied it”?  The easiest way to demonstrate the differences is by viewing the configuration file (vmx) for the VM before and after the two different options have been selected.

 

“I Moved It”

By indicating that you had moved the VM (instead of copying it) the only UUID change that is made to the configuration file is to the ‘uuid.location’ setting, which as you’d expect indicates a change of location for the VM. The ‘uuid.bios’ and the existing generated network MAC address remains that same.

You will also notice that the CPUID settings have also changed which is also the case for when you indicate that the VM was copied.

The “I Moved It” option should be used when ‘moving’ the location of where a VM resides and a copy of the VM has not been made.

VMware ESX I Moved It

 

“I Copied It”

When you select that the VM has been copied then there a few more changes that are made to the VM’s configuration file when compared to just moving it.  These changes are to the ‘uuid.bios’, ‘uuid.location’ and as a result of these changes a newly generated network MAC address (ethernet.generatedaddress).

The “I Copied It” option should be used when you’ve made, and intend to run, more than one copy of the VM in your vSphere environment.

VMware ESX I Copied It

 

To summarise, here is a table which outlines the changes that are made when either the “I Moved It” or “I Copied It” are selected

  “I Moved It” (change?) “I Copied It” (change?)
uuid.bios uuid.bios uuid.bios
uuid.location uuid.location uuid.location
ethernet.generatedaddress ethernet.generatedaddress ethernet.generatedaddress
guestCPUID.x guestCPUID guestCPUID
hostCPUID.x hostCPUID hostCPUID
userCPUID.x userCPUID userCPUID

 

As you can see it is worth spending the time to understand the changes which will be made when presented with the “I moved it” or “I copied it” options as it can impact (eg: software re-activation) the guest OS of the VM.

I hope this helps clarify this small aspect of vSphere administration which can sometimes be an area of confusion.

 

StarWind Software
VMware vSphere Recommended Reads
TechHead Needs You - Top 25 Blog Sites
AppAssure
Veeam #1
Trilead
TrainSignal - vSphere Pro