Cloning a Windows 7 VirtualBox VM – Avoiding Activation Problems


As described in another post, I was developing a Windows 7 64-bit virtual machine (VM) in VirtualBox. I had completed the first phase in this project: setting up a minimal machine with no antivirus software installed and no working Internet connection. I believed this minimal Win7 x64 VM would be good for virtualizing (i.e., making portable versions of) 64-bit programs that I would not be able to virtualize on the barebones 32-bit Windows XP VM that I had been using for virtualization.

I was not sure, at this point, whether I actually had any 64-bit programs that I would want to virtualize. It was possible that this minimal Win7 x64 VM would only serve as a backup in case something went wrong in the next phase. The next phase was to configure a more fully developed Win7 VM for daily use, as detailed in that other post.

Once I had finished the minimal VM, it made sense to clone it. That way, the minimal VM would be preserved in a separate state, where it would not be at risk of contamination or corruption from mistakes I might make while creating, altering, and deleting snapshots of my latest experiments. Once I had that backup, I could go ahead and tinker with the working clone, eventually arriving at a finished production VM that I could use for daily productivity.

I would probably want to make another clone at that point, again for the purpose of saving the finished working VM, in case daily use of the production clone caused it to become unstable at some point. Here, again, I did not want to have a string of two dozen snapshots to go digging back through; I wanted the simplicity and clarity of an entirely separate parent VM to dust off and re-clone, if that need arose.

The Problem

That all seemed reasonable. So I finished the minimal VM and made a clone of it, and then started that clone and proceeded to refine it for production purposes. But now, when I went into Control Panel > System, I saw this: “3 days to activate. Activate Windows now.”

It seemed that cloning would trigger the demand for reactivation, whereas making a copy or snapshot would not. At my level of familiarity with VMs, copies or clones preserved a desired distinctness that snapshots did not. Unfortunately, I had run into difficulties when attempting to use copies of VMs. That was why I had come around to cloning as the alternative. It seemed I had to try to make cloning work for my purposes, if possible.

I was not sure what impact reactivation would have. There seemed to be different scenarios. I had the impression that the Windows 7 license permitted the use of one VM along with one physical installation. That was what I intended: I did not anticipate any reason to be running any two of these Windows 7 VMs at the same time. But I was not sure whether the Windows activation mechanism would understand or care about that. Having seen reports of various activation or deactivation problems that people had experienced, I was also concerned that activating a VM might impinge upon the activation status of the dual-boot Windows 7 installation on this computer. Further, there seemed to be a risk that, if I reactivated too many times — even if it was just in the process of trying to come up with one production VM for daily use — Microsoft would refuse to allow any more activations.

The solution seemed to be to protect myself against unpredictable and possibly unwarranted activation barriers by finding a way to clone the minimal VM without triggering the reactivation demand. A SuperUser discussion suggested several possible routes. Most if not all of these solutions would require the user to make sure that VirtualBox was not running. In Windows, it was possible for processes to continue to run after they had seemingly been shut down. Task Manager (Start > Run > taskmgr > Processes tab) would indicate whether that was the case, and a right-click would end them if necessary.

Solution 1: Before Installing Windows:
Configure the Original VM 

