1

I am wondering if anyone has recently tested, benchmarked, checked share trasfer speeds, IOPs etc on say server 2022 Hyper V VMs vs ZERO patches?

It could be no one has the time to, we have no choice so why bother or I don’t know where to look.

Maybe I have a private server not even on the Net and I want to make some choices even if it means turning off patches I would like to know the true impact.

People think Spectre, Meltdown or the core schedualer are a thing of the past. And well they are in many peoples minds, but is that just putting our heads in the sand?

Which brand or generation of chips if any are affected the most.
Is it even a thing in 2025?

I once did some cpu tests on VMs comparing server 2012 to 2016 to 2019 and found a 2x performance hit going to 2019. The main reason was the new Hyper-V hypervisor scheduler type was no longer the default (classic) now core is the default.
Some older posts on the topic

I am wondering how many hypervisor admins even consider which scheduler or the effectes of meltddown and spectre patches have.
Do most just go with - Fully patched or bust? I’ll take the performance hit even if its high just knowing I am in best practice compliance will cover my butt :slight_smile:

For kicks I redid the core vs classic schedualer on server 2022 thinking maybe they improved things.

The test was just making a 6 core 6 GB virtual machine on a fresh installation of verious Hyper V servers to see if there was any performance difference between them.

The original testing was done in 2021 using a R610 dual core x5670 xeons (12c/24t) using version 9 of Performance test CPU mark.

2012 Host with 2012 VM (6 core 6gig ram) - PM 9 cpu mark - 5444
2019 Host with 2012 VM (6 core 6gig ram) - PM 9 cpu mark - 2305
2019 Host with 2019 VM (6 core 6 gig ram)- PM 9 cpu mark - 2329
As you can see server 2019 performance was much slower than 2012. It was due to the scheduler of 2012 and 2016 being set to CLASSIC and not the newer core setting.
Fast forward to the same test done on slightly newer hardware a Dell T440 with Dual 8 core Silver 4110 CPUs + server 2022. Did it improve?

2022 host with 2022 VM (6 core 6 gig of ram) - PM 9 cpu mark - 6298 (type 3 core scheduler)
2022 host with 2022 VM (6 core 6 gig of ram) - PM 9 cpu mark - 8286 (type 2 classic scheduler)

Looks like the slower clocked skylake 8 cores are faster enough to over take the old x5670s even with the core scheduler 5444 vs 6298

But 2022 VMs are still 6298 with core scheduler vs 8286 using the classic server 2022 scheduler. 31 percent boost over default.
That is just cpu performance, not hard disks, networking or other testing.

In Hyper-V, the core scheduler is generally SLOWER but more secure than the classic scheduler for most workloads, especially in Windows Server 2022. While the classic scheduler may offer performance advantages in specific, highly optimized scenarios, the core scheduler’s isolation and security features often outweigh the performance difference

I have read that the core scheduler might be faster if you use change the VMs HT settings or Virtual Machine’s Threads Per Core Count. It defaults to 0 0r inherit from the OS.

All I know is at the default setting with a VM in 2022 the cpu scores are 31 percent slower.
Quite a speed hit. That combined with Spectre and Meltdown patches (I have not tested in 2025)
might add up.

I can see if you had a cloud server renting out VMs you might want ALL patches + core schedualer for security reasons. But I don’t see a compelling reason not to use the classic hyper V schedualer over the default core in server 2022 or 2025 if its a private server and all the VMs are controlled and owned by same guy. Risks of other other VMS peaking on other VMs to me is a very low attack surface.

Maybe I am missing something here. Anyone want to give me some compelling reasons to not run a HV server in classic mode for the increased performance?

Has any of you actually tested the performance hits on meltdown on skylake and newer cpus in hyper V? that topic seemed to have died down since 2018, I don’t think its really gone, just people have not tested it lately.

6 Spice ups
2

In a home-lab, running the less secure but higher performance method has merit. It means you can run older hardware and still perform well enough to continue testing newer products. But at the end of the day, you’re still at risk, even in a closed or air-gapped network. Good research, and thought experiment overall!

1 Spice up
3

I guess my point is were are always at risk even if you are fully patched. One needs to know enough in order to weight those risks with the performance. If using all patches means it will take 39,000 years to finish a job and the risk of running a classic scheduler is .001%. One might want to not use and take that risk.

I don’t think many really know the true risks of getting hacked by meltdown, spectre or classic scheduler. Also what is the risk of running full gui hyper v vs core. I run core, no web browser smaller attack surface.

