That's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.

Part of the problem is the conflict of transparency and security here. Fixing the wholesale reuse of RNG state would most likely require modifying the guest so that it is aware of being restarted from a snapshot so it can react appropriately.

However, that might have consequences on what restoring from a snapshot means conceptually.

How about having a command to manually reseed the PRNG?

You mean like write(2)? :)

Yes, in general write to /dev/random with the write permissions is how entropy gathering daemons and the like work. It gets added the input and mixed in. However, that doesn't fix the issue of how a snapshot restore works on most hypervisors. Adding an RNG refresh as part of the restore process could be possible, but definitely not trivial, and it could have other consequences if not carefully implemented.

Not to mention that if you let untrusted people control VMs on the host side, you have bigger problems than this attack.