Ubuntu Karmic in Virtualbox VM failed to resume after Hibernate

Resume from hibernation failed with cryptic error messages in the dmesg log:

[    4.816045] PM: Starting manual resume from disk
[    4.816046] PM: Resume from partition 8:5
[    4.816048] PM: Checking hibernation image.
[    4.816092] PM: Resume from disk failed.

I'd created the VM with an initial 1024 MB of RAM, and accepted the Ubuntu installer's automatic partitioning of the 15 GB VDI I'd created for the VM. Apparently the installer isn't smart enough to consider allotting enough swap space for hibernation while creating the swap partition, because it created a 768 MB swap partition. 

Although I didn't see any log messages about running out of swap space to dump memory image while hibernating, I wondered if this might be the problem. After shutting down the VM, I reduced RAM allocation to 512 MB, and restarted the VM. Hibernation and resume worked fine. I repeated this procedure, bumping the allocated RAM up to 768 MB - still worked.

So, if for some reason you need hibernation working with Ubuntu 9.10 inside your Virtualbox VM, and have taken the auto-partitioning scheme, like I did, this is one point to check.

I also discovered that the Virtualbox Guest Additions go crazy after a hibernate/resume inside the VM; the shared X11 clipboard no longer works (can't copy text in the VM and paste in in the host OS); mouse capture and uncapture reverts to the manual mode instead of automatic capture/uncapture; host CPU utilization for an apparently idle VM hits the roof (keeps one core at 100%). 

This means that Virtualbox's own close-window-and-save-VM-state method of suspending a VM is the best. I wound up poking into the guest OS' suspend and hibernate because Virtualbox failed to resume the VM properly - it just discarded state and booted the VM from scratch, which puzzled me. After I reduced the RAM assigned to the VM, apparently Virtualbox's own save-state seems to have started working as well. At least, a couple of tries succeeded. Also, the save-state and resume-state operations seem to have sped up drastically (but maybe disk cache has something to do with that).

Ah, well - just a small brain-dump for the next time I find a VM save-state and resume fails.

UPDATE 28 Feb 2010: That was NOT the end of it... subsequent attempts to use VBox's save-state again gave me problems, at which point I began some determined Googling because this was really pissing me off. Turns out that VBox 3.1.0 onwards has a new bug, where save-state locations other than the default ~/.VirtualBox/Machines/$VMNAME/Snapshots are ignored when looking for saved state while resuming. I added a confirmation of the problem at the Virtualbox Forums, and confirmed that "if the saved-state file is created in the default location (as mentioned above) then resume from saved state works. If it is created in a custom location, the saved-state file is ignored by VB 3.1.x and the VM is booted from scratch. The saved-state file created in the custom location is left there, and not deleted after switching back to the default Snapshot Folder."