Forum Discussion
Hyper-V Server 2022
Free 'Microsoft Hyper-V Server' product update
Since its introduction over a decade ago in Windows Server 2008, Hyper-V technology has been, and continues to be, the foundation of Microsoft’s hypervisor platform. Hyper-V is a strategic technology for Microsoft. Microsoft continues to invest heavily in Hyper-V for a variety of scenarios such as virtualization, security, containers, gaming, and more. Hyper-V is used in Azure, Azure Local, Windows Server, Windows Client, and Xbox among others.
Starting with Microsoft Hyper-V Server 2019, the free ‘Microsoft Hyper-V Server’ product has been deprecated and is the final version of that product. Hyper-V Server 2019 is a free product available for download from the Microsoft Evaluation Center: https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019
Microsoft Hyper-V Server 2019 will continue to be supported under its lifecycle policy until January 2029, see this link for additional information: https://docs.microsoft.com/en-us/lifecycle/products/hyperv-server-2019.
While Microsoft has made a business decision to no longer offer the free 'Microsoft Hyper-V Server' product, this has no impact to the many other products which include the Hyper-V feature and capabilities. This change has no impact to any customers who use Windows Server or Azure Local.
For customers looking to do test or evaluation of the Hyper-V feature, Azure Local includes a 60-day free trial and can be downloaded here: https://learn.microsoft.com/en-us/azure/azure-local/ . Windows Server offers a free 180-day evaluation which can be downloaded from the Evaluation Center here: https://www.microsoft.com/en-us/evalcenter
Microsoft remains committed to meeting customers where they are and delivering innovation for on-premises virtualization and bringing unique hybrid capabilities like no other can combined with the power of Azure Arc. We are announcing that Microsoft Hyper-V Server 2019 was the last version of the free download product and that customers begin transitioning to one of the several other products which include Hyper-V or consider Azure.
Thank you,
Elden Christensen
Principal Group PM Manager
Windows Server Development Team
Elden_Christensen We're a MSP. I know many of my peers that also are MSP's are likely in the same boat as me here on this. Our clients are SMB and the vast majority are hybrid, using M365 BP sku's and at least one on-prem Windows Server (running as a guest on top of Hyper-V Server) due to variety of reasons. We have intentionally rebuilt their networks from whatever it was at onboarding into a platform where their physical server(s) (most are single hosts) are running Hyper-V Server and their original server OS is virtualized onto said host (even if they only have a single server os). We do this for portability between hardware during upgrades, for testing of software upgrade process on key LOB apps, and also for fast recovery of disasters; be it hardware or something awful like a crypto attack.
For our own practice as it relates to how we deploy client infrastructure, our entire internal stack (including scripting, backups and management capabilities) rely on Hyper-V server on each and every server we manage. NONE of these are candidates for Azure Stack HCI for the following reasons: Cost, and minimum hardware requirements (need multiple servers, etc). The pricing structure of adding $10/core/month is a huge price increase (from zero) for these SMB clients when this adds no value over what they can do with alternative offerings that are still free. The ability to just use Server OS with HV role installed is a non-starter as well, as that opens up a large attack surface that is not otherwise needed (something you should be mindful of) as well as potential performance penalties that it will also introduce.
Your decision on this has a pretty substantial impact on our long term plans as it relates to pushing the MS ecosystem. Our clients trust and buy/use whatever we advise them to (being their trusted technology advisors) and as a result we now have to evaluate what we do long term as this impacts our clients and also us (which by extension will impact them further). I can say right off the bat that killing Hyper-V Server will not force people into Stack HCI/Azure-itself. That is a miscalculation. We will move to VMWare or more likely to XCP-ng and by extension so will ALL of our customers over time. This also by osmosis causes us all to look at other competitors for things beyond just the Hypervisor too.
Small fish become big fish, and companies that will now have to use a competitor stack (vmware or otherwise) are not going to later move to MS as they grow; that's an incorrect assumption. I think this is something you guys perhaps did not think about. The Hyper-V Server platform is the entry into the entire infrastructure side of your ecosystem and has a low friction pathway to Azure as they grow. Taking that away ensures that future Azure business will not materialize since once on another platform you cannot easily change it.
I think the solution here is to have Azure Stack be free in some capacity; your goal is to get this out there and adopted right? That solves all problems I mentioned. One sku can do the basics like we did with HV Server, the other paid sku has all the bells and whistles of Azure Stack. This keeps people in the ecosystem with a no-resistance pathway to the full sku and/or Azure as they grow. Short of something like this, you're basically giving up your entire position in the infrastructure space for all SMB and also inviting competitors to encroach on unrelated services that spawn from this move... first we look at XCP-ng, and since that's open source and worked great perhaps we then look at alternatives to Azure AD or M365, etc etc etc.
Another intangible here that applies not only to the businesses out there, but also the future IT engineers just getting started, who may learn on something else now and likely not give MS a look (losing evangelists along the way by extension). Every green tech I have hired over the years were all exposed to and trained on Hyper-V systems. That will go away too as they learn on some other platform.
If there are discussions on pairing back this change, don't wait too long and please do not handicap it with less features than we can do now with HVS as it stands. Everyone else out there in the same position as we are will soon start the journey of moving platforms. It will take a long time for us and others to do out there, but once the glacier is moving it will be hard to reverse it.
I'd prefer to stay in the ecosystem and don't want to switch fwiw.
Let's just say we run 500 HyperV servers with Veeam to allow clients to replicate the main OS to a hot-spare cluster. If the plan is to EOL this product we need to start to plan the move away now and I will run you through why.
Let's do some numbers for all to see based on future processor core count averages. In the last quarter, we have seen a huge shift to AMD 32 based processors, specifically the extremely powerful AMD EPYC 7543.
Now we are from Australia where the price per core is $14 aud.
64 Cores x $14 = $896 per month
500 servers = $448k extra a month for servers that currently cost us just the Windows Servers SPLA licencing which as you have started still will continue to be charged.
Yes, we are a large cloud hosting provider in Australia the numbers are legit a concern. I am sure Veeam is going to have a big say about where they head and well everyone else. SPLA licencing was already a joke and now this is icing on the cake.
P.S Your SPLA licencing is also a joke where under the agreement clients are forced to licence all SOE Windows AND Linux VM's. It's epic trying to explain to clients that even though they are running a VMware server and they have 10 Linux VM's and a single Windows VM the clients are required to licence ALL SOE. Yes, that means all 11 virtual machines 🙂
Happy to be corrected on any of the above
DavidYorkshire I did not misunderstand, I was replying to a question asked in this comment:
So let's get this clear.
Will any Hypr-V or future releases have charges associated with CPU Cores on top of the Windows Licencing?
A nice simple question 🙂
so the pricing models for both OS which offer Hyper-V in the future are already core based and do not charge extra for their (core) function.
Think you've misunderstood what is being discussed here - this isn't about running Hyper-V on the Standard/Datacenter versions of Windows Server (which as you say are licensed by core).
It is about Hyper-V Server, which is a separate SKU with its own installation media. It is free, but any Windows workloads on it have to be licensed as it does not include any licenses for clients. Hyper-V Server is very similar to a server core installation with the Hyper-V role installed (other roles are not permitted under the licensing terms).
Hyper-V Server appeared when Hyper-V itself did (2008?), and since then every release of Windows Server has had a corresponding version of Hyper-V Server - up to 2019, that is. As we have been told above, there will not be a 2022 version.
Azure Stack HCI is similar in many ways, but has paid-for subscription requirements for all client VMs, and can only operate as a cluster, not a standalone host.
- Agree, but even easier would be allow (single) AzS HCI machines without Azure registration for Free.
> Hyper-V also exists as a dedicated operating system.
The Operating System is called Microsoft „Hyper-V Server 2016“ (or 2019). Thats (confusingly) similar but not the same. it is different from Hyper-V the technology or the Hyper-V Role. (It is for that reason a good idea to always qualify by using the full name).The Windows Server which is required for the Hyper-V Feature is licensed by core. This is true for 2016, 2019 and 2022.
- All of that is over complicated to achieve some semblance of balance. See my post about a simple way to solve the problem while driving Azure Stack adoption.... make HV Server a "free tier" in Azure Stack with basic HV functionality, with Stack bells and whistles reserved for licensed systems.
Best of both worlds and keeps it super simple. It drives Azure Stack adoption, keeps the lab folks and small fish happy, it also provides a direct upgrade path to Azure since the VM's are already in Azure Stack ecosystem. - That's what I meant though. Drivers already have to be signed by Microsoft at least by default on all 64 bit systems. So those would continue to work.
But I just meant to extend that so vendors have to get their approval for the free/locked down Hyper-V OS.
I recognize it's not necessarily a good thing for us admins, but it gives Microsoft the reassurance that people wouldn't use their Free OS in place of a server, while also providing a large measure of security, since it would presumably be very difficult to get malware approved by MS. - athendrix you almost had it except
#2 take take features away from an existing product and there might be some deployments where Hyper-V on fat install makes sense.
You're last point about being MS Signed, it would stop drivers and system utilities from working including RMM, taking away one of the prime reasons to have a windows based hypervisor not a Linux one. Let people use 3rd party backup, but having built in azure backup which only takes a few clicks or a script to set up, the azure account is already set up from activation, and is ready to put the backup into a Azure VM that can spin up within minutes would be a huge leg up on the competitors because of that integration, ease of use and low cost of storage, the only real cost would be if you actually end up spinning up that backup VM.
Also makes for pathways to encourage movement of VMs to Azure by having them be able to be tested locally first before going live So now let me explain how you monetize this, and how Microsoft makes this a big win for everyone involved.
I suspect this change to Azure Stack HCI comes from a threefold goal of pushing people to Azure, Simplifying the development process, and more effectively monetizing Hyper-V.
So here's how you get all of those, and make everyone happy.
Step 1. Restore Hyper-V Server as a Free Platform (You can even put Azure in the name. Azure Hyper-V Server Or Azure Hyper-V Stack or similar) and make it a standalone flagship free product.
Step 2. Remove the Hyper-V role from Windows Server 2022, and deprecate all other versions of Hyper-V.
This makes Hyper-V Server THE definitive way to deploy Hyper-V, so development can be simplified, and EVERYONE benefits from having the reduced attack surface and reduced footprint on the host.
Step 3. Add Storage Spaces Direct to Hyper-V Server. It needs Hyper-converged Storage to be able to replace all versions of Hyper-V.
Step 4. Require a Microsoft/Azure account to install Hyper-V Server. This will rub some people a little bit the wrong way, but it'll be acceptable, so long as we can choose if we want to be able to harden the install so it can't be cloud *managed*
You still need to have people use the account to setup the install though, so Step 5 can work.
Step 5. Here's where Microsoft gets people in their cloud.
Fully integrated simple backups to Azure with the option of live monitoring, so Azure can spin up the backup if the on-site VM goes down.
Hyper-V Server lacks the Hyperconverged Storage Spaces Direct, and Hyper-V in general lacks a cohesive backup solution. So including a live cloud backup out of the box directly to Azure that will be guaranteed easy to setup since they'll already have to have an account will be the best way to get those VMs in the cloud.
Everybody wins here. Hyper-V becomes a separate free product with flagship functionality, simplified development process, and direct links to get VMs in Azure.
You could even alter the base Windows setup that Hyper-V Server uses to ONLY RUN MICROSOFT SIGNED EXECUTABLES. Both for security purposes, and to ensure that Azure remains the primary method of backup.- I wish people would understand how to respond to these kinds of moves. Flailing around isn't helpful by itself (I've long ago learned the hard way). Make the business case as to why this move isn't a good decision and what the impact is and any possible solutions you see. Anything else is just noise and/or possibly reinforcing the reason to shed all the whiners that throw tantrums.
The situation is quite clear now. We have no real answers why this SKU is being dropped.
M$ knows that hyper-v server is used quite a lot for non M$ VMs and does not generate any revenue. It's the said foot in the doors, but in homeless shelter, which they do not care about at all.
They want these VMs in Azure, period.SMB with a few hosts running WinSrv VMs is fine (core + hyper-v role), but what if they need another hosts for a few large Linux VMs as well? They would need licenced the servers and that's the issue here. Enterprises doesn't care that much about a few $ monthly fees for Azure Stack HCI, for SMB it's a deal breaker.
This is tech community and the drop of Hyper-V server SKU is money decision. All we can do is wait if M$ will stick to it's plan. They want SMBs to move to Azure (more money) and Copr/Ent to use HCI (more money).
- I recall when dual socket machines hit thestreet that some vendors wanted prices based on that. Microsoft on the other hand does not charge more for Windows desktop even the R9 5950X processor which is more cores than needed for gaming.
Elden_Christensen wrote:
what is being discussed here in this thread is the free 'Microsoft Hyper-V Server' SKU. Which is a free OS download just for running VMs.I think that everyone in this thread already knows this, and this is what is upsetting.
Installing Windows Server core and then adding the Hyper-V role to that is functionally the same thing on a technical level.
But what we want is a break on the licensing structure so that we can continue to use this function without the onerous licensing requirements, especially when adding Linux VMs to the mix.
If you want to move us towards Azure Stack HCI, OK Great, make us a untimed free tier version of it which is functionally the same as the Hyper-V SKU, including single-host scenarios.
I can't speak for everyone, but personally I don't think that it would be too much of a trade-off to be expected for register an Azure account to be able to use the free Azure Stack HCI, and this would at least achieve some of your goals to get more users at least signed up for Azure and therefore have all the other (paid) offerings of Azure at our fingertips. Especially features like Azure Site Recovery could be super useful for our use case.
I would even go one step further, and be willing to meet you half way on this, where maybe you could offer Azure Stack HCI for free, on the condition that at least 1 VM per account is set up to a untimed free tier of Azure Site Recovery is set up, even if the Azure Site Recovery not incurring charges because it hasn't actually been activated to go live.
Yes I know that many will just set this up just to get the free Azure Stack HCI and not actually use it and therefore not paying any money at all, but at least you would be getting your foot in the door, especially if a disaster were to strike then it would already be set up and they could instantly become a paying customer.
I would also suggest that the Azure Stack HCI -> Azure Site Recovery linking process be as easy as possible.
The alternative here is that everyone in this thread is instead of sticking with a dead platform (2019 version) they are going to go with a completely free alternative like ESXi free tier, Proxmox or XCP-ng, which has no future potential for a connection to Azure.
We are the ones who would most likely start out on something free and then work our way up Microsoft the stack to the paid products (and my business spends many thousands a month on Microsoft licensing as it is, my bank account proves it). Your Azure Stack HCI has no chance of success without us being on board. It is a two-way street here.
So let's get this clear.
Will any Hypr-V or future releases have charges associated with CPU Cores on top of the Windows Licencing?
A nice simple question 🙂
Elden_Christensen wrote:
The Hyper-V feature is critical to Microsoft, as part of Windows Server, Windows client, XBox, the Azure Stack family, and the foundation for Azure. Hyper-V feature is being heavily innovated and invested in. I recognize it's confusing with the naming, but what is being discussed here in this thread is the free 'Microsoft Hyper-V Server' SKU. Which is a free OS download just for running VMs. The Hyper-V feature is not going anywhere and no assumptions should be made otherwise.
Thanks!
EldenIt's still confusing I bet for some, even the way even you stated just now. A more clear definition would be:
Hyper-V exists as a ROLE/FEATURE you can enable on a full GUI Windows operating system. Hyper-V ALSO exists as a dedicated operating system in of itself (no GUI) where it's express purpose is to run VM's and nothing else. Hyper-V "The Operating System" is what is going away. The Hyper-V "Role/Feature" is not going away.
-Obviously I am still in the "We really need the Hyper-V Server the OS" camp as articulated previously.
- One Windows server with millions of blade servers can all run billions of Linux VMs easily. With Hyper-V and PowerShell its not hard to do.
Redmond wants more on premises to move to data centers where profits are higher for Azure. - We all understand you are talking about the non-windows hyper-v server.
Stop pretending like this is a "nothing change" that impacts freeloaders only. - Elden_Christensen
Microsoft
The Hyper-V feature is critical to Microsoft, as part of Windows Server, Windows client, XBox, the Azure Stack family, and the foundation for Azure. Hyper-V feature is being heavily innovated and invested in. I recognize it's confusing with the naming, but what is being discussed here in this thread is the free 'Microsoft Hyper-V Server' SKU. Which is a free OS download just for running VMs. The Hyper-V feature is not going anywhere and no assumptions should be made otherwise.
Thanks!
Elden I suspect that open source will find more developers given that Redmond lacks any real sustained commitment for a technology.
I personally used Linux from the get go and BSD before that so open source has been on my radar for quite some time now.
Hyper-V will still work but maybe its time to dump it on github and let the community maintain it
