Unfriendly shutdown of Windows Guest: unable to boot!

[luposlip]

Can you do a chkdsk on that partition from the repair console?

I was able to run a "chkdsk /p /r" which made the files on the drive readable again.

But the windows installation is dead, so I had to revert to an older version of the vdi file.

[luposlip]

Maybe this is a Mac OS X specific problem as I have never heard of this before on other platforms. We'll look into it.

Thanks!

[alexeynaidyonov]

Maybe this is a Mac OS X specific problem as I have never heard of this before on other platforms. We'll look into it.

I've reproduced it twice in a row with OS X (first I've accidentally pulled out power cable out of imac with my own leg, second time I've killed vmbox intentionally).

Seems like Linux version is more tolerant for power failures since I wasn't able to reproduce the problem at my linux box.

[daveungerer@gmail.com]

Maybe there's something our setups have in common?

I'm running version 10.5.2 of OS X currently - new machine and I'm still busy downloading 10.5.5. On a MacBook 4.1 (Santa Rosa), 2.1. GHz core duo, 2.5 Gb ram (unmatched modules as I'm waiting for the other 2 Gb module to arrive).

[salvatore]

I recently experienced this same issue; here's some specifics about my scenario.

MacBook Pro (Intel Santa Rosa) 2.4ghz w/4MB RAM.
OS X 10.5.5
Virtual Box 2.0.2
VM was XP Home Edition

I didn't realize the power connection had become dislodged, and the laptop lost power instead of forcing itself to sleep. After rebooting the VM would show the XP boot splash screen, but would disappear soon afterward. The log has several hundred lines of 'disk read error'. I dont have an XP disk with me to attempt a recovery.

If there's other information I can provide to help diagnose this, please let me know.

.salvatore

[Minette]

I just had a major crash of Win XP Pro which I am running inside MacOS 10.5.5 on a MacBook.
I was copying GBs of data from an external USB drive (looking at the drive through networking because the USB disk would never show on Win XP, but that's another story) when half the screen of my MacBook dimmed, like the entire screen does before going in sleep mode, and my Mac completely hung.
When I restarted the Mac and VirtualBox, every reboot of the Virtual Machine would give me an error message UMOUNTABLE_BOOT_VOLUME right after the Windows logo shows up and immediately restart the VIrtualBox VM.
I tried recovering with my Win XP CD and it does not let me do it, too damaged.

As a side note, I have used Win XP for over 6 years now on a Dell and never never had any problem like this where I lost the OS completely.

I am reinstalling another instance of XP in VBox, but would like to know how I can access the files of the first installation from the second installation. I made the mistake of not backing them up, I guess I trusted VBox too much
Thank you.

[fixedwheel]

I was copying GBs of data from an external USB drive (...) when half the screen of my MacBook dimmed, like the entire screen does before going in sleep mode, and my Mac completely hung.

i hardly know anything about applemac, but i know someone who lost all his valuable GBs of Data while moving them to or from external USB drive his applemac completely hung. There was a bug in MacOS X causing this freeze

I made the mistake of not backing them up, I guess I trusted VBox too much

i suspect you trusted Apple too much

[jimav]

Hmm, this may explain why vbox is 'unreliable' compared with real hardware when power is lost:

Vbox ignores IDE disk-flush commands in the guest by default. If Windows XP periodically tells the IDE controller to flush its write buffers, some changes might actually never be propagated to the host's file system, causing corruption if power is lost. I'm just guessing here; but you might want to try enabling IDE flushing and see if things get better (see below).

The vobx user manual (page 132 in the pdf version) says this:

11.1.3 Responding to guest IDE flush requests

If desired, the virtual disk images (VDI) can be flushed when the guest issues the IDE
FLUSH CACHE command. Normally these requests are ignored for improved performance.
To enable flushing, issue the following command:

VBoxManage setextradata VMNAME "VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/IgnoreFlush" 0

The value [x] that selects the disk is
0 for the master device on the first channel,
1 for the slave device on the first channel,
2 for the master device on the second channel
or 3 for the master device on the second channel.
Only disks support this configuration option. It must not be set for CD-ROM drives.

[jimav]

In case any Sun developers are listening:

Suggest that vbox infrequently (e.g. every 5 minutes) flush all cached disk state to host disk storage even if IDE DisableFlush is set on. And maybe provide an option to fsync too.

If you are worried that this would impact performance too much, then do the flush only if the guest's disk-write frequency is low, assuming normal writes have the effect of flushing previously-buffered data.

That should avoid disk corruption if power is lost (e.g. laptop battery dies in middle of the night), assuming the guest OS flushes its data to 'disk' periodically.

[luposlip]

In case any Sun developers are listening:

Suggest that vbox infrequently flush all cached disk state to host disk storage even if IDE DisableFlush is set on. And maybe provide an option to fsync too. If you are worried that this would impact performance too much, then do the flush only if the guest's disk i/o activity is at a low level, i.e., a condition likely to indicate an "idle" guest.

For example, every 5 minutes.

That should avoid disk corruption if power is lost (e.g. laptop battery dies in middle of the night), provided the guest OS has flushed its disk data.

Actually it seems like Sun already fixed this issue witg version 2.1.2. From the changelog:

Code: Select all

Mac OS X hosts: save the state of running or paused VMs when the host machine’s battery reaches critical level 

Can any Sun guy/gal confirm this? I'm not sure it fixes all of the problem, because if the power is suddenly out on i.e. a desktop computer w/o UPS, the above fix isn't probably sufficient, and your suggestion might be a thing to look at.

[jimav]

Actually it seems like Sun already fixed this issue witg version 2.1.2. From the changelog:

Code: Select all

Mac OS X hosts: save the state of running or paused VMs when the host machine’s battery reaches critical level 

Can any Sun guy/gal confirm this? I'm not sure it fixes all of the problem, because if the power is suddenly out on i.e. a desktop computer w/o UPS, the above fix isn't probably sufficient, and your suggestion might be a thing to look at.

Explicitly sensing battery level is nice (though such system integration will be very difficult to get right on all platforms, given that low-battery-shutdown thresholds might be implemented in messy window-system software).

IMO it would be most helpful to let us tell VMs to catch any termination signal and save the VM state before exiting. That would safely handle normal user log-offs, accidental window closing, X-server crashes, etc. It could also handle OS shut-down (including due to low battery) because unix, when shutting down, sends sig 15 and waits a while before doing kill -9. However, the delay would have to be long enough to allow VMs to save their state.

On my system (ubuntu 8.10, 2.67GHz i7, 10kRPM disk), it takes just about 10 seconds to save the state of a Windows VM using 2GB of memory. This is exactly how long Ubuntu waits for processes to exit after kill -15 before they get kill -9. This is controlled by code in /etc/init.d/{killprocs,sendsigs} which could be hacked to wait longer.

As a practical matter, VirtualBox would have to install some intercept in the OS-shutdown machinery to reliably allow enough time to save VM state.

Here's an idea: If kernel modules can intercept arbitrary system calls (by hook or crook), then make vboxdrv guarantee a minimum delay between sig 1 or 15 and sig 9 when sent to processes executing VMs. That way, -if- the VM is set up to save state when it gets sig 1 or 15 then it will get enough time; if it's not set up to do that, it will die immediately as usual.