I’ve read quite a bit but I have to say I do not really know. I know there are much much easier ways to hack than those difficult ways. ie. Change Healthcare 50 million hack was done via screen connect update that changed admin passwords back to default and they were too lazy to have two factor turned on. Fail. Much easier than exploiting a meltdown vulnerability.

2 Spice ups
4

Negative, - it’s too time consuming and given how many cores you can get on CPUs these days, a slight degradation vs a better security posture is often assumed acceptable.

This said, some providers handle these issues better than others, Hyper-V would not be my first, second or even third choice for a hypervisor, even without these issues.

I read your topic, lengthy as it was, and I would ask if you have any compelling reasons not to use the latest scheduler - it’s not just about CPU cycles. You now have NVMe and many more features in newer OSes that old Oses and schedulers wont work well with. These will consume their own cycles as well.

ReFS, deduplication and compression are features you wouldn’t have had back then either or they would have been early revisions.

It’s possible the classic scheduler will be retired at some point, but if you need every cycle of the CPU for VMs and are happy with any risks that come with this, then by all means stick with classic.

You’ve answered your own question, core is smaller and less to attack, given you also slightly more resources for VMs.

GUI is useful for those not comfortable with core, but with the smaller risk of having a GUI to attack, it’s also relevant for people who don’t have the skillset to run it headless.

While you raise valid queries, I’m not sure I fully understand what you are asking, if it’s about risk of core vs standard, it’s risk vs reward, and if you need more cycles and no mitigations, then this is your choice, but if you’re needing every inch of CPU cycles, perhaps a better CPU is the better option.

While someone using meltdown or spectre is less likely and more complex, the reward to them may be greater - look at SSL, for many MANY years it was the defacto standard, not enough people wanted to get that deep in to exploiting this, until Heartbleed, then many more followed.

It only takes one smartass to make a move, so to speak.

People are usually the weakest link.

classic scheduler is better for older, legacy OSes, those not hypervisor aware, but do bear in mind newer OSes also do a lot more, understand the hypervisor and the scheduler and can work with it.

I do not know anyone who gets this deep to want to go back to an older scheduler for extra cycles. It may also be against compliance if the company has to show mitigations.

TL:DR

If your CPU is older than 2019, classic scheduler can help, but if your CPUs are newer, then core mode is a better option, CPUs are designed with virtual schedulers in mind.

If you plan to use latest CPUs, modern OSes, then core is your choice, standard scheduler is better for older kit, or time-sensitive workloads, up until the point Microsoft disable and remove it.

Using standard scheduler with modern OSes, modern CPUs may actually be negative and make things worse - they’re designed with core scheduler in mind.

2 Spice ups
5

I appreciate any and all answers. I just like to better understand what the true performance costs and risks are. I know there are people here that have much more experience than I. You guys help fill in my knowledge gaps with real life experiences.

I have to admit I don’t like performance hits of any kind. I don’t want to buy a new graphics card to find it costs 2x more and is 20 percent slower. Same thing with servers. I was just curious at how much of a hit moden cpus are taking by the mitigations of spectre, meltdown and scheduler changes. I’m probably in the minority of people that have that want to know, the rest are too damn busy working hard while I am hardly working :slight_smile:

On this skylake T440 I really don’t want a 30 percent hit in performance hit from the core. scheduler I have not seen any good discussion on exactly how the core is superior. It maybe be Could be the 2018 sky-lake xeons are better to use classic over core hyper visor scheduler.

I made a trade off on hard drives. I would love 20 TB NVMES or SSDs but they cost a fortune so I have 18TB Raid 10 spinning rust w raid card and cache. 3.5" drives still a better bang for the buck.

Doubt I will be running anything newer than server2022 on it for 5+ years. Will be using it for Sql, sybase imaging databases.

1 Spice up
6

It’s more of an impact if you heavily oversubscribe your resources. Don’t buy a server and make things fit, buy a system fit for the workload you want, taking in to consideration some impact from this.

If you get VM spec right, the impact is also less.

A DC with 16 cores is going to be impacted more than one with 2 cores.

But they are also the biggest impact in performance, what you see as performance hit may actually be IO not CPU.

OSes above 2019 expect the core scheduler.

I expect you are overthinking this for a (possible) small gain in raw CPU.

If you spec your servers (VMs) correctly and don’t heavily oversubscribe, you will likely be fine for 99% of your workload, since everyone else is running this way.

