Features/KVM Stable Guest ABI

KVM Stable Guest ABI

Summary

Allow guest virtual machines to be presented with the same ABI across QEMU upgrades.

This is particularily important for Windows guests where a guest ABI change may require Windows installs to be reactivated.

See also Features/KVM Stable PCI Addresses.

Owner

• Name: Mark McLoughlin

Current status

• Targeted release: Fedora 12
• Last updated: 2009-07-16
• Percentage of completion: 30%

TODO

• Add 'pc-0-11' machine type to qemu and make it the default
• Make 'qemu -M pc' a symlink to the latest machine type
• Make libvirt query the current default machine type and store it in the guest XML
• Testing

Completed

• Settled on Solution 2.
• Patches to pc-0-10 machine type posted and accepted for 0.11

Detailed Description

KVM guests are presented with an emulated hardware platform that includes (e.g. a CPU model, APIC, PIT, ACPI tables, IDE/USB/VGA controllers, NICs etc.). When QEMU is updated to a new version, some aspects of this platform may change as new hardware capabilities are added to that platform.

From the guest OS point of view, this is equivalent to updating a physical hardware platform and may, in the case of Windows, require the OS install to be activated. To avoid such issues, guest machines should transparently continue to run on their original platform, even when QEMU is upgraded.

A number of solutions are being discussed upstream.

Solution 1 :: Don't Change the ABI

An obvious solution to the problem is to not change the default ABI in QEMU. New features could be added to QEMU, but they would have to be explicitly requested.

Pros:

1. Simple for QEMU and libvirt
2. Possible to implement for Fedora 12

Cons:

1. Makes it more difficult for new guests to benefit from QEMU improvements

Solution 2 :: ABI Version Number

The idea here is that when a guest is run for the first time, it uses the latest available ABI and libvirt should take not of the ABI version number for future use.

Various options for specifying the ABI version have been suggested (e.g. -M pc1, --abi 0.10 or an item in a config file). How libvirt would query for the latest ABI version would probably depend on what option for selecting a version is settled on, but it could be as simple as a /usr/share/qemu/machines/pc.dt symlink.

Pros:

1. Simple, both for QEMU and libvirt
2. Possible to implement for Fedora 12

Cons:

1. Makes back-porting of ABI changes to older versions more difficult

Solution 3 :: Device Versions in a Config File

Similar to solution 2, except each device has a version number which can be specified in a config file.

See also solution 3 in Features/KVM Stable PCI Addresses for how libvirt would need to be able to merge guest configuration changes into a qemu config file.

Pros:

1. Also solves the stable PCI addresses issue

Cons:

1. Significant work still required in QEMU
2. Very complex solution for libvirt
3. Highly unlikely to be in place for Fedora 12

Solution 4 :: Device Versions in a Compat Hints File

Similar again, except a monitor command would be used to dump the device versions to an opaque file format. This would mean libvirt would not need to modify a configuration file.

See also solution 4 in Features/KVM Stable PCI Addresses.

Pros:

1. Also solves the stable PCI addresses issue
2. Straightforward solution for libvirt

Cons:

1. Upstream not keen on adding both compat hints and machine description formats
2. Quite unlikely to be ready for Fedora 12

Benefit to Fedora

This feature would remove a significant issue with Fedora's virtualization support of Windows.

Scope

Each of the proposed solutions requires work in both QEMU and libvirt. No other Fedora packages would be affected.

How To Test

Upgrade to a new version of QEMU which has ABI changes and check that these changes are not visible to existing guests.

User Experience

It should be possible to upgrade QEMU without causing Window's guests to require reactivation.

Dependencies

The main dependency is agreeing upstream on the QEMU part of the solution.

Contingency Plan

No contingency plan required; if one of the solutions is not implemented, the feature will not be available and nothing else will be affected.

Documentation

• Izik's patch (November 2007)
• Markus's patch series (Jan 2009)
• Markus's machine description format RFC (February 2009)
• Markus's tenth iteration of his machine description patches (April 2009)
• First thread where saveabi idea came up (May 2009)
• Most recent discussion (June 2009)
• Patch adding the pc-0-10 machine type

Release Notes

KVM guests in Fedora 12 now have a stable ABI, reducing the chance that Windows guests will require reactivation when QEMU is upgraded in future.

Comments and Discussion

• See Talk:Features/KVM Stable Guest ABI