Cloning a Windows 7 VirtualBox VM – Avoiding Activation Problems


The Problem
Solution 1: Before Installing Windows: Configure the Original VM
Solution 2: After Installing Windows but Before Cloning: Edit the .vbox File
The Reinitialize Option
Solution 3: After Making the Clone: Edit the .vbox File
Solution 4: Use a PowerShell Script
Other Solutions & Related Tools



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 step would be to configure a more fully developed Win7 VM for daily use, as detailed in that other post. (Note: this post has been updated somewhat from its original version.)

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 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. There was the prospect that, in its push to move people to Windows 10, Microsoft might invent arbitrary excuses to deny Windows 7 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. In Notepad, it would be Format > uncheck Word Wrap.
  • 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 this website screws up the formatting, 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 that, at least where only one clone was able to run at a time, the user might be viewed as permissibly running 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:
Modify the .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.

In 2018, I revisited this section of this post. This time around, I was using a Windows 10 host rather than a Linux host. I also had a different situation. This time, I didn’t have a clone created directly from a source, using VirtualBox. That sort of clone would be registered (i.e., listed) in VirtualBox Manager as soon as it was created.

Instead, I wasn’t sure what I had. It was either a clone or a copy. I had set it aside for a while, and I wasn’t sure where it came from. I think what happened, though, was that I used CloneVDI (discussed in another post) to expand the size of the source VM, and that triggered the reactivation demand.

I confirmed that, in any case, this copy was indeed a later version of the source VM. I confirmed that when I tried to add it to the list in VirtualBox Manager (via Machine > Add). Doing so gave me this error:

Failed to open virtual machine located in [path and file name].


Cannot register the hard disk [path and file name and UUID] because a hard disk [same path, different file name, same UUID] already exists.

Result Code: E_INVALIDARG (0x80070057)

In other words, both the source and this clone had the same hard disk UUID. So that pretty much guaranteed they were related: the clone (or copy; whatever it was) was a descendant of the source VM.

I looked at their .vbox files, as discussed above. (In Windows, I found Wordpad to be good for this. Unlike Notepad, it detected where lines should end: the contents of those files were not streamed along a single line.) In Wordpad, I could see why the error message referred to a hard disk, and not to a machine. The “<Machine uuid=.” values, occurring about nine lines down from the top in each .vbox file, were not identical. That is, VirtualBox was not seeing a conflict due to the machine UUIDs. Rather, the conflict occurred due to the hard disk numbers. Those (repeating the same UUID) were listed at two places in those .vbox files: as the HardDisk UUID under the Media Registry, near the start of the file, and also as the Image UUID under the Attached Device section, near the end.

I wondered whether I could generate a new hard disk UUID, thereby removing the conflict, by cloning the copy. To find out, I went into VirtualBox Manager > select the source VM > right-click > Remove > Remove only. That removed the source VM from the VirtualBox Manager’s list of VMs, but did not delete its files from the system. Next, I used Machine > Add > add the copied VM’s .vbox file to the list. With that VM selected in VirtualBox Manager, I tried Machine > Clone > Expert Mode > give it a new name, select Full Clone and Everything, and check the box to Reinitialize the MAC address (since the thing would need to be reactivated anyway — see above) > Full clone. Unfortunately, this produced an error:

Failed to clone the virtual machine .

Could not create the clone medium [clone VM path and name] (VERR_VD_READ_OUT_OF_RANGE).

Result Code: VBOX_E_FILE_ERROR (0x80BB0004)

That error also recurred if I chose Current Machine State rather than Everything in the cloning options. Seeking a solution to that error, a search produced only a handful of hits. I thought at first that the problem might stem from insufficient disk space for the clone. But after I revised VirtualBox Manager > File > Preferences > General > Default Machine Folder to point to a different drive with plenty of extra space, the problem recurred.

Another theory was that there might be something wrong with the system producing that error. That theory was intriguing. This Windows 10 installation was the one whose corruption by a recent Microsoft update had prompted me to set up a Linux machine as an alternative. Proceeding on that Linux host, then, VirtualBox was able to clone the copied VM without a problem. As on the Windows machine, the source VM and its copy (i.e., the two VMs that had the same hard disk UUID, above) could not coexist on the VirtualBox Manager list of VMs; but when I removed the copy from the list, I found that the source VM and the clone of the copy did coexist.

So the answer seemed to be: yes, at least in this situation, creating a clone of a machine with a conflicting UUID produced a VM whose UUID was no longer in conflict with the source VM. As just described, I had to use a Linux machine to verify that, but that was the outcome. If that had not worked, GroovyPost (Krause, 2017) seemed to think that a vboxmanage internalcommands sethduuid command could solve the problem, and an old post by MrKoen (2009) raised other possibilities.

