Mounted virtual Windows disk disappeared/won't come back

Doh! You have to log in to Windows before the disk appears. The info about the dismounting bug still applies though.
 
Last edited:
No. Does it work reliably with Parallels? Doesn't the Windows guest OS require exclusive access to the disk? I'm sure Windows would be quite upset if the disk keeps changing under it's feet. As I understand it, the current system is a user-mode filesystem that goes via the Parallels tools, and thus is synchronous with Windows.
 
Yes, you are right, therefore I asked this,
Looks like some third party software or driver does so.
Is there ProTools, Symantec, or some special software on Mac OS side
 
I'm not sure what you mean by special. However, I'm working with a recent clean install of Leopard, and since then I've kept a copy of every package I've installed. Here's what I have:

Adium
Photoshop CS3
BBEdit 8.2.6
Carbon Copy Cloner
Elgato EyeTV 3
Feisar iSync extensions for my Sony phone
GraphicConverter 5.9.5
iWork '06
Last.fm
LaunchBar
OmniGraffle Pro 3.2.4
OmniOutliner 3.6.3
OmniDiskSweeper 1.6
Salling Clicker 3.5.1
Second Life 1.20.15
Skype 2.7.0.257
Thunderbird 2.0.0.14
TimeLog 4.3.2
VLC 0.8.6f

Generally, I'm _very_ conservative about installing stuff, having had plenty of bad experiences with dirty systems.

The EyeTV installs a driver and I generally have it running when I'm using Parallels because of the cross-platform development I'm doing. Other than that, none of these other applications do anything bizarre with drivers or filesystems as far as I can tell. My machine is fairly heavily loaded because I do a lot of things at once. My Windows is really only used to run a cross-platform compiler, which loads it quite a lot and might cause timeouts. BUT, the disk usually disconnects when I try and do something intensive from Mac OS when Windows is idle.
 
My machine is fairly heavily loaded because I do a lot of things at once.

This can be the cause, in case of high I/O operations this can be the case
Did you try to put Parallels on external drive, this should decrease I/O load on bus?
 
Do you mean the Parallels application, or the VM disk? If you mean the latter, I'm running from my Boot Camp partition, and that has to be on the main drive. I'll do some experiments with different amounts of load when I have the time. (I have deliverables this week.)

However, even if heavy load causes an I/O timeout and a spontaneous unmount, I really think Parallels should re-mount the disk without having to reboot Windows. Couldn't Parallels monitor the situation and reconnect?

And if only Parallels would mount the disk in the same place each time (oh please yes!) then a lot of things wouldn't be too badly disrupted. This isn't as good as it working reliably in the first place, but it would help a great deal. At the moment I not only have to re-start Parallels, I lose all my shell sessions, editing sessions, etc. because the disk doesn't remount in the same place.
 
Hello John. I'm a bit skeptical about your assertion that Parallels can't remount the disk. Here's why: logging out of Windows and back in (without restarting Parallels or Windows) remounts the disk. Therefore something inside Parallels is clearly capable of restarting the MacFUSE mount.

I also did some testing. After a reboot, and without running anything else on my machine (except Safari), I ran Parallels and Terminal, and did the following command:

cd Documents/Parallels/My\ Boot\ Camp/Windows\ Disks/C/Program\ Files/
find . -type f -exec cat '{}' ';' > /dev/null

(In other words, copy the contents of all files in "Program Files" out of Parallels.)

Parallels' little green light on the disk icon flickers for a random amount of time up to minute or two, then stops flickering, then a few seconds later the disk unmounts itself. Here's the output in Console's "All Messages":

2008-07-28 16:27:03 fseventsd[42] failed to make the directory /private/tmp/442/C/.fseventsd (1/Operation not permitted)
2008-07-28 16:28:21 fseventsd[42] scan_old: bailing out because device mounted @ /private/tmp/442/C has dls 0x0 and dls->fci 0x0
2008-07-28 16:28:38 kernel MacFUSE: force ejecting (no response from user space 5)
2008-07-28 16:28:38 KernelEventAgent[39] tid 00000000 received VQ_DEAD event (32)
 
Depends on exit signal from MacFuse, - but I cannot continue further on this it is internals
We can test which load forces MacFuse to umount disk
 
Hi John. In _this_ case, using the test above, I was able to get the filesystem to remount by logging out and in to Windows only, so it should be possible for this kind of failure. Clearly MacFUSE is exiting with the right kind of exit signal in this case. Thanks for your persistence, and I look forward to your results!
 
Ok, I know, but this is going to be Parallels Desktop internals, probably I can create bug, but I am not sure this is the case to be fixed as such situation is very rare, and also we increased I/O stability in PD 4, If you want I can suggest you to test Parallels Server (the engine is almost the same as in PD 4 ), so you will be able to evaluate I/O
 
Another quick tip I have discovered. Pausing and resuming the virtual machine also causes the windows disk to remount, so you don't even have to log out and in again to get it back. This saves some time. You will still lose sessions and unsaved work from the Mac side though.
 
I have the exact same issue (XP guest OS hard drive just disappears and need to reboot and restart Parallels to get it back) and it appears to be getting worse. Used to happen like once a week and now twice a day. I asked for help from Parallels folks but did not get any good answers as to why it happens or how to fix it.
 
Parallels say the situation is "very rare" but I do not believe it. Almost any serious amount of activity with the mounted disk causes it to fail. I cannot be the only one using it with any intensity. I'm not even doing that much!
 
I agree. We have three Macs using Parallels/XP right now and all three of them lose the XP drive with varying frequency. Lucky me, mine is the worst.
 
Yes, this is the first suggestion we gave in this situation,
I guess problem occurs on low level in Mac OS, due to high load on I/O subsystem
 
Well, personally, I recommend against using this. I only had this feature enabled in the beginning and turned it off shortly after, It doesn't do nothing that shared folders can't do, except it opens up a promiscuous connection between both operating systems (OSX has write access to every Windows file without any respect for permissions), and fills up windows drives with useless spotlight and trash files, that take up space and are irrelevant for Windows.

Of course that this doesn't escuse the fact that it dismounts the drive on high (this is a relative measure) I/O activity. I just frown heavily at this feature and that it's enabled by default.
 
Back
Top