Features/KVM and QEMU merge

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(User Experience)
(vgabios, openbios, bochs-bios already included in Fedora)
 
(5 intermediate revisions by 3 users not shown)
Line 6: Line 6:
  
 
* Name: [[User:Glommer|Glauber Costa]]
 
* Name: [[User:Glommer|Glauber Costa]]
* Email: '''FIXME'''
+
* Email: glommer@redhat.com
  
 
== Current status ==
 
== Current status ==
  
 
* Targeted release: [[Releases/11|Fedora 11]]
 
* Targeted release: [[Releases/11|Fedora 11]]
* Last updated: 2009-03-25
+
* Last updated: 2009-03-26
 
* Percentage of completion: 100%
 
* Percentage of completion: 100%
  
Line 22: Line 22:
 
Currently, there is both a <code>qemu</code> package and <code>kvm</code> package. The <code>kvm</code> package's source is a fork of the QEMU source, but KVM regularily re-bases to the latest QEMU source and merging of KVM support into the QEMU code base is actively under-way. The medium term plan is for the KVM fork of QEMU to go away.
 
Currently, there is both a <code>qemu</code> package and <code>kvm</code> package. The <code>kvm</code> package's source is a fork of the QEMU source, but KVM regularily re-bases to the latest QEMU source and merging of KVM support into the QEMU code base is actively under-way. The medium term plan is for the KVM fork of QEMU to go away.
  
In anticipation of this, the package maintainers feel it would be a good idea to merge the packages now. This would be done as follows:
+
In anticipation of this, the package maintainers feel it would be a good idea to merge the packages now. This is to be done as follows:
  
# The <code>qemu</code> package would be built using the <code>kvm</code> codebase.
+
# The <code>qemu</code> package is built using the <code>kvm</code> codebase.
# The <code>qemu</code> source package would provide a sub-package for each target - <code>qemu-kvm</code>, <code>qemu-x86_64</code>, <code>qemu-i386</code>, <code>qemu-ppc</code> etc.
+
# The <code>qemu</code> source package provides a sub-package for each group of target architectures - <code>qemu-system-x86</code>, <code>qemu-system-ppc</code>, <code>qemu-system-sparc</code> etc.
# There would be a <code>qemu-common</code> package for BIOS binaries, documentation etc.
+
# The <code>qemu-user</code> sub-package contains the various user mode emulators.
# The <code>kvm</code> package would be obsoleted by <code>qemu-kvm</code>.
+
# The <code>qemu-common</code> package contains BIOS binaries, documentation etc.
# A <code>qemu</code> meta-package would be provided which requires all the different target sub-packages.
+
# The <code>kvm</code> package is obsoleted by <code>qemu-system-x86</code> .
 +
# A <code>qemu</code> meta-package requires all the different target sub-packages.
 +
 
 +
The <code>qemu</code> package previously contained binary BIOS images which were copied directly from the upstream release tarball without rebuilding from source. As part of the package merge, this long-standing issue is resolved by splitting those images into their own packages which are built from source - <code>bochs-bios</code>, <code>vgabios</code> and <code>openbios</code>.
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
  
A single package is far more maintainable than multiple packages. Any bug fixes or security errata would involve much less work.
+
A single package is far more maintainable than multiple packages. Any bug fixes or security errata involves much less work.
  
 
This change will have to be made eventually once the merge happens upstream. Doing the package merge now means we reap the benefits earlier.
 
This change will have to be made eventually once the merge happens upstream. Doing the package merge now means we reap the benefits earlier.
Line 40: Line 43:
 
No changes are required outside of the changes to the two packages in question.
 
No changes are required outside of the changes to the two packages in question.
  
Comps needs updating to pull in <code>qemu-kvm</code>, or maybe even the <code>qemu</code> meta-package.
+
Comps could be update to pull in <code>qemu-system-x86</code> rather than <code>kvm</code>, but either works fine.
  
 
The <code>kvm</code> package needs to be blocked from rawhide.
 
The <code>kvm</code> package needs to be blocked from rawhide.
Line 47: Line 50:
  
 
== How To Test ==
 
== How To Test ==
Users willing to test this feature should proceed no differently from any kvm or qemu upgrade.
+
 
Pick your guests (and user applications, in case of qemu), and make sure they still work under the new
+
Try updating or installing the pre-merge packages using e.g. <code>yum update kvm</code>. Check that updating <code>kvm</code> results in the <code>qemu-system-x86</code> package being installed and that updating <code>qemu</code> pulls in the various sub-packages.
package.
+
 
 +
Aside from the package updating issue, this feature should be tested as any <code>kvm</code> or <code>qemu</code> upgrade. Test existing guest virtual machines or install new guests using the package and check they run correctly.
  
 
== User Experience ==
 
== User Experience ==
No user experience change is expected. People should be able to run guests in the very same way they did before.
 
  
== Dependencies ==
+
No user visible change is expected. Users should be able to run guests in the very same way they did before.
  
There hasn't been a QEMU release in over a year (0.9.1).
+
The primary benefit to users is that the <code>qemu</code> package will no longer lag behind the <code>kvm</code> package.
  
Clearly it would be preferable if there was a new QEMU upstream release upon which a KVM release would be based.
+
== Dependencies ==
  
The <code>kvm</code> codebase has had essentially no testing of the non-native targets. No doubt dragons be lurking there, but these issues will have to be resolved as part of the upstream QEMU merge anyway. We expect to be able to resolve any of these issues upstream without significant delay.
+
There hadn't been a QEMU release in over a year (since 0.9.1). However, upstream [http://www.archivum.info/qemu-devel@nongnu.org/2009-03/msg00188.html recently released 0.10] which helps us to ship an actual released tarball rather than an arbitrary development snapshot.
 +
 
 +
