[libvirt] [PATCH] docs: add page describing goals for host platform version support
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..859b482428 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> + + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major 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 no 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 that what is described here. + </p> + + <h3>Linux OS</h3> + + <p> + For distributions with frequent, short-lifetime releases (Fedora, + Ubuntu, OpenSUSE, etc), the project will aim to support all versions + that are not end of life by their respective vendors. + </p> + + <p> + For distributions with long-lifetime releases (RHEL, Ubuntu LTS, + SLES, etc), 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. + </p> + + <h3>Windows</h3> + + <p> + The project supports building with current versions of the MinGW + toolchain, hosted on Linux. + </p> + + <h3>OS-X</h3> + + <p> + The project supports building with the current version of OS-X, + with the current homebrew package set available. + </p> + + <h3>FreeBSD</h3> + + <p> + 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. + </p> + + <h2>Virtualization platforms</h2> + + <p> + 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 upto 5 years, or until the vendor discontinues + support, whichever comes first. + </p> + + </body> +</html> -- 2.14.3
On Tue, Apr 03, 2018 at 03:56:11PM +0100, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..859b482428 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> + + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major 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 no listed here, it does not imply that libvirt
s/no/not/
+ 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 that what is described here. + </p> + + <h3>Linux OS</h3> + + <p> + For distributions with frequent, short-lifetime releases (Fedora, + Ubuntu, OpenSUSE, etc), the project will aim to support all versions + that are not end of life by their respective vendors. + </p> + + <p> + For distributions with long-lifetime releases (RHEL, Ubuntu LTS, + SLES, etc), 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. + </p> + + <h3>Windows</h3> + + <p> + The project supports building with current versions of the MinGW + toolchain, hosted on Linux. + </p> + + <h3>OS-X</h3> + + <p> + The project supports building with the current version of OS-X, + with the current homebrew package set available. + </p> + + <h3>FreeBSD</h3> + + <p> + 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. + </p> + + <h2>Virtualization platforms</h2> + + <p> + For hypervisor drivers which execute locally (QEMU, LXC, VZ,
s/ VZ,// or s/VZ/OpenVZ/ ?
+ 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 upto 5 years, or until the vendor discontinues + support, whichever comes first. + </p> + + </body> +</html> -- 2.14.3
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
On Tue, Apr 03, 2018 at 05:23:21PM +0200, Pavel Hrdina wrote:
On Tue, Apr 03, 2018 at 03:56:11PM +0100, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
+ <h3>FreeBSD</h3> + + <p> + 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. + </p> + + <h2>Virtualization platforms</h2> + + <p> + For hypervisor drivers which execute locally (QEMU, LXC, VZ,
s/ VZ,// or s/VZ/OpenVZ/ ?
Not sure I see why you want that ? The modern VZ driver is run locally in libvirtd, the same as QEMU, LXC, etc.
+ 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 upto 5 years, or until the vendor discontinues + support, whichever comes first. + </p> + + </body> +</html> -- 2.14.3
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Apr 05, 2018 at 10:54:53AM +0100, Daniel P. Berrangé wrote:
On Tue, Apr 03, 2018 at 05:23:21PM +0200, Pavel Hrdina wrote:
On Tue, Apr 03, 2018 at 03:56:11PM +0100, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
+ <h3>FreeBSD</h3> + + <p> + 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. + </p> + + <h2>Virtualization platforms</h2> + + <p> + For hypervisor drivers which execute locally (QEMU, LXC, VZ,
s/ VZ,// or s/VZ/OpenVZ/ ?
Not sure I see why you want that ? The modern VZ driver is run locally in libvirtd, the same as QEMU, LXC, etc.
Right, once I've read it again it actually make sense. I thought that it shouldn't be mentioned twice. Pavel
On Tue, 2018-04-03 at 15:56 +0100, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..859b482428 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml">;; + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> + + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major 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 no 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 that what is described here. + </p> + + <h3>Linux OS</h3> + + <p> + For distributions with frequent, short-lifetime releases (Fedora, + Ubuntu, OpenSUSE, etc), the project will aim to support all versions + that are not end of life by their respective vendors. + </p> + + <p> + For distributions with long-lifetime releases (RHEL, Ubuntu LTS, + SLES, etc), the project will aim to support the most recent major
I guess Debian should be added to the list?
+ version at all times. Support for the previous major version will + be dropped 2 years after the new major version is released. + </p> + + <h3>Windows</h3> + + <p> + The project supports building with current versions of the MinGW + toolchain, hosted on Linux. + </p> + + <h3>OS-X</h3>
s/OS-X/macOS/
+ + <p> + The project supports building with the current version of OS-X,
s/OS-X/macOS/
+ with the current homebrew package set available. + </p> + + <h3>FreeBSD</h3> + + <p> + The project will aim to support the most recent major version
s/will aim/aims/ ?
+ at all times. Support for the previous major version will + be dropped 2 years after the new major version is released. + </p> + + <h2>Virtualization platforms</h2> + + <p> + 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
s/VMWare/VMware/
+ support versions upto 5 years, or until the vendor discontinues
s/upto/up to/
+ support, whichever comes first. + </p> + + </body> +</html>
Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
On 04/03/2018 10:56 AM, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..859b482428 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> +> + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major 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 no 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 that what is described here. + </p> + + <h3>Linux OS</h3> + + <p> + For distributions with frequent, short-lifetime releases (Fedora, + Ubuntu, OpenSUSE, etc), the project will aim to support all versions + that are not end of life by their respective vendors. + </p> + + <p> + For distributions with long-lifetime releases (RHEL, Ubuntu LTS, + SLES, etc), 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. + </p> + + <h3>Windows</h3> + + <p> + The project supports building with current versions of the MinGW + toolchain, hosted on Linux. + </p> + + <h3>OS-X</h3> + + <p> + The project supports building with the current version of OS-X, + with the current homebrew package set available. + </p> + + <h3>FreeBSD</h3> + + <p> + 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. + </p> +
Could we add some sort of table where we could keep track of "known" and supported OS versions, what libvirt version was used, what QEMU version was used? <table class="top_table"> <tr> <th> OS Release </th> <th> QEMU Version </th> <th> libvirt Version </th> </tr> </table> I'm sure Red Hat folks could easily list the Fedora, RHEL, and CentOS versions... Probably need a few others to provide feedback on their particular host platform of choice. Once created it is a periodic maintenance task.
+ <h2>Virtualization platforms</h2> + + <p> + For hypervisor drivers which execute locally (QEMU, LXC, VZ,
Probably could add a link to https://libvirt.org/drivers.html for "hypervisor drivers"
+ 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.
The following feels like a new paragraph....
+ If a hypervisor is not commonly shipped directly by any distro + listed above, (VMWare ESX, HyperV, VZ), the project aims to + support versions upto 5 years, or until the vendor discontinues
up to
+ support, whichever comes first. + </p>
Again a table may be interesting here especially for those older ones that Martin noted without any change for quite a few years now. Possibly calls out that we need to perform a retirement ritual on some thing[s]. Perhaps a separate table listing when specific driver or a specific driver version support was removed from upstream. Essentially an easy way for someone to find it on some older branch. For these the table formats aren't as clear, but hypervisor drivers could have multiple row entries - one for each target OS platform. Something to make referencing history easier. John
+ + </body> +</html>
On Tuesday, 3 April 2018 18:28:46 CEST John Ferlan wrote:
Could we add some sort of table where we could keep track of "known" and supported OS versions, what libvirt version was used, what QEMU version was used?
Do you mean like what repology does? https://repology.org/metapackage/qemu/versions https://repology.org/metapackage/qemu-kvm/versions https://repology.org/metapackage/libvirt/versions It does not list commercial distributions though, but surely the status of RHEL is the same as CentOS. -- Pino Toscano
On Tue, Apr 03, 2018 at 06:35:06PM +0200, Pino Toscano wrote:
On Tuesday, 3 April 2018 18:28:46 CEST John Ferlan wrote:
Could we add some sort of table where we could keep track of "known" and supported OS versions, what libvirt version was used, what QEMU version was used?
Do you mean like what repology does? https://repology.org/metapackage/qemu/versions https://repology.org/metapackage/qemu-kvm/versions https://repology.org/metapackage/libvirt/versions
It does not list commercial distributions though, but surely the status of RHEL is the same as CentOS.
Ah yes, that's the site I was just looking for. We should just link to the relevant pages on that site rather than duplicating it. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Apr 03, 2018 at 12:28:46PM -0400, John Ferlan wrote:
On 04/03/2018 10:56 AM, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..859b482428 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> +> + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major 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 no 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 that what is described here. + </p> + + <h3>Linux OS</h3> + + <p> + For distributions with frequent, short-lifetime releases (Fedora, + Ubuntu, OpenSUSE, etc), the project will aim to support all versions + that are not end of life by their respective vendors. + </p> + + <p> + For distributions with long-lifetime releases (RHEL, Ubuntu LTS, + SLES, etc), 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. + </p> + + <h3>Windows</h3> + + <p> + The project supports building with current versions of the MinGW + toolchain, hosted on Linux. + </p> + + <h3>OS-X</h3> + + <p> + The project supports building with the current version of OS-X, + with the current homebrew package set available. + </p> + + <h3>FreeBSD</h3> + + <p> + 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. + </p> +
Could we add some sort of table where we could keep track of "known" and supported OS versions, what libvirt version was used, what QEMU version was used?
<table class="top_table"> <tr> <th> OS Release </th> <th> QEMU Version </th> <th> libvirt Version </th> </tr> </table>
I'm sure Red Hat folks could easily list the Fedora, RHEL, and CentOS versions... Probably need a few others to provide feedback on their particular host platform of choice.
Once created it is a periodic maintenance task.
Sure, we can do that - i wonder if it would be better served by a wiki page though ? I vaguely recall that there's a web site somewhere that actually lists software versions in various distros, but can't remember what it is now :-( Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Apr 03, 2018 at 15:56:11 +0100, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..859b482428 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> + + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major 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 no 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 that what is described here. + </p>
I think we should explicitly mention that we do not support possible downstream extensions or modifications to any 3rd party software used by libvirt. In other words, e.g., QEMU 0.12 was HMP-only upstream and thus libvirt will use HMP to talk to QEMU from RHEL-6 even though QMP support was backported to the downstream QEMU version. Of course, if a feature which can be properly detected by libvirt is backported to an earlier version, libvirt may be able to use it, although I'd still consider it unsupported in terms "don't file bug reports if it doesn't work, as long as it works with upstream QEMU". Jirka
participants (6)
-
Andrea Bolognani -
Daniel P. Berrangé -
Jiri Denemark -
John Ferlan -
Pavel Hrdina -
Pino Toscano