Without having read the whole thread in detail, let me add that i had those poofs as well when i stored my images on a firewire connected external fat32 partitioned harddisk. The problems went away once i moved to the macos filesystem. Let me also add that i also haven't reached the fat32 file size limit. I am pretty sure that FAT32 caused this instability.
Eternal Poofs Of Deathâ„¢ (EPOD)
- Thread starter danimal39
- Start date
Thorby - Have you tried to turn off devices yet on your VMs? I'm trying to isolate my particular situation and so far, the two remaining devices I've yet to turn back on is USB and sound. Everything else seems to work without a hitch, been running since 9 this morning, so that's....5 hours, a new record. =)...networking, floppy, CD/DVD, all seems to work well being active.
Still putting the program through its paces, though. I'll let you know what I find out, Andrew. Thanks!
--
Danny
Still putting the program through its paces, though. I'll let you know what I find out, Andrew. Thanks!
--
Danny
Holy crap!!! How did that happen??
When I set up this new macpro with its two, 500GB drives, I partitioned the second drive with two, 10GB volumes, VISITOR1 and VISITOR2, just for containing files (.hdd, .pvs, other) related to virtual machines. And -- wow -- those two volumes are MSDOS FAT32s! ... Not something I'd have done intentionally, must be a Disk Utility default I didn't notice...
I do note that when I took a poof-ing .hdd to a DVD, and from the DVD onto a Macbook hard disk (which I just checked and is definitely OS X Extended) the .hdd still failed (poofed) in that new environment.
I'll try removing devices from the Parallels setup screen -- I can no longer get to the Windows Device Manager (if that's what you mean) because the VM poofs too early.
Disabled all devices except Memory and Hard Disk in each of two failing VMs. They still poofed during bootup, just like before.
Reformat VISITOR1 and VISITOR2 as OS X Extended volumes. Rebuild WinXP VM: installed, ran software update (63 updates!) installed F-Secure trial. All lovely but that's normal. The real test comes tomorrow!
Last edited:
Okay Andrew,Andrew @ Parallels said:
I have W2K installed on a Virtual HDD formated in NTFS loaded on a FAT32 drive. Parallels is loaded on my main MacPro OSX drive. To clarify, the VHDD is located on an external and completly seperate ATA drive installed in the 2nd CD bay. Details as follows:
WDC WD1600JB-00GVC0:
Capacity: 149.05 GB
Model: WDC WD1600JB-00GVC0
Revision: 08.02D08
Serial Number: WD-WCAL98266182
Removable Media: No
Detachable Drive: No
BSD Name: disk2
Protocol: ATA
Unit Number: 1
Socket Type: Internal
Low Power Polling: No
OS9 Drivers: No
S.M.A.R.T. status: Verified
Volumes:
BACKUP:
Capacity: 148.85 GB
Available: 144.82 GB
Writable: Yes
File System: MS-DOS FAT32
BSD Name: disk2s2
Mount Point: /Volumes/BACKUP
I did all that you suggested, I've got EVERYTHING off except for the stinkin' HDD and it still wont get past about 5 seconds of post boot run-time in Windows 2000 (quite possibly the MOST stable windows platform).
So the question is...do I need to format the real HDD to NTFS and also format the VHDD to NTFS?
-MacSolidWorks
Possible time sync or clock issue with Parallels to OSX
It occured to me that the POOF or EPOD issue seems to be occuring after a specified time limit for everyone affected. For some it's the next day, for others it 5 hours (as mentioned above), for me it was about the same.
I created my Win2K VM early in the day, installed all the thousands of updateds and service packs, got Microsoft Office installed and updated, even installed SolidWorks 2005.
My newly installed VM was working fine when I left the office for dinner at 6:15pm, when I returned at 9:00pm I pulled OSX out of sleep (I left the VM up and running with OSX in sleep mode to test the stability of the VM) and began installing an update for SolidWorks.
The update was to bring SW up to the 2006 version which required swapping multiple CD's in the drive...then the POOFING began on CD #3. So that's about 8 hours of good running.
At any rate, my thought is that there may be a time sync or clock issue with parallels. Maybe something similar to the millenium computer issue a few years ago?
I did a "get info" in finder to look at the created date and time information .hdd & .pvs files. Interestingly there is NO information. It shows the modified date and time but only two dashes for the created date and time.
To be fair, the other files I checked that are Windows files created in BootCamp do not show a created time and date either. However, wouldn't the .hdd and .pvs files be an OSX file type since they are running under an OSX application?
A conundrum for sure.
danimal39 said:
It occured to me that the POOF or EPOD issue seems to be occuring after a specified time limit for everyone affected. For some it's the next day, for others it 5 hours (as mentioned above), for me it was about the same.
I created my Win2K VM early in the day, installed all the thousands of updateds and service packs, got Microsoft Office installed and updated, even installed SolidWorks 2005.
My newly installed VM was working fine when I left the office for dinner at 6:15pm, when I returned at 9:00pm I pulled OSX out of sleep (I left the VM up and running with OSX in sleep mode to test the stability of the VM) and began installing an update for SolidWorks.
The update was to bring SW up to the 2006 version which required swapping multiple CD's in the drive...then the POOFING began on CD #3. So that's about 8 hours of good running.
At any rate, my thought is that there may be a time sync or clock issue with parallels. Maybe something similar to the millenium computer issue a few years ago?
I did a "get info" in finder to look at the created date and time information .hdd & .pvs files. Interestingly there is NO information. It shows the modified date and time but only two dashes for the created date and time.
To be fair, the other files I checked that are Windows files created in BootCamp do not show a created time and date either. However, wouldn't the .hdd and .pvs files be an OSX file type since they are running under an OSX application?
A conundrum for sure.
It's a really, really bad idea to put your virtual hard drive on a file system formatted with FAT32. FAT32 has an absolute limit of 4GB for the size of any file. As soon as your virtual hard drive tries to grow beyond that limit, it will fail.bgose said:
Reformat that drive using HFS+ (Mac OS Extended) format.
Thorby - how's your testing going? The most interesting thing happened here. In trying to prove/disprove the sound device being the culprit, I'm running now, with all my devices turned on, including sound. It's been running solid for the last part of yesterday and the morning. Nothing to show for yet. Sounds works as expected, I'm starting to install software on the VM (keeping in mind the hdd is still on the FAT32 partition, and I'm keeping an eye on the file size) this morning and all seems to be working well...
Another interesting thing was, in poking around enabling/disabling devices yesterday, I noticed my sound properties panel had choices for 'dsp' and something else I can't remember besides for 'Default Audio'. I ignored it and clicked on enable, selected default audio and launched my VM. No problems yet...
Perhaps my sound properties were wonky and it was defaulted to 'dsp' or something weird like that, causing the poofs. I'll admit, I never took a closer look at the sound properties...
--
Danny
Another interesting thing was, in poking around enabling/disabling devices yesterday, I noticed my sound properties panel had choices for 'dsp' and something else I can't remember besides for 'Default Audio'. I ignored it and clicked on enable, selected default audio and launched my VM. No problems yet...
Perhaps my sound properties were wonky and it was defaulted to 'dsp' or something weird like that, causing the poofs. I'll admit, I never took a closer look at the sound properties...
--
Danny
OK....so it did it again. With sound device disabled. Also, with a poofing hdd, turning off all the devices and moving it on to an HFS+ volume will not let it boot again. I can see XP trying to switch resolutions (and my Parallels window actually gets to 1024x768), and even before the desktop comes up, it EPODs. Running in safe mode, the last item I see is windows\system32\drivers\mup.sys. Not sure what is loading after mup.sys, but it's causing the EPOD. Which, I've observed before just about every single time this has happened. mup.sys is the last item to load, and I can't get my VM running.
Strangely enough, the VM ran solid for over a day and a half prior to this morning. Thorby? How is your VM running?
--
Danny
Strangely enough, the VM ran solid for over a day and a half prior to this morning. Thorby? How is your VM running?
--
Danny