When going to deploy a VMware vSphere OVA based vApp package you may receive the following vague error message: “The OVF package is invalid and cannot be deployed” along with “The operation is not supported on the object”.  The latter part of this error message is the message which is more specific to this particular error.

One possible cause for the “The operation is not supported on the object” error message is that you are trying to deploy the vApp into a vSphere host cluster with a single host and/or where DRS isn’t enabled.  Admittedly this is something of a generic error message, though this is definitely something worth checking and I have received this error message a few times before via the scenario outlined above.

If this isn’t the cause of your error or you have a variation of the “The OVF package is invalid and cannot be deployed” error message (which can cover a number of errors) then I recommend you take a look at the VMware community forums here.

Well folks, it’s that time again when Eric Siebert from vSphere-Land.com kicks off voting for the ‘Top 25 VMware Virtualization Blogs’. As he points out in his blog post here,  there are now over 180 blogs dedicated to VMware and Virtualization – this is definitely an impressive number which is a real indication to how passionate people feel towards the VMware range of products and virtualization in general.  The voting runs 7th February with only one round of voting being allowed per IP address – so those of you using a corporate internet connection, get in early. 

The voting is very straight forward and will only take 1 – 2 minutes of your time, all you have to do is select your Top 10 favourite VMware related virtualization blog sites and then sort them in your order of preference (ie: 1 – 10) – it’s as easy as that!

(Click on the image below to vote) 

If you enjoy the VMware and virtualization content I post about and/or maybe the vChat webcasts and would consider casting a vote for TechHead it’d be much appreciated as it is a nice indicator for me that people enjoy and get value from the site – though of course I also really like talking with readers via the comments of the various posts.

Thanks for reading TechHead and as always feedback always welcome!

 

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.

First 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’.

 

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 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.

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

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.

 

In vChat Episode 22 (aka “the late one”) David Davis, Eric Siebert and myself talk about a range of different tech and VMware related topics.  It’s been a while since our last vChat and things weren’t helped by my taking ages to edit this episode – so apologies for the delay.  Lesson Learnt:  Never commit to editing videos when moving house and most of your things are in storage.  Anyway, here are the topics we cover in this vGeek filled episode:

• VMworld Europe 2011 in Copenhagen including vSphere Client for iPad announced with vMotion and vCenter Operations Manager release at VMworld Europe
• VMworld 2012 in Barcelona
• Home Labs including HP Microserver, Iomega PX Series, and virtual vs physical
• VCP5 and how to prepare for it using TrainSignal’s vSphere 5 and Scott Lowe’s Mastering vSphere 5 book
• Last day to upgrade your VCP4 to the VCP5 is Feb 29
• Mike Laverick’s new SRM 5 book
• Duncan and Frank’s vSphere 5 Clustering Deepdive Book
• NEW VMware Press Books including Cody Bunch’s book on vCenter Orchestrator and Storage Design with vSphere
• Cisco Press book – Cloud Computing: Automating the Virtualized Data Center
• Top Virtualization Blog Voting – COMING SOON!
• iPhone 4S
• Apple Nano Watch with Lunatic Band
• Siri – John Briggs, UK Siri voice
• Reasons to go to vSphere 5
• vRAM Pooled Pricing & Cloud VM Pricing – article by David Davis “Chaotic Cloud Pricing and more!

 

vChat is a regular virtualization video chat covering VMware vSphere, Cloud Computing, Virtualization News, and maybe some geeky humor. Regular contributors are 3 vExperts – Simon Seagrave (TechHead.co.uk), Eric Siebert (vSphere-Land.com), and David Davis (VMwareVideos.com).

Sponsored by VMware vSphere Video Training from Train Signal.com

You can now SUBSCRIBE TO VCHAT on iTunes!

 

Ok, so it’s a little way off though the speed at which time seems to fly these days VMworld will be soon upon us once again.  As you have probably heard already there are changes to the location of both the US and European based VMworld events.  The US based VMworld is returning once again to the Moscone Conference Centre in San Francisco and the European based VMworld from Copenhagen to Barcelona.  Here are more details around the location & dates:

