Quick and dirty suspend feature

[fdr]

The case of re-allocating if CPU and/or memory resources have since allocated is left unsolved.

Also seen is grotesque copies of bookkeeping of VmHost core and memory counts, as well as some tests I declined to copy and paste for "systemctl stop" idempotency.

[furkansahin]

We can either exclude suspending and suspended states from the before_run and handle destroy path in these labels OR we need to be careful transitioning the VMs back to not suspended and then destroy. Otherwise, we will cause used_cores value to drift from reality.

[furkansahin]

Do we have to nap this long? It simply means the unsespending will happen manually. Considering the semaphore increment will be done by the operator, I'm OK with this. But, maybe we can reduce it?

[fdr]

well, strange thing, last system routinely napped for a thousand years and was more event-driven. This system is actually regressing in reducing spurious polling-like traffic relative to its predecessor.

So it's odd it shows in one place, yet, we're kinda doing something wrong everywhere else where we could fall asleep for a long time.

[byucesoy]

Maybe we should schedule the strand when semaphore is incremented. It would definitely push things more towards being event driven and would encourage longer naps.

[bsatzger]

I like the idea of being more event driven, and incrementing semaphores could be one of these events. In this case, someone needs to log into the console already and increment the unsuspend semaphore. It's probably ok to then also run the strand to immediately perform the unsuspend action.