During the name delete, a DNS request times out due to adapter being removed and re-added a few seconds earlier. This “stale adapter clean-up” operation marks the DNS name to be deleted as it was registered for the vmxnet3 adapter which is now being removed. Removal of the vmxnet3 adapter triggers a “ stale adapter clean-up” operation.
Vmware tools download 10.0.9 upgrade#
So as per VMware support, “setting VMware Tools to upgrade triggers the vmxnet3 adapter to be removed and then re-added. This issue occurs especially with the VMs running vmxnet3 adapter.
Vmware tools download 10.0.9 update#
To understand this behaviour we opened a case with VMware and after several followups, they confirmed that VMware tools update might remove the DNS records given some coincidence and they already have some internal documentation but nothing is available as VMware KB. We checked the timestamp of DNS record deletion and VMware tools update and both were correlating, this confirms that VMware tools update removed the DNS records, but how, we had no clue. After checking the DNS auditing logs, we found that the DNS records were deleted and the user field was showing the Computer account (ServerName$) who requested the delete operation.
We suspected it may be something to do with the DNS so we went to DNS management and searched for the DNS records of impacted servers, but we couldn’t find them. Then we tried to ping it via IP address and it was replying to ping, also RDP was working via IP and we were able to login into the server. I did a ping to the server via name and it’s being time out. VMware update manager is really handy while doing such updates, it easily scans all the VMs and provides you with a list of VMs which are eligible for the update, also you can schedule the update task.Īfter updating the VMware tools we observed that a couple of servers were not available over the network, however, while going to the VM summary page I found that VMs are up & running and showing the FQDN name of the server along with IP address, also VMware tools were updated and running fine. My current VMs are running on version 10.0.9(10249), so we thought of updating the VMware tools to the latest version, after taking a look into release notes. For more information on compatibility, see VMware Product Interoperability Matrix.Hi Guys! Recently we upgraded our ESXi hosts from version 6.0 U3 to 6.5 U1, after the upgrade a new version of VMware tools was available i.e. This compatibility requirement is also applicable to open-vm-tools 10.1.0 packaged by various Linux distributions. If a virtual machine is being managed by VMware Site Recovery Manager 6.1.1 or earlier, avoid installing or upgrading VMware Tools to version 10.1.0. Workaround: Upgrade VMware Site Recovery Manager to version 6.1.2 or 6.5 before installing or upgrading VMware Tools to version 10.1.0. VMware Site Recovery Manager 6.1.2 and 6.5 versions are compatible with VMware Tools 10.1.0. VMware Tools 10.1.0 is not compatible with VMware Site Recovery Manager 6.1.1 or earlier Upgrading VMware Tools to 10.1.0 on a virtual machine managed by VMware Site Recovery Manager 6.1.1 or earlier breaks the VMware Site Recovery Manager workflows. The release notes for VMware Tools 10.1.7 still list this as a known issue. You have to upgrade to SRM 6.1.2 for 10.0.12/10.1.x support. I opened a ticket about this a few weeks ago and was told that 10.0.9 is the latest 10.x release that supports SRM 6.1.x.
0 kommentar(er)
