Windows 10: VM Tips and Tricks?

Yes, I've already done it. I don't get your point, other than that you don't know how the Checkpoints work. OP's question:

The answer: Use checkpoints. When installed and ready to save your vm, create a checkpoint to save the vm in its initial state. You can always restore it, go back to the exact point when the checkpoint was created.

 

I think two different questions might be getting answered here, and I thank you both for your feedback. Having separate VM states for different customers sounds like it can be best accomplished by having 2 or disks. I'm not seeing how it can be done with checkpoints honestly, although I see how checkpoints make easy to roll back to a given state for a given machine (e.g., it's initial state). But I would still like to export that initial state and have it live on a completely different disk, in case something drastic happens.

 

Checkpoints are great (they are like restore points really) you can try something and roll it back.

For separate machines you want different disks (either exported or copied).

You could install something on one disk, make a checkpoint (A) and restore back, install something else, make another checkpoint (B) and restore back. If you then upgraded A through Windows update and not B (but added a new program to B) you would get completely lost with checkpoints. How you would restore from some state of B to some state to A is at least non-trivial..

It just wouldn't work as that is not what checkpoints are for.

 

It never stops amazing me how the people who do not know refuse to accept the fact they really do not know and feel offended when the lack of their knowledge is shown. It's as if it would be more important to not correct the false information than to give the correct information.

Of course you can make two branches of checkpoints. Or three or four or five, as you desire. Here's an example of a vm I am working just now, checking various imaging and cloning scenarios, at the moment two totally different checkpoint branches. I can restore (apply) any checkpoint on any branch when I want to and create new checkpoints on that branch:

Truly noted. In the future when / if I want to response a thread, I will first send you a PM outlining my possible response and waiting your acceptance before posting it.

 

Warning Let's keep this friendly shall we.

 

OK, No further comment.

 

Let's just make this very clear:

OP's question:

When you want to save the initial state of your vm, the checkpoint is the way to do it. It does exactly what you want to, according to your question: it saves the initial state of your vm.

Please remember that although it has been posted in this thread that you cannot have several branches of checkpoints, that is not true; you can create new checkpoint branches as you wish and restore (apply) any checkpoint from any branch whenever you want to and further create new checkpoints on that branch.

The checkpoints do not only do exactly what you asked for, they allow you to save various states of your virtual machine.

If you want to reuse the same VHD on another vm, then export is the way to do it. Remember that an exported new vm needs it's own product key to activate whereas restoring a checkpoint to state when Windows was activated does not require reactivation.

 

I'm really looking to have two different environment states. Since I can't use the same key across different virtual machines, it looks like I have to use one machine (where it's activated) and change the pointer to the disk. That seems pretty easy to do.

With checkpoints, can you do this ...

Create initial VM state - create checkpoint 1
Install Software/Setup ENV for Customer/Scenario A - create checkpoint 2
Go back to initial VM state, and install software/setup ENV for Customer/Scenario B - create checkpoint 3

Now let's say I'm working with B for awhile, and need to go to A. So I go back to checkpoint and do some work. How to I go back to B? Would I need to save off checkpoints each time I switch from A to B?

 

An unauthorized response, this not being a tutorial but let's try *Wink

Yes, the checkpoint feature is the absolutely easiest and practical method to do exactly that.

If you have saved new documents, installed new software or done any changes on your vm then yes. If you have just used it generally bot not saved anything special, you don't have to do it.

Here's an example scenario:



(Click to enlarge.)

"Now" marks where I am / the vm is at the moment, in 2nd checkpoint in the first branch after installing Office 2016. Because I changed the state of the vm by installing Office, I created this last checkpoint. (Number 1 in screenshot above is the "mother", the parent checkpoint, all later checkpoint branches and checkpoints in them will be child objects to it, therefore I do not count it as first checkpoint in this branch.)

I can now apply the first checkpoint, the "mother" for both checkpoint branches (1) or any of the previous checkpoints in this branch (2 or 3) or jump to a totally different branch of checkpoints by selecting any checkpoint in the 2nd branch (4 or 5). Whatever checkpoint I select, the vm is restored to that exact state, as it was when the checkpoint was created.

When applying a checkpoint Hyper-V by default checks if you want to save the current state first in a new checkpoint before creating a new one:




To apply a checkpoint, right click it and select Apply:

 

VMs are copyable and portable. I copy VMWare virtual machines to a network drive as a backup method to ensure that I can recover when an active vm becomes unusable (which can happen, though relatively rarely). However, if you try to create a new vm with the same product key you will get a message that the product key is in use or is unavailable, or something similar. Product keys in a vm are subject to the same licensing terms as in any computer.

In summary, vms are not distributable in the manner you are asking about. Contact Microsoft Sales and Support about redistributable copies of vms.

 

Hi there

Incorrect -- Cloning VM's will retain activation etc etc. If you MOVE a VM to significantly detectable different hardware you *might* be requested for activation but in general you won't be.

Bear in mind though you are only allowed to run ONE VM at a time under the license. It's a bit like having 7 backup copies of W10 -- you can restore any of them without re-activation and they will work -- however restoring and running more than ONE concurrently is not allowed.

Cheers
jimbo

 

When you are asked to reactivate a VM is when you convert it between virtualization programs. For example if you convert a VirtualBox vm to a VMWare vm. That is a change in virtual motherboards. The virtual motherboard does not change if you are moving the VM from one computer to another. IT departments routinely move vms between servers.

The user is entitled to protect his investment by backing up his data, including vms. There are many ways to do so.

Cloned vms will run concurrently on different computers without requiring reactivation but the MAC address must be regenerated to avoid network conflicts. This is a violation of a consumer license, however. This is avoided in IT enviroments with the use of volume license keys.

 

Hi there

Nothing in the EULA about MAC -- running VM's doesn't mean you have to even install networking - you can choose between Host only, NAT, Bridged or None - well you can in VMware / vbox.

Mac addresses can be protected / set in your firewall but in general at a non corporate level you can ignore this. VM's though if you move them between different environments (on a CONSUMER rather than a corporate network) will give a message of the type "Did you Move or Copy" the VM at the first power on. Thi is only done because of an identifier GUUID -- you can set in the config to not create a new GUUID if a VM is copied / moved to a new machine (or even to a new HDD).

It's 100% legal to CLONE VM's. If you have a single windows license then you are only allowed to run ONE VM at a time unless you have a Volume type license.

I've converted a VM from VMWARE to HYPER-V and back again without getting asked for re-activation. I suppose it's dependant on your VM configuration and whether the VM can detect any significant difference in the REAL or Virtual hardware -- for instance the VM will know what type of physical CPU it's using so some hardware changes will be detected.

Cheers
jimbo

 

The EULA doesn't concern itself with MACs because it is not a licensing issue and that isn't why I mentioned it. But duplicate MAC addresses on an infrastructure network will cause a network conflict so it is de rigeur to generate a new MAC in one of the clones.

 

Sorry, Kari, you are correct and I was wrong.

I apologise for saying otherwise - you can certainly can make different branches of checkpoints.

If anyone finds it a more convenient method - it is certainly an option to consider.

BR, Hali