Assuming however it could somehow be pulled off; I guess potential ways to mitigate would be to keep a copy of the exact hardware characteristics of the system you originally have, kernel log on bootup, precise size of disks, chipsets of all the various controllers and compare when the system reboots. It would however be possible though extremely hard to get an exact duplicate of all of these at the virtualisation layer level.
You could call the virtualisation layer in the cpu requesting access to virtualise a subsystem, clock the data bus speeds... There should be some overhead from virtualisation that wasn't there when dedicated...
It's an interesting problem. I'll think more about it.
As for time needed, assume this: The attacker sets up a physical server that can accept the same physical disks as your server (with hotswap), with an additional disk (or ssd) for booting into a hypervisor, sets parameters for this hypervisor to closely mirror that of your server. The attackers server would typically be faster than yours -- it is/can be bought some time after your server was, so this should almost be universally possible.
The attacker boots the vm server, sets everything up; then kills power to your machine, moves the disks over. Your downtime: the time it takes to move the disks (literally).
Good luck differentiating between this and legitimate downtime.
I still think reading the encryption keys from RAM after cooling them with some co2 would be the more likely attack, but it's a fun thought experiment...