I have the latest WS 5.5.
All my guests are XP32, the host is also XP32 - 4gb ram, AMD X2 4800, with fast disks.
I find Shared folders are horrendously slow. When navigating through them in Explorer it can take 30 seconds before the folder contents display. Once I'm in the folder access is general quick, but if I leave it and come back a short while later (even as short as 1 minute later), and then try to do something (select the files, right click on a file, anything) Explorer will again freeze for 30 seconds before anything happens.
When I do eventually get to the point where I can copy a file, it seems fast enough. And I have pointed Symantec Ghost to the shared folder as its location to backup the drive, and the time it took seemed resonable (1.5 minutes to High compress and backup a 3gb drive). However the huge browse times make frequent use of these folders highly annoying.
I've searched and found numerous old posts reporting the same problem - but most of them have no replies. I take it therefore that this is an inherant problem with shared folders and they are not intended to be a replacement for a network share.
I'm going to use a network share mounted as a drive instead - I just thought I'd post this in case there is an word from VMWare as to whether it will be fixed in future, and as help for others if they experience the same issue.
I have mapped a shared folder to a logical drive. Seems to be better that way. At least from Windows point of view.
Thanks for the tip Peter - I just tried it, and it does seem much faster.
It takes ages to load the root of my C drive, but it seems fast in all other folders. I don't actually need to see the root, and when I browse straight to
.host\C\SomeFolder it is fast.
Thanks!
I have several 4.5.2 users also reporting that Shared Folders seem to be terribly slow. It seems that the more Shared Folders they add, the slower the Virtual Machine becomes.
So you're mapping a drive through Windows Explorer pointing to
.host\c\folders and getting better performance? Is that "c" or "c$"?
Maybe somebody from VMware can jump in here. What's the story with Shared Folders?
Message was edited by:
onalimb
I should have said:
.host\Shared Folders\C
and it's C not C$ - C is the name I gave to the C:\ Shared Folder in the VM Settings.
And yeah, here's how it breaks down:
Shared Folder 'FolderA' mapped to C:\FolderA = slow performance
Shared Folder 'C' mapped to C:\ - slow performance accessing C\, but fast accessing C\FolderA\ and all other folders except root
There's s pretty good chance it has nothing to do with shared folders and is, instead, a "feature" of Windows networking. I've seen the same thing happen with Windows shares many times and VMWare Shared Folders are, as I understand it, a Windows network service.
If I access a normal Windows share, i.e.:
192.168.0.100\C$ (where that IP is my host, so it's the same folder mapped via Shared Folders)
it is instantaneous browsing any folder.
If I access a normal Windows share, i.e.:
192.168.0.100\C$ (where that IP is my host, soit's the same folder mapped via Shared Folders)
it is instantaneous browsing any folder.
And such results are why I stick with standard Windows networking for any transfer of files between my guests and my host.
Always a good idea to explain fully I suppose. I didn't say I had always seen it happen with every Windows share I had ever experienced. I've worked on Windows network client code on 9x and NT based platforms. It does happen with Windows networking. Another thing that might be relevant is that Microsoft (at least the last time I was working on clients) takes first shot at every name resolve request. For raw UNC there may be no pre-built connection table element but with a mapped drive there is. If you are the last guy to get to resolve the name then you look bad, pity the VMWare client redirector.
I still like my suggestion:
" ... Maybe somebody from VMware can jump in here. What's the story with Shared Folders? ... "
In the case I worked on the code was changed to intercept the request rather than operate in the re-director path. That made our code get first shot at handling the name. I like your suggestion too
I fought with this issue for a really long time. What is occurring is windows tries to do a name resolution for ".HOST" when you access a shared folder it waits for the resolution to fail (about 30 seconds) before working. If you don't have a network connected you will notice it occurs much faster. The solution is to add the following entry to C:\Windows\system32\drivers\etc on the client HOST:
127.0.0.1 ".HOST" #PRE #Host Shared Folders
Hope this helps (I fought this problem for months)
Did you add that to the c:\winnt\system32\drivers\etc\hosts file, or the lmhosts.sam file in the same directory? I've added it to both to be on the safe side . . .
You should add this to the lmhosts file (NOT lmhosts.sam).
lmhosts.sam is a SAMPLE file, it doesn't do anything. So create a new file called lmhosts in %SystemRoot%\System32\Drivers\Etc in your VM of course and add the line:
127.0.0.1 ".host" #PRE
After doing this, save the file (if in NOTEPAD, make sure it does NOT have a .TXT extension, or any extension for that matter).
Then to force a reload of the file, from the command prompt type:
nbtstat -R
(note this must be a capital R)
I've had a LOT of problems with using shared folders to access my outlook folders that are on the host (run Outlook in a VM), so I'm hoping this will fix this problem (perhaps a timeout)? No results yet, but will post if this fixes my problem (or not).
I have tried just sharing a drive letter on my host using standard Windows networking - works fine except in cases where I want to read my old email when the physical machine isn't connected to the network. I use bridging in the VM and VMWare tells me the network card isn't available (which is true), so it won't work in that situation.
So I was hoping shared folders would get around this, but it seems flakey at best. Hopefully the LMHOSTS trick posted will solve my problem.
If not, I'm going to try added the MS Loopback adapter to the host, and seeing if I can configure the VM to use it via NAT or bridging to get to the host. No idea if this will work, and I can understand if it doesn't, but that would be my next best thing (other than moving the PSTs to the VM's drive, which I'd rather not do).
Many people reported problems with PST files residing on a network share. Most frequently it was a PST file corruption. Make sure that you have a good backup.
Thanks for the info. Actually I've never had a problem with corruption with the PSTs, either when using VMWare Shared Folders or when using standard network shares from the VM.
Its just that Outlook would forget where they were.
Since I did the LMHOSTs thing at least for a few hours, everything seems to be fine using Shared Folders for the PSTs. (other than the fact Outlook is still seeing my previous links to the PST folders - looks like an Outlook bug, it won't let me remove them nor will it let me open them).
yeehaa - fixed the problem for me.
VMware needs to fix this (dont suppose they read these forums though )
I put the "127.0.0.1" .host fix in my lmhosts file in WinXP.
I'm on ubuntu 6.10 host with a WinXP guest.
The sharing is just horrendously slow in the beginning. Like if I click on a folder, it just sits there for like 10 secs and then goes ahead to list the files.. It catches up speed after that, but if you do something esle for like 10 secs (other than browsing the share..) you will see the slow down again.
Anyone know how I can fix this for sure??
bump?