VMware

This Question is Not Answered

1 "correct" answer available (10 pts)
1 2 3 4 Previous Next 59 Replies Last post: Sep 2, 2008 10:10 AM by dosers   Go to original post
Click to view I_C's profile Enthusiast 41 posts since
Jun 3, 2008

I have repeated the wake from sleep spontaneous reboot a few times to make sure it wasn't my imagination :) It could be anything, usb device waking up, time machine backup running after waking... At least that is what is happening when the vm is coming online just before it reboots on mine. I'll look at it more tomorrow.


Attachments:
Click to view etung's profile Guru 11,086 posts since
Oct 15, 2006
Wow, that's kind of scary (especially with all the other people seeing this). I've filed PR 285962 about this.

If anyone's not using a 64-bit guest and is hitting this, that would be useful to know.
Click to view XianPalin's profile Novice 2 posts since
Aug 6, 2008

For the record, and to bump this back up to the top, I am randomly having this problem as well, both in Fusion 2b1 and Fusion 2b2, where my Mac Pro sometimes does a hard reboot when I try and open a Virtual Machine, whether it's Boot Camp (Vista 64-bit), or a VM (Xp 32-bit). I did not have this problem with Fusion 1.

I haven't tested to see whether or not it's related to my machine being asleep (I do put the machine to sleep at night, but always close VMware first), but it is quite annoying.

Click to view I_C's profile Enthusiast 41 posts since
Jun 3, 2008

As a cheap work around you can:

sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --restart

and it wont reboot your machine when you power on a vm after waking from sleep. But having to remember to always do that is annoying.


Click to view etung's profile Guru 11,086 posts since
Oct 15, 2006
o.O

Can people who are seeing this test if I_C's boot.sh hypothesis true, or merely a coincidince? If true, it would help narrow down the search.
Click to view JeFurry's profile Novice 20 posts since
Aug 7, 2008
I'm using a 32-bit Windows XP SP3 VM, created with a slipstreamed SP3 installation CD under VMWare 2.0 beta 1 (now upgraded to beta 2), and I'm getting the instant reboots on my one month old 8-core Mac Pro running 10.5.4 patched up to date.

If I put the system to sleep with the VM running, waking from sleep goes almost immediately to a restart instead of resuming (after a few seconds delay with a blank screen, which is presumably while it's waking from sleep then triggering the restart). If I suspend the VM and put the Mac to sleep, it seems to wake from sleep correctly and operate normally, but when I later attempt to resume the VM, I immediately get a restart as mentioned above - no kernel panic, no diagnostic logs... just a sudden blank screen and reboot.

In both cases, after the reboot, the VM is in a "powered off" state, which suggests it did actually resume and change state before the host machine restarted.

I'm happy to run further tests if needed, as time permits.
Click to view bkirby's profile Novice 6 posts since
May 24, 2008

The workaround fixes the issue for me.

I have 2 VM's, one XP Media Center Edition, one XP Pro, both 32-bit. If I bring my MacPro out of sleep, and then attempt to resume either suspended VM, the whole machine restarts hard. This is 100% reproducable by sleeping the machine and resuming. After that, resuming any suspended VM crashes.

I don't see any crashes if I run the workaround after the MacPro wakes up.

--

Bill


Click to view etung's profile Guru 11,086 posts since
Oct 15, 2006
Interesting!

What network mode are you all using (NAT/Bridged/etc.)? What version of OS X?
Click to view XianPalin's profile Novice 2 posts since
Aug 6, 2008

I'm on a 2008 Mac Pro, OS X 10.5.4. Both machines (boot camp on a separate SATA drive and VM on the local OS X drive, no RAID anywhere) cause the problem and both are setup for Bridged networking.

I'll try the boot.sh workaround tonight and let you know if it works.

Click to view bkirby's profile Novice 6 posts since
May 24, 2008

I'm running OS 10.5.4. Both VM's are in NAT network mode.

--

Bill

Click to view HPReg's profile Hot Shot 384 posts since
Dec 22, 2004
Folks, we are still unable to repro this issue at VMware (we tried hard). So we rely on you for the debugging.

Confirming that the "boot.sh --restart" workaround works for everybody (in particular dosers) would be very useful.

If it turns out it works, then the next step is to see which of our kernel extensions is responsible for this. To do so, you need to make a copy of boot.sh in the same directory, let's call it boot2.sh, and modify boot2.sh so that it only reloads one kernel extension at a time: i.e. first try by commenting out all kextload/kextunload commands except for vmmon.kext. Now use boot2.sh --restart. Does it workaround the problem? If yes, then we know that the vmmon kext is guilty. If it does not solve the problem, then move to the next kext: commenting out all kextload/kextunload commands except for vmci.kext. And so on and so forth. After this experiment, we will know which kext is guilty.

Thanks for helping us help you.
Click to view I_C's profile Enthusiast 41 posts since
Jun 3, 2008

I will go through the boot.sh as you outlined this evening and see how it goes and post my results. Thanks!

VMware Developer

SDKs, APIs, Videos, Learn and much more in the Developer community.

Learn More

Developer Sample Code

Increase your developer productivity with VMware API sample code.

Learn More

VMworld Sessions & Labs

Online access to the latest VMworld Sessions & Labs and online services.

Learn more

Purchase PSO Credits Online

Purchase credits to redeem training and consulting services online.

Buy Now

Community Hardware Software

View reported configurations or report your own.

Learn More

VMware vSphere

Come witness the next giant leap in virtualization.

Register Today

Communities