From Fedora Project Wiki
No edit summary
(re-work this substantially to clarify)
Line 5: Line 5:
Allow [[Virtualization|guest virtual machines]] to be presented with the same ABI across QEMU upgrades.
Allow [[Virtualization|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.
The idea is that the hardware profile of the virtual machine should not change when QEMU is upgraded.
 
This is particularly important for Windows guests where a guest ABI change may require Windows installs to be reactivated.


See also [[Features/KVM Stable PCI Addresses]].
See also [[Features/KVM Stable PCI Addresses]].
Line 16: Line 18:


* Targeted release: [[Releases/12|Fedora 12]]
* Targeted release: [[Releases/12|Fedora 12]]
* Last updated: 2009-07-16
* Last updated: 2009-07-22
* Percentage of completion: 30%
* Percentage of completion: 80%


=== TODO ===
=== TODO ===


* Add 'pc-0-11' machine type to qemu and make it the default
* Ensure the remaining patches for libvirt and QEMU are accepted and included in Fedora 12
* 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
* Testing


=== Completed ===
=== Completed ===


* Settled on Solution 2.
* Settled on a [[KVM Stable Guest ABI Design Notes|solution]].
* Patches to <code>pc-0-10</code> machine type [http://lists.gnu.org/archive/html/qemu-devel/2009-07/threads.html#00478 posted] and accepted for 0.11
* QEMU patches to add the <code>pc-0.10</code> machine type [http://lists.gnu.org/archive/html/qemu-devel/2009-07/threads.html#00478 posted] and [http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01129.html accepted] for 0.11
* QEMU patches [http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01718.html posted] to add the <code>pc-0.11</code> machine type and alias it to <code>pc</code>
* libvirt patch [http://www.redhat.com/archives/libvir-list/2009-July/msg00592.html posted] to make it canonicalize QEMU machine types when the guest is first created


== Detailed Description ==
== Detailed Description ==
Line 37: Line 39:
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.
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.
A number of [[KVM_Stable_Guest_ABI_Design_Notes|solutions]] were discussed upstream. In the end, it was decided that each release should add a new machine type (e.g. <code>qemu -M pc-0.11</code>) and the <code>pc</code> machine type should be an alias for the latest. This allows libvirt to determine what the latest machine type is when the guest is created and use that machine type in future.
 
== 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:
 
# Simple for QEMU and libvirt
# Possible to implement for Fedora 12
 
Cons:
 
# 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. <code>-M pc1</code>, <code>--abi 0.10</code> 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 <code>/usr/share/qemu/machines/pc.dt</code> symlink.
 
Pros:
 
# Simple, both for QEMU and libvirt
# Possible to implement for Fedora 12
 
Cons:
 
# 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:
 
# Also solves the stable PCI addresses issue
 
Cons:
 
# Significant work still required in QEMU
# Very complex solution for libvirt
# 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:
 
# Also solves the stable PCI addresses issue
# Straightforward solution for libvirt
 
Cons:
 
# Upstream not keen on adding both compat hints and machine description formats
# Quite unlikely to be ready for Fedora 12


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 105: Line 47:
== Scope ==
== Scope ==


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


== How To Test ==
== 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.
* Ensure the required versions of libvirt and QEMU are installed
* '''FIXME''': Can you be more specific about what version should be compared and tested?
** '''FIXME'' add required version numbers here
* Install a guest using e.g. <code>virt-install</code>
* Check the XML configuration of the guest using <code>virsh dumpxml</code> and verify the <code>machine</code> property of the <code>&lt;os&gt;&lt;type&gt;</code> element is <code>pc-0.11</code>


== User Experience ==
== User Experience ==
Line 133: Line 77:
* Most recent [http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00735.html discussion] (June 2009)
* Most recent [http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00735.html discussion] (June 2009)
* [http://lists.gnu.org/archive/html/qemu-devel/2009-07/threads.html#00481 Patch] adding the pc-0-10 machine type
* [http://lists.gnu.org/archive/html/qemu-devel/2009-07/threads.html#00481 Patch] adding the pc-0-10 machine type
* Gerd's [http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01129.html patches] to add the pc-0.11 machine type
* [http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01718.html Patches] to add the <code>pc-0.11</code> machine type and alias it to <code>pc</code>
* [http://www.redhat.com/archives/libvir-list/2009-July/msg00592.html libvirt patch]
* [[KVM_Stable_Guest_ABI_Design_Notes Notes]] on the potential solutions considered.


== Release Notes ==
== Release Notes ==

Revision as of 13:29, 22 July 2009

KVM Stable Guest ABI

Summary

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

The idea is that the hardware profile of the virtual machine should not change when QEMU is upgraded.

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

See also Features/KVM Stable PCI Addresses.

Owner

Current status

  • Targeted release: Fedora 12
  • Last updated: 2009-07-22
  • Percentage of completion: 80%

TODO

  • Ensure the remaining patches for libvirt and QEMU are accepted and included in Fedora 12
  • Testing

Completed

  • Settled on a solution.
  • QEMU patches to add the pc-0.10 machine type posted and accepted for 0.11
  • QEMU patches posted to add the pc-0.11 machine type and alias it to pc
  • libvirt patch posted to make it canonicalize QEMU machine types when the guest is first created

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 were discussed upstream. In the end, it was decided that each release should add a new machine type (e.g. qemu -M pc-0.11) and the pc machine type should be an alias for the latest. This allows libvirt to determine what the latest machine type is when the guest is created and use that machine type in future.

Benefit to Fedora

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

Scope

The work required is limited to QEMU and libvirt. No other Fedora packages would be affected.

How To Test

  • Ensure the required versions of libvirt and QEMU are installed
    • 'FIXME add required version numbers here
  • Install a guest using e.g. virt-install
  • Check the XML configuration of the guest using virsh dumpxml and verify the machine property of the <os><type> element is pc-0.11

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

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