Bug 1839808
| Summary: | Configuring 'e1000e' VIF type results in 'UnsupportedHardware' exception | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Stan Toporek <stoporek> |
| Component: | openstack-nova | Assignee: | Stephen Finucane <stephenfin> |
| Status: | CLOSED ERRATA | QA Contact: | OSP DFG:Compute <osp-dfg-compute> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 13.0 (Queens) | CC: | ailan, amoralej, dasmith, eglynn, jhakimra, kchamart, knoel, lyarwood, mdean, sbauza, sgordon, stephenfin, vromanso, yvugenfi |
| Target Milestone: | z13 | Keywords: | Patch, Triaged, ZStream |
| Target Release: | 13.0 (Queens) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-nova-17.0.13-21.el7ost | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-28 18:32:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Stan Toporek
2020-05-25 15:55:00 UTC
It looks like nova internal test for supported network device models in qemu\kvm is failing:
Those are the supported models (E1000E is not one of them for some reason):
nova/virt/libvirt/vif.py:92
SUPPORTED_VIF_MODELS = {
'qemu': [
network_model.VIF_MODEL_VIRTIO,
network_model.VIF_MODEL_NE2K_PCI,
network_model.VIF_MODEL_PCNET,
network_model.VIF_MODEL_RTL8139,
network_model.VIF_MODEL_E1000,
network_model.VIF_MODEL_LAN9118,
network_model.VIF_MODEL_SPAPR_VLAN],
'kvm': [
network_model.VIF_MODEL_VIRTIO,
network_model.VIF_MODEL_NE2K_PCI,
network_model.VIF_MODEL_PCNET,
network_model.VIF_MODEL_RTL8139,
network_model.VIF_MODEL_E1000,
network_model.VIF_MODEL_SPAPR_VLAN],
'xen': [
network_model.VIF_MODEL_NETFRONT,
network_model.VIF_MODEL_NE2K_PCI,
network_model.VIF_MODEL_PCNET,
network_model.VIF_MODEL_RTL8139,
network_model.VIF_MODEL_E1000],
'lxc': [],
'uml': [],
'parallels': [
network_model.VIF_MODEL_VIRTIO,
network_model.VIF_MODEL_RTL8139,
network_model.VIF_MODEL_E1000],
}
Then, I assume, for some reason, Windows Server guests are configured to use e1000e and are failing the following test:
nova/virt/libvirt/vif.py:199
if not is_vif_model_valid_for_virt(virt_type, model):
raise exception.UnsupportedHardware(model=model, virt=virt_type)
Also, it looks like there was some similar case (it is marked as “Solution verified”). Unfortunately, I don’t have the credentials to access full information.
https://access.redhat.com/solutions/3947641
So either e1000e should be added as a supported network device for QEMU\KVM or Window Server configuration should be edited to use virtio or e1000.
This appears to a valid issue. For reference, based on a quick bit of research, libosinfo is configuring VIF type because Windows does not provide virtio drivers out-of-the-box. The e1000e is the PCIe variant of the e1000 NIC and therefore requires the Q35 machine type. Since libvirt supports this for the QEMU/KVM backend, there should be no reason nova does not. The fact we don't appears to have been an oversight. (In reply to Yan Vugenfirer from comment #2) ... > Also, it looks like there was some similar case (it is marked as “Solution > verified”). Unfortunately, I don’t have the credentials to access full > information. > https://access.redhat.com/solutions/3947641 The solution suggests editing instance records in the DB as a workaround. This should be a last-resort and I'll seek to have this advice removed. The correct solution is to address the issue at root, as you've suggested. This is in progress now. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openstack-nova bug fix advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4393 |