Highlighted
Contributor
Contributor

VM WS 7.0 copy op on host fails when same server accessed from guest using NAT

VMware WS 7.0.1 build 227600 Host OS XP64bit (verified on 32bit host as well and also on multiple computers)

I start a copy operation on the host from
server1, copying a large file to the physical host drive.

While that copy is in progress, within a guest OS running XP32bit, and NAT network mode, logged in as a local user, I access
server1.

I receive a popup asking for credentials to access
server1. I can provide them and will have access to
server1.

However, at the same time I get the popup, the copy in progress on the host aborts with a non-specific error (something like server no longer available).

I can restart the copy and it will fail again - as long as I am connected from the guest OS. If I then disconnect the guest os from the server (closing windows, then removing any references seen with a 'net use' (for example ' net use
server1\ipc$ /del') and then retry the copy on the host, it will work.

If I change the network mode from NAT to Bridged on the guest OS and then retry the above tests - the problem does not occur. It only happens when the guest is set for NAT mode.

VMware tools are installed and up-to-date in the guest OS.

I have verified that this does NOT happen with v6.5. It began after upgrade to 7.0.0. Today I upgraded to 7.0.1 to test that before posting this. Same issue.

I have opened a case with VMware on this over a month ago but there seems to be little progress on it.

Anyone else seen this or that can reproduce it? I checked around the forums and googled a bit before putting this together.

Tags (4)
0 Kudos
2 Replies
Highlighted
Contributor
Contributor

OK, lets put a fork in this and call it done.

Finally heard back with reference to:

http://kb.vmware.com/kb/1013871 (which my prior searches had not turned up).

Also support provided the following

Now why did it work : I'd have not been expected this to work, Having said that, the only reason could be that for how/why things have changed might be due to the local DNS resolution in the NAT. E.g., it used to be that a URL like http://www could work on the host but would never work for guests. This is because the host knows what DNS suffix to use (vmware.com, in our case) but the VMs never learn's about the DNS suffixes from our NAT/DHCP servers.

A feature that was added was to tell when a VM is trying to do this type of lookup and use the host's to add the appropriate DNS suffix. So, now a VM should be able to use a URL like http://www rather than specify the full http://www.vmware.com.

This can relate to this situation because the host and guest can now use the same name to talk to the server, whereas previously the host could use a partial DNS name while the VM had to use a full DNS name.

Using different names might help to avoid the Windows issue.

This feature was also present in WS 6.5 (although now it can be disabled in WS 7.0 by adding "prohibitHostLookup = 1" to the section of vmnetnat.conf

and restarting the NAT service),

So removing this may just help not garneted.

And it's always right to specify a full server name or better go with a bridged network.

0 Kudos
Highlighted
Contributor
Contributor

I am having this same problem except I am using the bridged connection already. I connect to the domain for my guest machine and everything looks fine. But when I try to access a networked drive which sometimes I can and sometimes I cannot. It ask for creditials again. Also, when I go to user and groups and try to add a network user on there it does not see the domain I am connected to.

Any suggestions??? Thanks in advance.

0 Kudos