Choosing virtual hardware: what you show the guest decides its speed

A virtual machine's hardware is not a fact, it is a choice. You decide which network card and which disk controller the guest is shown. And that decision directly sets the machine's speed.

Two families

Emulated real hardware. The guest is shown a physical card it has known for years. Because it already knows it, nothing extra needs installing.

Hardware designed for virtualisation. The guest is shown a device that says "I am virtual". Because the guest knows this, it speaks a short and direct language.

The difference shows up in performance. With an emulated card, every packet passes through a layer imitating the behaviour of hardware that does not really exist. With a device designed for virtualisation, that imitation is gone.

Why emulation exists

For compatibility. An old operating system with no virtual drivers looks at the emulated card, says "I know this one", and boots without trouble.

So emulated hardware is a tool for installation day. So that the machine comes up, we can get inside, and we can install the drivers.

The real issue: nobody goes back

Here is the problem. The machine is installed, it runs, it does its job. Nobody says "the virtual drivers are in place now, let me change the hardware".

The result: for months, sometimes years, that machine keeps running on temporary hardware chosen on installation day. Nothing reports an error. It is simply slower than it should be.

The rule is simple: emulated hardware is a tool for installation day, not for the machine's lifetime. Change it the moment the drivers are in place inside the guest.

The two settings nobody revisits

The network card model. Old card models are still selectable and they work when selected. Working does not mean they are right.

Running the disk queue on its own thread. This keeps disk requests from waiting on the machine's main processing. With it off everything still works, they just wait on each other during busy moments.

Both are left at their defaults during installation and never opened again.

And a lesson in measurement: a total is not a symptom

This is the most general part of this article, and it does not apply only to virtual hardware.

Network cards have a counter of dropped packets, and that counter is never reset. If a machine that had one bad hour last year shows two hundred dropped packets, that number sits there forever.

Looking at that number and saying "this machine is dropping packets" is wrong. The right question is is it dropping right now, that is, not the total but the rate. How many packets are dropped in a minute?

The same distinction appeared in disk wear: not the percentage, the slope. It can be written as a general rule: an accumulated total tells you about the past, a rate tells you about today. Decisions are made by looking at today.

What Atlas does

Atlas recognises old network card models and marks it when a machine is still using one. In the same way, it shows when the disk queue is not running on its own thread.

Both are at the suggestion level, not warning. The reason is the same as in the previous article: these are not broken, they could simply be better. Calling something that is not broken a warning devalues real warnings.

On packet loss, the product applies the measurement lesson above: it does not look at the accumulated counter but at the drop rate over the last few minutes. If at least one packet is dropped per minute the card appears; when the loss stops, the card disappears by itself.

The reason for this is written into the code: because of a counter that is never reset, a machine that lost two hundred packets in the past would look guilty for life. The question asked is not "did it lose packets in the past" but "is it losing them right now".