Features/NetDeviceFailover

Summary

Provide infrastructure to allow a management tool to present both an rtl8139 and virtio-net network adapter, detect when a driver is loaded for virtio-net, and enable the virtio-net adapter disabling the rtl8139 adapter.

Owner

Name: Anthony Liguori
Email: anthony@codemonkey.ws

Detailed Summary

The rtl8139 is the default network adapter in qemu-kvm. The e1000 is the default network adapter in qemu. In both projects, the virtio-net network adapter has the best performance. The default network adapter choice is typically a trade off between performance and compatibility with the virtio, e1000, and rtl8139 filling out the spectrum in terms.

Other hypervisors deal with this problem by taking an older adapter and adding a paravirtualized mode to it so that a single adapter gets both good performance and good compatibility. Unfortunately, because we require our changes to be accepted by mainline Linux, this is not a viable strategy for us.

We could achieve a similar result by doing the following (using tap networking):

Start a guest with two network cards (such as rtl8139 and virtio-net)
Start with both cards having their link down
Detect when each card is initialized by the guest OS
When the performant card's driver is loaded, disable the link for the legacy card and enable the link for the performant card
When the legacy card's driver is loaded, wait a short timeout (500ms) and check if the performant card's driver is loaded, if it isn't, enable the legacy card's link

This will address both the case where drivers are present at start up and when the performant card's driver is loaded post start up. To implement this functionality in a management layer, the following functionality would be needed in qemu:

Introduce an API for devices to expose generic guest driver status. This API could cover events like initializing, ready, and failed.
Expose a QMP interface to query device driver's status and to expose async QMP events

To make this work directly in qemu, we would need to introduce a higher level API to enable this configuration. It is unclear whether this is a reasonable thing to do.