Getting the kvm kernel modules

From KVM
Revision as of 10:07, 31 May 2015 by Bsd (talk | contribs) (added categories)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

There are a variety of sources of kvm kernel modules. Which ones to use depend on whether you are interested in using, testing, or developing kvm.

As of now, all major community and enterprise distributions contain kvm kernel modules and userspace; these are either installed by default or require installing a kvm package. For someone looking for stability, these are the best choice. No effort is needed to build or install the modules, support is provided by the distribution, and the distribution/module combination is well tested.

For those stuck on an older kernel, but wishing to run a modern, stable kvm release the kvm maintainers provide an external module kit that can run a modern kvm on an older kernel. These packages are named kvm-kmod-3.x.y (or kvm-kmod-3.x), and correspond to the kvm code contained in Linux 3.x.y. They can generally be run on any Linux kernel older than 3.x, but not older than 2.6.24.

If you wish to help testing the kvm component of the next Linux release, but without running a -rc kernel from kernel.org, you may use kvm-kmod-3.x-rcy, containing the code from Linux 3.x-rcy backported to run on older kernels. Feedback from running this release will help improve the kvm in the next kernel release.

For testing development snapshots, the kvm-kmod git repository can be cloned. See kvm-kmod README for detailed build instructions. Modules generated via this source don't correspond exactly to any Linux release, but instead use code from the kvm.git (the kvm development repository) at the point of their release. These are generally the most up-to-date modules.

In summary:

Release type Suitable for
Distribution provided Mainstream use; supported by distribution
kvm-kmod-2.6.x.y Running modern, stable kvm releases on older kernels
kvm-kmod-2.6.x-rcy Testing the next kvm-kmod-2.6.x.y release
kvm-kmod git Testing bleeding-edge development code