TreyH

Yes, it does, but following its directions exactly on Ubuntu 20.04 LTS under Unraid doesn’t work. It took me some fiddling to find the right combination, so I really hope this helps someone else out later!
 
These alterations are necessary because most Linux distros have recently (well, gradually over the past 5–10 years, Ubuntu LTS just a few years ago) switched from swap partitions to swap files. If you have an actual swap partition (fairly unlikely these days, but possible) then the steps in the AskUbuntu question above should work better for you.
 
(Funny, we (well, not me we—but people who were alive then) used swapfiles on Unixes all the way back to the 1970’s (!), switched to swap partitions in the 1990’s, usually abandoned swaps entirely in the next decade, and now we’re back to swap files—I’m not sure why we call them two-word “swap files” now when we used to call them one-word “swapfiles”, but, ya know…)
 
Anyway… Here’s what to do:
Locate your swap file—almost certainly it’s at “/swap.img” or “/swap”, but you can run “swapon” (not as root, and with no arguments, lest bad things happen!) to find out. (It should also be listed in /etc/fstab.) Run this (replacing “/swap.img” below if necessary), and make a note of the UUID generated (which I’ll call <SWAP_UUID> below). It should be a hexadecimal-dashed value in a 8-4-4-4-12 form like “b34dc0d3-5968-5a32-f4d9-f9e6b5d4afa6”. sudo findmnt -no SOURCE,UUID -T /swap.img Then run 
sudo swap-offset /swapfile and make a note of the number value (I’ll call it <OFFSET> below).
Save a backup copy of /etc/default/grub (in your home directory or somewhere else it will stick around between reboots, not /tmp!) and then edit it (with sudoedit or your favorite method for editing system files) to modify the “GRUB_CMDLINE_LINUX_DEFAULT” line that should already be there, but is probably currently blank. Insert the UUID from the last step at “<SWAP_UUID>”. (Yes, that does mean there are two equals signs in “resume=UUID=<SWAP_UUID>”, it’s not a typo…) It’s possible you’ve had to edit it before to make booting Linux work with a passthrough device; if so, keep those arguments while adding the “resume” and “resume_offset”. GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=<SWAP_UUID> resume_offset=<OFFSET> quiet splash"  
Run
sudo update-grub Important: if you run into any trouble below this step and don’t have a working hibernate/resume, come back here and restore /etc/default/grub to its prior state and re-run this command. If your machine refuses to boot after an attempted hibernation, attach to its graphical console at startup time with VNC, and select a safe boot from the startup GRUB menu. [Continued below at bottom¹.] 
Install the uswsusp package: sudo apt install uswsusp Configure it with: sudo dpkg-reconfigure -pmedium uswsusp Answer “Yes” to “Continue without a valid swap space?” Do not select the /swap.img choice; instead, select the choice corresponding to the UUID above, probably “/dev/disk/by-uuid/<SWAP_UUID>”. Answer “No” to encryption—unless on this Linux VM you’ve done the steps usually associated with getting a Windows gaming VM to work with native GPU/USB, there is no keyboard or graphics attached to the VM at resume time (which is a slightly weird state not really corresponding to traditional BIOS/UEFI startup), so there’s literally no way to enter the password because the VM doesn’t have any connection to the “outside world” when it asks. If you have done those GPU/USB steps and want to enable encryption, you probably have other work to do, and I can’t tell you what will work. But needing encryption on a shutdown VM in a running virtual host is surely quite a niche case… When you finish the three questions in the uswsusp wizard, it will exit and should give messages showing it’s refreshing your initramfs config itself. But if for some reason it does not, (or, if for your own reasons you know you need to manually modify your initramfs.conf further) run: sudo update-initramfs -u But whether the wizard updates initramfs or you do, ensure it does not make any complaint of “no matching swap device is available”; if it does, you should look at a guide (there are many out there) for removing and recreating your swap file, and then start over with #1 above.
Now test that uswsusp hibernation works:
sudo s2disk If you’re logged in via graphical console, you should see the machine shutdown. If you’re logged in via SSH, your connection should quickly go dead. Either way, refreshing the VMS tab of your Unraid console, you should see your VM as “Stopped”.
Start the VM again, just as if you were booting it cold (most easily, by clicking on its icon in the VMS tab and choosing “Start” from the pop-down.
Within seconds, your machine should be back up and you can SSH back in, or attach to its graphical console. Run “uptime” to verify that, as far as the OS is concerned, the VM never rebooted (that is, the uptime value should be back to the last time you rebooted the OS, not just the seconds or minutes it took to get here from clicking “Start” in this step). Any other running processes that don’t die when a network connection is interrupted should continue running normally.
You’ve manually hibernated and resumed now, but unfortunately this still won’t respond to Unraid asking Linux to hibernate itself. To do that, you need to modify systemd. Run:
sudo systemctl edit systemd-hibernate.service You’ll have an editor with either a blank file, or a file that wasn’t working before. Clear it and replace it with:
[Service] ExecStart= ExecStart=/usr/sbin/s2disk ExecStartPost=/bin/run-parts -a post /lib/systemd/system-sleep (The two “ExecStart=” lines, the first with an empty right-hand side, is intentional and required.) Save and exit the editor.
You can verify you now have a hibernate systemd function by running
systemctl status systemd-hibernate.service It should give output including a mention of an “override.conf”.
Now test the systemd hibernate manually:
systemctl hibernate It will likely ask you for your password several times. (Don’t worry, when Unraid requests a hibernation, it won’t need your password.) Once again the VM should shutdown, and you should do the same to bring it back up and verify it worked as in step 7.
Now you can test the real thing by selecting “Hibernate” from the VM’s pop-down menu in the Unraid VMS tab, waiting a few seconds, reloading to verify the VM is stopped, selecting “Start” from the VM’s pop-down menu, and one last time checking it worked as in steps 7 and 10. If this doesn’t work (whether by the VM’s failing to respond to the Hibernate, or its shutting down hard instead of hibernating, or appearing to hibernate but not successfully resuming) when everything before this did, make sure you’ve installed the recommended “guest” packages for your Linux distro on the VM. (It is usually necessary to reboot after installing the guest packages and before attempting a hibernate/resume cycle.)
Now, if you wish, you can set the VM to auto-hibernate when Unraid reboots. A timeout of 90 seconds should be more than sufficient (unless you have very large RAM and very slow disk, I suppose…).
 
——
¹ If after this step, you attempt to boot and
you don’t even get a GRUB safe boot option; or, if you have no way to access the graphical console in order to interact with GRUB; and so the machine
endlessly reboots, hangs at boot, or shuts itself back down immediately after boot; you’ll need to boot from a live rescue installer image and restore GRUB.
 
To do that, you’ll either need to change the Unraid VM settings to include a live rescue installer as the OS Install ISO: option, or you’ll need to create a whole new VM with the live image and with the old disk image available as a primary or secondary disk via 9p or other such means.) And then follow its instructions (or the many guides online, such as this one) to repair a corrupted GRUB config. The Boot-Repair tool for Ubuntu (described here for if you accidentally install Windows on your preexisting Ubuntu machine) is a no muss, no fuss way that works in most situations (but I’ve actually never tested it in an Unraid VM—so you may need to fall back to one of the more manual options described in these guides!).
 
But…
 
Much safer and easier: If you have the available disk space, the safest and easiest thing to do is to make a backup copy of your entire VM’s boot disk image; that way, even if GRUB gets corrupted so badly it won’t let you boot into safe mode, you can revert back to the backup image of your Ubuntu installation before you modified it.
 
I happened to have installed a brand-new SSD just before starting this process, so I made image backups as manual “snapshots” at several points above before eventually landing on the above steps I could do start-to-finish.