Now that the source VM and its descendant (i.e., the clone of the copy of the source VM) were both registered in VirtualBox Manager on the Linux machine, it seemed that I should be able to run the vboxmanage command (above) to resolve the activation issue. I had already accumulated some notes related to this process, as it would have unfolded in Windows, if the Windows 10 system had been cooperative. I include those notes here — although at this point, as I say, I was proceeding with VirtualBox in the Linux host. Thus, at the risk of redundancy, the steps I took at this point were as follows:

  • I closed VirtualBox.
  • I used a text editor to view the contents of the .vbox files for the source VM and for this descendant VM. In Windows, I found that Wordpad was adequate for this purpose. In Linux, I used the default text editor.
  • In each of those .vbox files, I identified the line that began with “<Machine uuid=.” beginning about nine lines down from the top. I copied that line into a text file. (After the UUID, that line contained the name of the VM to which it pertained, so that I wouldn’t mix up the two UUIDs by accident.) Then I closed the .vbox file without making any changes in it.
  • In the text file, I used those two UUIDs to create a command of this form: vboxmanage modifyvm [clone VM’s Machine UUID] –hardwareuuid . (As above, those are two hyphens, not one long dash, preceding hardwareuuid.) So, for example, if the machine UUID from the source .vbox had been dbc5316a-2600-4d6e-8964, and if the machine UUID from the clone’s .vbox file had been 02f110e7-369a-4bbc-bbe6, this would have been the desired command:
    vboxmanage modifyvm 02f110e7-369a-4bbc-bbe6 --hardwareuuid dbc5316a-2600-4d6e-8964
  • I copied and pasted that command into a command window. In Linux, that was Terminal, and it required no additional preparation. In Windows, to avoid an error (i.e., “‘vboxmanage’ is not recognized as an internal or external command, operable program or batch file”), I would have had to either add VBoxManage to the system’s path or steer the command prompt to the folder where VBoxManage.exe was installed (e.g., C:\Program Files\Oracle\VirtualBox) using the CD command (i.e., cd “C:\Program Files\Oracle\VirtualBox”).
  • When I ran the command, Terminal (in Linux) didn’t have much to say about it. There was no response. On the positive side, there was also no error message. To verify that the descendant VM was now activated, I had to start up VirtualBox > select the VM > Start > Control Panel > System > scroll to the bottom. There, it said, “Windows is activated.”

In other words, it worked.

Solution 4: Use a PowerShell Script

The SuperUser discussion also offered a PowerShell script, for those who were using VirtualBox in Windows. The proffered script appeared to be intended for use where the clone had already been made. The SuperUser version of the script was a bit cryptic. I was not familiar enough with PowerShell to make it work as-is. Instead, I added a number of comments to provide some clarity. The following lines provide my fleshed-out interpretation of that script. I did not finish testing this script; it may need additional work. To read the script, copy its text into a text editor (e.g., Notepad).

# This is VBoxCloneReac.ps1
# This script runs in PowerShell. PowerShell is included in Windows 7+ and
#   is available for download and installation in Windows XP SP2+.
# Back up your material before using this script.

# This script reactivates a clone of an activated VirtualBox virtual machine (VM).
# The following instructions provide one way to save and use this script in
#   a Windows system.

# Make sure both the source VM and its clone are registered and functioning
#   in VirtualBox, and that the source is activated (see Control Panel > System).
# This should be a clone made in VirtualBox, not a copy (made by e.g., copying
#   the VM in Windows Explorer). In a copy, both VMs will have the same UUID, 
#   therefore VirtualBox will not register one of them.

# Copy this script to Notepad, and save it as VBoxCloneReac.ps1.
# Close Notepad. In Windows Explorer, right-click on VBoxCloneReac.ps1 > Edit.
# VBoxCloneReac.ps1 should open for editing in the PowerShell GUI.
# Edit the contents of VBoxCloneReac.ps1 as the following steps indicate.

# Define the VM that has been cloned:
# In the following command, replace  with the name of the source VM,
#   as listed in VirtualBox.
# Example: $SourceVM="Win7 VM Version 1"

# Define the clone that has been created from that source VM:
# In the following command, replace [clone] with the name of the clone VM,
#   as listed in VirtualBox.
# Example: $CloneVM="Win7 VM Version 2"

# Define the directory where VBoxManage.exe is located:
# In the following command, replace [dir] with the full path of the folder
#   that contains VBoxManage.exe.
# Example: $VBoxDir="C:\Program Files\Oracle\VirtualBox"

# Save this script.
# Use Task Manager (Win-R > taskmgr) to make sure VirtualBox is not running.
# Use PowerShell > File > Run to run this script.

# Nothing to change here: these lines perform the reactivation.
set-executionpolicy remotesigned
cd $VBoxDir
$uid=$($($(.\VBoxManage.exe showvminfo $SourceVM|select-string "Hardware UUID:").ToString()).Split())[4]
.\VBoxManage modifyvm $CloneVM --hardwareuuid $uid

It seemed this script might work in a Windows guest VM on a Linux host system, if VirtualBox was installed in the guest. Again, VirtualBox could not be running on the system (in that case, it would be the guest system) at the time when the system was executing this script.

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 & Related Tools

The preceding sections describe methods of preventing the VirtualBox cloning process from triggering a demand for reactivation. My search indicated that these were not the only kinds of steps that people could take and apparently had taken in response to Windows activation difficulties. Other possibilities 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. Possibly there would also be something useful in my previous post on Windows XP activation. 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. Note also the potential value of a tool like Advanced Tokens Manager, as explained by How-To Geek.

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

5 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?

  3. Jeff S. says:

    Just wanted to note that I ran into this problem when creating a VM on a new host (laptop) that pointed to the .VDI file on a file server. I was running the image on the file server but wanted to run it on the laptop as well. The new entry on the laptop got a new UUID and what got everything working was reading the UUID from the linux host (as listed with vboxmanage list vms) and then running the modifyvm program on the laptop to change the UUID there to match. Now that windows 7 VM seems happy and activated successfully.

  4. scott says:

    On the newer .vbox files, the hardware uuid key is not present in the initial file. I tried to add the same hardware uuid as the machine uuid and nothing changed. I had to clone the vm, (so a new machine uuid was generated) then use vboxmanage vmmodify to set the hardware uuid to the activated vm’s machine uuid. At that point, a hardware uuid key was inserted in the clones .vbox file.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.