HeadScratcher wrote:I have copied the 50+ gig VB directory to backup media, and could copy it back over to a new HDD if my current HDD were to fail.
Would this trigger a call for a Windows reactivation?
No, it wouldn't. Win7 would only want reactivation if the machine UUID changes, which won't happen as long as you keep the .vbox and .vdi files together. If you clone the VM (not the same as copying) or use the export/import feature then the VM UUID changes, and the machine UUID along with it... unless you have overridden the default machine UUID with an explicit UUID.
HeadScratcher wrote:A related question: let's say the SSD fails instead, and I install a slightly newer version of VirtualBox -- 5.0.12, say, instead of my current 5.0.2 -- on the new SSD, then try to point it to the VB directory on the HDD.
Would that trigger reactivation?
No. Updating software never affects data. In this case the VM UUID stored in the data file is not affected.
HeadScratcher wrote:I found a post elsewhere suggesting that I first fire up VBoxManage on the command line, then add a new hardware ID to my current installation through the command:
VBoxManage modifyvm --hardwareuuid
This new hardware ID will supposedly allow me to copy the VB folder without triggering activation calls. Sounds like an interesting experiment, but I'm worried that I'll trigger an activation call by adding a hardware ID that wasn't there before.
The whole point is to add an ID that was there before, so that it becomes explicit, not a variable default. The explicit setting is hopefully retained by cloning (I've never actually tested it, otherwise you'd have to correct the .vbox file manually).
If I was you I'd pick a VM where activation isn't an issue, say a Linux VM. Then I'd experiment with how to set an explicit hardware UUID such that it appears how I want when read by a DMI tool inside the guest. If you can do that you can do it for a Windows VM too.