TechRanker offered instructions on setting up a VM that would not trigger the reactivation requirement when it was cloned. In my interpretation, the required steps were as follows:

  • Use a UUID (also known as GUID) generating website (1 2 3) to create a new UUID. Let’s say the newly generated UUID was dbc5316a-2600-4d6e-8964-a07f3de5ded8. (I did not know how these sites could be sure that the newly generated UUID had never been used before; I just went with it.)
  • Use VirtualBox to create a new VM, with nothing installed in it. The steps here, in my version of VirtualBox, were Machine > New > Create a virtual hard disk now.
  • I was using a Linux system, so I used the Linux file manager. On a Windows system, I would have used Windows Explorer. Either way, I located the .vbox file that I had just created.
  • I right-clicked on that .vbox file and used the option to open it with a program of my choice. In Windows, that would have been Notepad. In Linux, I wanted to open it in gedit. But gedit wasn’t on the list, so I typed its name to add it to the list.
  • The .vbox file opened in gedit. I could see that the file prominently instructed me, “DO NOT EDIT THIS FILE.” But we were not going to ignore that. We were just gathering information.
  • In gedit, I went into Edit > Preferences > uncheck “Enable text wrapping.” This would make it easier to see the file structure and to count lines.
  • I found the line that began with “<Machine uuid=.” That was about nine lines down in that .vbox file. This line told me that my new, empty VM had a Machine UUID of, let’s say, 02f110e7-369a-4bbc-bbe6-6f0b6864ccb6. I copied that UUID into another text file.
  • Further down in the .vbox file, around line 20, I noticed a line that said simply “<Hardware version=”2″>.” (This was not to be confused with the “HardDisk uuid” line, up around line 12.) I noticed that there was no other information on that Hardware Version line. Then I exited gedit, saving no changes to the .vbox file.
  • I opened a command prompt and typed a command of this form: vboxmanage modifyvm [existing Machine UUID] –hardwareuuid [newly generated UUID]. (In case the formatting gets screwed up, that’s two hyphens (i.e., the minus key, located next to the zero at the top of most keyboards) in front of “hardwareuuid”; it is not one hyphen, or one long dash.) (It appeared this command would be the same if I had been using VirtualBox in Windows.) In other words, using the two UUIDs shown above, I would have typed this:
vboxmanage modifyvm 02f110e7-369a-4bbc-bbe6-6f0b6864ccb6 --hardwareuuid dbc5316a-2600-4d6e-8964-a07f3de5ded8
  • Executing that command just brought me back to the command prompt, which was probably good news: at least there were no errors.
  • I reopened the same .vbox file to take another look. The Machine UUID line had not changed. But the <Hardware version=”2″ line now contained the new UUID that I had specified in my command. Its contents were now of this form: <Hardware version=”2″ uuid=”{[newly generated UUID]}”>. In other words, if my system had given me the sample UUIDs shown above, the command would have looked like this:
<Hardware version="2" uuid="{dbc5316a-2600-4d6e-8964-a07f3de5ded8}">
  • Once again, I closed out of gedit, saving no changes to the .vbox file.

TechRadar said that, with that done, I could now start VirtualBox, and go ahead to install and activate Windows in this newly created VM, and then make a clone, and Windows would continue to be activated in the clone. I didn’t verify that.

Carlin explained that, when VirtualBox created a clone, it would generate a new Machine UUID, and this new UUID would trigger the change from activated to non-activated. The objective of the foregoing steps was to insert a UUID that would not change when Windows was cloned. I was not clear on how that actually worked.

I had already installed Windows in my VM, so this wasn’t the ideal solution for me. There was also the question of what would happen in the next generation: would Windows still be activated in a clone of the clone? Since those were likely aspects of my present and future situation, I was interested in finding another method.

Solution 2: After Installing Windows
but Before Cloning: Edit the .vbox File

Another solution suggested in that SuperUser discussion offered the possibility of fixing the cloning activation problem after Windows has already been installed in the original VM, but before the clone was made. Using information and techniques provided in Solution 1 (above), the instructions seemed to be as follows:

  • Use a text editor to view the contents of the .vbox file for the original VM.
  • In that .vbox file, copy the UUID from the Machine uuid= line and add it to the Hardware version =”2″ line. Include the characters (e.g., brackets) needed to make the Hardware Version line look like my example (above). Unlike the situation in Solution 1 (above), this Hardware Version line would not contain a newly generated UUID. Instead, it would just repeat the Machine UUID. Given the example UUIDs shown above, the line would look like this:
    <Hardware version="2" uuid="{02f110e7-369a-4bbc-bbe6-6f0b6864ccb6}">
  • Save and exit the .vbox file.
  • Start VirtualBox. Make the clone. Go into its Control Panel > System to see if it is demanding reactivation.

I tried those steps, after making a backup of my original VM. It seemed to work, but my findings at this point were complicated by an additional factor, discussed in the next section.

