Issues booting with os_distro=centos7.0

[John Garbutt]

If we have os_distro=centos this isn't known by os-info, so we get:

Cannot find OS information - Reason: (No configuration information found for operating system centos7): OsInfoNotFound: No configuration information found for operating system centos7

If we "fix" it to os_distro=centos7.0 we get:

Instance failed to spawn: UnsupportedHardware: Requested hardware 'virtio1.0-net' is not supported by the 'kvm' virt driver

This is with Rocky, but was also happening with Queens, I believe.

[John Garbutt (johngarbutt)]

This looks related:
https://github.com/virt-manager/virt-manager/commit/617b92710f50015c5df5f9db15d25de18867957d

[John Garbutt (johngarbutt)]

seems like the problem is that the device is considered invalid by:
https://github.com/openstack/nova/blob/ff0f33cf7e44c5d01f3fb999295eff4508c24a14/nova/virt/libvirt/vif.py#L67

[Kashyap Chamarthy (kashyapc)]

Based on a chat with Dan Berrangé (thank you), there are two problems
here:

(1) Nova's validation of network models is incomplete, i.e. the method
    is_vif_model_valid_for_virt() has an incomplete list of hardware
    models

(2) The "model names returned by libosinfo are *NOT* required to be
    valid libvirt network model names". I.e. there is no such
    "virtio-1.0-net" model name in libvirt, if we see here:
    https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/conf/domain_conf.c#l515

And libosinfo is just telling us that the guest supports
'virio-1.0-net'. There are two ways to provide that: the
"virtio-transitional" vs. "virtio-non-transitional" devices.

Where "virtio-transitional" provides a device that will auto-negotiate
virtio 1.0 support; while "virtio-non-transitional" provoides a device
that is fixed to always use virtio 1.0 support.

    - - -

The recomendation for all CentOS 7.0 devices is to go with 'virtio'.

    - - -

Documentation on "virtio-transitional" vs. "virtio-non-transitional":

    https://libvirt.org/formatdomain.html#elementsVirtioTransitional)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/669190

[sean mooney (sean-k-mooney)]

we discussed this a bit on irc today and honestly i think the osinfo module made several bad assumption not just that the returned value would be valid.

for now i think we should just do the minimal fix for johns issue but

we shoudl consider either droping it entirely or reimplmenting it as it is ignoring the
virt_type, it is assuming the virt_dirver is libvirt eventhough it should be driver indepened since ist in nova.virt not nova.virt.libvirt, it is miss using os_distro, os distro should be centos with os_version set to 7 for centos7 and there are likely other latent issues with it.

so for backport reasons yes we shoudl normalise the valuse but

setting os_distro=centos7.0 is technically missusing that filed.

https://github.com/openstack/glance/blob/90b1f8dc7a2411a7e0286f286d84d8e511d93791/etc/metadefs/operating-system.json#L16-L25

so this feature has been broken since it was added.

[sean mooney (sean-k-mooney)]

i ment to leave https://bugs.launchpad.net/nova/+bug/1835400/comments/5 here

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/669190
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6be668e51992df53a4d871bea70bc738a9beacb8
Submitter: Zuul
Branch: master

commit 6be668e51992df53a4d871bea70bc738a9beacb8
Author: John Garbutt <email address hidden>
Date: Thu Jul 4 15:06:17 2019 +0100

    Stop sending bad values from libosinfo to libvirt

    When we try to use either virtio1.0-block or virtio1.0-net it is
    correctly rejected by libvirt. We get these returned from libosinfo for
    newer operating systems that support virtio1.0.

    As we want to support libvirts older than 5.2.0, its best we just request
    "virtio", please see:
    https://libvirt.org/formatdomain.html#elementsVirtioTransitional

    You can see virtio1.0-net and virtio-block being added here:
    https://gitlab.com/libosinfo/osinfo-db/blob/master/data/os/fedoraproject.org/fedora-23.xml.in#L31

    Change-Id: I633faae47ad5a33b27f5e2eef6e0107f60335146
    Closes-Bug: #1835400

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 20.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/688067

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/688068

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/688069

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/688067
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a06922d546a26c9e6550a93cbe0718cf841b6b9f
Submitter: Zuul
Branch: stable/stein

