The solution in use now is that the guest OS asks the VM host for entropy using its VM guest specific kernel drivers, to seed the CSPRNG of the guest. If you ha

The solution in use now is that the guest OS asks the VM host for entropy using its VM guest specific kernel drivers, to seed the CSPRNG of the guest. If you have it do that on every guest RNG request you'll get the same desired effect without adding more communication. When you duplicate any VM guest, all sensitive key material should be replaced instantly (preferably never copied to begin with, the host should generate and inject fresh key material). Refilling the entropy pool alone isn't enough when reuse-insecure ciphers like stream ciphers are actively used, for the reasons stated above. Some ciphers are more tolerant of reuse (see AES-GCM vs AES-GCM-SIV).