The Reinitialize Option

When making the clone, using VirtualBox, I had to decide whether to check the box that said, “Reinitialize the MAC address of all network cards.” A search led to a VirtualBox forum discussion in which people presented the following thoughts:

  • If you don’t select that Reinitialize option, you can’t run both the original and the clone on the same network at the same time, because they will have the same MAC address and will therefore be in conflict (though possibly this will not be a problem with NAT network mode).
  • Selecting the Reinitialize option will probably trigger the Windows reactivation demand. (That seemed right; I was pretty sure I had selected that option before making my previous clone.)
  • If you don’t select the Reinitialize option when you create the clone, you can reinitialize the clone’s MAC address later, when the clone is shut down, by going into the clone’s Settings > Network > Adapter 1 tab (or other tab, if appropriate) > Advanced > MAC Address > click the recycle button at the right. Presumably that would generate a reactivation demand.

I was not sure how this information would interact with the edits that I had just made in the original VM’s .vbox file. I decided to try it both ways, making clones of that original VM with and without the Reinitialize box checked. Then I examined their condition. In their Control Panel > System areas (opening each clone, one at a time), both clones said that Windows was activated. On the Hardware Version lines in their .vbox files, both clones still had the UUID that I had placed onto that line in the original VM’s .vbox file, and in both cases those UUIDs were different from the Machine UUIDs shown in those .vbox files.

(On one later try, I did not get these results. I suspected the reason was that, in that case, I may have left VirtualBox running while I made the Solution 2 edit. It appeared that VirtualBox would wipe out direct edits to the .vbox file in that case.)

It appeared, from these results, that my edit of the original VM’s .vbox file had taken precedence over the Reinitialize box. In other words, it seemed that my .vbox edit may have eliminated the reactivation demand, regardless of whether the MAC address was reinitialized. This was consistent with the claim, in a Disqus thread, that putting the original VM’s UUID onto the Hardware line was sufficient to satisfy activation. The person making that claim went on to say that Microsoft expected users to buy a new license in every case, but I was not sure. It seemed possible that, at least where only one clone was able to run at a time, the user might be within the scope of the claim that it was permissible to run Windows on one VM.

I tried making a clone of each of those clones. In this generation, I checked the Reinitialize box in both cases. To make sure, I went into their settings and clicked the recycle button to reinitialize (again), as described above. Then I opened these VMs, one at a time, and went into their Control Panel > System. These, too, were activated. Unless the Windows activation checker was not constantly awake — unless, that is, it might later come to life and change its mind — it appeared that, in all future generations, the Reinitialize button would no longer function as others had described (above), once the original VM’s .vbox Hardware line was edited as indicated above.

There remained the question of whether the Reinitialize box made a difference, when cloning from an original VM whose .vbox file was not edited as described above. To test this, I made a clone of the original VM and edited that clone’s .vbox file to restore its Hardware line to its original condition. I verified that this clone’s Control Panel > System page said that Windows was activated. Then I made clones of that clone, one with the Reinitialize button checked and one with that button unchecked. Both said that Windows was activated.

I was not sure what to make of that result. My original problem, before starting this post, was that I had made a clone of a Windows 7 installation, and it had needed to be reactivated. Just now I had done exactly the same thing, and the clone did not need to be reactivated. Why the difference? I had undone the change I had made to the original VM’s .vbox file, and yet I had obtained a result that suggested the change was still in place.

It seemed that I must have screwed up somehow, or that my experiment was flawed, or that, in some way, I was overlooking some essential difference between the original situation and this last experiment. But then I got the same result when I made a clone of a different VM, this one containing a 32-bit rather than 64-bit version of Windows 7. That Win7 x32 clone likewise needed reactivation. The conclusion seemed to be that, once I had altered the original Win7 x64 VM’s .vbox file, or perhaps once I had altered it and then run that VM, other changes had taken place — in, perhaps, the .vdi file — and now the Reinitialize checkbox was irrelevant. It seemed that (aside from the possibility of more complex editing in one or more VM files) the only way to undo the effect of the .vbox edit described above would be to replace the original VM with an earlier backup of that VM.

