Common KVM processor

[twentytwo]

Hello,

When I checked the Task Manager in Windows 10 and viewed Performance, the selected CPU is worded "Common KVM processor" instead of name of the CPU? Intel i7 8600K. What can I do to make it read the CPU name instead of common KVM processor? Does correcting the name affect the overall VM performance?

 

[sg90]

On the VM Wizard change the CPU type to host, you can also do this by selecting the VM Hardware Tab - > Processor and then edit.

You need to stop and start the VM for this to take effect.

 

[twentytwo]

Thank you SG90, your solution works!

 

[LnxBil]

Does correcting the name affect the overall VM performance?

Not easy to answer, but mostly yes. It has a lot of implications.

The whole idea about virtualization is to virtualize every computing resource, so it is natural to use also the virtualized CPU. Windows will detect that it is running on virtualized hardware anyways.

 

[DurzoBlint123]

I know this is an old post, but here is just a quick note for anyone else googling this. I wasn't paying attention when I originally built my Win11 VM, and left the default selection of Common KVM Processor. When I shut down the VM, changed the processor to "Host" and started it back up again, device manager still showed it has "Common KVM Processor". I attempted to right click on the device and select "Updates Drivers", but it stated that the drivers were already correct.
It wasn't until I rebooted a second time just to try it, that the processor in the VM's device manager showed "Intel Core i7...".

 

[bzb-rs]

But is there any actual performance enhancement if we select the right model or use 'host' option instead of common kvm processor?

 

[LnxBil]

But is there any actual performance enhancement if we select the right model or use 'host' option instead of common kvm processor?

Yes. If the general processor is not presenting a cpu flag and passing through does, you will be able to use the cpu flag inside of the guest and optimized code will be able to use it. Best example is the AES-NI instruction and I tested this years ago (not sure if it is still true). Without the passthrough, 192-bit AES CBC was done in software, after activating the cpu flag and using optimized code, the operation was done in hardware and was much faster. The downside of this is, that you will lose the ability to migrate the VM to other nodes if you use some cpu flags or cpu=host and thas is worse than being able to use have a little more speed, but if you only have one node or don't care about HA, go for it.

 

[gkovacs]

Yes. If the general processor is not presenting a cpu flag and passing through does, you will be able to use the cpu flag inside of the guest and optimized code will be able to use it. Best example is the AES-NI instruction and I tested this years ago (not sure if it is still true). Without the passthrough, 192-bit AES CBC was done in software, after activating the cpu flag and using optimized code, the operation was done in hardware and was much faster. The downside of this is, that you will lose the ability to migrate the VM to other nodes if you use some cpu flags or cpu=host and thas is worse than being able to use have a little more speed, but if you only have one node or don't care about HA, go for it.

This is not entirely true. As newer processors are fully compatible with older models, you can easily and safely migrate guests using an older CPU model set in KVM. For example if you have Ivy Bridge, Haswell and Skylake servers, you should set your KVM guests to the lowest common denominator CPU model (in this case Ivy Bridge), and they will happily migrate and run on hosts with newer hardware. We have been using this technique for years without any problems and without any detectable performance differences, as Ivy Bridge already has the AES crypto instructions. What's important for performance is that you don't use the KVM emulated processor model, only Intel/AMD hardware models, you don't necessarily need to use "host" CPU passthrough.

 

[VictorSTS]

As newer processors are fully compatible with older models

This is true at an OS/application level, but not fully applicable to live migration. Even if the processors are compatible doesn't mean that every new CPU has all the instructions every older CPU had. There has been BIOS and microcode updates that disabled vulnerable instructions, so your newer CPU might not have instructions that your older one has because it has not updated microcode yet.
Live migration among different brand/model, CPUs, BIOS/microcode revision and host kernel version isn't 100% guaranteed, even if there are best practices that increase success rate, as using the oldest cpu in your cluster for KVM CPU model.

 

[LnxBil]

Live migration among different brand/model, CPUs, BIOS/microcode revision and host kernel version isn't 100% guaranteed

Exactly and that is what has been reported on the forums before.

I'm glad you (@gkovacs) have not experienced it, I did not either, yet at least one person ran a deep dive into this problem, reported back and others could reproduce the problems. Maybe it's all better now, yet guaranteed is nothing.