• VMworld San Francisco: 27th – 30th August 2012
• VMworld Barcelona: 16th-18th October 2012

I hope to make to it one or both of the VMworld events this year and am glad to see it returning to San Francisco (City has a great atmosphere) and moving to Barcelona (Copenhagen was a nice place but sooooo expensive). 

VMware have recently announced an update to some of their existing VMware View Clients along with introducing much awaited new View Clients running on Mac OS X and Linux (Ubuntu), along with the Amazon Fire tablet device!  The updates (v1.3) were to the iPad and Android clients.

For many of us the introduction of a Mac OSX and Linux based View Client is an exciting prospect, which will definitely make VMware’s Virtual Desktop offering more attractive to a wider audience who are currently considering a move to a virtual desktop environment.  It should be pointed out however that the Mac OSX and the Linux View Clients, both which supports PCoIP, is at this stage only a Tech Preview. 

So what can you expect from these new VMware View Client offerings?  The following is a summary from VMware’s press announcement:

• Rich Desktop Experience with PCoIP – The new VMware View clients for Mac and Linux bring users the rich desktop VMware View experience to Mac and Linux users. VMware View Clients with PCoIP provide end users with top performance regardless of network conditions.
• Optimized for Mac OS X Lion — Designed from the ground up for the Mac and with support for Lion Full Screen mode, Mac users can seamless switch between their Mac apps and their VMware View virtual desktop with a swipe on the trackpad.
• Simple Connectivity — The VMware View clients for Mac and Linux are tightly integrated with VMware View 4.6 and 5 for simple setup and connectivity. Quickly reconnect to your desktop in a few simple steps.
• Available in Ubuntu Software Center — VMware View client for Linux will be available in the Ubuntu Software Center in the coming weeks, making it easy for desktop Linux users to install the VMware View Client and access their virtual desktops.
• Available soon in Amazon Appstore for Android for the Amazon Kindle Fire — VMware View Client for Android will soon be available in the Amazon Appstore for Android, making it easy for Amazon Kindle Fire users to install the VMware View client and access their virtual desktops.

Head on over to VMware’s Mac OS X View Client page here or their Linux View Client page here for more information.  The new Linux based VMware View Client can be downloaded from the Ubuntu Software Centre, and Kindle Fire users can download the client from the Amazon App store. Another link worth taking a look at is a nice write up by Gabe at Gabe’s Virtual World on installing the Mac OS X View Client.

Probably the most interesting part of VMware’s View announcement is the inclusion of a client for the Kindle Fire.  If you’re not familiar with the Kindle Fire, it is Amazon’s latest Kindle offering which in a tablet format has a full colour 7” multi touch screen and is based on Google’s Android operating system.

There is currently speculation that we could start to see the Kindle Fire be used as a mixed personal and business device.   With a US$199 price tag and a colour multi touch screen it is easy to see how this device could start to be widely adopted by both personal and business users.  Of course, I have to admit that I have never actually used a Kindle Fire, as it’s not currently available in the UK, so can’t confirm if it’d be up to the task of being used as a day to day device for email, web browsing, virtual desktop connectivity, etc.  The reception of the Kindle Fire has been mixed, with some such as Greg Knierman of Infosmack and the Nekkid podcast being quite damming of it (some great conversation going on in the comments of Greg’s post).  Either way, with the release of more enterprise centric applications such as VMware View  it will be interesting to see if the Amazon Fire starts to be used for business type tasks or will it simply only ever remain a fancy colour eBook reader?  Either way, with the attractive price point it must be making a small dent into Apple’s iPad sales.

Below: A screen shot of the VMware View Client running on a Amazon Fire device. 

So will the release of the VMware View Client onto these other devices and operating systems be enough to sway a business’s decision to implement VMware View as opposed to another virtual desktop system such as Citrix’ XenDesktop?  I’d be interested to know your thoughts on this.  why not leave a comment below.