OpenStack - User contributions [en]

LibvirtDistroSupportMatrix

2016-09-27T17:11:34Z

Daniel Berrange: /* Nova release min version */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Pike
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! GA date
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Jessie
| 2015-04-25
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 23
| 2015-11-03
| 1.2.18
| 2.4.0
| 1.30.1

|-
| 24
| 2016-06-21
| 1.3.3
| 2.6.0
| 1.33.30

|-
! openSUSE !! !!

|-
| 13.2
|
| 1.2.9
| 2.1.0
| 1.26.9

|-
| Leap 42.1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Oracle Linux !! !!

|-
| 7
|
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 7.1
|
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
|
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 12
|
| 1.2.5
| 2.0.2
| 1.26.9

|-
| 12SP1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
|
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
|
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-09-27T17:04:55Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! GA date
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Jessie
| 2015-04-25
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 23
| 2015-11-03
| 1.2.18
| 2.4.0
| 1.30.1

|-
| 24
| 2016-06-21
| 1.3.3
| 2.6.0
| 1.33.30

|-
! openSUSE !! !!

|-
| 13.2
|
| 1.2.9
| 2.1.0
| 1.26.9

|-
| Leap 42.1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Oracle Linux !! !!

|-
| 7
|
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 7.1
|
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
|
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 12
|
| 1.2.5
| 2.0.2
| 1.26.9

|-
| 12SP1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
|
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
|
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-09-27T16:58:23Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! GA date
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy-backports
|
| 1.2.1
| 1.7.0

|-
| Jessie
| 2015-04-25
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 23
| 2015-11-03
| 1.2.18
| 2.4.0
| 1.30.1

|-
| 24
| 2016-06-21
| 1.3.3
| 2.6.0
| 1.33.30

|-
! openSUSE !! !!

|-
| 13.2
|
| 1.2.9
| 2.1.0
| 1.26.9

|-
| Leap 42.1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Oracle Linux !! !!

|-
| 7
|
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 7.1
|
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
|
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 12
|
| 1.2.5
| 2.0.2
| 1.26.9

|-
| 12SP1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
|
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
|
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-09-27T16:57:45Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! GA date
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy-backports
|
| 1.2.1
| 1.7.0

|-
| Jessie
| 2015-04-25
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 23
| 2015-11-03
| 1.2.18
| 2.4.0
| 1.30.1

|-
| 24
| 2016-06-21
| 1.3.3
| 2.6.0
| 1.33.30

|-
! openSUSE !! !!

|-
| 13.2
|
| 1.2.9
| 2.1.0
| 1.26.9

|-
| Leap 42.1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Oracle Linux !! !!

|-
| 7
|
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 7.1
|
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
|
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
|
| 1.0.5
| 1.4.2

|-
| 12
|
| 1.2.5
| 2.0.2
| 1.26.9

|-
| 12SP1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
|
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
|
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-09-27T16:56:40Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! GA date
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 2013-05-04
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
|
| 1.2.1
| 1.7.0

|-
| Jessie
| 2015-04-25
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 23
| 2015-11-03
| 1.2.18
| 2.4.0
| 1.30.1

|-
| 24
| 2016-06-21
| 1.3.3
| 2.6.0
| 1.33.30

|-
! openSUSE !! !!

|-
| 13.2
|
| 1.2.9
| 2.1.0
| 1.26.9

|-
| Leap 42.1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Oracle Linux !! !!

|-
| 7
|
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
|
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
|
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
|
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
|
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
|
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
|
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
|
| 1.0.5
| 1.4.2

|-
| 12
|
| 1.2.5
| 2.0.2
| 1.26.9

|-
| 12SP1
|
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
|
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
|
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-09-27T16:46:30Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
|24
|1.3.3
|2.6.0
|1.33.30

|-
! openSUSE !! !!

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
| Leap 42.1
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2
| 1.26.9

|-
| 12SP1
| 1.2.18
| 2.3.1
| 1.26.10

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-04-29T15:24:33Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 2.1.2
| 1.28.1

|-
| 7.2
| 1.2.17
| 2.3.0
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 16.04 (Xenial LTS)
| 1.3.1
| 2.5.0
| 1.32.2
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

NB2: RHEL versions of QEMU refer to the qemu-kvm-rhev RPM, '''not''' the qemu-kvm RPM, since the former is what is intended for use with OpenStack

LibvirtDistroSupportMatrix

2016-04-25T18:57:54Z

Daniel Berrange: /* Libvirt min version change policy */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== QEMU min version change policy ===

After deciding the minimum libvirt version, the minimum QEMU version is determined by looking for the lowest QEMU version from all the distros that support the decided libvirt version

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2016-04-25T18:56:27Z

Daniel Berrange: /* Nova release min version */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt
! Current min QEMU
! Next min QEMU

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Newton
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|-
! Ocata
| 1.2.1
| 1.2.1
| 1.5.3
| 1.5.3

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

Sprints/NovaMitakaSprintAttendees

2016-01-15T09:18:28Z

Daniel Berrange:

Nova Mitaka Midcycle List of Attendees

Please add yourself to the following list of attendees to help us with logistics and maybe also help you find each other. Adding yourself to the list is completely optional.

{| class="wikitable"
|+ List of attendees
! Name
! Hotel
! Arrive
! Leave
! has car
! if you want to contact me
|-
| Paul Murray || none (local) || already here || not leaving || yes || pmurray@hpe.com
|-
| Augustina Ragwitz || Holiday Inn || Sunday || Saturday || No || augustina.ragwitz@hpe.com
|-
| Andrew James || Holiday Inn || Sunday || Friday || No || ajames@hpe.com
|-
| Carl Baldwin || Holiday Inn || Monday night || Friday || No || (see gerrit)
|-
| The Leaky Pipes || Holiday Inn || Monday night || Thursday evening || No || jaypipes@gmail.com
|-
| Matt Riedemann || Holiday Inn || Monday || Friday || No || (see gerrit)
|-
| Matthew Treinish || Holiday Inn || Monday night || Friday || Yes || mtreinish@kortar.org
|-
| Andrew Laski || Holiday Inn || Sunday || Thursday evening || No || alaski@gmail.com
|-
| Sean Dague || Holiday Inn || Tues Morning || Saturday || No || sean@dague.net
|-
| Sylvain Bauza || Holiday Inn || Monday afternoon || Friday morning || Yes || sbauza CHEZ free POINT fr (translate Eng.)
|-
| Tony Breeds || Holiday Inn || Sunday night || Thursday afternoon || Yes || tony@bakeyournoodle.com
|-
| Daniel Berrange || Holiday Inn || Monday night || Thursday aftenoon || no || Use the force
|-}

LibvirtDistroSupportMatrix

2015-12-18T16:30:43Z

Daniel Berrange: /* Nova release min version */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|-
! Nxxxx
| 1.2.1
| TBD

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-12-18T16:30:26Z

Daniel Berrange: /* Nova release min version */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been listed in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

There is more background on the rationale used for picking minimum versions in the operators mailing list thread here:

http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.2.1

|- Nxxxx
| 1.2.1
| TBD

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-10-07T10:49:14Z

Daniel Berrange: /* Nova release min version */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been lsited in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 1.1.1 (TBC)

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-10-07T10:10:07Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been lsited in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 0.10.2

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-10-07T10:08:34Z

Daniel Berrange: /* Nova release min version */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been lsited in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt

|-
! Havana
| 0.9.6
| 0.9.6

|-
! Icehouse
| 0.9.6
| 0.9.11

|-
! Juno
| 0.9.11
| 0.9.11

