Copying a VM

[BCosell]

I'd like to make a full copy of my VM. I'm on Win10/pro with a win10/pro guest system. As I mentioned in a previous thread, cloning a windows VM doesn't really work for testing because the clone isn't registered. I can make copies of the .vbox and .vdi file but I'm not sure how to rename them so I can fire up the copy. Obviously I can rename the files but I'm guessing that the vbox file knows the "name" of its associated vdi file. I don't want to ever be able to run them both at the same time [at the least, I think MS might notice the duplicated prod IDs] but I'd like to "play" in the new copy, if it works [or not!] I can easily blow it away and then [if appropriate] do the corresoponding installs/tweak in the master VM.

Thanks! /bernie]

[socratis]

I'd like to make a full copy of my VM

On the same host? That's called a "cloning".

cloning a windows VM doesn't really work for testing because the clone isn't registered

That's a false statement. Cloning a VM always registers it.

Obviously I can rename the files but I'm guessing that the vbox file knows the "name" of its associated vdi file

Exactly. So don't start messing with the files manually, unless you know what you're doing, which means that you wouldn't be asking for help...

Answer the first point... do you want to have an identical copy of your VM for testing in the same host? In that case, you're looking at "cloning the VM".

[BCosell]

cloning a windows VM doesn't really work for testing because the clone isn't registered

That's a false statement. Cloning a VM always registers it.

That's not true. Something in the underlying virtual hardware changes and win10 believes it is not authenticaed or registered or whaever it is that windows systems do to make MS happy with them. My cloned win10 VM didn't work!

Answer the first point... do you want to have an identical copy of your VM for testing in the same host? In that case, you're looking at "cloning the VM".

Again; a clone isnt' "identical" -- the underlying virtual hardware changes enough to make windows unhappy. Is there some "really identical" clone that doesn't tweak something in the virtual hardware??

[BCosell]

Let me clarify the problem a bit: This from another thread about activation:
--------------------------------------------
Re: Win10 clone activation

Postby Martin » 2. Jul 2019, 19:01
The "clone" process creates a new, seperately usable VM. So it changes the virtual hardware enough to be a "different" PC for Windows.
----------------------------------------
Activiation was the term I was trying to remember: the cloned win10 VM starts up just fine, but windows detects the changed "virtual hardware" and demands to be activated. Since it has the same product-ID as the original system, MS won't be happy about activating two systems with the same ID.

[scottgus1]

Good you figured out that what Socratis said was perfectly true: the cloned guest does get registered, and registering is not in-OS activation, and that you had a misunderstanding of terms.

Usually a good idea when learning is to ask questions rather than making bold statements that the teacher is wrong. Puts the teacher off a bit when the student rebels like that after requesting the teacher's volunteer time for help.

[BCosell]

You're right. I stand chastised, humbled, but, alas, still uninformed....

[scottgus1]

What you could do is make a copy of the vdi while the guest is shut down. Then switch the names of the original vdi and the copy when you want to switch environments. Switch the names back when you want to go back to the original environment. Swap names as needed. You can have as many copies as your physical disk can hold. This should still be using the same "motherboard" as the original activated guest so all of the copies will be activated too.

One thing I should add is I don't think that this solution is compatible with snapshots. If you have snapshots in your guest let us know and we might be able to come up with something else.

[scottgus1]

It may also theoretically be possible to make an official clone look the same as the original to the guest OS for activation purposes with the DMI editing features of Virtualbox. See the manual, sections 9.11 and 9.8.2. You would apparently need to run DMIdecode for Windows in the guest to get the data the clone would need to show.

[BCosell]

What you could do is make a copy of the vdi while the guest is shut down. Then switch the names of the original vdi and the copy when you want to switch environments. Switch the names back when you want to go back to the original environment. Swap names as needed. You can have as many copies as your physical disk can hold. This should still be using the same "motherboard" as the original activated guest so all of the copies will be activated too.

I think I understand this. Basically the .vbox is always opening [what it thinks is] the same VM and I can simply shuffle vdis underneath it. Very easy.
it'd be cleaner if windows had hard links but this should work just fine. Thanks!

[BCosell]

It may also theoretically be possible to make an official clone look the same as the original to the guest OS for activation purposes with the DMI editing features of Virtualbox. See the manual, sections 9.11 and 9.8.2. You would apparently need to run DMIdecode for Windows in the guest to get the data the clone would need to show.

Wow.. This sounds very cool but looks like it is way tricky. I see that I could use DMIdecode to find out the full "machine config" in the first VM and then edit those settings in the clone. See,s scaru tp me but thanks..

[socratis]

One thing that's missing from the whole discussion is; what do you want to do with the "clone"? As it's been discussed, the clone is not a "twin" of the original, but has it's own signature, mainly the attached VDI's UUID. So, yes, a clone will need activation (unfortunately). The "what do you want to do" then boils down to, is the clone going to be needed for long term? Because you could simply ignore the activation procedure altogether.

Another way to achieve what you want is to take a snapshot of your VM, do whatever you want to do, and then revert to the snapshot that you took.

If you give us some more details, we could try and think of something...

[BCosell]

One thing that's missing from the whole discussion is; what do you want to do with the "clone"? As it's been discussed, the clone is not a "twin" of the original, but has it's own signature, mainly the attached VDI's UUID. So, yes, a clone will need activation (unfortunately). The "what do you want to do" then boils down to, is the clone going to be needed for long term? Because you could simply ignore the activation procedure altogether.

Another way to achieve what you want is to take a snapshot of your VM, do whatever you want to do, and then revert to the snapshot that you took.

If you give us some more details, we could try and think of something...

I want to be able to play around with potentially dangerous [or annoying] software and not clobber my "reference" system. I hadn't thought a lot about snapshots, but I bet that that'd do what I want with a lot less hassle. Is it typical in a kinda 'testbed' VM to instantly take a snapshot, then putz around safely and if it is good, go back to the reference snapshot, do what you want and then make a new reference snapshot. I don't intend them to long-term, and certainly not permanent so I think this'll be a much better approach to doing testing and fooling [e.g.,debugging programs I write that occasionally have the bad habit of deleting everything or screwing something up] Thanks!

[pt58]

Snapshots may well do what you require in this instance and will keep the activation status of your Windows VM.
However, before you start tinkering with snapshots, make sure you have backed up the whole folder containing the windows VM (the one that contains the .vdi and the .vbox)

It has been discussed many times on these forums how fragile the snapshot chain can be.
If you have a backup of the VM folder, at least you can just copy it back over the corrupted folder and get back to a clean, activated windows VM, should the worst happen!

In any event, I would limit the number of snapshots to 2 or 3 otherwise it becomes unmanageable and each snapshot adds to the fragility of the whole chain.