Hyper-V Server 2022

Elden_Christensen 
If you guys are still monitoring this thread, I recently thought of a solution that may be of interest to you.

So Hyper-V Server Standalone is officially discontinued, but in the last couple years, Linux kernel patches have been put out to be able to make Linux the root partition for a Hyper-V Installation.

So if Microsoft pushed out the rest of what would be necessary to make an on-premises installation of Hyper-V with a Linux root partition, then I think that would satisfy most everyone here.

You could even package it yourself with the official Microsoft Linux distributions CBL-Mariner and/or CBL-Delridge and call it Hyper-V Server again if you wanted to, but this time, there'd be no Windows components. Just raw Hyper-V and Linux.
I'd say the ability to manage it via Powershell in Linux, and some way to connect to the console of a VM would be all we'd really need for a Linux based Hyper-V solution.

Either way, I'd say the pushing of patches to the Linux Kernel implies that this will happen sooner or later, but doing it sooner, and making it the new direction of Hyper-V Server would probably be more than enough to satisfy us dissidents in this thread.

In terms of basic licensing costs, having reviewed the issues raised in this thread, in summary there are just a few broad scenarios under which losing access to the dedicated Hyper-V Server SKU is going to have an impact on licensing costs or cause other issues while the option to run Windows Server Core Standard or Datacenter with the Hyper-V role still exists.

1. It will no longer be possible to install or upgrade to a later version of Hyper-V Server on the hypervisor host without paying the upgrade cost for the latest version of Windows Server Standard or Datacenter. So you will no longer be able to run Hyper-V Server 2022 when you only have guest OSE licenses purchased for Windows Server 2019 or below.
2. It will no longer be possible to use Hyper-V Server in situations where none of the guest OSEs are running Windows Server - for example, running all-Linux, or BSD, or other non-Microsoft services, or all Windows client operating systems in VDE deployments.
3. In certain edge cases such as embedded scenarios where it is desirable to set up a hypervisor on servers with small amounts of storage such that disk space is at a absolute premium.

Some of the other scenarios people have raised:

1. Would require additional licensing in order to be properly licensed in the first place (using a 'spare' Hyper-V Server for failing over Windows Guest OSEs, for example).
2. Have an equivalent option under existing Windows Server licensing (using Windows Server Core with the Hyper-V role) with no additional licensing costs.
3. Are not covered under the existing terms for Hyper-V Server anyway (using the Hyper-V Server for purposes other than those permitted in the EULA - i.e. to provide hardware virtualization services and run software to manage and service operating system environments on the licensed server).

It seems that Microsoft need to make Azure Stack HCI more palatable for enthusiasts, SMBs and nonprofits - or they need to work harder to advertise the option of the perpetual 'Windows Server' model for smaller deployments and nonprofits where the current Azure Stack HCI license model is just too expensive to make it worthwhile and they may feel forced to carry out an (in some cases entirely unnecessary) move to an alternative hypervisor.

Elden_Christensen you have unmasked yourself!  Haha!  Now you will never be left alone!!!  Well since you're here let me re-iterate, speaking officially only for myself, but I hope for many here, that despite the bumps over changes, I am grateful for your help and patience in this thread, and for all you and Microsoft are doing to make the IT world a better place for all of us.  You and your team deserve a big thank you, and you certainly have that from me! So THANK YOU!

AdamB2395 You are very welcome.  I hope I could help in some small way.  I hope your future plans work out well and - who knows - as Elden states, Microsoft is listening, so it will be interesting to see what the future brings as well!

Best regards to you both,

Glen

GlenBarney1 

Hi Glen,

Thank you for the reply. I was familiar with the distinction between Activation and Licensing, however, your reply sheds a greater amount of detail on the subject and is thus very helpful; it has satisfactorily answered my questions.

Kind regards.

Hi Adam -

Yes, right after I hit "Post" I saw your edit - all good, of course, I think everyone here, including both Microsoft and myself, just wants to make sure everyone is taken care of as best we can.

To your follow up question: Forgive me if you know all this already, but, for context: Licensing requirements and Activation requirements are not exactly the same thing. Activation is a technical process. If you are doing machine level replication using HyperV or XCPNG, it is likely (depending on how you do it and how your hypervisor works) that replication will preserve the activation status of the source host, so that the destination host will already be activated if and when you fire it up. It is also possible that activation status will be lost, in which case the host will attempt to re-activate when it's fired up - and that will happen automatically if an Internet connection exists. In either case you should generally not have to do anything like applying a new product key to the target server regardless of hypervisor. It should all "just work".

In contrast, licensing is a legal process. You have to have paid for, and own, in some legal way, enough Windows Server/CPU licenses to make all of your machines legal. I suppose that in your case, where you are only running two live machines, and the replication targets are never running and never used and just sitting there waiting for a disaster that we hope never happens - in that case you might not need a second license for those machines since you're not "using" them (as quoted from the document) - but again I am not a lawyer and cannot answer that authoritatively.

But I guess my point was that whether you need a second license or not is not related to the choice of HyperV Server vs any of the other hypervisor options mentioned in the thread, so the loss of HyperV Server won't change your operating costs in any way. Regardless of how many legal licenses you actually need, that number remains the same whether you're on HyperV or ESX or whatever. (The only exception to that of course would be if you upgraded to Datacenter for the physical boxes, in which case you wouldn't need anything else beyond that... other than CALs or whatever, of course.)

In any event, to answer your question, no, whether HyperV, or Datacenter, or XCPNG, you should not need to change anything or do anything if disaster strikes: your backup machines, when brought online, will either already be activated, or will attempt to self-activate online, and either way it should be transparent. Only if your product keys run out of activations will you get a warning; in which case you just call Microsoft's licensing center humans and explain it to them, and they'll fix it for you... often while you wait.

I hope this is helpful!

Glen

GlenBarney1 

Hi Glen,

I realized later that Chris was not an employee, hence the edit. Nonetheless, I wanted to add my voice to the chorus expressing discontent with the decision. There's 7 years before the complete end-of-life of Hyper-V; perhaps I'm a naïve optimist, but perhaps if enough ruckus raised, Microsoft will change their mind.

I wanted to thank you for your detailed response. It is very helpful. I have a follow up question with regard to what you said about the standby VMs on the backup server requiring an additional license; from a practical standpoint, how precisely does that work? The VM is licensed from within the OS, using the Activation menu; is the expectation that if that VM is ever turned on, we would need to change the license to a different one using the same menu (obviously we cannot turn the VM on to license it, nor would that persist even if we did if it is a replica)? If so, and we replicate it back to the primary (as in the case of failed physical server that we repair), would we then need to re-license it again back to the original license?

Kind regards.