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!

 

Good news folks!  2012 has seen the release of a new Microsoft TechNet Subscription Discount code.  This new code for 2012 will give you 15% (small print: this is based on the US currency so may vary slightly between countries) and is due to expire on the 29th February 2012. 

Code: TNFLA12

To give you an idea of the type of savings you can find on a Microsoft TechNet subscription, here are the savings on a new TechNet Professional subscription in the US, UK and Europe (checked against France & Germany): TechNet Pro - US $349.00 -> $296.65 TechNet Pro – UK £234.21 -> £199.08 TechNet Pro – Europe €373.64 -> €317.59

If you run your own IT lab environment the Microsoft TechNet subscription is definitely a worthwhile investment as it gives you access to most Microsoft applications and MS operating systems, along with legitimate licence keys for non-production use.

Those of you like myself who are already signed up to the Microsoft TechNet subscription programme will no doubt agree that it offers great value for money, and avoids the headache of trying to ‘track down’ license keys.  It also certainly beats having to install time limited trial versions which you end up having to reinstalling after a set period of days, which only wastes precious lab time.  Along with access to the actual Microsoft software you the TechNet subscription also provides you with access to the Microsoft Knowledge Base and the moderated Microsoft TechNet Forums, which are also valuable resources.

Check out the TechHead ‘Hot Deals’ section at the top of this page for more decent product discounts and deals I have come across along with any new or updated Microsoft TechNet discount codes.

A big thanks goes out to Colin Westwater who pointed out this new 2012 Microsoft TechNet code to me.

Good news for all Iomega IX2 and IX4 non-Cloud Edition owners who want to back their Apple Mac up to their Iomega IX2 or IX4 using Time Machine.  A firmware update (v2.1.40) has been released by Iomega which resolves the issue of not being able to backup your Apple Mac using Apple’s Time Machine backup utility.  For those of you with a Cloud Edition model of the Iomega IX2, IX4 or PX series storage devices have had a firmware update containing the fix since back in August 2011 (v3.1.12.47838, 11th August  2011).

Prior to applying this v2.1.40 firmware update for non-Cloud Edition models you were unable to establish a connection via Time Machines to the IX2/IX4 device due to a change in Lion OS X that did “not allow standard network connections via AFP, which is the protocol used to create Time Machine backups on network device”.  One point to note is that as of today (4th January 2012) the ‘Update Device Software’ page in the Iomega IX2 and IX4’s web based management console is still saying that the v2.1.38.22294 is the latest available FW update – don’t be fooled by this as you can download the v2.1.40 firmware update for the Iomega IX2 here and the IX4 here and then ‘Copy Update File’.

 

I have applied this new Iomega firmware update to my IX4 non-Cloud Edition and can confirm that it works just fine.  I can now backup from my Apple MacBook Pro to the IX4 without any issue.