Solution 3: After Making the Clone:
Edit the Clone’s .vbox File

The SuperUser discussion giving rise to some of the foregoing material suggested that it would also be possible to use a vboxmanage command, as in the first solution discussed above, to revise the .vbox file for a clone of an already-configured Windows VM. I decided to try this approach on the Win7 x32 VM clone mentioned in the preceding paragraph. The steps necessary to implement this approach appeared to be as follows:

  • Proceed, as in Solution 1 (above), to view the original VM’s .vbox file and copy its Machine UUID to a separate text file. Make a note in that separate file to clarify that this is the original VM’s Machine UUID. Notice that there is no UUID on the Hardware Version line (above). Exit without saving any changes to the .vbox file.
  • Do the same thing with the clone’s .vbox file: copy its Machine UUID to that separate text file, label it, and exit the .vbox file without saving any changes.
  • Run a command of this form: vboxmanage modifyvm [clone’s Machine UUID] –hardwareuuid [original VM’s Machine UUID]. (See Solution 1, above, for more information on that command.)
  • Start VirtualBox. Run the VM. Verify that the clone’s Control Panel > System area no longer calls for activation.

Those steps worked for me: the clone was activated. As I had experienced with Solution 2 (see preceding section), clones of this clone were likewise activated, regardless of whether I clicked the Reinitialize option in VirtualBox.

I supposed this solution could also be achieved by editing the .vbox file directly, as in Solution 2 (above). Indeed, it appeared that Solution 2 might be the only one of these three solutions for which a direct .vbox edit was essential.

Solution 4: Use a PowerShell Script

The SuperUser discussion also offered a PowerShell script, for those who were using VirtualBox in Windows. I was not working in Windows and was not knowledgeable about PowerShell. The proffered script appeared to be intended for use where the clone had already been made. That script was as follows:

$vboxDir="c:\Program Files\Oracle\VirtualBox"
cd $vboxDir
$uid=$($($(.\VBoxManage.exe showvminfo $ORIGVirtualMachineName|select-string "Hardware UUID:").ToString()).Split())[4]
.\VBoxManage modifyvm $clonedVirtualMachineName --hardwareuuid $uid

I didn’t know whether this script would work as desired. If it would, of course, the variables stated on the first three lines would have to be modified to suit the specific case. I supposed that a skilled scripter would be able to devise a one-line command that would enter those variables automatically.

It looked like this script would have the advantage of doing the hard work (i.e., looking up the UUID values from the .vbox files); the user apparently just needed to know the names and locations of the VMs. As such, it seemed that a skilled scripter could also revise this script to accommodate the situations discussed in all of Solutions 1 through 3 (above). For that matter, a revised script could look for the locations of VMs and could guide the user through the options. No doubt a Linux script could achieve similar ends.

Other Solutions

The preceding sections describe methods of preventing the VirtualBox cloning process from triggering a demand for reactivation. Of course, these were not the only kinds of steps that people could take and apparently had taken in response to Windows activation difficulties. Those could include simply going online to reactivate this VM, with the risks described above; buying another Windows 7 license; as well as more radical and in some cases probably illegal use of pirated license keys, the Daz Windows Loader, or other tricks like those described in a ZDNet article. It did appear that VirtualBox could be improved to incorporate the solutions described above, so as to eliminate the difficulty of achieving those solutions and the temptation to try easier alternatives.


I had found my solution — indeed, multiple solutions, depending on whether I had already installed Windows in the original VM and, if so, had already made a clone of that VM. Aside from the possibility of learning how to write relevant scripts, my solution seemed to call for either editing the .vbox file or running a vboxmanage command. But possibly there were other solutions, further down in the list of results produced by my search or something like it.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , . Bookmark the permalink.

3 Responses to Cloning a Windows 7 VirtualBox VM – Avoiding Activation Problems

  1. fhfgh says:

    Does it works on Win 10?

  2. Dr.Teo says:

    What if the Hardware version =”2″ line does not exists?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s