A virtual machine’s processor type: why the default is slow and why host is not always right

When creating a virtual machine there is a field called processor type, and it is usually left at its default. That default is a fairly old, generic processor model.

This is not an oversight, it is a deliberate choice. But leaving it there without knowing what it costs you would be an oversight.

Why the default is so old

The processor model shown to a virtual machine determines where that machine can be moved. A running machine cannot be moved to a server that does not support the processor features it was shown.

Showing the oldest and most generic model gives the widest compatibility. That is the logic of the default: let it go anywhere.

What it costs

Modern processors have special instructions that make certain jobs many times faster. Encryption, compression, media work and hashing benefit from them directly.

The old default model hides those instructions from the guest. Because the guest cannot see them, it takes the slow path. The result: your server is capable of doing that job quickly, but your virtual machine is not.

The difference is not small. A service doing encryption can take many times longer inside the virtual machine than the same work takes on the server. And that difference never shows up as an error anywhere; it is only felt as "this place is slow".

The opposite end: showing the server's processor as it is

At the other end you can pass the server's processor through as it is. The guest sees all the modern instructions and runs at its fastest.

The price is equally clear: that machine cannot be moved while running to a server with a different processor. If you have built a cluster, the machine you want to move on a maintenance night stays put precisely because of this setting.

So the choice is the same trade that keeps appearing in this wiki: performance or mobility.

Three situations, three answers

If you have a single machine, pass the server's processor through. There is nowhere to move to, so there is no point paying for compatibility.

If the servers in the cluster are identical, you can still pass it through. Same processor, same features.

If the servers in the cluster differ, take the middle path: pick a named modern model that all of them support. You get most of the modern instructions and portability is preserved. This is the most overlooked and usually the most correct option.

The common trap

It happens in this order: you start with one machine, you set the processor to the server's, months pass, you buy a second server and build a cluster, and when a maintenance night comes the machines will not move.

At that moment nobody remembers a setting made months ago. On the day you build a cluster, review the processor setting of the existing machines.

What to know when changing it

Changing the processor model means showing the guest that the hardware has changed. So the change requires the machine to be fully stopped and started again; restarting from inside is not enough.

Some operating systems also notice a hardware change in licensing terms. If you have such a guest, take that into account before making the change.

What Atlas does

Atlas recognises the old default processor types and marks it when a machine is still running on one of them.

The choice of level here is meaningful: this is a suggestion, not a warning. The reason is honest: the default is not broken, it works. There is simply performance left on the table. Calling something that is not broken a warning lowers the value of real warnings.

The mark sits under the performance heading, so it does not say "this machine is set up wrong", it says "this machine could be faster".

And the suggestion takes you straight to where the setting is. Telling someone that something could be improved and then making them search for where it lives is only slightly better than not telling them.