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
Any update on this? I ran into this same problem after installing the Open VMware tools on a client today.
Any update but time now to issue a SR.
"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.
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....
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.
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...
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
No Bad! I will add the locations to the blog post 🙂
hi all, anyone know when will be an official fix for this issue available?
thanks!
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?
a shot in the dark;
I only see this on ESXi hosts offsite with unconfigured ntp service. maybe coincidence?
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!
Added NTP and still boots fine. Looking at my list of other "Standard" packages but this is goofy now.
No, I meant ntp on the host.
I have inhouse all ESXi configured with ntp activated but abroad they do not have.
Yeah don't have access to that since it's a hosted Public Cloud, but it was happening so consistently!
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!
To date I have not again been able to consistently re-produce it with the Engineering on ESX
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!
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.
CentOS 6.3
VMwareTools-9.0.0-782409
2 NICs
Renaming libtimeSync.so didn't help as well as disconnecting/connecting NICs.
Has anyone successfully resolved this problem using the library rename workaround?