This information is for friends of s2disk (hibernate) who have problems with it when using VirtualBox (VB). What I’m saying here applies to an x86-64-bit-system with an Intel-CPU and VB 4.3.34 but probably to other VB-versions as well. I would like to point out that this is - in all likelihood - NOT an openSuse-specific issue. But as I’m using oS, I’m reporting it here.
s2disk (hibernate) may fail if you are running VirtualBox-VMs whose “Large pages”-feature is set to “off”.
“Large pages: off” causes a certain kernel-memory-item (NR_FILE_MAPPED) to increase way above usual values. This in turn may cause s2disk to fail.
You can check the settings of a particular virtual machine (VM) with the command
~> VBoxManage showvminfo "name of VM" --details
What you get is (among other info)
…
Hardw. virt.ext: on
Nested Paging: on
Large Pages: off
VT-x VPID: on
VT-x unr. exec.: on
…
For supported Intel (!) -CPUs with “Nested Paging: on” you can set “Large Pages” to “on” with the following command:
~> VBoxManage modifyvm "name of VM" --largepages on
The VM must be in a shut-down-state for this. Same command with “off” sets large pages to “off”.
According to the VB-manual “on” should even get you a performance-gain of 5%.
Also according to the manual, “large pages on/off” does not apply to AMD-CPUs. But I don’t know whether those are affected by the problem at all (would be interesting to know, though).
With “Large Pages: on” NR_FILE_MAPPED-values should be in the normal range and s2disk should succeed (provided you haven’t used too much memory and you have enough swap-space, that is).
I personally never “hibernate” or “standby” a system through the OS, there are numerous ramifications… and all are likely not specific to the virtualization technology.
I’ve never had a Guest refuse to “hibernate” or “standby” but then I haven’t tried to do so for many, many years. But, one of the problems I ran into long ago was that once in a while a system wouldn’t properly “wake up” for various reasons… ie just unresponsive, not accepting credentials, etc. That can be really frustrating since after a period of time you may not remember exactly what was going on in that Guest when it was put to sleep.
The virtualization technology’s own “suspend” alternative has been reliable. Again, not specific to any particular virtualization, I’ve found that the “Power - Suspend” option has always been reliable. The diff is that the virtualization technology writes the active memory map to disk and the OS never knows it has been powered off.
Your clock will always be inaccurate(thinking it’s the date and time when the system was suspended) when you resume. Unfortunately, this is typical however you “suspend” “hibernate” or “standby” a Guest, so if the Guest is doing something that’s likely dependent on accurate time, I shutdown the Guest properly so the next time it fully boots it will set time properly. If a Guest is “woken up” I always have to remember to manually re-sync time if I’m about to do something that’s dependent on accurate time.
So, bottom line is that at least for the various ways I’ve used virtualization, I’ve decided the possible convenience for suspending the OS is high risk with little reward. I’ll suspend a Guest using the virtualization technology when the occasion requires, but shutting down the Guest is always my first option.
Lastly, although the SDB seems to be woefully out of date even for 13.1 Evergreen, it’s probably still worth skimming if you’re thinking of messing around with s2disk: https://en.opensuse.org/SDB:Suspend_to_disk
Well,
I’d consider that even more of a taboo.
It’s fairly well known that suspending the Host causes unpredictable Guest issues, since they in turn are almost never properly suspended or shutdown themselves so suffer a sudden power issue, possibly in the middle of a transaction which almost certainly cause corruption. Remember, transactions that the HostOS can see can be resolved automatically before executing a power command. Transactions in a Guest are not visible to the HostOS so would not be handled correctly.
You’ll find numerous threads over the years about shutdown scripts that ensure the Guests are properly placed in some kind of stable state before the Host is shutdown or suspended.
This is off-topic here, IMO. I’ve written my post to help people who would like to use s2disk but have encountered problems due to the technical reasons outlined above. If you don’t like it, too bad but I can’t help it.
If you want to discuss the meaningfulness or risks of using s2disk while using virtualisation in general you should start a new thread or write a guideline.
OK.
Although we might disagree on whether the whole idea of hibernating a HostOS is relevant to the utility that is related to putting a machine into hibernation…