For the past 10 years or so, up to and including 6.0.12 (I *think* - you'd sort-of expect that the bug arrived with the 6.0 series, but AFAICT I was running 6.0.12 from 22-Sep-2019 until 06-May-2020, and don't recall having this problem late last year) suspending a Windows 7 host running Ubuntu guests (at least 16.04, 18.04, and 19.10) "just worked" with no observable problems (aside from the Bridged Network bug, which I assume still exists to this day).
In Dec2019, I had to update the host from W7 to W10, which throws a giant spanner into any sort of attempt to pinpoint when the problem started: it may well be CAUSED by W10, but it'll be a while before I can test on the same hardware with a Linux host. (I'll test a W7 guest at some point as well, which will be easier, but can't right now). Regardless, after also updating to VBox 6.1.6 in May, I discovered that guests no longer had functioning Audio Out after a host suspend. I went back to the 6.0 branch with 6.0.22, but that has the same problem.
The workaround is to suspend and resume the guest independently. Not brilliant, but certainly a lot less of a headache than having to reboot the guest.
JamesBanana's display-suspend audio problem seemed to be resolved by enabling Audio *In*, if I'm reading that thread correctly, but one of my VMs does have that enabled and still suffers from this bug, so I suspect either it's gotten worse since his post or that only works for him thanks to luck / timing / etc, especially since his failure was intermittent to begin with, while mine is "stable".
I wonder if perhaps the best way for VBox to handle things is to actually send ACPI Suspend messages to guests in reponse to a host suspend request, and block the host suspend until those have been processed. While it would doubtless slow down the suspend, it should only be by a couple of seconds at most (and I suspect not even perceptibly **), and would probably fix the Bridged Networking bug as a side-effect as well as numerous other potential guest issues. The only real negative to it would be a buggy guest potentially blocking the suspend indefinitely, so it would need a timeout, but even then the worst-case outcome would still be at least as good as the current situation.
** oh, ugh: "unless a guest has some defective configuration" - like being set up to Hibernate rather than Suspend, and a lot of OS's and DE's default to that now because of laptops. I'd still say that sending ACPI events is the right behavior, and highly desirable, but it would probably need to be OFF by default just to avoid people complaining about how "VBox made Suspend slow!"... :/
I generally have a known list of running guests, so in the meantime I'll see if some simple scripting on the host can handle things nicely-ish - but it would certainly be better if the process returned to just working by itself and didn't require that path, as it won't work for timeout-induced suspends etc.
--
I didn't see anything useful in the logs last time I looked, but I was tired then. I'll go over this one as well just in case something jumps out at me.