Since we are building both QEMU and KVM from a <code>kvm-userspace</code> tarball, we need a KVM release based on the QEMU 0.10.x series. This is planned by the upstream KVM maintainer in the short term. In the meantime we're shipping a snapshot of KVM git.
  
 
== Contingency Plan ==
 
== Contingency Plan ==
Line 69: Line 74:
  
 
== Documentation ==
 
== Documentation ==
* '''FIXME'''
+
 
 +
* [http://www.redhat.com/archives/fedora-virt/2009-February/msg00000.html Package split discussion]
 +
* [http://www.redhat.com/archives/fedora-virt/2009-February/msg00064.html More discussion]
 +
* [http://www.archivum.info/qemu-devel@nongnu.org/2009-03/msg00188.html QEMU 0.10.0 release annoucement]
 +
* [http://www.archivum.info/qemu-devel@nongnu.org/2009-03/msg01067.html QEMU 0.10.1 release announcement]
 +
* <s>[https://bugzilla.redhat.com/485418 vgabios review request]</s>
 +
* <s>[https://bugzilla.redhat.com/485420 openbios review request]</s>
 +
* <s>[https://bugzilla.redhat.com/485417 bochs-bios review request]</s>
  
 
== Release Notes ==
 
== Release Notes ==
Line 82: Line 94:
 
[[Category:F11 Virt Features|KVM and QEMU merge]]
 
[[Category:F11 Virt Features|KVM and QEMU merge]]
  
[[Category:FeatureReadyForWrangler]]
+
[[Category:FeatureAcceptedF11]]

Latest revision as of 05:58, 29 April 2009

Contents

[edit] Summary

Combine the kvm and qemu packages into a single package.

[edit] Owner

[edit] Current status

  • Targeted release: Fedora 11
  • Last updated: 2009-03-26
  • Percentage of completion: 100%

[edit] Detailed Description

The QEMU package provides a processor and system emulator which enables users to launch guest virtual machines not only under the same hardware platform as the host machine, but also dramatically different hardware platforms. For example, QEMU can be used to run a PPC guest on a x86 host. QEMU dynamically translates the machine code of the guest architecture into the machine code of the host architecture.

KVM provides kernel support for running guests of the same architecture as the host. Guests run directly on the hardware with out any translation needed by the host, allowing much higher levels of performance to be attained. QEMU can now use the KVM kernel support for higher performance virtualization.

Currently, there is both a qemu package and kvm package. The kvm package's source is a fork of the QEMU source, but KVM regularily re-bases to the latest QEMU source and merging of KVM support into the QEMU code base is actively under-way. The medium term plan is for the KVM fork of QEMU to go away.

In anticipation of this, the package maintainers feel it would be a good idea to merge the packages now. This is to be done as follows:

  1. The qemu package is built using the kvm codebase.
  2. The qemu source package provides a sub-package for each group of target architectures - qemu-system-x86, qemu-system-ppc, qemu-system-sparc etc.
  3. The qemu-user sub-package contains the various user mode emulators.
  4. The qemu-common package contains BIOS binaries, documentation etc.
  5. The kvm package is obsoleted by qemu-system-x86 .
  6. A qemu meta-package requires all the different target sub-packages.

The qemu package previously contained binary BIOS images which were copied directly from the upstream release tarball without rebuilding from source. As part of the package merge, this long-standing issue is resolved by splitting those images into their own packages which are built from source - bochs-bios, vgabios and openbios.

[edit] Benefit to Fedora

A single package is far more maintainable than multiple packages. Any bug fixes or security errata involves much less work.

This change will have to be made eventually once the merge happens upstream. Doing the package merge now means we reap the benefits earlier.

[edit] Scope

No changes are required outside of the changes to the two packages in question.

Comps could be update to pull in qemu-system-x86 rather than kvm, but either works fine.

The kvm package needs to be blocked from rawhide.

The kvm bugzilla product's rawhide version needs removing. Bugs need migrating.

[edit] How To Test

Try updating or installing the pre-merge packages using e.g. yum update kvm. Check that updating kvm results in the qemu-system-x86 package being installed and that updating qemu pulls in the various sub-packages.

Aside from the package updating issue, this feature should be tested as any kvm or qemu upgrade. Test existing guest virtual machines or install new guests using the package and check they run correctly.

[edit] User Experience

No user visible change is expected. Users should be able to run guests in the very same way they did before.

The primary benefit to users is that the qemu package will no longer lag behind the kvm package.

[edit] Dependencies

There hadn't been a QEMU release in over a year (since 0.9.1). However, upstream recently released 0.10 which helps us to ship an actual released tarball rather than an arbitrary development snapshot.

Since we are building both QEMU and KVM from a kvm-userspace tarball, we need a KVM release based on the QEMU 0.10.x series. This is planned by the upstream KVM maintainer in the short term. In the meantime we're shipping a snapshot of KVM git.

[edit] Contingency Plan

No real contingency is required. If the change can't made in time for release, the status quo will remain.

Regressions may be introduced versus the current QEMU 0.9.1 release, but we don't consider that rolling back to a previous release will be an option. QEMU upstream is very active, so we expect any unanticipated regressions would be resolved quickly. This situation isn't really impacted by the merge.

[edit] Documentation

[edit] Release Notes

Fedora 11 includes a merge of the qemu and kvm RPMs. The merging of the two codebases continues upstream, but the Fedora package maintainers have chosen to merge the packages in order reduce the maintainership burden and provide better support.

[edit] Comments and Discussion