VMware Cloud Community
RockT
Contributor
Contributor

ESXi 5.1: vmsvc warning guestinfo RecordRoutingInfo: Unable to collect IPv4 routing table

Hi,

we have two RHEL6.3 VMs which need 15 minutes to boot!

The problem happens when starting the network interfaces in vmsvc.

Host: ESXi 5.1, latest 5.1 tools from repo installed, two vmxnet3 interfaces

Both interfaces are connected to two different portgroups on the same swtich with same VLAN ID (!) and one uplink.

Please help how to find out the cause of this.

Thx Rainer

vmsvct.png

Tags (2)
87 Replies
rlboyd
Contributor
Contributor

Any update on this?   I ran into this same problem after installing the Open VMware tools  on a client today.

0 Kudos
mururua69
Contributor
Contributor

Any update but time now to issue a SR.

0 Kudos
jcantara
Contributor
Contributor

"boot->stall->shutdown->nic_disconnect->boot->NO_stall->shutdown->nic_connect->boot->NO_stall"

This appears to have solved the problem for me as well. It started on my CentOS 6.3 guest today after installing vmware tools 9.0.0-782409.

0 Kudos
eghost355
Contributor
Contributor

may I ask whether the "vmware tools 9.0.0-782409" or "discount the nic" is the solution?

tried VMwareTools-9.2.2-893683.tar.gz and encountering the same problem....

0 Kudos
admin
Immortal
Immortal

Folks,  Thanks for the continued discussion.  I have been talking to Engineering and based on some test VM's I gave them with the public cloud provider I use they think they have isolated the problem.  I cannot yet say what the final work around is, but when we have something solid I will be sure to post a blog article and reference that here.  They think they know the cause, they are just trying to understand the WHY is it happening.  The disconnect, reconnect NIC workarounds are not going to work long term, so for myself I have just removed the tools since much of the networking like VMXNET is upstreamed into the Kernel, although you lose the controlled shutdown aspect for now.  I'll keep working with them, but they are clear this is not an isolated problem and something easily re-produced.

0 Kudos
admin
Immortal
Immortal

We are still working on the final solution but here is the explanation of the problem and a possible workaround:  http://www.chriscolotti.us/vmware/workaround-for-vsphere-5-1-guest-unable-to-collect-ipv4-routing-ta...

0 Kudos
jcantara
Contributor
Contributor

Chris, thank you for the detailed update and workaround. In case anyone doesn't know how to locate the library in question, on my CentOS 6.3 system, the file was in 2 locations, one for x86 and one for x64. Presumably you only need to rename the one that matches the architecture of your guest, but renaming both shouldn't hurt.

/usr/lib/vmware-tools/plugins32/vmsvc/libtimeSync.so
/usr/lib/vmware-tools/plugins64/vmsvc/libtimeSync.so

0 Kudos
admin
Immortal
Immortal

No Bad!  I will add the locations to the blog post 🙂

0 Kudos
eghost355
Contributor
Contributor

hi all, anyone know when will be an official fix for this issue available?

thanks!

0 Kudos
admin
Immortal
Immortal

I have been trying to re-produce again on vCD 5.1 with a clean OS install, and now the issue will not present:  Installed new VM from CentOS 6.3 Installed Version 9 tools  warm reboot....no issues now 😕  This was very consistent before so I'm at a bit of a loss.  Maybe this is a specific kernel issue?

0 Kudos
RockT
Contributor
Contributor

a shot in the dark;

I only see this on ESXi hosts offsite with unconfigured ntp service. maybe coincidence?

0 Kudos
admin
Immortal
Immortal

CLearly there is some other combination of packages installed that interfere.  Let me install NTP, but since this is a 'Timesync" issue.....I need to track all the installs from ground up until it presents.  FUN!

0 Kudos
admin
Immortal
Immortal

Added NTP and still boots fine.  Looking at my list of other "Standard" packages but this is goofy now.

0 Kudos
RockT
Contributor
Contributor

No, I meant ntp on the host.

I have inhouse all ESXi configured with ntp activated but abroad they do not have.

0 Kudos
admin
Immortal
Immortal

Yeah don't have access to that since it's a hosted Public Cloud, but it was happening so consistently!

0 Kudos
eghost355
Contributor
Contributor

I encountered this problem in VM Workstation 9.0.1 as well. Clear install CentOS v6.3, stock kernel or just compile install latest 3.4.2x kernel, then install the VMTools that came with VM WS 9.0.1. Then this problem will happen about 1/3 of reboot. I haven't enabled NTP, on AMD Phenom hosts.

Hope their will be a solution soon! Is it the reason why VM WS 9.0.2 still not released yet?

Thanks!

0 Kudos
admin
Immortal
Immortal

To date I have not again been able to consistently re-produce it with the Engineering on ESX

0 Kudos
eghost355
Contributor
Contributor

Just tried to update VM Workstation 9.0.2 and its bundled VMTools VMwareTools-9.2.3-1031360.tar.gz on a newly installed CentOS 6.3 guest ==> Immediate reproduce the vmsvc warning. So seems the problem has not been solved yet....

Do you mean you cannot reproduce it after renaming the following two files?

/usr/lib/vmware-tools/plugins32/vmsvc/libtimeSync.so
/usr/lib/vmware-tools/plugins64/vmsvc/libtimeSync.so

If so then the bug was still there. Just avoid calling it only?

Also if renamed the libtimeSync.so, what consequence to the guest OS? Will its system cock out-sync with hosts?

Thanks a lot!

0 Kudos
DBM201110141
Contributor
Contributor

I have same messages with some extra but no delay on boot.

Mar 19 13:13:32 sim-front vmsvc[1141]: [ warning] [guestinfo] RecordRoutingInfo: Unable to collect IPv4 routing table.

Mar 19 13:13:32 sim-front vmsvc[1141]: [ warning] [guestinfo] RecordRoutingInfo: Unable to collect IPv6 routing table.
Mar 19 13:13:32 sim-front vmsvc[1141]: [ warning] [guestinfo] Failed to get nic info.

CentOS 6.3

VMwareTools-9.0.0-782409

2 NICs

Renaming libtimeSync.so didn't help as well as disconnecting/connecting NICs.

0 Kudos
flawaetz
Contributor
Contributor

Has anyone successfully resolved this problem using the library rename workaround?

0 Kudos