commit a06922d546a26c9e6550a93cbe0718cf841b6b9f
Author: John Garbutt <email address hidden>
Date: Thu Jul 4 15:06:17 2019 +0100

    Stop sending bad values from libosinfo to libvirt

    When we try to use either virtio1.0-block or virtio1.0-net it is
    correctly rejected by libvirt. We get these returned from libosinfo for
    newer operating systems that support virtio1.0.

    As we want to support libvirts older than 5.2.0, its best we just request
    "virtio", please see:
    https://libvirt.org/formatdomain.html#elementsVirtioTransitional

    You can see virtio1.0-net and virtio-block being added here:
    https://gitlab.com/libosinfo/osinfo-db/blob/master/data/os/fedoraproject.org/fedora-23.xml.in#L31

    Change-Id: I633faae47ad5a33b27f5e2eef6e0107f60335146
    Closes-Bug: #1835400
    (cherry picked from commit 6be668e51992df53a4d871bea70bc738a9beacb8)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/688068
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=89d2a764d75aad6876551663e8350d301336eb59
Submitter: Zuul
Branch: stable/rocky

commit 89d2a764d75aad6876551663e8350d301336eb59
Author: John Garbutt <email address hidden>
Date: Thu Jul 4 15:06:17 2019 +0100

    Stop sending bad values from libosinfo to libvirt

    When we try to use either virtio1.0-block or virtio1.0-net it is
    correctly rejected by libvirt. We get these returned from libosinfo for
    newer operating systems that support virtio1.0.

    As we want to support libvirts older than 5.2.0, its best we just request
    "virtio", please see:
    https://libvirt.org/formatdomain.html#elementsVirtioTransitional

    You can see virtio1.0-net and virtio-block being added here:
    https://gitlab.com/libosinfo/osinfo-db/blob/master/data/os/fedoraproject.org/fedora-23.xml.in#L31

    Change-Id: I633faae47ad5a33b27f5e2eef6e0107f60335146
    Closes-Bug: #1835400
    (cherry picked from commit 6be668e51992df53a4d871bea70bc738a9beacb8)
    (cherry picked from commit a06922d546a26c9e6550a93cbe0718cf841b6b9f)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/688069
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5d89cfed2b18642df5d720268ec38d1bd7752bd4
Submitter: Zuul
Branch: stable/queens

commit 5d89cfed2b18642df5d720268ec38d1bd7752bd4
Author: John Garbutt <email address hidden>
Date: Thu Jul 4 15:06:17 2019 +0100

    Stop sending bad values from libosinfo to libvirt

    When we try to use either virtio1.0-block or virtio1.0-net it is
    correctly rejected by libvirt. We get these returned from libosinfo for
    newer operating systems that support virtio1.0.

    As we want to support libvirts older than 5.2.0, its best we just request
    "virtio", please see:
    https://libvirt.org/formatdomain.html#elementsVirtioTransitional

    You can see virtio1.0-net and virtio-block being added here:
    https://gitlab.com/libosinfo/osinfo-db/blob/master/data/os/fedoraproject.org/fedora-23.xml.in#L31

    Change-Id: I633faae47ad5a33b27f5e2eef6e0107f60335146
    Closes-Bug: #1835400
    (cherry picked from commit 6be668e51992df53a4d871bea70bc738a9beacb8)
    (cherry picked from commit a06922d546a26c9e6550a93cbe0718cf841b6b9f)
    (cherry picked from commit 89d2a764d75aad6876551663e8350d301336eb59)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 17.0.13 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 19.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 18.3.0 release.