[RndTbl] Windows activation on Linux VM host?

[Alberto Abrao]

On 2021-01-22 8:28 a.m., Kevin McGregor wrote:
> What John said.
>
> The rest of you are making this way too complicated. The physical 
> hardware beyond the CPU capabilities does not "seep" into a VM. The 
> motherboard (chipset and everything else) is fully virtual and moves 
> with the VM. As an aside, on VMware ESX you can specify a "maximum" 
> CPU generation such that e.g. any Intel CPU newer than Nehalem looks 
> exactly like a Nehalem. Good for multiple generations of blades in a 
> server farm; with this enabled you can live-migrate from any blade to 
> any other blade all you want.
KVM does the same. And yes, come to think of it, that would pretty much 
eliminate the activation re-trigger. Good point.
>
> Just don't P2V. Ever.
>
> I've moved VMs from host to host many times and *never* had a 
> licensing problem.There are no "VM-unfriendly" versions of Windows 
> licenses. They can all be virtualized equally. You need one license 
> per "machine", whether that machine is physical or virtual. Moving the 
> VM around changes nothing.
>
All of the above is true - except for P2V'ing - and even for OEM licenses.

(and yes, we are making it complicated, lol)

>
>
> On Fri, Jan 22, 2021 at 12:37 AM John Lange <john at johnlange.ca 
> <mailto:john at johnlange.ca>> wrote:
>
>     I'll offer up my non-expert opinion and say that you will be fine
>     with a single VM on removable media running Windows10 regardless
>     of which machine you fire it up on. My reasoning is straight
>     forward; it is very much common practice to have virtual
>     environments with many physical hosts and to move VMs between
>     hosts on a regular basis. Granted that is a more complex
>     environment that just removable media but the concept is the same.
>     Moving VMs between physical hosts is afterall one of the whole
>     points of virtualizing so if Windows10 stopped working everytime
>     you did that what would be the point?
>
>     As far as testing goes, I have in the past had Windows VMs on a
>     Linux workstation and when I upgraded to a newer system I just
>     copied the VMs over and fired them up on the new machine, no
>     problem. (this was Windows7, but I expect W10 would be the same).
>
>     However, the one thing that I don't believe will work is to P2V a
>     workstation that was purchased with Windows10 already on it. That
>     version of Windows is OEM licensing and I believe it still has
>     very specific terms that the license lives and dies on the
>     original hardware only. I'm sure you can P2V it and it will run,
>     but it may complain? That being said I'm sure there is a way to
>     re-activate it by buying the proper Windows10 license.
>

You can P2V*, it *will* complain, and then you have the two options I 
described before for activation. All are A-OK.


The only caveat with OEM is that the VM must run on the same physical 
hardware tied to the licence. If you buy a server with an OEM Windows 
Server licence, for example, and wants to virtualize it on top of 
something else (VMware, for example), it is OK to use the same licence 
to do so, as long as VMware is running on top of the original hardware.


* as a fun tidbit, virt-p2v clones the physical hardware to the point 
that it also clones the NIC's MAC Address. When I was preparing my last 
presentation, I p2v'd a machine, then started it on the virtual host. 
After that, I went back to the physical machine and wiped its hard 
drive, proceeding to stage the environment for the demo Nextcloud 
install. After all was said and done, I was left wondering why the 
connection for the fresh physical machine would drop every minute or so...

...yep, the resulting p2v virtual machine had the exact same MAC address 
of the NIC found on the physical one. So when I had the physical machine 
back on the network, chaos ensued. :D


Kind regards,
Alberto Abrao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://muug.ca/pipermail/roundtable/attachments/20210122/b479e800/attachment.htm>