- Libvirt aims to support building and executing on multiple host OS - platforms, as well as working with multiple hypervisors. This document - outlines which platforms are targeted for each of these areas. -
- -- These platforms are used as the basis for deciding - upon the minimum required versions of 3rd party software libvirt depends - on. If a platform is not listed here, it does not imply that libvirt - won't work. If an unlisted platform has comparable software versions - to a listed platform, there is every expectation that it will work. - Bug reports are welcome for problems encountered on unlisted platforms - unless they are clearly older vintage than what is described here. -
- -- Note that when considering software versions shipped in distros as - support targets, libvirt considers only the version number, and assumes - the features in that distro match the upstream release with the same - version. In other words, if a distro backports extra features to the - software in their distro, libvirt upstream code will not add explicit - support for those backports, unless the feature is auto-detectable in - a manner that works for the upstream releases too. -
- -- The Repology site is a useful resource to identify currently shipped - versions of software in various operating systems, though it does not - cover all distros listed below. -
- - - - -- For distributions with frequent, short-lifetime releases, the project - will aim to support all versions that are not end of life by their - respective vendors. For the purposes of identifying supported software - versions, the project will look at Fedora, Ubuntu, and openSUSE distros. - Other short-lifetime distros will be assumed to ship similar software - versions. -
- -- For distributions with long-lifetime releases, the project will aim to - support the most recent major version at all times. Support for the - previous major version will be dropped 2 years after the new major - version is released. For the purposes of identifying supported software - versions, the project will look at RHEL, Debian, Ubuntu LTS, and SLES - distros. Other long-lifetime distros will be assumed to ship similar - software versions. -
- -- The project supports building with current versions of the MinGW - toolchain, hosted on Linux. -
- -- The project aims to support the most recent major version - at all times. Support for the previous major version will - be dropped 2 years after the new major version is released. -
- -- Note that to compile libvirt will require extra packages - to be made available on the macOS host. It is recommended - to use HomeBrew since this - is what libvirt CI tests with, however, MacPorts - is an alternative option that is likely to work. -
- -- The project aims to support the most recent major version - at all times. Support for the previous major version will - be dropped 2 years after the new major version is released. -
- -- For hypervisor drivers which execute - locally (QEMU, LXC, VZ, libxl, etc), the set of supported operating - system platforms listed above will inform choices as to the minimum - required versions of 3rd party libraries and hypervisor management - APIs. -
-- If a hypervisor is not commonly shipped directly by any distro - listed above, (VMware ESX, HyperV, VZ), the project aims to - support versions up to 5 years, or until the vendor discontinues - support, whichever comes first. -
- - - diff --git a/docs/platforms.rst b/docs/platforms.rst new file mode 100644 index 0000000000..2845ac40ea --- /dev/null +++ b/docs/platforms.rst @@ -0,0 +1,100 @@ +======================== +Supported host platforms +======================== + +.. contents:: + +Libvirt aims to support building and executing on multiple host OS platforms, +as well as working with multiple hypervisors. This document outlines which +platforms are targeted for each of these areas. + + +Build targets +============= + +These platforms are used as the basis for deciding upon the minimum required +versions of 3rd party software libvirt depends on. If a platform is not listed +here, it does not imply that libvirt won't work. If an unlisted platform has +comparable software versions to a listed platform, there is every expectation +that it will work. Bug reports are welcome for problems encountered on +unlisted platforms unless they are clearly older vintage than what is described +here. + +Note that when considering software versions shipped in distros as support +targets, libvirt considers only the version number, and assumes the features in +that distro match the upstream release with the same version. In other words, +if a distro backports extra features to the software in their distro, libvirt +upstream code will not add explicit support for those backports, unless the +feature is auto-detectable in a manner that works for the upstream releases +too. + +The `Repology`_ site is a useful resource to identify currently shipped +versions of software in various operating systems, though it does not cover all +distros listed below. + +* `libvirt on Repology`_ +* `qemu on Repology`_ +* `qemu-kvm on Repology`_ + +Linux OS +-------- + +For distributions with frequent, short-lifetime releases, the project will aim +to support all versions that are not end of life by their respective vendors. +For the purposes of identifying supported software versions, the project will +look at Fedora, Ubuntu, and openSUSE distros. Other short-lifetime distros +will be assumed to ship similar software versions. + +For distributions with long-lifetime releases, the project will aim to support +the most recent major version at all times. Support for the previous major +version will be dropped 2 years after the new major version is released. For +the purposes of identifying supported software versions, the project will look +at RHEL, Debian, Ubuntu LTS, and SLES distros. Other long-lifetime distros will +be assumed to ship similar software versions. + +Windows +------- + +The project supports building with current versions of the MinGW toolchain, +hosted on Linux. + +macOS +----- + +The project aims to support the most recent major version at all times. Support +for the previous major version will be dropped 2 years after the new major +version is released. + +Note that to compile libvirt will require extra packages to be made available +on the macOS host. It is recommended to use `HomeBrew`_ since this is what +libvirt CI tests with, however, `MacPorts`_ is an alternative option that is +likely to work. + +FreeBSD +------- + +The project aims to support the most recent major version at all times. Support +for the previous major version will be dropped 2 years after the new major +version is released. + + +Virtualization platforms +======================== + +For `hypervisor drivers`_ which execute locally (QEMU, LXC, VZ, libxl, etc), +the set of supported operating system platforms listed above will inform +choices as to the minimum required versions of 3rd party libraries and +hypervisor management APIs. + +If a hypervisor is not commonly shipped directly by any distro listed above, +(VMware ESX, HyperV, VZ), the project aims to support versions up to 5 years, +or until the vendor discontinues support, whichever comes first. + + +.. _HomeBrew: https://brew.sh/ +.. _MacPorts: https://www.macports.org/ +.. _Repology: https://repology.org/ +.. _hypervisor drivers: drivers.html +.. _libvirt on Repology: https://repology.org/metapackage/libvirt/versions +.. _qemu on Repology: https://repology.org/metapackage/qemu/versions +.. _qemu-kvm on Repology: https://repology.org/metapackage/qemu-kvm/versions