Is it possible to run a virtual Windows (10) on a Linux host running something like virtualbox? It has to be normal Win 10 Home or Pro though, no corporate licensing. I ask because I'm unsure how Windows activation (cursed be!) handles that situation. I'd like to be able to run the same host image on 2 different boxes (but not at the same time) and not have it moan about activation. So I guess the question is more this: does the VM hide/abstract the hardware enough from Windows to have it think it hasn't changed boxes? (The idea is a portable drive with the VM on it would travel between 2 locations which are never used simultaneously. Each location would have an identical Linux box. Don't ask why; suffice it to say that speed is paramount and cloud or net access or remote access won't cut it. Lugging the entire box is not an option. Laptop is a very sub-par option.) Thanks!
Based on a recent experience, I'd say that Windows will not let you get away with this, but I'd like to know what happens if it's already activated BEFORE virtualizing. I used virt-p2v to create a Windows instance of a fresh install. I had just bought a new machine and thought I would be clever if I did this before wiping it and installing Ubuntu. It mostly worked. I actually wrote down what happened and here's the weird story. Licensing is stupid. When I was done, it told me I needed to activate but then it complained and said I had the wrong license type for a VM. I forget the wording of that though. Also though, afaik you can run without activating indefinitely. (sorry this is long but it's all true...) *How To Run a Virtual Windows 10 Desktop* Microsoft Azure has a 12 month free trial. It's a datacentre service, where you can run virtual machines in the cloud. Hardware owned and managed by Microsoft, where you can just create computers in the cloud and use them. Creating an instance of Windows 10 Pro is easy. There is a message on the screen that says "make sure you have a valid Windows license, of one of these types..." They list them but there is no way to buy them. I wanted a checkbox that said "charge me $1/month for the license" but it didn't exist. I used the online chat. They wanted my phone number so a consultant could call me. I said no. 2 days later they called me anyway. I told them what I wanted and they said they didn't know the answer. To be clear, my question was how to buy a Windows license for an Azure machine. They didn't know. I think I do know the answer, which is SPLA but The minimum commit for that is $150/month last time I checked. I happen to have a brand new computer with Windows 10 Pro on it, so I might as well just virtualize this before wiping it and installing Ubuntu. It took hours to install the Windows updates, which I decided to do first before uploading the image. That's normal though. I _should_ have installed the virtio drivers first as well, which would have made them automatically picked up during the VM creation. virt-p2v noticed that they were not installed though and use the RTL8139 driver. Very nice of them to do that. It works just fine, although virtio is faster. Won't really make a serious difference for this machine though. I went to Redhat's virt-p2v. On my Ubuntu desktop, "sudo apt-get install libvirt-tools" and run virt-p2v-make-disk. First USB stick I was going to use was too small. Only 4GB. Second one was 16GB, which was fine. After 2 hours it completed making the image. Why it makes the image on the USB instead of staging it I don't know. This stick isn't bootable. I forgot, I had trouble with this one before. It works as storage but not bootable. Used a Kingston 16GB one instead that previously had CentOS boot image on it. This one took another 2 hours but worked fine. I ran virt-p2v after setting up my vm host to accept passwordless sudo. I decided to create a new user for this and set the rule for just that user in the sudoers file using the visudo command. That way I can delete the rule and the user after conversion and all is well. Red Hat recommends using root login, which I don't normally do over ssh, and since this vmhost is Ubuntu, it's set up for su by default. I told it to store the new image in /lib/libvirt/images where the other ones already were. It was going to put it in /tmp by default. I suppose I could have moved it but why. This ran overnight. The fresh Windows install was on a 250GB SSD drive. I think it took 6 hours or more, but I'm not sure that was really the upload time, maybe more conversion after the fact, which is done by virt-v2v. virt-p2v told me it succeeded. No VM running yet, but this seemed good. It also left me an xml file in /var/lib/libvirt/images so I used that to do "virsh create xxxxx.xml" which worked with no modifications. Then I could connect to it using VNC to check out the network config. At this point I remembered that I should definitely have turned on remote desktop before running virt-p2v. To connect to the vnc port virsh display vncdisplay machine-name-that-I-gave-it ssh -L 5910:localhost:5901 smt@vmhost then vncviewer localhost:5910 The screen was tiny and the lowest res possible but enough to get the IP using cmd and also turn on remote desktop. From the VM host command line I verified that rdp was open by "telnet 192.168.122.219 3389" and all is well there. Now to reach it from my desktop I need some iptables rules on the vmhost sudo iptables -t nat -I PREROUTING -smy-home-IP-here/32 -dvmhost-IP-here -p TCP --dport 3389 -j DNAT --to-destination 192.168.122.219 But I get connection refused when doing the telnet test from my desktop. So... "sudo iptables -nL" tells me that libvirt does things I didn't think about. There's a quick fix, relatively obvious. Tell it to ignore its own rules in the case where I want my rule to matter.: sudo iptables -I LIBVIRT_FWI -d 192.168.122.219 -s my-home-ip -j RETURN sudo iptables -I LIBVIRT_FWO -d my-home-ip -s 192.168.122.219 -j RETURN Now the telnet test works from my my-home-ip. However xfreerdp still fails to let me log in. It complains about ssl protocols but I know this is likely authentication issues, based on past experience. I went back to the vnc console, created a new user with admin privileges (I had been using Administrator as the only account on this machine), and when I tried logging in with the new user it worked. Magic. Now I have a fully functional VM Windows 10 Pro. RDP screen resolution is fine. I've installed Chrome and other things now. So the real question is... How do other people deal with technology? There are dozens of things in this story that the average computer user would not even come close to dealing with. On 2021-01-21 2:55 a.m., Trevor Cordes wrote:
Is it possible to run a virtual Windows (10) on a Linux host running something like virtualbox? It has to be normal Win 10 Home or Pro though, no corporate licensing.
I ask because I'm unsure how Windows activation (cursed be!) handles that situation. I'd like to be able to run the same host image on 2 different boxes (but not at the same time) and not have it moan about activation. So I guess the question is more this: does the VM hide/abstract the hardware enough from Windows to have it think it hasn't changed boxes?
(The idea is a portable drive with the VM on it would travel between 2 locations which are never used simultaneously. Each location would have an identical Linux box. Don't ask why; suffice it to say that speed is paramount and cloud or net access or remote access won't cut it. Lugging the entire box is not an option. Laptop is a very sub-par option.)
Thanks! _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2021-01-21 Scott Toderash wrote:
I used virt-p2v to create a Windows instance of a fresh install. I had just bought a new machine and thought I would be clever if I did this before wiping it and installing Ubuntu. It mostly worked. I actually wrote down what happened and here's the weird story. Licensing is stupid. When I was done, it told me I needed to activate but then it complained and said I had the wrong license type for a VM. I forget the wording of that though.
Also though, afaik you can run without activating indefinitely.
So you got it virt'ed but you never got it back into a "properly activated" state? The p2v option is certainly good to know.
Yes. I'm still thinking about the activation state before converting. I wiped the machine after, so I can't verify. I don't recall seeing any request for me to activate while it was on the original hardware, only after virtualization. So technically it worked, but eventually I'll be punished for not activating Windows. If I acquire the right kind of key I can fix that though. On 2021-01-21 10:09 p.m., Trevor Cordes wrote:
On 2021-01-21 Scott Toderash wrote:
I used virt-p2v to create a Windows instance of a fresh install. I had just bought a new machine and thought I would be clever if I did this before wiping it and installing Ubuntu. It mostly worked. I actually wrote down what happened and here's the weird story. Licensing is stupid. When I was done, it told me I needed to activate but then it complained and said I had the wrong license type for a VM. I forget the wording of that though.
Also though, afaik you can run without activating indefinitely.
So you got it virt'ed but you never got it back into a "properly activated" state?
The p2v option is certainly good to know.
Again, not a lawyer, so that is NOT legal advice. But the information is out there should anyone wish to make an informed decision. On 2021-01-22 7:21 a.m., Scott Toderash wrote:
Yes. I'm still thinking about the activation state before converting. I wiped the machine after, so I can't verify. I don't recall seeing any request for me to activate while it was on the original hardware, only after virtualization.
Exactly. Still, if you pass the hardware bits required to the VM, it would activate. And, as long as that is your sole Windows VM running on that host, you should be fine.
So technically it worked, but eventually I'll be punished for not activating Windows. If I acquire the right kind of key I can fix that though.
Again, if you have a licence (be it OEM or Retail) for the original hardware, and as long as you have a licence for each instance of Windows you are running, you're fine. === https://www.microsoft.com/OEM/en/Pages/support-faq.aspx#fbid=u11sV_78rNg *Q.* Can I install OEM software on a virtual machine (VMware)? *A.* You can install OEM software in a virtual environment as long as you have a separate license for each instance of the software. It is fine to use the OEM version as long as it is properly licensed. To be clear, a separate version of the software must be installed for both the “standard” and “virtual” installations. === Thus, if you're using FOSS to virtualize, you don't need a licence for that (!). But you do need a licence for the VM, which you're passing through from the hardware bits in my example. Let's say you're running Windows on a machine. But now you embraced the Penguins. So you p2v your current install, install Linux, KVM the old install. Boot it up. No activation. Two options: 1) Use your key (Retail or OEM) to activate. You may have to call Microsoft. If you go back to bare metal, you will have to do it all over again. 1a) "But I don't have my OEM key, there's only a fancy sticker saying Windows!"... yes, you do. It's somewhere(tm). Again, passing the bits is more practical, but there are ways to get there if you would rather not bother. And no, it's nothing "illegal". I am *NOT* talking about Piracy *AT ALL*, let's make this absolutely clear. 2) Pass the bits as I described. No need to call. If you ever decide to go back to Windows, you are fine too. Trevor, if WINE does not work, get a single Retail licence and activate the VM on one of the machines. Then, try to jump it around and see if it keeps the activation. As long as xml files - or whatever VirtualBox uses - are one and the same, it *should* keep the activation. Keep me posted on this, it does pique my interest :) Kind regards, Alberto Abrao
I've seen the reference a few times to "pass the hardware bits" and I'm not sure what the exact thing to do is. Is this something I would do with libvirt then? Possibly edit the vm config and add a parameter of some kind? On 2021-01-22 8:19 a.m., Alberto Abrao wrote:
Again, not a lawyer, so that is NOT legal advice. But the information is out there should anyone wish to make an informed decision.
On 2021-01-22 7:21 a.m., Scott Toderash wrote:
Yes. I'm still thinking about the activation state before converting. I wiped the machine after, so I can't verify. I don't recall seeing any request for me to activate while it was on the original hardware, only after virtualization.
Exactly.
Still, if you pass the hardware bits required to the VM, it would activate. And, as long as that is your sole Windows VM running on that host, you should be fine.
So technically it worked, but eventually I'll be punished for not activating Windows. If I acquire the right kind of key I can fix that though.
Again, if you have a licence (be it OEM or Retail) for the original hardware, and as long as you have a licence for each instance of Windows you are running, you're fine.
===
https://www.microsoft.com/OEM/en/Pages/support-faq.aspx#fbid=u11sV_78rNg
*Q.* Can I install OEM software on a virtual machine (VMware)?
*A.* You can install OEM software in a virtual environment as long as you have a separate license for each instance of the software. It is fine to use the OEM version as long as it is properly licensed. To be clear, a separate version of the software must be installed for both the “standard” and “virtual” installations.
===
Thus, if you're using FOSS to virtualize, you don't need a licence for that (!). But you do need a licence for the VM, which you're passing through from the hardware bits in my example.
Let's say you're running Windows on a machine. But now you embraced the Penguins.
So you p2v your current install, install Linux, KVM the old install. Boot it up. No activation.
Two options:
1) Use your key (Retail or OEM) to activate. You may have to call Microsoft. If you go back to bare metal, you will have to do it all over again.
1a) "But I don't have my OEM key, there's only a fancy sticker saying Windows!"... yes, you do. It's somewhere(tm). Again, passing the bits is more practical, but there are ways to get there if you would rather not bother. And no, it's nothing "illegal". I am *NOT* talking about Piracy *AT ALL*, let's make this absolutely clear.
2) Pass the bits as I described. No need to call. If you ever decide to go back to Windows, you are fine too.
Trevor, if WINE does not work, get a single Retail licence and activate the VM on one of the machines. Then, try to jump it around and see if it keeps the activation. As long as xml files - or whatever VirtualBox uses - are one and the same, it *should* keep the activation.
Keep me posted on this, it does pique my interest :)
Kind regards, Alberto Abrao
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
If you have a hardware-based activation token (aka SLIC, which is embedded into the BIOS for anything new enough), there are way to pass that through using KVM. I assume there's something like this for VirtualBox as well, but I never cared to check *cough* Oracle *cough*. If you don't, you can pass the required hardware registers and use a key to activate the install. Then, as long as you pass them again (or install on bare metal), you'll have the means to activate again. If both machines have been activated at one point, passing SLIC through means they will activate, even if they recognize the hardware is not really the same - and they will, as although the abstracted layer can (and probably) will be the same, the SLIC portion will be different. If both have been activated and valid, that should not be an issue. It will just re-arm itself. You'll need two licences - one for each machine. Still, should you ever decide to do something else with them, it will be there for you to use. I am sure there are ways for you to go further ahead and pretend they are one and the same, but you will be right at piracy territory. That's NOT to say you won't be there already by doing what I just described - it takes a lot of research to be an expert on MS licensing, and I could not care less - but then you can always argue that you stretched the situation to give them the most money possible, and that should be enough, I hope. Kind regards, Alberto Abrao On 2021-01-21 2:55 a.m., Trevor Cordes wrote:
Is it possible to run a virtual Windows (10) on a Linux host running something like virtualbox? It has to be normal Win 10 Home or Pro though, no corporate licensing.
I ask because I'm unsure how Windows activation (cursed be!) handles that situation. I'd like to be able to run the same host image on 2 different boxes (but not at the same time) and not have it moan about activation. So I guess the question is more this: does the VM hide/abstract the hardware enough from Windows to have it think it hasn't changed boxes?
(The idea is a portable drive with the VM on it would travel between 2 locations which are never used simultaneously. Each location would have an identical Linux box. Don't ask why; suffice it to say that speed is paramount and cloud or net access or remote access won't cut it. Lugging the entire box is not an option. Laptop is a very sub-par option.)
Thanks! _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Yes, this will work fine. I'm assuming you will create a Windows VM on one Linux box (KVM, VirtualBox, VMware, whatever), then install Windows 10 into that VM. When Windows is installed and boots, it will get activated *in that VM image*, which is 100% supported by Microsoft. Don't p2v. If this VM is stored on a removable media, you would just shut down the VM, unplug the media, move it physically to a different Linux host, plug it in, then boot the VM. Windows will still think it's running on the same VM, *because it is*, and thus not need reactivation. If the two Linux hosts have different CPUs (keep the same manufacturer and gen) you should have no problem. Everything else about the VM is encapsulated - BIOS version, motherboard, devices, etc. The versions of the virtualisation software should be the same or as similar as possible. Obviously don't try to boot a VM on VirtualBox on one host and KVM on another host. On Thu, Jan 21, 2021 at 2:55 AM Trevor Cordes <trevor@tecnopolis.ca> wrote:
Is it possible to run a virtual Windows (10) on a Linux host running something like virtualbox? It has to be normal Win 10 Home or Pro though, no corporate licensing.
I ask because I'm unsure how Windows activation (cursed be!) handles that situation. I'd like to be able to run the same host image on 2 different boxes (but not at the same time) and not have it moan about activation. So I guess the question is more this: does the VM hide/abstract the hardware enough from Windows to have it think it hasn't changed boxes?
(The idea is a portable drive with the VM on it would travel between 2 locations which are never used simultaneously. Each location would have an identical Linux box. Don't ask why; suffice it to say that speed is paramount and cloud or net access or remote access won't cut it. Lugging the entire box is not an option. Laptop is a very sub-par option.)
Thanks! _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Oops! Brain tired. Should read "If the two Linux hosts have the same CPUs (manufacturer and gen) you should have no problem". On Thu, Jan 21, 2021 at 8:42 AM Kevin McGregor <kevin.a.mcgregor@gmail.com> wrote:
Yes, this will work fine.
I'm assuming you will create a Windows VM on one Linux box (KVM, VirtualBox, VMware, whatever), then install Windows 10 into that VM. When Windows is installed and boots, it will get activated *in that VM image*, which is 100% supported by Microsoft. Don't p2v. If this VM is stored on a removable media, you would just shut down the VM, unplug the media, move it physically to a different Linux host, plug it in, then boot the VM.
Windows will still think it's running on the same VM, *because it is*, and thus not need reactivation.
If the two Linux hosts have different CPUs (keep the same manufacturer and gen) you should have no problem. Everything else about the VM is encapsulated - BIOS version, motherboard, devices, etc. The versions of the virtualisation software should be the same or as similar as possible. Obviously don't try to boot a VM on VirtualBox on one host and KVM on another host.
On Thu, Jan 21, 2021 at 2:55 AM Trevor Cordes <trevor@tecnopolis.ca> wrote:
Is it possible to run a virtual Windows (10) on a Linux host running something like virtualbox? It has to be normal Win 10 Home or Pro though, no corporate licensing.
I ask because I'm unsure how Windows activation (cursed be!) handles that situation. I'd like to be able to run the same host image on 2 different boxes (but not at the same time) and not have it moan about activation. So I guess the question is more this: does the VM hide/abstract the hardware enough from Windows to have it think it hasn't changed boxes?
(The idea is a portable drive with the VM on it would travel between 2 locations which are never used simultaneously. Each location would have an identical Linux box. Don't ask why; suffice it to say that speed is paramount and cloud or net access or remote access won't cut it. Lugging the entire box is not an option. Laptop is a very sub-par option.)
Thanks! _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2021-01-21 Kevin McGregor wrote:
Oops! Brain tired. Should read "If the two Linux hosts have the same CPUs (manufacturer and gen) you should have no problem".
Yes, in this case the physical hardware would be identical. However, there is conflict between Alberto's & Kevin's answers... has anyone actually tried it? And for sure you weren't using a corporate Windows license key? (And not a Server version either.) I recall hearing something like Alberto said re: non-corporate Windows detecting it was in a VM and complaining. I guess the big part of the question is, if Windows doesn't have a blanket anti-VM block in it, how much of the host hw id info really does "seep" into to guest... The problem here that testing it might "waste" a paid Windows license. Even if we bought 2 licenses and activated twice, I'm not convinced the activation code won't get angry at going back and forth between the 2 boxes. Man, do I hate Windows and non-FLOSS. Maybe I need to see if my customer could instead forget Windows and make everything work in WINE... Thanks!
On 2021-01-21 10:03 p.m., Trevor Cordes wrote:
On 2021-01-21 Kevin McGregor wrote:
Oops! Brain tired. Should read "If the two Linux hosts have the same CPUs (manufacturer and gen) you should have no problem". Yes, in this case the physical hardware would be identical.
Means nothing. There's still the GUID of the mainboard, which is very much different even when everything else is the same.
However, there is conflict between Alberto's & Kevin's answers... has anyone actually tried it?
I do have experience with Windows and its activation perks... mostly for the consumer version, which incidentally is what you want.
And for sure you weren't using a corporate Windows license key? (And not a Server version either.) I recall hearing something like Alberto said re: non-corporate Windows detecting it was in a VM and complaining.
I am less concerned about the "being on a VM" and more about "making sure you have a reliable anchor for it". It would not matter for a sitting duck, but you want to dance around with it. I am reasonably sure that you don't want to be typing lengthy codes on your phone when calling the Microsoft Activation Hotline. (Thank you for calling Microsoft! Which product would you like to activate? Please say Windows, Office, ... ugh). Even then, we want to abide to Microsoft's terms. And here (https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_W...) we find: *b.**Device.* In this agreement, “device” means a hardware system (whether physical or virtual) with an internal storage device capable of running the software. A hardware partition or blade is considered to be a device. (iv) *Use in a virtualized environment*. This license allows you to install only one instance of the software for use on one device, whether that device is physical or virtual. If you want to use the software on more than one virtual device, you must obtain a separate license for each instance. Keep in mind I am not a lawyer (really? lol). Now, as with everything Microsoft licensing, this is ambiguous enough to have you thread the grey area if you have a single licence for the dancing VM, as it states a device meaning a *hardware *system, physical or virtual. It does mention "one virtual device", and we can argue that we are talking about a single virtual environment , even though it sometimes travels between different hosts. Now, we are talking about consumer, retail versions here, so I may not be grasping at straws when I point this. That said, keep in mind that I am not a lawyer (you don't say? :D), so my opinion is worth...yeah. That said, stay with me. Even assuming that would be perfectly legit, you still have the problem of keeping the activation when changing hardware. The virtual environment may be abstract enough that it does not detect enough of a change and just pretends nothing ever happened. Or it does smell a rat and asks for activation. Well, please see above if that happens. In this case, if our assumption is right, it would be OK for licensing, but not nice at all to administrate.
I guess the big part of the question is, if Windows doesn't have a blanket anti-VM block in it, how much of the host hw id info really does "seep" into to guest...
As much as you let in, for KVM at least.
The problem here that testing it might "waste" a paid Windows license. Even if we bought 2 licenses and activated twice, I'm not convinced the activation code won't get angry at going back and forth between the 2 boxes.
It will not, because the code goes to Microsoft only once. When you pass the tables like I described on my previous email, it results in a hash that Windows is able to pass onto the activation servers. - Hardware hash is passed to Microsoft activation servers. - If there is no key tied to it, it reports "not activated". Boo. Gimme key! - You have the key in. Let's say, Pro version. - Key is now tied to the hash. - You're activated! So now you nuke it from orbit and start fresh. Same process happen again, but this time: - Hardware hash is passed to Microsoft activation servers. - Uncle Bill says: "oh, I remember you! You have a licence here, but let's talk first: what are you, really?" - "I am a Pro, dude, but I have no l33t codes on me, sry" - "Just as I remembered. Sweet! I remember your l33t codes from times gone by, no need to bore me again. Here, a cookie. Off you go." - Activated! And that alone is *enough*. With that, it quickly finds out if you're activated or not, and off it goes. No key, no rearm, nothing. You will *never* be prompted for a key if there is a valid licence tied to your hardware's hash, thus, by passing the SLIC bits to the VM, and that physical hardware having a good valid Windows 10 licence previously activated with Microsoft, it will just take care of itself. Done. You will never type a key for that hardware ever again, assuming you 1) never phone-activate the key on another device, thus revoking the authorization for the one to which it is tied (true for RETAIL versions, keep that in mind, as OEM licences are not able to be revoked in this manner, at least theoretically); and 2) use the same version of Windows (e.g. Windows 10 Pro key = Windows 10 Pro install. Home = Home. You get the idea). That also means that both machines would have a Windows licence *tied to their hardware*, which could be used even after the VM setup is no longer warranted, either for another VM, or for a bare metal install should it ever be repurposed as a beefy workstation, for example. Now, it remains to be seen if that's feasible using VirtualBox. As I said, one is able to do that with KVM.
Man, do I hate Windows and non-FLOSS. Maybe I need to see if my customer could instead forget Windows and make everything work in WINE...
As you mentioned WINE, I suggest you investigate that and see if he is happy. If that is not an option, let me know and we can research something that is sure to steer your client far away from uncle Bill's fury. Kind regards, Alberto Abrao
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. John On Thu, Jan 21, 2021 at 11:28 PM Alberto Abrao <alberto@abrao.net> wrote:
On 2021-01-21 10:03 p.m., Trevor Cordes wrote:
On 2021-01-21 Kevin McGregor wrote:
Oops! Brain tired. Should read "If the two Linux hosts have the same CPUs (manufacturer and gen) you should have no problem".
Yes, in this case the physical hardware would be identical.
Means nothing. There's still the GUID of the mainboard, which is very much different even when everything else is the same.
However, there is conflict between Alberto's & Kevin's answers... has anyone actually tried it?
I do have experience with Windows and its activation perks... mostly for the consumer version, which incidentally is what you want.
And for sure you weren't using a corporate Windows license key? (And not a Server version either.) I recall hearing something like Alberto said re: non-corporate Windows detecting it was in a VM and complaining.
I am less concerned about the "being on a VM" and more about "making sure you have a reliable anchor for it". It would not matter for a sitting duck, but you want to dance around with it. I am reasonably sure that you don't want to be typing lengthy codes on your phone when calling the Microsoft Activation Hotline. (Thank you for calling Microsoft! Which product would you like to activate? Please say Windows, Office, ... ugh).
Even then, we want to abide to Microsoft's terms.
And here ( https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_W...) we find:
*b.* *Device.* In this agreement, “device” means a hardware system (whether physical or virtual) with an internal storage device capable of running the software. A hardware partition or blade is considered to be a device.
(iv) *Use in a virtualized environment*. This license allows you to install only one instance of the software for use on one device, whether that device is physical or virtual. If you want to use the software on more than one virtual device, you must obtain a separate license for each instance.
Keep in mind I am not a lawyer (really? lol). Now, as with everything Microsoft licensing, this is ambiguous enough to have you thread the grey area if you have a single licence for the dancing VM, as it states a device meaning a *hardware *system, physical or virtual. It does mention "one virtual device", and we can argue that we are talking about a single virtual environment , even though it sometimes travels between different hosts. Now, we are talking about consumer, retail versions here, so I may not be grasping at straws when I point this. That said, keep in mind that I am not a lawyer (you don't say? :D), so my opinion is worth...yeah. That said, stay with me.
Even assuming that would be perfectly legit, you still have the problem of keeping the activation when changing hardware. The virtual environment may be abstract enough that it does not detect enough of a change and just pretends nothing ever happened. Or it does smell a rat and asks for activation. Well, please see above if that happens. In this case, if our assumption is right, it would be OK for licensing, but not nice at all to administrate.
I guess the big part of the question is, if Windows doesn't have a blanket anti-VM block in it, how much of the host hw id info really does "seep" into to guest...
As much as you let in, for KVM at least.
The problem here that testing it might "waste" a paid Windows license. Even if we bought 2 licenses and activated twice, I'm not convinced the activation code won't get angry at going back and forth between the 2 boxes.
It will not, because the code goes to Microsoft only once. When you pass the tables like I described on my previous email, it results in a hash that Windows is able to pass onto the activation servers.
- Hardware hash is passed to Microsoft activation servers. - If there is no key tied to it, it reports "not activated". Boo. Gimme key! - You have the key in. Let's say, Pro version. - Key is now tied to the hash. - You're activated!
So now you nuke it from orbit and start fresh. Same process happen again, but this time:
- Hardware hash is passed to Microsoft activation servers. - Uncle Bill says: "oh, I remember you! You have a licence here, but let's talk first: what are you, really?" - "I am a Pro, dude, but I have no l33t codes on me, sry" - "Just as I remembered. Sweet! I remember your l33t codes from times gone by, no need to bore me again. Here, a cookie. Off you go." - Activated!
And that alone is *enough*. With that, it quickly finds out if you're activated or not, and off it goes. No key, no rearm, nothing. You will *never* be prompted for a key if there is a valid licence tied to your hardware's hash, thus, by passing the SLIC bits to the VM, and that physical hardware having a good valid Windows 10 licence previously activated with Microsoft, it will just take care of itself. Done. You will never type a key for that hardware ever again, assuming you 1) never phone-activate the key on another device, thus revoking the authorization for the one to which it is tied (true for RETAIL versions, keep that in mind, as OEM licences are not able to be revoked in this manner, at least theoretically); and 2) use the same version of Windows (e.g. Windows 10 Pro key = Windows 10 Pro install. Home = Home. You get the idea).
That also means that both machines would have a Windows licence *tied to their hardware*, which could be used even after the VM setup is no longer warranted, either for another VM, or for a bare metal install should it ever be repurposed as a beefy workstation, for example.
Now, it remains to be seen if that's feasible using VirtualBox. As I said, one is able to do that with KVM.
Man, do I hate Windows and non-FLOSS. Maybe I need to see if my customer could instead forget Windows and make everything work in WINE...
As you mentioned WINE, I suggest you investigate that and see if he is happy. If that is not an option, let me know and we can research something that is sure to steer your client far away from uncle Bill's fury.
Kind regards, Alberto Abrao _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- John Lange
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. 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. On Fri, Jan 22, 2021 at 12:37 AM John Lange <john@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.
John
On Thu, Jan 21, 2021 at 11:28 PM Alberto Abrao <alberto@abrao.net> wrote:
On 2021-01-21 10:03 p.m., Trevor Cordes wrote:
On 2021-01-21 Kevin McGregor wrote:
Oops! Brain tired. Should read "If the two Linux hosts have the same CPUs (manufacturer and gen) you should have no problem".
Yes, in this case the physical hardware would be identical.
Means nothing. There's still the GUID of the mainboard, which is very much different even when everything else is the same.
However, there is conflict between Alberto's & Kevin's answers... has anyone actually tried it?
I do have experience with Windows and its activation perks... mostly for the consumer version, which incidentally is what you want.
And for sure you weren't using a corporate Windows license key? (And not a Server version either.) I recall hearing something like Alberto said re: non-corporate Windows detecting it was in a VM and complaining.
I am less concerned about the "being on a VM" and more about "making sure you have a reliable anchor for it". It would not matter for a sitting duck, but you want to dance around with it. I am reasonably sure that you don't want to be typing lengthy codes on your phone when calling the Microsoft Activation Hotline. (Thank you for calling Microsoft! Which product would you like to activate? Please say Windows, Office, ... ugh).
Even then, we want to abide to Microsoft's terms.
And here ( https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_W...) we find:
*b.* *Device.* In this agreement, “device” means a hardware system (whether physical or virtual) with an internal storage device capable of running the software. A hardware partition or blade is considered to be a device.
(iv) *Use in a virtualized environment*. This license allows you to install only one instance of the software for use on one device, whether that device is physical or virtual. If you want to use the software on more than one virtual device, you must obtain a separate license for each instance.
Keep in mind I am not a lawyer (really? lol). Now, as with everything Microsoft licensing, this is ambiguous enough to have you thread the grey area if you have a single licence for the dancing VM, as it states a device meaning a *hardware *system, physical or virtual. It does mention "one virtual device", and we can argue that we are talking about a single virtual environment , even though it sometimes travels between different hosts. Now, we are talking about consumer, retail versions here, so I may not be grasping at straws when I point this. That said, keep in mind that I am not a lawyer (you don't say? :D), so my opinion is worth...yeah. That said, stay with me.
Even assuming that would be perfectly legit, you still have the problem of keeping the activation when changing hardware. The virtual environment may be abstract enough that it does not detect enough of a change and just pretends nothing ever happened. Or it does smell a rat and asks for activation. Well, please see above if that happens. In this case, if our assumption is right, it would be OK for licensing, but not nice at all to administrate.
I guess the big part of the question is, if Windows doesn't have a blanket anti-VM block in it, how much of the host hw id info really does "seep" into to guest...
As much as you let in, for KVM at least.
The problem here that testing it might "waste" a paid Windows license. Even if we bought 2 licenses and activated twice, I'm not convinced the activation code won't get angry at going back and forth between the 2 boxes.
It will not, because the code goes to Microsoft only once. When you pass the tables like I described on my previous email, it results in a hash that Windows is able to pass onto the activation servers.
- Hardware hash is passed to Microsoft activation servers. - If there is no key tied to it, it reports "not activated". Boo. Gimme key! - You have the key in. Let's say, Pro version. - Key is now tied to the hash. - You're activated!
So now you nuke it from orbit and start fresh. Same process happen again, but this time:
- Hardware hash is passed to Microsoft activation servers. - Uncle Bill says: "oh, I remember you! You have a licence here, but let's talk first: what are you, really?" - "I am a Pro, dude, but I have no l33t codes on me, sry" - "Just as I remembered. Sweet! I remember your l33t codes from times gone by, no need to bore me again. Here, a cookie. Off you go." - Activated!
And that alone is *enough*. With that, it quickly finds out if you're activated or not, and off it goes. No key, no rearm, nothing. You will *never* be prompted for a key if there is a valid licence tied to your hardware's hash, thus, by passing the SLIC bits to the VM, and that physical hardware having a good valid Windows 10 licence previously activated with Microsoft, it will just take care of itself. Done. You will never type a key for that hardware ever again, assuming you 1) never phone-activate the key on another device, thus revoking the authorization for the one to which it is tied (true for RETAIL versions, keep that in mind, as OEM licences are not able to be revoked in this manner, at least theoretically); and 2) use the same version of Windows (e.g. Windows 10 Pro key = Windows 10 Pro install. Home = Home. You get the idea).
That also means that both machines would have a Windows licence *tied to their hardware*, which could be used even after the VM setup is no longer warranted, either for another VM, or for a bare metal install should it ever be repurposed as a beefy workstation, for example.
Now, it remains to be seen if that's feasible using VirtualBox. As I said, one is able to do that with KVM.
Man, do I hate Windows and non-FLOSS. Maybe I need to see if my customer could instead forget Windows and make everything work in WINE...
As you mentioned WINE, I suggest you investigate that and see if he is happy. If that is not an option, let me know and we can research something that is sure to steer your client far away from uncle Bill's fury.
Kind regards, Alberto Abrao _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- John Lange
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
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@johnlange.ca <mailto:john@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
I don’t think Trevor was considering a P2V, which means most of the foregoing discussion is moot. Trevor, go ahead. It’ll work fine. 😀 On Fri, Jan 22, 2021 at 08:57 Alberto Abrao <alberto@abrao.net> wrote:
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@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 _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2021-01-22 Kevin McGregor wrote:
I don’t think Trevor was considering a P2V, which means most of the foregoing discussion is moot.
Trevor, go ahead. It’ll work fine. 😀
Thanks Kevin! That's precisely the answer I was looking for in the end. However, now you know who I'll be growling at if it eats my activations! :-) (No, I'm not doing P2V, though the idea is intriguing for other ideas I have.)
participants (5)
-
Alberto Abrao -
John Lange -
Kevin McGregor -
Scott Toderash -
Trevor Cordes