{"id":2998,"date":"2013-02-15T09:39:19","date_gmt":"2013-02-15T14:39:19","guid":{"rendered":"http:\/\/chriscolotti.us\/?p=2998"},"modified":"2014-08-22T14:06:53","modified_gmt":"2014-08-22T18:06:53","slug":"workaround-for-vsphere-5-1-guest-unable-to-collect-ipv4-routing-table","status":"publish","type":"post","link":"https:\/\/chriscolotti.us\/vmware\/workaround-for-vsphere-5-1-guest-unable-to-collect-ipv4-routing-table\/","title":{"rendered":"Workaround for vSphere 5.1 Guest Unable to collect IPv4 routing table"},"content":{"rendered":"
Folks this has become an interesting discussion on a VMware Community Forum as of a few weeks ago about this vSphere 5.1 error. \u00a0In fact I myself ran into the same issue on a new build with the vCloud Service Evaluation cloud a couple of weeks ago. \u00a0I decided being a good\u00a0citizen\u00a0and VMware employee to start an internal discussion of this to see where it could lead. \u00a0Below is a screen show you MIGHT see showing the error, however what I can tell you now is this error actually has NOTHING to do with the root cause issue so let me explain.<\/p>\n
<\/a><\/p>\n This is rather easy and is something anyone can do. \u00a0What I can say for sure, this is not tools version related, it is not even virtual hardware related, it is something with the tools and vSphere 5.1 specifically, regardless of versions. \u00a0I actually tested both:<\/p>\n The error itself is arbitrary and happens to be presented while the Virtual Machine is simply trying to finish the boot. \u00a0I know this as I was asked to start renaming certain libraries\u00a0including\u00a0libguestinfo.so which removed the error in the screen, but the Virtual Machine still stalls on boot. \u00a0This error is completely un-related to the underlying root cause which is actually that the Virtual Machine is hanging on boot for about 10-15 minutes.<\/p>\n So in the spirit of troubleshooting, engineering used my test Virtual Machines to go through other libraries until we isolated the libtimeSync.so library. \u00a0Now, if you recall way back early in vCloud Director I ran into a time sync issue<\/a> that was ultimately being caused by the fact NTP was not enabled on a cell. \u00a0However, what I pointed out in that article was that EVERY virtual machine,\u00a0regardless\u00a0if the tools are set to sync with the host or not when the tools running will ALWAYS time sync initially on boot if the tools are installed. \u00a0Then once the tools are running, the settings of sync with host or not are enforced.<\/p>\n What appears to be happening here and we don’t yet have the “why” is that the time sync library is causing the hang on the initial boot. \u00a0So now that we know the reason it is hanging and the library causing it we can do a quick work around which for most people should be good until we can get a final root cause as to the reason the library is just taking so long.<\/p>\n This is so simple you are going to wonder why I made you read the rest of the article. \u00a0Well, frankly I think it’s important to understand the troubleshooting we have taken to understand and isolate the issue so you know why it’s happening not just the “fix”. \u00a0So what that the answer right now seems to be simple assuming you only have access to the vSphere guest itself like I do in a fully hosted environment:<\/p>\nThe vSphere Setup To Reproduce:<\/h3>\n
\n
\n
The Real Problem<\/h3>\n
The vSphere Workaround<\/h3>\n