The reason I posted at all was because of the thought that Hyper-v may be fancier than I assume (I have not checked). The thought occurs that in this day and age they might provide digital certification of the API, to tell you that it isn't lying.
Hyper-v again.
I have been asked to consider this by a colleague and I think I know the answer, but perhaps I should ask anyway.
How practical would it be to make special provision for Hyper-v in the VM check? My understanding is that Hyper-v offers an API to the guest OS which you can interrogate to get a unique signature of the host, so it should still be possible to node lock to the physical host even though the OS is running inside the VM.
OTOH... I know that VirtualBox for example has an option to also provide a Hyper-v compatible API to the guest. And VirtualBox is open source. Meaning that the API could be lying about the physical machine signature.
Cloning the VM in Hyper-V clones the Hyper-V provided UUID of the machine. In other words, it has the exact same shortcomings of taking the fingerprint of the machine.
Hence our recommendation to prevent node-locked licensing on VMs, and only using floating licensing on VMs. TurboFloat detects VMs and treats them differently than real machines. It treats them in such a way that even if the VM is cloned bit-for-bit, TurboFloat treats the VM as a separate machine.
In the very near future we're making it significantly easier to spin-up TurboFloat Server instances. We're providing cheap, and very easy hosted TFS instances with a web interface for end-users several months from now. We know the main hurdle to using TurboFloat was having the customer install the TFS on a real machine. With our hosted TFS instances that hurdle disappears.
References:
Types of software licensing: https://wyday.com/limelm/help/licensing-types/
Licensing from inside a virtual machine or hypervisor: https://wyday.com/limelm/help/vm-hypervisor-licensing/
Thanks very much for the reply. Hyper-v is just using an embedded UUID? That hardly seems worth their bother. I assumed that since Microsoft had a vested interest in ensuring that Office etc wasn't ripped off, they would provide an API for reliable node locking even when Hyper-v was used. Oh well.
I just got finished with a discussion with the same colleague regarding TurboFloat and VMs (I recently added TurboFloat client support to our software). We had kind of convinced ourselves that VM's were ok if floating licenses were used - especially since our IT guy is insisting that few of our clients will ever let us install TFS on their real server. Are you saying that TFS doesn't allow VM installations regardless of how the product key permissions is configured? We were planning to install TFS on a server VM in the next couple of days, precisely to test this scenario.
p.s. Just as an aside, I don't see how that thing about TurboFloat being able to detect a cloned VM can be true! If you allow that VMs are ok then AFAIK the only physical hardware you can access is the CPU, and maybe the network neighborhood. Everything else can be faked.
Besides, my main doomsday scenario regarding VMs didn't involve clones, it involved snapshots (probably you are familiar with the feature). The client gets a lease from TFS, then you create a snapshot (or an immutable state - same thing), which you keep reverting to, extending the grace period indefinitely. The worrying thing is that this is easy to think of and easy to do.
Finally, if I could confirm one fact regarding TurboFloat: if I have the "no VMs" option selected then that only blocks VMs at the server end, correct? In the TF API I don't see an equivalent of TA's x_E_IN_VM result code.
>> "Are you saying that TFS doesn't allow VM installations regardless of how the product key permissions is configured? "
You should not allows TFS on a VM. It is absolutely not recommended. Why? Because a customer can clone the VM get X * Y floating licenses.
Either:
1. Host the TFS on your infrastructure.
or
2. Use our hosted version of the TFS (coming very soon).
>> "p.s. Just as an aside, I don't see how that thing about TurboFloat being able to detect a cloned VM can be true! If you allow that VMs are ok then AFAIK the only physical hardware you can access is the CPU, and maybe the network neighborhood. Everything else can be faked."
Right. TurboFloat detects the VM, and treats it as a hostile (faked) machine. And by the very nature of floating licenses, the "license lease" is kept in-memory and is valid for only that particular user-session on that particular "machine".
The license lease is not saved to disk. VM states can be cloned but only a single one of those clones will successfully get a new license lease.
>> "Finally, if I could confirm one fact regarding TurboFloat: if I have the "no VMs" option selected then that only blocks VMs at the server end, correct? In the TF API I don't see an equivalent of TA's x_E_IN_VM result code."
Right. Because TF fully handles VMs as well as real machines. It's designed to run inside VMs. But, like I said earlier, and like it's mentioned in multiple places in our documentation: do not run the TFS on a VM.
Thanks for the replies. The idea of hosting TFS on our own hardware had not occurred to me, but it sounds like a useful option to consider - I'll have to discuss it with our IT guy.