1 Spice up
7

That’s dependent on the workloads you are running.

Evaluate each environment for what it is, and design appropriately.

1 Spice up
8

I was just giving examples of trade offs. I am just talking about cpu not Hard disks, internet or other bottlenecks. Just keeping it simple for now not talking about other hypervisors that may or may not be better for this discussion.

31 percent slower VM is not small. A job that that takes 4 hours now takes 5.24 hours. This is not easily done until you actually test it.

I maybe be over thinking but its better than under thinking it :slight_smile: ahh hand me a beer screw it Ill just toss more cores at it :slight_smile:

Ill do some real world testing down the road and likely use the newer preferred core scheduler in the end.

If anyone has any links or information oh current performance issues with spectre and meltdown mitigations would be appreciate. I just want to know what they are not that I will run with them non patched. I can test on skylake xeon but nothign newer atm.

1 Spice up
9

I understood your point, but a slow or paging HDD can cause high CPU cycles, so it’s not just CPU = CPU, other devices affect CPU performance.

Not disagreeing, but as I noted earlier, the older scheduler will likely be removed at some point and modern OSes expect core scheduler in Hyper-V.

If you need every cycle your CPU can give you and are willing to accept any risks you see from meltdown and spectre, then by your own decision nothing stops you using the previous scheduler.

It’s also not just the scheduler that demines your runtime, if your application isn’t multi-thread aware and/or isn’t designed with virtualization in mind, it may under perform with a higher core count.

I’d suspect your own testing is doing to be what drives you one way or the other, even if other people did ‘real-world’ tests, they wont be the same as your workloads.

I’ll say good luck and leave this topic.

1 Spice up
10

Thanks for your input.

I did test both spectre and meltdown on and off. The performance loss was near nill on cpu and maybe a little on zipping file testing. The core vs Classic shedualer seems to be the big performance loss, I might be able to get core

Im not sure how this factors into server 2022, I do not plan to run any OS newer than say 2025 server as a VM. Which modern OS would have an issue if its run on a HV 2022 server as a guest VM? 2022 does not seem to care.
I could see maybe an issue running things as Type 2 that are older Type 1 VMs (bios boot)
Are you saying the OS would just refuse to boot tossing up a error if it does not detect a core scheduler is running? Its not that difficult to change the setting and reboot the server if that were to occur in the future. I’m probably missing your point on this.

I agree that other activities can affect a benchmarking test. I tried to keep all variables the same but one.

I spoke with a HV admin and he said yea sometimes Some Hyper-V servers might need to use the classic scheduler for performance reasons, The classic scheduler, a traditional round-robin approach, can sometimes offer better performance than the core scheduler in specific scenarios.

Seems I should be able to tweak the core scheduler to come closer than 31 percent of the classic. I don’t know if its just a matter of non used dormant threads vs real performance loss per active thread yet.

Cya Rod-IT

1 Spice up
11

No, I said it’s highly likely the core scheduler will be the only option and that the older scheduler will likely be removed going forward. So perhaps when Server 2027 comes out, there will be no classic scheduler - I don’t know, it’s speculation based on the fact a newer scheduler (whether you prefer it or not) exists, Microsoft wont code both for too long if the new ones is in use by 99% of people.

Before you ask, how will they know - telemetry data.

1 Spice up
12

Most of the time CPU is not the bottleneck. If we got to choose where we’d take the hit for improved security I’d choose CPU to be the fall guy.

1 Spice up
13

From a company point of view there is also the fact that you won’t get or renew security accrediations bottom line if you aren’t up to date. In todays market these can be the difference between getting or losing new clients as things such as CSE+ and ISO 27001 are no longer just nice to haves.

Its also absolute nonsense that many don’t know the real risks- for many here its literally our jobs to know.

Also in an enterprise environment I’m certainly not caring if performance is slower by a miniscule amount when I know I have done as much as possible to keep ourselves secure. If we notice performance drops (unlikely) then we will simply purchase and plug in another HCI node, under no circumstances would our company ever choose to be less secure over that as the potential costs of a breach far outweight the capex cost.

Of course there are other methods people can penetrate systems but that certainly is no reason to ignore ror disregard certain vectors of attack as you have- good security practices assume every point of attack is a weakness.

TLDR: yes they are always at risk, but your thinking makes them even more at risk and in a enterprise environment that would not be acceptable.

2 Spice ups