|-
! Kilo
| 0.9.11
| 0.9.11

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 0.10.2

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (Precise LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-10-07T10:02:54Z

Daniel Berrange: /* Libvirt OS distribution support matrix */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been lsited in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

=== Nova release min version ===

{| class="wikitable"
|-
! Nova version
! Current min libvirt
! Next min libvirt

|-
! Liberty
| 0.9.11
| 0.10.2

|-
! Mitaka
| 0.10.2
| 0.10.2

|}

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (Precise LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-10-07T09:57:47Z

Daniel Berrange: /* Distro minimum versions */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been lsited in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

When NEXT_MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be changed to have <strike>strikethrough</strike> format.

When MIN_LIBVIRT_VERSION is updated, any distros which don't meet that version should be deleted from this table

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (Precise LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-10-07T09:55:26Z

Daniel Berrange: /* Libvirt OS distribution support matrix */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with.

=== Libvirt min version change policy ===

At the start of each Nova development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise undesired distro versions. Based on this distro evaluation, it may be possible to increase the min required version of libvirt in Nova, and thus drop some compatibility code for older versions.

When a decision to update the minimum required libvirt version is made, there must be a warning issued for one cycle. This is achieved by editting nova/virt/libvirt/driver.py to set

NEXT_MIN_LIBVIRT_VESION = (X, Y, Z)

This causes a deprecation warning to be printed when Nova starts up warning the admin that the version of libvirt they are on will be dropped in the subsequent release.

After a version has been lsited in NEXT_MIN_LIBVIRT_VERSION for one release cycle, the corresponding actual min required libvirt can be updated by setting

MIN_LIBVIRT_VESION = (X, Y, Z)

At this point of course, an even newer version might be set in NEXT_MIN_LIBVIRT_VERSION to repeat the process....

=== Distro minimum versions ===

This table provides information on a representative sample of OS distros and the version of libirt/qemu/libguestfs that they ship. This is *NOT* intended to be an exhaustive list of distros where OpenStack Nova can run - it is intended to run on any Linux distro which can satisfy the minimum required software versions. This table merely aims to help identify when min required versions can be reasonably updated without loosing support for important OS distros.

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
|23
|1.2.18
|2.4.0
|1.30.1

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (Precise LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtAPI

2015-09-25T09:04:16Z

Daniel Berrange: Deleted all content.

= Libvirt API =

The content previously on his page was incredibly outdated and misleading. If you really need to view it, please consult the history for this page.

LibvirtVIFTypeXMLConfigs

2015-06-24T16:28:40Z

Daniel Berrange: /* Consolidated XML configs needed */

=Libvirt VIF Type XML configuration=

This document outlines the way the LibvirtGenericVIFDriver configures networking in Liberty-1 development tree, and also looks at a few proposed new VIF types

== Current configuration ==

=== Common configuration===

A number of aspects of the guest interface configuration are common to all VIF types, though some types do have restrictions on valid values. For example. VIF_TYPE_VHOSTUSER requires a model of virtio.

<nowiki><interface type="...">
<mac address="01:02:ab:de:03:04"/>
<model type="virtio|e1000|...."/>
<driver name="vhost|qemu"/>
<bandwidth>
....QOS settings...
</bandwidth>
</interface></nowiki>

=== VIF_TYPE_OVS ===

Primary method:

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<portprofile type="openvswitch">
<parameters
interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'
profileid="something"/>
</portprofie>
</interface></nowiki>

Or if firewall filtering is needed, it uses

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<filterref name="nwfilter"/>
</interface></nowiki>

=== VIF_TYPE_IVS ===

Either

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

Or if firewall filtering is needed, it uses

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_DVS ===

VMWare specific, not used by libvirt

=== VIF_TYPE_IOVISOR ===

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_BRIDGE ===

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<filterref name="nwfilter"/>
</interface></nowiki>

=== VIF_TYPE_802_QBG ===

<nowiki><interface type="direct">
<source dev="eth0">
<portprofile type="802.1qbg">
<parameters
managerid="11"
typeid="1193047"
typeidversion="2"
instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/>
</portprofile>
</interface></nowiki>

=== VIF_TYPE_802_QBH ===

<nowiki><interface type="direct">
<source dev="eth0" mode="vepa">
<portprofile type="802.1qbh">
<parameters profileid="manager"/>
</portprofile>
</interface></nowiki>

=== VIF_TYPE_HW_VEB ===

<nowiki><interface type="direct">
<source dev="eth0" mode="passthrough">
</interface></nowiki>

Or

<nowiki><interface type="hostdev">
<source dev="00:02:10.2"/>
<vlan>3</vlan>
</interface></nowiki>

=== VIF_TYPE_MLNX_DIRECT ===

<nowiki><interface type="direct">
<source dev="eth0" mode="passthrough">
</interface></nowiki>

=== VIF_TYPE_MIDONET ===

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_VHOSTUSER ===

<nowiki><interface type="vhostuser">
<source type="unix" path="/some/sock" mode="0775"/>
</interface></nowiki>

=== VIF_TYPE_VROUTER ===

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_OTHER ===

Dummy placeholder, not used by libvirt.

=== Proposed: VIF_TYPE_MACVTAP ===

<nowiki><interface type='direct'>
<source dev='eth0' mode=’vepa|bridge’/>
</interface></nowiki>

== Consolidated XML configs needed ==

Based on what is implemented in existing VIF types and proposed VIF types, it is possible to consoldiate to a limited set of libvirt variants

In fact out of the 15 different VIF types, there are only ultimately 5 distinct libvirt guest configurations used

=== VIF_TYPE_BRIDGE ===

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<filterref name="nwfilter"/>
<vportprofile>
....
</portprofile>
</interface></nowiki>

=== VIF_TYPE_GENERIC ===

A standalone TAP dev, that is connected to host in unspecified manner

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_VHOSTUSER ===

<nowiki><interface type="vhostuser">
<source type="unix" path="/some/sock" mode="0775"/>
</interface></nowiki>

=== VIF_TYPE_PCI_ASSIGNED ===

<nowiki><interface type="hostdev">
<source dev="00:02:10.2"/>
<vlan>3</vlan>
</interface></nowiki>

=== VIF_TYPE_DIRECT ===

<nowiki><interface type='direct'>
<source dev='eth0' mode=’vepa|bridge|passthrough’/>
<vportprofile>
....
</portprofile>
</interface></nowiki>

As an alternative to specifying a 'mode' it might be desirable to have separate VIF types VIF_TYPE_VEPA, VIF_TYPE_PASSTHROUGH, VIF_TYPE_DEV_BRIDGE

LibvirtVIFTypeXMLConfigs

2015-06-24T15:04:17Z

Daniel Berrange:

=Libvirt VIF Type XML configuration=

This document outlines the way the LibvirtGenericVIFDriver configures networking in Liberty-1 development tree, and also looks at a few proposed new VIF types

== Current configuration ==

=== Common configuration===

A number of aspects of the guest interface configuration are common to all VIF types, though some types do have restrictions on valid values. For example. VIF_TYPE_VHOSTUSER requires a model of virtio.

<nowiki><interface type="...">
<mac address="01:02:ab:de:03:04"/>
<model type="virtio|e1000|...."/>
<driver name="vhost|qemu"/>
<bandwidth>
....QOS settings...
</bandwidth>
</interface></nowiki>

=== VIF_TYPE_OVS ===

Primary method:

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<portprofile type="openvswitch">
<parameters
interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'
profileid="something"/>
</portprofie>
</interface></nowiki>

Or if firewall filtering is needed, it uses

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<filterref name="nwfilter"/>
</interface></nowiki>

=== VIF_TYPE_IVS ===

Either

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

Or if firewall filtering is needed, it uses

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_DVS ===

VMWare specific, not used by libvirt

=== VIF_TYPE_IOVISOR ===

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_BRIDGE ===

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<filterref name="nwfilter"/>
</interface></nowiki>

=== VIF_TYPE_802_QBG ===

<nowiki><interface type="direct">
<source dev="eth0">
<portprofile type="802.1qbg">
<parameters
managerid="11"
typeid="1193047"
typeidversion="2"
instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/>
</portprofile>
</interface></nowiki>

=== VIF_TYPE_802_QBH ===

<nowiki><interface type="direct">
<source dev="eth0" mode="vepa">
<portprofile type="802.1qbh">
<parameters profileid="manager"/>
</portprofile>
</interface></nowiki>

=== VIF_TYPE_HW_VEB ===

<nowiki><interface type="direct">
<source dev="eth0" mode="passthrough">
</interface></nowiki>

Or

<nowiki><interface type="hostdev">
<source dev="00:02:10.2"/>
<vlan>3</vlan>
</interface></nowiki>

=== VIF_TYPE_MLNX_DIRECT ===

<nowiki><interface type="direct">
<source dev="eth0" mode="passthrough">
</interface></nowiki>

=== VIF_TYPE_MIDONET ===

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_VHOSTUSER ===

<nowiki><interface type="vhostuser">
<source type="unix" path="/some/sock" mode="0775"/>
</interface></nowiki>

=== VIF_TYPE_VROUTER ===

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_OTHER ===

Dummy placeholder, not used by libvirt.

=== Proposed: VIF_TYPE_MACVTAP ===

<nowiki><interface type='direct'>
<source dev='eth0' mode=’vepa|bridge’/>
</interface></nowiki>

== Consolidated XML configs needed ==

Based on what is implemented in existing VIF types and proposed VIF types, it is possible to consoldiate to a limited set of libvirt variants

=== VIF_TYPE_BRIDGE ===

<nowiki><interface type="bridge">
<source bridge="br0"/>
<target dev="vnet0"/>
<filterref name="nwfilter"/>
<vportprofile>
....
</portprofile>
</interface></nowiki>

=== VIF_TYPE_GENERIC ===

A standalone TAP dev, that is connected to host in unspecified manner

<nowiki><interface type="ethernet">
<target dev="vnet0"/>
</interface></nowiki>

=== VIF_TYPE_VHOSTUSER ===

<nowiki><interface type="vhostuser">
<source type="unix" path="/some/sock" mode="0775"/>
</interface></nowiki>

=== VIF_TYPE_PCI_ASSIGNED ===

<nowiki><interface type="hostdev">
<source dev="00:02:10.2"/>
<vlan>3</vlan>
</interface></nowiki>

=== VIF_TYPE_DIRECT ===

<nowiki><interface type='direct'>
<source dev='eth0' mode=’vepa|bridge|passthrough’/>
<vportprofile>
....
</portprofile>
</interface></nowiki>

As an alternative to specifying a 'mode' it might be desirable to have separate VIF types VIF_TYPE_VEPA, VIF_TYPE_PASSTHROUGH, VIF_TYPE_DEV_BRIDGE

LibvirtVIFTypeXMLConfigs

2015-06-24T14:51:08Z

Daniel Berrange:

LibvirtVIFTypeXMLConfigs

2015-06-24T14:49:49Z

Daniel Berrange: /* VIF_TYPE_BRIDGE */

LibvirtVIFTypeXMLConfigs

2015-06-24T14:49:29Z

Daniel Berrange: /* VIF_TYPE_IVS */

LibvirtVIFTypeXMLConfigs

2015-06-24T14:49:05Z

Daniel Berrange: /* VIF_TYPE_OVS */

LibvirtVIFTypeXMLConfigs

2015-06-24T14:47:27Z

Daniel Berrange: Created page with "=Libvirt VIF Type XML configuration= This document outlines the way the LibvirtGenericVIFDriver configures networking in Liberty-1 development tree, and also looks at a few p..."

LibvirtDistroSupportMatrix

2015-05-15T10:57:53Z

Daniel Berrange:

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (Precise LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 14.04 (Trusty LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10 (Utopic)
| 1.2.8
| 2.1.0
| 1.26.7

|-
| 15.04 (Vivid)
| 1.2.12
| 2.2.0
| 1.28.6

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-05-15T10:10:55Z

Daniel Berrange:

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
| 1.18.1

|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
| Jessie
| 1.2.9
| 2.1.0
| 1.28.1

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 12.10
| 0.9.13
| 1.2.0

|-
| 13.04
| 1.0.2
| 1.4.0
| 1.18.10

|-
| 13.10
| 1.1.1
| 1.5.0
| 1.22.4

|-
| 14.04 (LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10
| 1.2.8
| 2.1.0
| 1.26.7
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2015-05-15T10:08:21Z

Daniel Berrange:

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
! Fedora !! !!

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
|22
|1.2.13
|2.3.0
|1.29.38

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
| 13.2
| 1.2.9
| 2.1.0
| 1.26.9

|-
! Oracle Linux !! !!

|-
| 7
| 1.2.8
| 1.5.3
| 1.28.1

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2

|-
| 12
| 1.2.5
| 2.0.2

|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 12.10
| 0.9.13
| 1.2.0

|-
| 13.04
| 1.0.2
| 1.4.0
| 1.18.10

|-
| 13.10
| 1.1.1
| 1.5.0
| 1.22.4

|-
| 14.04 (LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|-
| 14.10
| 1.2.8
| 2.1.0
| 1.26.7
|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

Meetings/Nova

2015-02-05T14:20:05Z

Daniel Berrange: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

== Agenda for next meeting ==

Scheduled for:
* February 5th 2015 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150205T140000)

Add your IRC nick to this list to be pinged at the start of the meeting: <code>abhishekk mikal tjones cburgess jgrimm adrian_otto funzo mjturek jcook ekhugen irina_pov krtaylor danpb alexpilotti flip214 raildo jaypipes gilliard garyk edleafe dims moshele anteaya Nisha claudiub lxsli neiljerram markus_ swamireddy z</code>

* Kilo Release Status
** 2/5: https://wiki.openstack.org/wiki/FeatureFreeze
** confirm exception process, aiming for zero exceptions
** at least until we have some
* Kilo Priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
** Nova-net to Neutron Migration (anteaya or jogo to report)
** We need to remember to pay attention to the priority reviews etherpad, we've drifted off a little
* Gate status
** http://status.openstack.org/elastic-recheck/gate.html
* Bugs
** hit list: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
** [https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1266262,n,z Ext4 as default ephemeral disk]
** [https://review.openstack.org/#/c/141883/ fix AggregateTypeAffinityFilter multi values support]
** [https://review.openstack.org/#/c/153230 Baremetal ports cannot be mapped to networks]
* Stuck reviews
** https://review.openstack.org/#/c/134153/ Connecting Nova to DRBD storage nodes directly. [flip214]
** https://review.openstack.org/#/c/134499/ Don't assume contents of values after aggregate_update
** https://review.openstack.org/#/c/146914/ Add new VIF type VIF_TYPE_TAP
** https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:virtimageinfo,n,z Fix file injection with RBD (https://bugs.launchpad.net/nova/+bug/1257674)
** https://review.openstack.org/#/c/138444/ Isolate Scheduler DB for Instances (spec exception review) - need follow-up review with changes from mid-cycle discussion
** https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/libvirt-kvm-systemz,n,z ''system z'' items [markus_z]
** https://review.openstack.org/#/q/topic:bp/libvirt-vif-vhost-user,n,z Libvirt: Support for vhostuser vif. [pczesno]
* Open discussion
** Feature matrix - http://docs-draft.openstack.org/80/136380/7/check/gate-nova-docs/28be8b3//doc/build/html/support-matrix.html (sdague) - is merged now
*** We should decide if the matrix data is fine, or if we need reviews to address it
*** http://lists.openstack.org/pipermail/openstack-dev/2015-February/056093.html
** Kilo meetup debrief: https://etherpad.openstack.org/p/kilo-nova-midcycle
** Spec discussion - https://review.openstack.org/#/c/147882 (rushiagr, swamireddy)
** ?

=== Sub-teams ===

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-16-21.01.html 2012-08-16]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-09-21.00.html 2012-08-09]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-21.40.html 2012-08-02]

[[category: compute]]
[[category: teams]]

HypervisorSupportMatrix

2015-02-05T10:52:59Z

Daniel Berrange: /* Features */

= Compute Drivers =

OpenStack Compute (Nova) has an abstraction layer for compute drivers. This is what allows you to choose which hypervisor(s) to use for your Nova deployment. The reality is that the support of each of the options is not equal. They are not tested the same amount. They also do not all support the same features. The purpose of this page is to describe the current support state of each compute driver in terms of testing and functionality.

== Driver Testing Status ==

=== Group A ===

These drivers are fully supported. Test coverage includes:
* unit tests that gate commits
* functional testing that gate commits

Drivers in this group include:
* libvirt (qemu/KVM on x86)

=== Group B ===

These drivers are in a bit of a middle ground. Test coverage includes:
* unit tests that gate commits
* functional testing providing by an external system that does not gate commits, but advises patch authors and reviewers of results in gerrit (the code review system).

Drivers in this group include:
* [http://wiki.cloudbase.it/hyperv-tempest-exclusions Hyper-V]
* [[NovaVMware/Minesweeper| VMware]]
* [[XenServer/XenServer_CI | XenServer 6.2]]

=== Group C ===

'''NOTE:''' Drivers in Group C will be deprecated by the Icehouse release. See [[HypervisorSupportMatrix/DeprecationPlan]] for details.

These drivers have minimal testing and may or may not work at any given time. Use them at your own risk. Test coverage includes:
* (maybe) unit tests that gate commits
* no public functional testing

Drivers in this group include.
* baremetal
* docker
* Xen via libvirt
* LXC via libvirt

== Hypervisor feature support matrix ==

This is an attempt to help new users decide on a hypervisor based on features that can be controlled through compute.

Historically, most [[OpenStack]] development is done with the KVM hypervisor with which you are more likely to find community support for issues . All features that are currently supported in KVM are also supported in QEMU.

[http://technet.microsoft.com/en-US/library/hh833684.aspx Microsoft Hyper-V] and VMware ESXi are gaining much support with Hyper-V now being available with a [http://windowsitpro.com/hyper-v/microsoft-free-hyper-v-server-2012-features free license]. ESXi can also be used with a free license however API support is limited as READ ONLY without vCenter and an Enterprise license.

As far as the [[Xen]] hypervisor is concerned, it is worth noting the following definitions:
* [[XenServer]]: Open Source but commercially supported product from Citrix (Free edition also available)
* Xen Cloud Platform (XCP): Open-source equivalent of [[XenServer]] (and the development project for the toolstack). Everything said about [[XenServer]] below applies equally to XCP.
* XenAPI: The management API exposed by [[XenServer]] and XCP.
* XAPI: The primary daemon on [[XenServer]] and Xen Cloud Platform; the one that exposes the XenAPI.
* [[Xen/Libvirt|Xen via Libvirt]]: Xen hypervisor management using the libvirt Xen driver.

Nova has support for [[XenServer]] and XCP through the XenAPI virt layer. Note that this does not imply support for other Xen-based platforms such as those shipped with RHEL 6 or SUSE, which is provided via the libvirt layer (i.e. Xen via libvirt).

As far as the [[Baremetal]] hypervisor is concerned, it is worth noting that [[Ironic]] will deprecate the baremetal driver upon its graduation. New features are being added to [[Ironic]].

Please help keep this list up-to-date.

'''Legend''': ✔ indicates support, ✗ indicates the feature is not supported, * indicates there is a caveat to the functionality (caveats need to be documented!), and a blank cell generally indicates more testing is needed to make a judgment.

=== Features ===

'''WARNING This table is no longer considered to be the canonical source of information about driver support status. For Kilo releases onwards, please consult the new [http://docs.openstack.org/developer/nova/support-matrix.html Nova Hypervisor Support Matrix]'''

{| border="1" cellpadding="2" cellspacing="0"
| '''Feature'''
| '''[[XenServer|XenServer/XCP]] '''
| '''[http://libvirt.org/drvqemu.html KVM/libvirt on (x86)]'''
| '''[http://libvirt.org/drvqemu.html QEMU/libvirt (x86)]'''
| '''[http://libvirt.org/drvlxc.html LXC/libvirt]'''
| '''[http://libvirt.org/drvxen.html Xen/Libvirt]'''
| '''[http://docs.openstack.org/trunk/config-reference/content/vmware.html VMware]'''
| '''[[Hyper-V]]'''
| '''[[Baremetal]]'''
| '''[[Ironic]]'''
| '''[http://www.docker.io Docker]'''
| '''[http://www.ibm.com/systems/power/software/linux/powerlinux/powerkvm PowerKVM]'''
|-
| Launch
| ✔
| ✔
| ✔
| ✔
| ✔ *(12)
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
|-
| Reboot
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔*(11)
| ✔
| ✔
|-
| Terminate
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
|-
| Resize
| ✔
| ✔
| ✔
|
| ✔
| ✔
| ✔
| * (15)
| * (15)
| style="color: red" | ✗
| ✔
|-
| Rescue
| ✔
| ✔
| ✔
|
|
| ✔
|
| style="color: red" | ✗
|
| style="color: red" | ✗
| ✔
|-
| Pause
| ✔
| ✔
| ✔
|
| ✔
| style="color: red" | ✗
| ✔
| * (15)
| * (15)
| ✔
| ✔
|-
| Un-pause
| ✔
| ✔
| ✔
|
| ✔
| style="color: red" | ✗
| ✔
| * (15)
| * (15)
| ✔
| ✔
|-
| Suspend
| ✔
| ✔
| ✔
|
| ✔
| ✔
| ✔
| * (15)
| * (15)
| style="color: red" | ✗
| ✔
|-
| Resume
| ✔
| ✔
| ✔
|
| ✔
| ✔
| ✔
| * (15)
| * (15)
| style="color: red" | ✗
| ✔
|-
| Inject Networking
| ✔*(1)(2)
| ✔*(1)
| ✔*(1)
|
|
| ✔*
| ✔
| style="color: red" | ✗
| style="color: red" | ✗
|
|
|-
| Inject File
| ✔
| ✔*
| ✔*
|
|
|
| style="color: red" | ✗*(6)
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
|
|-
| Serial Console Output
| ✔(4)
| ✔
| ✔
| style="color: red" | ✗
|
| ✔
| ✔
|
|
| ✔
|
|-
| VNC Console
| ✔*
| ✔*
| ✔*
| ✔
|
| ✔
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
|
|-
| SPICE Console
| style="color: red" | ✗
| ✔
| ✔
|
|
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
|-
| RDP Console
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| ✔
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
|
|-
| Attach Volume
| ✔
| ✔
| ✔
| style="color: red" | ✗
| ✔
| ✔
| ✔
|
|
| style="color: red" | ✗
| ✔
|-
| Detach Volume
| ✔
| ✔
| ✔
| style="color: red" | ✗
| ✔
| ✔
| ✔
|
|
| style="color: red" | ✗
| ✔
|-
| Live Migration
| ✔
| ✔
| ✔
|
| ✔
| style="color: red" | ✗ (10)
| ✔
| * (15)
| * (15)
| style="color: red" | ✗
| ✔
|-
| Snapshot
| ✔
| ✔
| ✔
|
| ✔ * (13)
| ✔
| ✔
| * (15)
| * (15)
| ✔
| ✔
|-
| iSCSI
| ✔
| ✔
| ✔
|
|
| ✔
| ✔
|
|
|
| ✔
|-
| iSCSI CHAP
| ✔
| ✔
| ✔
|
|
|
| ✔
|
|
|
| ✔
|-
| Fibre Channel
| style="color: red" | ✗
| ✔
| ✔
|
|
|
|
|
|
|
| ✔
|-
| Set Admin Pass
| ✔
| style="color: red" | ✗
| style="color: red" | ✗
|
|
| style="color: red" | ✗
| style="color: red" | ✗*(6)
| * (15)
| * (15)
| style="color: red" | ✗
|
|-
| Get Guest Info
| ✔
| ✔
| ✔
|
|
| ✔
| ✔
|
|
| ✔
| ✔
|-
| Get Host Info
| ✔
| ✔
| ✔
|
|
| ✔
| ✔
|
|
| ✔
| ✔
|-
| Glance Integration
| ✔
| ✔
| ✔
|
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
|-
| Service Control
| ✔
| ✔
| ✔
|
|
| ✔
| ✔
|
|
|
| ✔
|-
| VLAN Networking
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| style="color: red" | ✗*(7)
| style="color: red" | ✗
| style="color: red" | ✗*(16)
|
| ✔
|-
| Flat Networking
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
|-
| Security Groups
| ✔
| ✔
| ✔
| ✔
| ✔
| style="color: red" | ✗*(9)
| style="color: red" | ✗*(7)
|
|
| ✔
| ✔
|-
| Firewall Rules
| ✔
| ✔
| ✔
|
| ✔
| style="color: red" | ✗ *(14)
| style="color: red" | ✗*(7)
| * (15)
| * (15)
|
| ✔
|-
| Routing
| ✔
| ✔
| ✔
|
| ✔
| ✔
| style="color: red" | ✗*(7)
| ✔
| ✔
| ✔
|
|-
| nova diagnostics
| ✔
| ✔
| ✔
|
| ✔
| ✔
|
|
|
| style="color: red" | ✗
| ✔
|-
| Config Drive
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| ✔
| style="color: red" | ✗
|
| style="color: red" | ✗
|
|-
| Auto configure disk
| ✔
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| style="color: red" | ✗
| ✔
|
|
| style="color: red" | ✗
|
|-
| Evacuate
| ✔
| ✔
|
|
| ✔
|
| ✔
| style="color: red" | ✗
| style="color: red" | ✗
|
| ✔
|-
| Volume swap
| style="color: red" | ✗
| ✔
| ✔
|
|
| style="color: red" | ✗
| style="color: red" | ✗
|
|
| style="color: red" | ✗
| ✔
|-
| Volume rate limiting
| style="color: red" | ✗
| ✔
| ✔
|
|
| style="color: red" | ✗
| style="color: red" | ✗
|
|
| style="color: red" | ✗
| ✔
|}

# Inject Networking only works with nova-network in Flat mode, and only with Debian/Ubuntu based virtual machines, and only at boot time
# [[XenServer]] integration also supports using a guest agent to inject networking settings, at any time when a VM has the guest agent installed, through an admin API extension
# (unused)
# XenAPI support for serial console [https://blueprints.launchpad.net/nova/+spec/xenapi-server-log was added in Havana]
# (unsued)
# Functionality provided by cloudbase-init for windows http://www.cloudbase.it/cloud-init-for-windows-instances/
# Vlan and Routing is only supported on Hyper-V when using the Quantum / Neutron Hyper-V Agent; VlanManager mode is not supported with nova-network.
# Support of Xen using Libvirt
# Security Groups supported on VC/ESX Driver when using the Quantum NVP Plugin
# https://bugs.launchpad.net/nova/+bug/1192192
# Copy on write images are not suported (see bug https://bugs.launchpad.net/nova/+bug/1253571).
# Only cold-snapshots are available.
# https://bugs.launchpad.net/nova/+bug/1269448
# Feature does not make sense for Baremetal / Ironic
# Feature currently enabled by some Ironic drivers, but not all.

=== Description of features ===

==== Auto configure disk ====

Automatically reconfigure the size of the partition to match the size of the flavor's root drive before booting.

==== nova diagnostics ====

The `nova diagnostics` command will provide some information about resource use associated with an instance. See the [http://docs.openstack.org/admin-guide-cloud/content/instance_usage_statistics.html OpenStack Cloud Administrator Guide] for more details.

==== Set Admin Pass ====

This feature is the use of a guest agent to change the administrative (root) password on an instance.

== Known bugs, by hypervisor ==

* [https://bugs.launchpad.net/nova/+bugs?field.tag=kvm KVM-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=xenserver,xen XenApi-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=xen+libvirt+&field.tags_combinator=ALL libvirt+Xen-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=qemu QEMU-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=lxc LXC-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=vmware VMware-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=hyper-v Hyper-V-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=baremetal Baremetal-specific bugs]
* [https://bugs.launchpad.net/nova/+bugs?field.tag=docker Docker-specific bugs]

Meetings/Nova

2015-02-04T18:04:50Z

Daniel Berrange: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

== Agenda for next meeting ==

Scheduled for:
* February 5th 2015 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150205T140000)

Add your IRC nick to this list to be pinged at the start of the meeting: <code>abhishekk mikal tjones cburgess jgrimm adrian_otto funzo mjturek jcook ekhugen irina_pov krtaylor danpb alexpilotti flip214 raildo jaypipes gilliard garyk edleafe dims moshele anteaya Nisha claudiub lxsli neiljerram</code>

* Kilo Release Status
** 2/5: https://wiki.openstack.org/wiki/FeatureFreeze
** confirm exception process, aiming for zero exceptions
** at least until we have some
* Kilo Priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
** Nova-net to Neutron Migration (anteaya or jogo to report)
** We need to remember to pay attention to the priority reviews etherpad, we've drifted off a little
* Gate status
** http://status.openstack.org/elastic-recheck/gate.html
* Bugs
** hit list: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
** [https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1266262,n,z Ext4 as default ephemeral disk]
** [https://review.openstack.org/#/c/141883/ fix AggregateTypeAffinityFilter multi values support]
* Stuck reviews
** https://review.openstack.org/#/c/134153/ Connecting Nova to DRBD storage nodes directly. [flip214]
** https://review.openstack.org/#/c/134499/ Don't assume contents of values after aggregate_update
** https://review.openstack.org/#/c/146914/ Add new VIF type VIF_TYPE_TAP
** https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:virtimageinfo,n,z Fix file injection with RBD (https://bugs.launchpad.net/nova/+bug/1257674)
* Open discussion
** Feature matrix - http://docs-draft.openstack.org/80/136380/7/check/gate-nova-docs/28be8b3//doc/build/html/support-matrix.html (sdague) - will be merged by time of meeting
*** We should decide if the matrix data is fine, or if we need reviews to address it
** Kilo meetup debrief: https://etherpad.openstack.org/p/kilo-nova-midcycle
** ?

=== Sub-teams ===

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-16-21.01.html 2012-08-16]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-09-21.00.html 2012-08-09]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-21.40.html 2012-08-02]

[[category: compute]]
[[category: teams]]

Meetings/Nova

2014-11-13T14:02:09Z

Daniel Berrange: /* Agenda for next meeting */

LibvirtDistroSupportMatrix

2014-11-05T10:36:25Z

Daniel Berrange: /* Libvirt OS distribution support matrix */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
! Fedora !! !!

|-
| 18
| 0.10.2.2
| 1.2.0
| 1.19.66

|-
| 19
| 1.0.5.1
| 1.4.2
| 1.22.2

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.28.1

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2
|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 12.10
| 0.9.13
| 1.2.0

|-
| 13.04
| 1.0.2
| 1.4.0
| 1.18.10

|-
| 13.10
| 1.1.1
| 1.5.0
| 1.22.4

|-
| 14.04 (LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2014-11-05T10:35:29Z

Daniel Berrange: /* Libvirt OS distribution support matrix */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
! Fedora !! !!

|-
| 18
| 0.10.2.2
| 1.2.0
| 1.19.66

|-
| 19
| 1.0.5.1
| 1.4.2
| 1.22.2

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-
| 7.1
| 1.2.8
| 1.5.3
| 1.22.6

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2
|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 12.10
| 0.9.13
| 1.2.0

|-
| 13.04
| 1.0.2
| 1.4.0
| 1.18.10

|-
| 13.10
| 1.1.1
| 1.5.0
| 1.22.4

|-
| 14.04 (LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

VirtDriverGuestCPUMemoryPlacement

2014-10-15T20:54:34Z

Daniel Berrange: /* Virtualization Driver Guest CPU / Memory Placement */

= Virtualization Driver Guest CPU / Memory Placement =

== Scope ==

This page considers the issues relating to CPU / memory resources when doing guest placement between and within virtualization hosts. '''NOTE''' this document presents the results of initial investigation / discussion of the area. Any details of the Nova design mentioned here, have been superceeded by the following formal design specifications:

* [http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-numa-placement.html NUMA placement]
* [http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-vcpu-topology.html vCPU topology]
* [http://specs.openstack.org/openstack/nova-specs/specs/juno/approved/virt-driver-cpu-pinning.html CPU pinning]
* [http://specs.openstack.org/openstack/nova-specs/specs/juno/approved/virt-driver-large-pages.html Large pages]

== Terminology ==

* '''vCPU''' - aka virtual CPU - a logical CPU assigned to a guest. A single vCPU may be either a socket, core or thread, according to the guest topology
* '''pCPU''' - aka physical CPU - a logical CPU present on a virtualization host. A single pCPU may be either a socket, core or thread, according to the host topology.
* '''NUMA''' - Non Uniform Memory Access architecture - access time depends on the locality between the memory page and processor core
* '''node''' - a unit with a NUMA system holding either CPUs or memory or both
* '''cell''' - a synonym for node, used by libvirt APIs
* '''socket''' - a discrete CPU chip / package within a NUMA node.
* '''core''' - a processing core within a CPU socket
* '''thread''' - aka hyper thread - a processing pipeline within a CPU core.
* '''KSM''' - Kernel Shared Memory - Linux memory page sharing technology
* '''THP''' - Transparent Huge Pages - Linux technology for proactively using huge pages for process RAM allocations

== Background ==

=== vCPU topology ===

Each virtualization driver in OpenStack has its own approach to defining the CPU topology seen by guest virtual machines. The libvirt driver will expose all vCPUs as individual sockets, with 1 core and no hyper-threads. While operating systems are generally technically capable of using any/all vCPU count / topology combinations there can be a few important caveats

* '''Licensing''' - OS vendors licensing rules may restrict the number of sockets an OS will use. This can force a preference for cores instead of sockets
* '''Performance''' - not all topologies are equal in their performance characteristics. For example, 2 host threads on the same core will offer less performance than 2 host threads on different cores. When seeing that a core has multiple threads OS schedulers will make special placement decisions for threads.

The performance implications of threads mean that it is not desirable to tell a guest it has multiple threads, unless those threads are being pinned 1-1 to host threads. If the guest vCPUs are free floating across host pCPUs, then the guest should just use cores/sockets and leave threads==1. It follows that there is no compelling reason to expose the ability to configure thread count to the user. At most the user may wish to indicate that their image does not want to execute on sibling threads, if the workload in the image is sensitive to such scenarios.

The licensing implications mean that a user uploading images to glance may need to indicate a topology constraint/preference for cores vs sockets for execution of their image. The cloud administrator may also wish to change the hypervisor defaults so that users don't hit common license restrictions. ie for a 4+ vCPU guest, limit to 2 sockets max by default, with remaining vCPUs set to be cores, so Windows images will be handled correctly "out of the box"

=== NUMA topology ===

==== Host NUMA ====

Any virtualization host in the modern era will have NUMA topology with RAM and pCPU sockets spread across 2 or more NUMA nodes. While some CPU models introduce a second level of NUMA, these will not be considered further in this document, since this only has minimal cache effects on performance.

The key factors driving usage of NUMA are memory bandwidth, efficient cache usage and locality of PCIe I/O devices. For example, each NUMA node would have dedicated bus to memory that is local to the node, but access to remote RAM may be across a bus that is shared with all nodes. Consider a 4 NUMA node system with 1 GB/s memory bandwidth per node, and 1 GB/s for shared bus. If all processes always use local RAM then there is 4 GB/s potential memory bandwidth. If all processes always use remote RAM, there is only 1 GB/s potential memory bandwidth. Usage of that shared bus might trigger unintended cache synchronization among the NUMA nodes, leading to a significant performance impact for memory-intensive workloads. When I/O performance is critical, the assignment of devices attached to remote PCIe buses (i.e. attached to a different NUMA node) might have severe effects in the performance degradation, adding to cache inefficiency the waste of resources in the shared intra-node bus.

Thus, incorrect placement of guests on NUMA nodes, or incorrect choice of PCI devices to assign, leads to a serious waste of virtualization host resources. The impact of this will dwarf any benefits from other memory/cpu setup decisions made such as vCPU topology, pCPU/vCPU pinning or use of large pages. Thus a standard policy will be to place guests such that they are entirely confined within a single NUMA node.

==== Guest NUMA ====

If the guest vCPU/RAM allocation is too large to fit inside a single NUMA node, or insufficient PCIe devices are available to assign from a NUMA node, a policy decision must be made. Either execution of the guest on the host in question would be rejected in favour of a host with larger NUMA nodes, or the guest may be allowed to span across multiple NUMA nodes. This decision may be changed if the guest is later relocated, for example, if evacuating a host for maintenance it may be desirable to push a guest off to a host with sub-optimal NUMA placement and accept the temporary performance impact. The answer to the placement question will depend on the use cases involved in the guest deployment. For example, NFV deployments will favour strict NUMA placement, where execution is rejected if the guest cannot fit in the desired NUMA node.

If it is decided to have a guest span multiple NUMA nodes, then to enable the guest OS to maximise utilization of the resources it has been allocated, NUMA topology must also be exposed to the guest. The guest NUMA nodes should then be directly mapped to host NUMA nodes. This will entail mapping guest RAM chunks to host RAM nodes, and setting vCPU affinity to pCPUs. For example if a guest has 4 vCPUs and will be placed across 2 host NUMA nodes, then vCPUs 0+1 will be tied to the first host NUMA node, and vCPUS 2+3 will be tied to a second host NUMA node. It is not mandatory for vCPUs 0+1 to be tied to specific pCPUs within the host NUMA node - they can be free floating within the node at the will of the host OS schedular. If the host has hyperthreading enabled, however, then it is desirable to expose hyperthreading to the guest and at the same time strictly set vCPU<->pCPU affinity even within the node - ie do not allow any free-floating of vCPUs.

Guest NUMA topology can be configured with little regard to the guest OS being run. If a guest OS does not support NUMA, then it would simply ignore the datatables exposed in the virtual BIOS. That said, the guest vCPU topology constraints will influence what particular NUMA topologies are viable to expose. ie if the guest only supports max 2 sockets, then there is little point in setting up 4 NUMA nodes with 1 socket 1 core in each. It would have to have 2 NUMA nodes with 1 socket, 2 cores in each.

=== Large pages ===

Most CPUs in the modern era have support for multiple memory page sizes, ranging from 4k through 2MB/4MB upto as large as 1 GB. Typically the smallest page size will be used by default for all processes. If a non-negligible amount of RAM can be setup as large pages, however, the size of the CPU page tables can be significantly reduced which improves the hit rate of the page table caches and thus overall memory access latency. With the operating system using small pages by default, over time the physical RAM can be fragmented making it harder to find contiguous blocks of RAM required to allocate large pages. This problem becomes worse as the size of large pages increases. Thus if there is an desire to use large pages it is preferrable to instruct the host kernel to reserve them at initial boot time. Current Linux kernels do not allow this reservation to be made against specific NUMA nodes, but this limitation will be lifted in the near future. A further restriction is that the first 1 GB of host RAM cannot be used for 1GB huge pages, due to presence of MMIO holes.

Linux kernels have support for a feature called "transparent huge pages" (THP) which will attempt to proactively allocate huge pages to back application RAM allocations where practical to do so. A problem with relying on this feature is that the owner of the VM has no guarantee which of their guests will be allocated large pages and which will be allocated small pages. Certain workloads / uses cases, such as NFV, will favour explicit huge page allocation in order to have guaranteed performance characteristics, while others may be satisfied by allowing the kernel to perform opportunistic huge page allocation.

Since RAM blocks are directly associated with specific NUMA nodes, by implication, large pages are also directly associated with NUMA nodes. Thus when placing guests on NUMA nodes, the compute service may need to take into account their large page needs when picking amongst possible hosts or NUMA nodes. ie two hosts may have NUMA nodes able to hold the guest, but only one host may have sufficient large pages free in the NUMA nodes.

Large pages can be enabled for guest RAM without any regard to whether the guest OS will use them or not. ie if the guest OS chooses not to use huge pages, it will merely see small pages as before. Conversely though, if a guest OS does intend to use huge pages, it is very important that the guest RAM be backed by huge pages otherwise the guest OS will not be getting the performance benefit it is expecting.

=== Dedicated resource ===

Compute nodes typically have defined over commit ratios for host CPUs and RAM. ie 16 pCPUs may allow execution of a total of 256 vCPUs, and 16 GB of RAM may allow execution of guests totalling 24 GB of RAM. The concept of over commit extends into basic NUMA placement, however, when large pages are added to the mix, over commit ceases to be an option for RAM. There must be a 1-1 mapping between guest RAM and host RAM for large page usage, and the host OS won't consider any huge pages allocated to the guest for swapping, so this precludes any RAM overcommit.

Any use of the large pages feature will thus necessarily imply support for the concept of "dedicated resource" flavours for RAM at least, though at that point it would make sense to extend it for vCPUS too.

Even when doing dedicated resource allocation per guest with no overcommit or RAM or CPUs, there will be a need for CPU + RAM reservations to run host OS services. If using large pages, an explicit decision must be made as to how much RAM to reserve for host OS usage. With CPUs there is more flexibility, since host OS services can always steal time from guests even if the guests have been allocated dedicated pCPUs to execute on. It may none-the-less be desirable to reserve certain pCPUs exclusively for host OS services, to avoid OS services having an unpredictable impact on performance of the guests. It is already possible to tell Nova to reserve a subset of CPUs for OS services, a facility which will continue to be supported and perhaps even enhanced.

In the event that a host is using memory over commit and the guests actually consume all the RAM they are assigned, the host will resort to swapping guests. Swapping can have a significant I/O impact on the host as a whole, so it may not make sense to mix guests with memory-overcommit and guests with dedicated RAM on the same host if strict isolation of these different workloads is required.

In the event that the host is using vCPU over commit and the guests all contend for vCPU, there can still be an impact on the performance of dedicated CPU hosts, due to cache effects, particularly if they are all within the same NUMA node. Thus if strict isolation of workloads is required, it will be desirable to isolate dedicated CPU vs overcommit CPU guests on separate NUMA nodes, if not separate hosts.

=== Memory sharing / compression ===

Linux kernels include a feature known as "kernel shared memory" (KSM) in which RAM pages with identical contents can be shared across different processes. The kernel will proactively scan memory pages to identify identical pages and then merge them. Copy-on-write is used to unshare the page again if any process dirties a shared page. KSM can provide significant improvements in the utilization of RAM when many identical guest OS are run on the same host, or guests otherwise have identical memory page contents. The cost of KSM is increased CPU usage from the memory scanning, and a potential for spikes in memory pressure if guest suddenly do writes which trigger lots of unsharing of pages. The virtualization management layer must thus actively monitor the memory pressure situation and be prepared to migrate existing guests to other hosts if memory pressure increases to levels that cause an unacceptable amount of swap activity or even risk OOM.

The zswap feature allows for compression of memory pages prior to being written out to swap device. This reduces the amount of I/O performed to the swap device and thus reduces the performance degradation inherant in swapping of host memory pages.

=== Related resources (PCI) ===

Decisions made wrt placement of guests on host pCPU/RAM may in turn affect decisions to be made about allocation of other host resources related to the guest VM. For example, PCI devices have affinity with NUMA nodes, such that DMA operations initiated by the PCI are best performed with RAM on the local NUMA node. Thus the decision about which NUMA node to allocate a guest's vCPUs or RAM from, will directly influence which PCI devices and/or functions are acceptable to assign to the guest in order to maximise performance and utilization.

== Technology availability ==

This section focuses on availability of technology in various hypervisors to support the concepts described

=== Libvirt / KVM ===

As of Apr 2014, libvirt supports

* vCPU<->pCPU pinning
* Host NUMA memory allocation placement + policy (ie which node to allocate guest RAM from, and whether this is mandatory or merely preferred policy)
* Large pages for backing of VM RAM
* Guest NUMA topology
* Guest vCPU topology
* Association of VMs into resource groups (using cgroups), which allows NUMA or schedular policies to be set for entire groups of guests at once.

A number of aspects are missing from libvirt, however, including

* Association of guest NUMA nodes to host NUMA nodes
* Control of large page allocation wrt NUMA nodes (depends on guest/host NUMA mapping)
* Reporting on availability of free large pages / large page sizes
* Control of large page size used for allocation
* APIs to create/define/control VM resource groups (must be done by OS admin ahead of time)
* Reporting of NUMA nodes associated with PCI devices

To allow dedicated resource allocation to specific guests there are a number of caveats/constraints

* Dedicated pCPU. As well as setting the desired pCPU affinity on the guest in question, all other guests on the host must be forced to avoid the dedicated pCPU of the first guest. There are several approaches to achieve this
** Create two resource groups for guests at host provisioning time, and split pCPU resources between the 2 groups. Start dedicated resource guests in one group and overcommit resource guests in the other group
** Have hosts which are used solely for dedicated resource guests with no overcommit
** Dynamically update the pCPU affinity of all existing guests when starting a dedicated resource guest
** Set up-front pCPU affinity on all guests, to reserve some portion of pCPUs for later usage by dedicated guests
** Set fixed schedular timeslices for the guests, but allow them to float freely across pCPUs

* Dedicated RAM. There are again several approaches to achieve this
** Use large pages for dedicated resource guests. This requires that the host have sufficient large pages free, and that the guest RAM be a multiple of large page size.
** Create two resource groups for guests at host provisioning time, and split RAM resources between the 2 groups. Start dedicated resource guests in one group and overcommit resource guests in the other group

A complication of dedicated RAM allocation is that KVM has many different needs for RAM allocations beyond the primary guest RAM. There is guest video RAM, and arbitrarily sized allocations needed by the KVM process when processing I/O requests. To a lesser extent this also affects vCPU needs, since there are KVM emulator threads that do work on behalf of the guest. Further the host OS in general requires both CPU and RAM resources

=== VMWare ===

TBD

=== XenAPI ===

* Limited vCPU topology by setting cores-per-socket value. No hyperthread count support http://support.citrix.com/article/CTX126524

== Design ==

=== Permissions ===

As a general rule, any time there are finite resources that are consumed by execution of a VM, the cloud administrator must have absolute control over the resource allocation. This in turn implies that the majority of the configuration work will be at the host level (nova.conf, etc) or at the flavour level. The only time where it is appropriate to permit end user image level config is for aspects which don't impact resource usage beyond what the flavour already allows for. From this it can be seen that the only parameters that are likely to be permissible at the image level are those related to vCPU topology, since that has negligible impact on host resource utilization, primarily being a mechanism for complying with software licensing restrictions.

=== Configuration ===

It should be clear from the background information that to maximise utilization of host resources, it is important to make full use of facilitaties such as NUMA and large pages. It follows from this that, even with zero configuration out of the box, it is desirable for Nova to make an effort to do best NUMA placement for guests, taking into account large pages where available. Explicit configuration should only be required in the subset of deployments which want to make a different set of performance/guest fit tradeoffs to suit specific requirements, or where the cloud provider wishes to artifically restrict placement to fit with different pricing tiers.

==== vCPU topology ====

* The end user should have the ability to express the constraints their OS image has wrt to socket vs cores choice
** To restrict topology (eg max_sockets==2) used by the guest to comply with OS licensing needs.
* The cloud administrator should have the ability to express the preferred or mandatory vCPU topology for guests against flavours
** To place limits on the topologies an end user can specify, to prevent the user defining topologies that force sub-optimal NUMA placement.
** To setup a default topology (eg max_sockets==2) to ensure guest OS images comply with common OS licensing needs without needing per-user image properties
* Where there is a conflict between user image constraints and administrator flavour constraints, the flavour might take priority
** ie if the flavour guest RAM is known to span multiple host NUMA nodes, the user's max_sockets=1 setting must be overriden by a flavour's min_sockets=2 setting to ensure that the scheduler isn't forced todo poor NUMA placement which would waste host resources

As noted in earlier discussion, the only time it makese sense to configure a guest with threads != 1, is if the guest vCPUs are being strictly bound to host pCPUs. This isn't something that an end user needs to consider, but an administrator wish to be able to setup flavours which explicitly avoid placement on a host with threads. This can be achieved by configuring host groups using schedular aggregates

From this it could follow that the following parameters are relevant to vCPU topology:

* image settings
** sockets=N (actual number of desired sockets. Calculate from other settings if omitted)
** cores=N (actual number of desired cores. Calculate from other settings if omitted)
** max_sockets=N (maximum supported number of sockets, assume==INF if omitted)
** max_cores=N (maximum supported number of cores, assume==INF if omitted)
* flavour settings
** sockets=N (default number of sockets, assume ==vcpus or == vcpus/cores if omitted)
** cores=N (default number of cores, assume ==vcpus/sockets if omitted)
** max_sockets=N (maximum number of permitted sockets, assume==INF if omitted)
** max_cores=N (minimum required number of permitted cores, assume==INF if omitted)

The flavour settings will always override the image settings, if both are specified.

Typical usage:

* Zero config setup
** N flavour vCPUs == N sockets
** allows maximum flexilibilty with NUMA placement
* Administrator sets flavour sockets=2
** cores is calculated by dividing vcpu count by socket count.eg 6 vcpu flavour gets 2 sockets, 3 cores
** Windows OS licensing works out of the box
* User sets image max_sockets=2
** max_sockets causes preference for cores if flavour vCPU count is greater than 2.
** Windows OS licensing works
* User sets image cores=4
** Guest will always use 4 cores, provided it is below flavour max_cores value
** If flavour has 4 vCPUs, then guest will be in 1 socket and thus confined to 1 NUMA node.

==== NUMA topology ====

* Administrator can define guest NUMA nodes against flavour
** To force guest RAM to be considered as multiple NUMA nodes to allow more efficient placement on host NUMA nodes
** Administrator shoud declare vCPU topology to satisfy sockets-per-node needs. ie if setting 2 nodes, then at least set min_sockets=2

A simple approach is to simply specify the number of NUMA nodes desired. The RAM and sockets would be divided equally across nodes. This minimises complexity of configuration parameters. If no NUMA node count was defined, then the hypervisor is free to use whatever NUMA topology it wants to in the guest, if any. It might be that there are several viable NUMA configuration depending on the host chosen by the schedular, however, the admin may wish to cap the number of NUMA nodes used.

* Zero config setup
** Hypervisor chooses how many NUMA nodes to setup as it sees fit based on how the guest RAM / vCPU allocation best fits into host RAM/vCPU availability
* Flavour administrator sets numa_nodes=1
** Hypervisor never sets any NUMA topology for the guest, even if guest RAM/vCPU allocation exceeds host RAM/vCPU availability in a single node.
* Flavour administrastor sets numa_max_nodes=2
** Hypervisor will pick a host where the guest is spread across at most 2 NUMA nodes. So the guest may be placed in 1 single NUMA node, or in 2 NUMA nodes, but will never be spread across 4 NUMA nodes.
* Flavour administrator sets numa_nodes=2
** Hypervisor sets up 2 guest NUMA nodes and spreads RAM + vCPUs equally across nodes. It will not use a host where the guest fits in 1 NUMA node, nor 4 NUMA nodes.
* Flavour administrator sets vcpus=6,numa_nodes=2,vcpus.0=0,1,vcpus.1:2,3,4,5,mem.0=2,mem=1=4
** Hypervisor sets up 2 NUMA nodes, the first with vcpus 0 & 1 and 2 GB of RAM, the second node with vcpus 2, 3, 4, 5 and 4 GB of RAM.

Note that administrator never defines anything about how guest is placed into host NUMA nodes. The hypervisor will always decide this as best it can based on how the guest topology is configured. The scheduler would be able to provide to some rules for picking hosts whose NUMA topology best fit with the needs of the flavour.

==== Large pages ====

* Administrator can define large page usage policy against flavour
** To define a high performance, flavour that is guaranteed 1 GB pages
** To prevent use of large pages by a flavour, to ensure they are available for other flavours

* Zero config setup
** Hypervisor chooses whether or not to make use of large pages as it sees fit
* Administrator sets page_sizes=large
** Hypervisor will not start the guest unless it can find large pages are available
* Administrator sets page_sizes=any
** Hypervisor will try to find largest pages first, but fallback to smaller pages if not available
* Administrator sets page_sizes=small
** Hypervisor will never use large pages for the guest, even if available
* Administrator sets page_sizes=1GB
** Hypervisor will not start the guest unless it can find 1 GB large pages. Will not use 2 MB large pages even if available

==== Dedicated resources ====

* Administrator can define that a flavour has dedicated pCPUs
** To guarantee a flavour which has zero contention from other guests
* Administrator can define that a flavour has exclusive pCPUS
** To guarantee a flavour which has zero contention from other guests or OS service/kernel threads

Based on this some configuration scenarios are

* Zero config
** Hypervisor will freely overcomit RAM or vCPUs
* Admin sets overcommit_ram=0 on flavour
** Hypervisor will assign dedicated RAM for the guest, but can still overcommit vCPUs
* Admin sets overcommit_vcpus=0 on flavour
** Hypervisor will assign dedicated vCPUs for the guest, but can still overcommit RAM
* Admin sets overcommit_ram=0,overcommit_vcpus=0 on flavour
** Hypervisor will assign dedicated vCPUs and RAM for the guest

=== Scheduler ===
Currently, libvirt and other drivers (xenapi ?) will report their CPU
info. Libvirt uses this information at the moment to check for compatibility between
source and destination hypervisors when live-migrating, but nowhere else. This data
also does not include any NUMA information, nor does it include any usage info.
In order to make this useful for scheduling, we would need to make sure that compute
hosts are exposing the needed information to the schedular.

It would also be good to make the format of the data that is currently kept in the
database as a json blob, better defined and standardized across virt drivers. It may
also be required that we change the way we store this information in the database for
performance reasons which can prove important especially for scheduling.

From the background information regarding execution of instances with dedicated
resources, it is clear that, at minimum, the scheduler needs to have the assign
instances to hosts according to whether the host runs dedicated resource workloads
or overcommit workloads. Not all deployments, however, will require or desire strict
separation of dedicated resource workloads from overcommit workloads, since it
leads to less flexible / efficient utilization of compute hosts. It is thus also valid to
allow the schedular to mix dedicated resource and overcommit instances on a single
host. eg if a host has 8 GB of RAM and 2 GB of huge pages reserved, it can
run 2 GB of dedicated resource guests fairly easily and still have 6 GB available
for overcommit workloads.

==== vCPU topology ====

The libvirt driver currently exposes the pCPU topology (ie sockets, cores, threads), but
there is no general utilization information for CPU resource. Within the context of a single
NUMA node there is no significant performance differentiation between sockets and cores,
so the scheduler should not need to be concerned with matching host/guest core/socket
counts. The core/socket count can be determined by the compute driver, once the
schedular has made the decision based on NUMA requirements.

If a flavour expresses anti-affinity for threads, then the schedular will want to avoid placing
the VM on hosts which have threads>1 for their pCPUs.

==== NUMA placement ====
The schedular needs to take into account the 'numa_nodes' setting on the flavour
when deciding where to place guests.

If 'numa_nodes' is not set, then the schedular is free to make an arbitrary decision
as to where the run the guest regardless of whether the flavour RAM fits into a single
NUMA node on the target host or not. It will still probably want to prefer hosts where
it could fit into a single NUMA node though.

If 'numa_nodes' is set to 1, then the schedular must only place a guest on a host
where the flavour RAM fits into a single NUMA node.

If 'numa_nodes' is > 1, then the schedular should place the guest on a host where
flavour RAM / numa_nodes fits into the size of the host's NUMA nodes.

The compute nodes will need to expose information about their NUMA topologies
(ie CPUs and RAM per node) and the current utilization of resources in these topologies.
This data will need to be added to the compute_host data model.

==== Large pages ====

Unlike NUMA - huge pages if asked for by the flavor will need to be on host that
allows for it and has pre-allocated them. It is likely that this will be required
on same hosts that will be dedicated to NUMA as well so we might want to make this
an explicit dependency. For example, if a host has huge pages configured, it is
considered also as struct from NUMA perspective.

THP can be used on hosts that allow oversubscription, and the scheduling can take
this into account if there is a request for huge pages that is not a hard rule but
best effort.

Hosts can then report if they support reserved or THP, if they support pre-allocated,
and in case of strict placement - they will report the free number of pages.

Based on the above we can have flavors that have huge_pages set to 'strict' which will
mean that scheduler will fail the instance if no host has enough huge pages free to
satisfy the hard memory requirement in a single NUMA node.

==== Dedicated resources ====

LibvirtDistroSupportMatrix

2014-08-13T12:52:27Z

Daniel Berrange: /* Libvirt OS distribution support matrix */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt
! QEMU/KVM
! libguestfs

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
! Fedora !! !!

|-
| 18
| 0.10.2.2
| 1.2.0
| 1.19.66

|-
| 19
| 1.0.5.1
| 1.4.2
| 1.22.2

|-
| 20
| 1.1.3
| 1.6.1
| 1.24.1

|-
| 21
| 1.2.6
| 2.1.0
| 1.27.25

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2
| 1.16.34

|-
| 6.5
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 6.6
| 0.10.2
| 0.12.1.2
| 1.20.11

|-
| 7.0
| 1.1.1
| 1.5.3
| 1.22.6

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2
|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (LTS)
| 0.9.8
| 1.0
| 1.14.8

|-
| 12.10
| 0.9.13
| 1.2.0

|-
| 13.04
| 1.0.2
| 1.4.0
| 1.18.10

|-
| 13.10
| 1.1.1
| 1.5.0
| 1.22.4

|-
| 14.04 (LTS)
| 1.2.2
| 2.0.0
| 1.24.5

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

LibvirtDistroSupportMatrix

2014-07-23T15:14:59Z

Daniel Berrange: /* Libvirt OS distribution support matrix */

== Libvirt OS distribution support matrix ==

This page documents the libvirt versions present in the various distro versions that OpenStack Nova aims to be deployable with. Periodically with each new development cycle this matrix will be consulted to determine if it is viable to drop support for any end-of-life or otherwise unused distros. This in turn potentially lets Nova mandate a newer version of libvirt, and thus drop compatibility code for older versions

{| class="wikitable"
|-
! OS Distro
! Libvirt Version
! QEMU/KVM Version

|-
! Debian !! !!

|-
| Wheezy
| 0.9.12
| 1.1.2
|-
| Wheezy-backports
| 1.2.1
| 1.7.0

|-
! Fedora !! !!

|-
| 18
| 0.10.2.2
| 1.2.0

|-
| 19
| 1.0.5.1
| 1.4.2

|-
| 20
| 1.1.3
| 1.6.1

|-
| 21
| 1.2.6
| 2.1.0

|-
! openSUSE !! !!

|-
| 12.2
| 0.9.11
| 1.1.0

|-
| 12.3
| 1.0.2
| 1.3

|-
| 13.1
| 1.1.2
| 1.6.0

|-
! RHEL !! !!

|-
| 6.4
| 0.10.2
| 0.12.1.2

|-
| 6.5
| 0.10.2
| 0.12.1.2

|-
| 6.6
| 0.10.2
| 0.12.1.2

|-
| 7.0
| 1.1.1
| 1.5.3

|-

! SLES !! !!

|-
| 11-SP3
| 1.0.5
| 1.4.2
|-
! Ubuntu !! !!

|-
| Cloud Archive (Havana)
| 1.1.1
| 1.5.0

|-
| 12.04 (LTS)
| 0.9.8
| 1.0

|-
| 12.10
| 0.9.13
| 1.2.0

|-
| 13.04
| 1.0.2
| 1.4.0

|-
| 13.10
| 1.1.1
| 1.5.0

|-
| 14.04 (LTS)
| 1.2.2
| 2.0.0

|}

NB: maintain alphabetical ordering of distros, followed by oldest released versions first

Meetings/Nova

2014-06-12T14:25:33Z

Daniel Berrange: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting-alt) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

== Agenda for next meeting ==

Scheduled for:
* June 12, 2014, 14:00 UTC, #openstack-meeting-alt (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140612T140000)
* June 19, 2014, 21:00 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140619T210000)

Add your IRC nick to this list to be pinged at the start of the meeting: <code>mikal</code><code>tjones</code><code>cburgess</code><code>jgrimm</code><code>adrian_otto</code><code>mzoeller</code><code>funzo</code>

* Juno mid-cycle meetup date/location
** https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint
* Release status
** Juno-1 is 12 June
*** https://github.com/openstack/nova/releases/tag/2014.2.b1
** Juno-2 is 24th July
*** blueprint review push?
*** nova-spec review push, decide what we want in juno (mostly)?
*** what can't go into Juno-3?
* Bugs (tjones)
** hot bug list?
** spotting bug "themes", like force_config_drive and resize/migrate (mostly due to those not being tested with multi-node hosts in the gate)
** Bug 1328694: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037304.html
** Bug 1323658: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037221.html
* Gate status
** how it looking? slow down approvals?
** what about driver tests?
* Sub team reports
* Open discussion
** (alaski) https://review.openstack.org/#/c/64769/
** (alaski) Tasks and (multiple)server create
** API specs to review:
*** https://review.openstack.org/84695 (v2.1 on V3 API)
*** https://review.openstack.org/96139 (v2.1 microversions)
*** (Tasks API)
*** (Policy should be enforced at API layer)
** Policy for changes submitted which help future Python3 portability
*** eg https://review.openstack.org/#/c/98573/

=== Sub-teams ===

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-16-21.01.html 2012-08-16]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-09-21.00.html 2012-08-09]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-21.40.html 2012-08-02]

Meetings/Libvirt/Minutes/20140610

2014-06-10T15:48:07Z

Daniel Berrange: Created page with "=Libvirt Sub-Team Meeting = ==Agenda: 2014/06/10== * Steven Wilson (sew) Curious about nested Docker support with libvirt lxc containers? Has anyone been able to make this..."

=Libvirt Sub-Team Meeting =

==Agenda: 2014/06/10==

* Steven Wilson (sew) Curious about nested Docker support with libvirt lxc containers? Has anyone been able to make this work? There seem to be cgroup layout differences that cause Docker layers to fail within libvirt lxc containers.

Meetings/Libvirt

2014-06-10T15:47:00Z

Daniel Berrange: /* Schedule */

= Libvirt Meetings =

Meeting to discuss any bug, blueprint or topic related to the libvirt driver in Nova.

The team will meet every Tuesday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0p1=0 15:00 UTC] in <code><nowiki>#openstack-meeting-3</nowiki></code>

== Who are we ? ==

The group is a subset of the Nova developers interested in the Libvirt driver in Nova, for any hypervisor (including but not limited to KVM, QEMU, Xen (libxl) and LXC), and welcomes contribution from interested parties representing any other OpenStack projects that utilize / integrate with Libvirt.

=== Mission ===

The mission of the team is

* ''To ensure Libvirt continues to be the leading virtualization driver in Nova for any hypervisor it supports"

=== Tasks ===

The areas the team works in are many and varied

* Triage incoming bug reports
* Review of blueprints / nova-specs
* Tracking of progress / resolving roadblocks in development / reviews
* Respond to gate stability issues impacting libvirt CI
* Planning / assistence for bringing new libvirt hypervisor/container drivers into Nova

=== Leadership ===

Meeting facilitator

* Daniel Berrange (IRC: danpb, Red Hat)

=== Contact info ===

Email: <code><nowiki>openstack-dev@lists.openstack.org</nowiki></code> (tag with [nova][libvirt])

IRC: <code><nowiki>#openstack-dev</nowiki></code> on freenode (OpenStack specific) or #virt on oftc.net (Libvirt upstream developers)

== Meetings ==

=== Agenda ===

Add items for discussion to the team meeting etherpad

* https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda

Etherpad to be copied to a wiki page 'Meeting/Libvirt/Mintues/YEARMONTHDAY' after the meeting completes

=== Schedule ===

* Tuesday, June 10th. 1500 UTC ([[Meetings/Libvirt/Minutes/20140610 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-06-10-15.00.html IRC logs]]]
* Tuesday, June 3rd. 1500 UTC ([[Meetings/Libvirt/Minutes/20140603 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-06-03-15.00.html IRC logs]]]
* Tuesday, May 27th. 1500 UTC ([[Meetings/Libvirt/Minutes/20140527 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-27-15.01.html IRC logs]]]
* Tuesday, May 20th. 1500 UTC ([[Meetings/Libvirt/Minutes/20140520 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-20-15.00.html IRC logs]]]

TelcoWorkingGroup

2014-06-04T16:46:16Z

Daniel Berrange: /* Who we are */

= Weekly NFV sub-team IRC meeting =
'''MEETING TIME: (Proposed, subject to change) Wednesdays, [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC], #openstack-meeting-alt, starting June 4'''

= Who we are =

''' Add your name here if you're joining the meetings - IRC nicks are pretty anonymous unless you give us a clue! '''
{| class="wikitable"
|-
! Nick !! Name !! Affiliation !! Interests
|-
| ijw || Ian Wells || Cisco's Openstack team || Vendor neutral NFV infrastructure, Cisco NFV appliances
|-
| cgoncalves || Carlos Goncalves || Instituto de Telecomunicacoes || Service Function Chaining, Traffic Steering
|-
| danpb || Daniel Berrange || Red Hat || Libvirt, KVM & Nova performance & enablement for NFV
|}

= Mission statement =

<blockquote>The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) workloads on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV.</blockquote>

<blockquote>The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against.</blockquote>

[[IRC|OpenStack IRC details]]

Chair: Russell Bryant (russellb)

== Agenda for next meeting ==

Wednesday, June 4 at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC] in #openstack-meeting-alt.

Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs]
* [https://etherpad.openstack.org/p/juno-nfv-bof Juno Design Summit NFV BoF]

=Use Cases=

TBD

= Development Efforts =

== Active Bugs ==

Add the "nfv" tag to bugs to have them appear in these queries:

* Nova: https://bugs.launchpad.net/nova/+bugs?field.tag=nfv
* Neutron: https://bugs.launchpad.net/neutron/+bugs?field.tag=nfv

== Active Blueprints ==

PRIORITY - repeatedly mentioned at the BOF as blockers:

{| class="wikitable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design
|-
| Support two interfaces from one VM attached to the same network || Nova || first BP submit || https://blueprints.launchpad.net/nova/+spec/2-if-1-net || https://review.openstack.org/97716
|-
| VLAN trunking networks for NFV || Neutron || first BP submit || https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks || https://review.openstack.org/97714
|-
| Permit unaddressed interfaces for NFV use cases || Neutron || first BP submit || https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces || https://review.openstack.org/97715
|-
|}

The rest:

{| class="wikitable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s)
|-
| SR-IOV Networking Support || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov || https://review.openstack.org/#/c/86606/
|-
| colspan="3" | ''Support for NUMA and VCPU topology configuration'' || ''https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology'' ||
|-
|
: Virt driver guest vCPU topology configuration
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology || https://review.openstack.org/93510
|-
|
: Virt driver guest NUMA node placement & topology
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement || https://review.openstack.org/93636
|-
|
: Virt driver large page allocation for guest RAM [[#dupe|*]]
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages || https://review.openstack.org/93653
|-
|
: Virt driver pinning guest vCPUs to host pCPUs
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning || https://review.openstack.org/93652
|-
|
: I/O (PCIe) Based NUMA Scheduling
|| Nova || New || TBD || TBD
|-
| Soft affinity support for server groups || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group || https://review.openstack.org/91328
|-
| Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/89712
|-
| Framework for Advanced Services in Virtual Machines || Neutron || || https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms ||
|-
| Neutron Services Insertion, Chaining, and Steering || Neutron || Approved || https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering || https://review.openstack.org/93524
|-
| Schedule vms per flavour cpu overcommit || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/flavor-cpu-overcommit || https://review.openstack.org/88286
|-
| OVF Meta-Data Import via Glance || Glance || Submitted || https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import || TBD
|-
| colspan="5" | ''Support for high performance Intel(R) Data Plane Development Kit based vSwitches''
|-
|
: Open vSwitch to use patch ports in place of veth pairs for vlan n/w
|| Neutron || Submitted || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use || TBD
|-
|
: Libvirt hugepage backed memory support
|| Nova || Submitted || https://blueprints.launchpad.net/nova/+spec/libvirt-hugepage || TBD
|-
|
: Support userspace vhost in ovs vif bindings
|| Nova || Submitted || https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost || TBD
|-
| NIC state aware scheduling || Nova || Rejected || https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling || https://review.openstack.org/87978
|-
| Add PCI and PCIe device capability aware scheduling || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/pci-device-capability-aware-scheduling || https://review.openstack.org/92843
|-
| [http://snabb.co/nfv.html Snabb NFV] mechanism driver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver || https://review.openstack.org/95711
|-
| VIF_SNABB (qemu vhost-user) support || Nova || Submitted w/ code || https://blueprints.launchpad.net/nova/+spec/vif-snabb || https://review.openstack.org/96138
|-
|Solver Scheduler - complex constraints scheduler with NFV use cases || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/solver-scheduler || https://review.openstack.org/#/c/96543/
|-
| Discless VM || Nova || Under discussion || https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe ||
|-
| Network QoS API || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api || https://review.openstack.org/#/c/88599
|-
| Persist scheduler hints || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/persist-scheduler-hints || https://review.openstack.org/#/c/88983/
|-
| Security groups using OpenFlow || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/#/c/89712/
|-
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring ||
|-
| Traffic Steering Abstraction || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction || https://review.openstack.org/92477/
|-
|}

== Needed Development Not Yet Started ==

TelcoWorkingGroup

2014-06-04T11:15:47Z

Daniel Berrange: /* Active Blueprints */

= Weekly NFV sub-team IRC meeting =
'''MEETING TIME: (Proposed, subject to change) Wednesdays, [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC], #openstack-meeting, starting June 4'''

This meeting is a weekly gathering of developers and operators interested in development activity in support of NFV use cases. We gather requirements to support these use cases and track active development efforts across OpenStack that relate to this area.

[[IRC|OpenStack IRC details]]

Chair: Russell Bryant (russellb)

== Agenda for next meeting ==

Wednesday, June 4 at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC] in #openstack-meeting.

Agenda:
* First meeting!
* Meet and greet
* Review Mission
** https://etherpad.openstack.org/p/nvf-subteam-mission-statement
** Positioning relative to complementary projects and subteams, e.g. Nova, Neutron, Heat, ServiceVM, IPv6, etc.
* Review our current blueprint list and fill in anything we're not tracking yet
* Review use case prioritization
* Discuss tracking approaches:
** Use cases
** Blueprints
** Bugs

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs]
* [https://etherpad.openstack.org/p/juno-nfv-bof Juno Design Summit NFV BoF]

=Use Cases=

TBD

= Development Efforts =

== Active Bugs ==

Add the "nfv" tag to bugs to have them appear in these queries:

* Nova: https://bugs.launchpad.net/nova/+bugs?field.tag=nfv
* Neutron: https://bugs.launchpad.net/neutron/+bugs?field.tag=nfv

== Active Blueprints ==

PRIORITY - repeatedly mentioned at the BOF as blockers:

{| class="wikitable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design
|-
| Support two interfaces from one VM attached to the same network || Nova || first BP submit || https://blueprints.launchpad.net/nova/+spec/2-if-1-net || https://review.openstack.org/97716
|-
| VLAN trunking networks for NFV || Neutron || first BP submit || https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks || https://review.openstack.org/97714
|-
| Permit unaddressed interfaces for NFV use cases || Neutron || first BP submit || https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces || https://review.openstack.org/97715
|-
|}

The rest:

{| class="wikitable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s)
|-
| SR-IOV Networking Support || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov || https://review.openstack.org/#/c/86606/
|-
| colspan="3" | ''Support for NUMA and VCPU topology configuration'' || ''https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology'' ||
|-
|
: Virt driver guest vCPU topology configuration
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology || https://review.openstack.org/93510
|-
|
: Virt driver guest NUMA node placement & topology
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement || https://review.openstack.org/93636
|-
|
: Virt driver large page allocation for guest RAM [[#dupe|*]]
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages || https://review.openstack.org/93653
|-
|
: Virt driver pinning guest vCPUs to host pCPUs
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning || https://review.openstack.org/93652
|-
| Soft affinity support for server groups || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group || https://review.openstack.org/91328
|-
| Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/89712
|-
| Framework for Advanced Services in Virtual Machines || Neutron || || https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms ||
|-
| Neutron Services Insertion, Chaining, and Steering || Neutron || Approved || https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering || https://review.openstack.org/93524
|-
| Schedule vms per flavour cpu overcommit || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/flavor-cpu-overcommit || https://review.openstack.org/88286
|-
| OVF Meta-Data Import via Glance || Glance || Submitted || https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import || TBD
|-
| colspan="5" | ''Support for high performance Intel(R) Data Plane Development Kit based vSwitches''
|-
|
: Open vSwitch to use patch ports in place of veth pairs for vlan n/w
|| Neutron || Submitted || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use || TBD
|-
|
: Libvirt hugepage backed memory support
|| Nova || Submitted || https://blueprints.launchpad.net/nova/+spec/libvirt-hugepage || TBD
|-
|
: Support userspace vhost in ovs vif bindings
|| Nova || Submitted || https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost || TBD
|-
| NIC state aware scheduling || Nova || Rejected || https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling || https://review.openstack.org/87978
|-
| Add PCI and PCIe device capability aware scheduling || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/pci-device-capability-aware-scheduling || https://review.openstack.org/92843
|-
| [http://snabb.co/nfv.html Snabb NFV] mechanism driver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver || https://review.openstack.org/95711
|-
| VIF_SNABB (qemu vhost-user) support || Nova || Submitted w/ code || https://blueprints.launchpad.net/nova/+spec/vif-snabb || https://review.openstack.org/96138
|-
|Solver Scheduler - complex constraints scheduler with NFV use cases || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/solver-scheduler || https://review.openstack.org/#/c/96543/
|-
| Discless VM || Nova || Under discussion || https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe ||
|-
| Network QoS API || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api || https://review.openstack.org/#/c/88599
|-
| Persist scheduler hints || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/persist-scheduler-hints || https://review.openstack.org/#/c/88983/
|-
| Security groups using OpenFlow || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/#/c/89712/
|-
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring ||
|-
|}

== Needed Development Not Yet Started ==

Meetings/Libvirt/Minutes/20140520

2014-06-03T15:50:47Z

Daniel Berrange: Daniel Berrange moved page Meeting/Libvirt/Minutes/20140520 to Meetings/Libvirt/Minutes/20140520

= Libvirt Sub-Team Meeting =

== Agenda: 2014/05/20==

Please put your full name + IRC nick against any agenda items you add

* Introduction to the new team (Daniel Berrange / danpb)
* Suitability of meeting time
** Other possibility: Monday 1600 UTC ?
** Alternate with Tuesday 0900 UTC to help China/Japan/India contributors ?
* Libvirt HV driver support requirements
** ie what features must a libvirt driver provide, in order to be useful for Nova
** https://wiki.openstack.org/wiki/LibvirtDriverSupportMatrix
* The future of Libvirt/Xen (Christian Berendt / berendt)
** B1 systems, Citrix and SUSE to investigate CI options
* Consider using 'block' FS type instead of exclusively using bind-mounts (Rick Harris / s1rp)
** Current code is very complex because is uses `virt/disk/mount.py` to make loopback and nbd devices available as bind-mounted fileystems
** We could use Libvirt's native handling of block devices to simplify the code
** Block handling was added in 0.9.6 (current min required version) https://github.com/c4milo/libvirt/commit/77791dc0e162463f3d885ea6481d07bae29d2494
*** Can't remember exact details, but there were some bugs in this initial support which had follow on patches, so might need something newer than 0.9.6. We want to bump min Nova libvirt to 0.9.11 anyway
** Side-note: This would allow us Rackspace to drop a patch we're holding for a NoopMounter that we were going to contribute upstream
** Question: What would the migration path be for instances already using bind-mounts for NBD, loopback, etc?
*** On restart do they use the new 'block' method?
*** Do we deprecate bind-mount (for block backends) in K-release, and remove in L-release?
** Caveat: What to do about global chown across the entire FS to handle UID mapping?
*** Do this in Glance on image-import?
*** Or can we get the kernel guys to provide a way to set mapping at mount time...
*** One first then the other? Yep, we'd need to support today's kernels :)
* The future of LXC in the Libvirt Driver (Rick Harris / s1rp)
** Cleanup image handling code
** Expose UID and GID mapping
** Environment variable handling (requires libvirt work)
** Should init path be exposed as well? (Andrew Melton / apmelton) yes
** Process return/exit code (requires libvirt work)
* I've proposed this https://review.openstack.org/#/c/88062 to handle the lxc disks (including block dev, which currently dosn't work), until we will move to a newer libvirt version.
* Bug triage (Kashyap Chamarthy/ kashyap)
** https://bugs.launchpad.net/nova/+bugs?field.tag=libvirt+
** Monthly bug triage day? Currently 118 bugs tagged as 'libvirt'
*** Periodically go through Nova bugs, find libvirt specific bugs, tag them appropriately. Root-cause analysis, general bug triage work flow -- https://wiki.openstack.org/wiki/BugTriage
* LibvirtLXC testing infrastructure (Thomas Maddox / thomasem)
** We met some folks at the summit who seemed pretty interested in helping with the CI infrastructure to bring LXC support up to snuff in terms of testing/gating
** RAX have a person looking at LXC tests for CI
** LXC CI will probably be done as part of the official gate, rather than 3rd party CI

Meeting/Libvirt/Minutes/20140520

2014-06-03T15:50:47Z

Daniel Berrange: Daniel Berrange moved page Meeting/Libvirt/Minutes/20140520 to Meetings/Libvirt/Minutes/20140520

#REDIRECT [[Meetings/Libvirt/Minutes/20140520]]

Meetings/Libvirt

2014-06-03T15:50:30Z

Daniel Berrange: /* Schedule */

= Libvirt Meetings =

Meeting to discuss any bug, blueprint or topic related to the libvirt driver in Nova.

The team will meet every Tuesday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0p1=0 15:00 UTC] in <code><nowiki>#openstack-meeting-3</nowiki></code>

== Who are we ? ==

The group is a subset of the Nova developers interested in the Libvirt driver in Nova, for any hypervisor (including but not limited to KVM, QEMU, Xen (libxl) and LXC), and welcomes contribution from interested parties representing any other OpenStack projects that utilize / integrate with Libvirt.

=== Mission ===

The mission of the team is

* ''To ensure Libvirt continues to be the leading virtualization driver in Nova for any hypervisor it supports"

=== Tasks ===

The areas the team works in are many and varied

* Triage incoming bug reports
* Review of blueprints / nova-specs
* Tracking of progress / resolving roadblocks in development / reviews
* Respond to gate stability issues impacting libvirt CI
* Planning / assistence for bringing new libvirt hypervisor/container drivers into Nova

=== Leadership ===

Meeting facilitator

* Daniel Berrange (IRC: danpb, Red Hat)

=== Contact info ===

Email: <code><nowiki>openstack-dev@lists.openstack.org</nowiki></code> (tag with [nova][libvirt])

IRC: <code><nowiki>#openstack-dev</nowiki></code> on freenode (OpenStack specific) or #virt on oftc.net (Libvirt upstream developers)

== Meetings ==

=== Agenda ===

Add items for discussion to the team meeting etherpad

* https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda

Etherpad to be copied to a wiki page 'Meeting/Libvirt/Mintues/YEARMONTHDAY' after the meeting completes

=== Schedule ===

* Tuesday, June 10th. 1500 UTC
* Tuesday, June 3rd. 1500 UTC ([[Meetings/Libvirt/Minutes/20140603 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-06-03-15.00.html IRC logs]]]
* Tuesday, May 27th. 1500 UTC ([[Meetings/Libvirt/Minutes/20140527 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-27-15.01.html IRC logs]]]
* Tuesday, May 20th. 1500 UTC ([[Meetings/Libvirt/Minutes/20140520 |Minutes]], [http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-20-15.00.html IRC logs]]]

Meetings/Libvirt/Minutes/20140527

2014-06-03T15:50:17Z

Daniel Berrange: Daniel Berrange moved page Meeting/Libvirt/Minutes/20140527 to Meetings/Libvirt/Minutes/20140527

=Libvirt Sub-Team Meeting=
==Agenda: 2014/05/27==
Please put your full name + IRC nick against any agenda items you add

* libvirt: start LXC from a block device volume - https://review.openstack.org/88062 - (Vladik Romanovsky, vladikr)
** Confused with what should be actually done.
* IPv6 Guest Configuration with /proc/sys mounted read-only (Thomas Maddox / thomasem)
** https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/964882
** Workarounds checked (both worked, the latter seems to maintain the limitation that we still can't use the inet6 static configuration in /etc/network/interfaces):
*** Mounting /proc/sys/net as RW via Libvirt patch (tried this and it worked, just need to discuss security implications...) (danpb mentions that some settings are host local and some are namespace local)
*** Using a post-up configuration to run ifconfig IPv6 net addr configurations and route to add gateway (desired as it doesn't require Libivrt patch, afaik)
*** The R/O mount was mostly security through obsecurity - only SELinux/APpArmour/UserNS provide any real security
** Curious about long-term solution; do network namespaces fix the problem the read-only mount aimed to prevent?
*** Need to figure out what bits of sysfs must be chown'd for userns
*** Might be kernel bugs lurking where the kernel sysfs handler uses capable vs ns_capable()
** Action Item: Take this to the libvirt mailing list
* Config-Drive with Libvirt LXC (Rick Harris / s1rp)
** WHY: Config-drive allows us to pass networking configuration into guest and perform file-injection (drop app specific configs into place, etc...)
** Should we use block-device (ISO format) or FS-style (plain old directory) via a bind mount?
** FS-style involves adding a new config-drive backend plugin (only a few lines of code) and uses <filesystem type="mount> in the domain XML
** PROPOSED ALTERNATIVE: Block-style would use standard ISO formatted blockdevice and use <filesystem type="block"> in the XML (haven't confirmed this works, but it should)
** QUESTION: Currently using FS-style, but would like to switch to block-style for the Nova upstream patch. Thoughts?
*** BLOCK-STYLE PRO: No new config-drive backend (all virt-configuraitons basically use ISO, except potentialy hyperV using fat)
*** BLOCK-STYLE CON: issues using <block> with <idmap> so far....
*** FS-STYLE PRO: Already have patch, very small
** What should the default mount-point destination be? Currently it's /var/lib/cloud/seed/config_drive (cloud-init's preferred dest) [make this configurable?]
** Action Item: Toss current patch up on to Gerrit for comments
** Action Item: Draft spec :-/
* Remove-fakelibvirt Update (Rick Harris / s1rp)
** On hold for now, turns out to be very contraversial, and it's not blocking anything
** Action Item: Need ML discussion on testing across hypervisors (unit vs integration) so we can get some kind of consistency
* Bug Triage
** https://bugs.launchpad.net/nova/+bugs?field.tag=libvirt+

Meeting/Libvirt/Minutes/20140527

2014-06-03T15:50:17Z

Daniel Berrange: Daniel Berrange moved page Meeting/Libvirt/Minutes/20140527 to Meetings/Libvirt/Minutes/20140527

#REDIRECT [[Meetings/Libvirt/Minutes/20140527]]

Meetings/Libvirt/Minutes/20140603

2014-06-03T15:50:04Z

Daniel Berrange: Daniel Berrange moved page Meeting/Libvirt/Minutes/20140603 to Meetings/Libvirt/Minutes/20140603

=Libvirt Sub-Team Meeting=
==Agenda: 2014/06/3==
Please put your full name + IRC nick against any agenda items you add
* Security contact
** The openstack vulnerability management team needs some libvirt contacts for the security response team
** Any volunteers?
** (Please let mikal know the outcome, as he can't make this meeting time)
*Bug Triage
**https://bugs.launchpad.net/nova/+bugs?field.tag=libvirt+
* USB-Passthrough(JingYuan+JingYuan)
**https://review.openstack.org/#/c/86118/

Meeting/Libvirt/Minutes/20140603

2014-06-03T15:50:04Z

Daniel Berrange: Daniel Berrange moved page Meeting/Libvirt/Minutes/20140603 to Meetings/Libvirt/Minutes/20140603

#REDIRECT [[Meetings/Libvirt/Minutes/20140603]]