Bug 1786876

Summary:

ERROR: 'python-nftables' failed: prevents libvirt from activating NAT, results in failure to start VMs

Product:

[Fedora] Fedora

Reporter:

Chris Murphy <bugzilla>

Component:

selinux-policy

Assignee:

Zdenek Pytela <zpytela>

Status:

CLOSED RAWHIDE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

unspecified

Docs Contact:

Priority:

unspecified

Version:

rawhide

CC:

awilliam, bugzilla, dwalsh, egarver, lvrabec, mgrepl, plautrba, psutter, robatino, samuel-rhbugs, zpytela

Target Milestone:

---

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

If docs needed, set a value

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2020-02-06 21:43:35 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:

Bug Depends On:

Bug Blocks:

1705303, 1757513

Attachments:

Description	Flags
journal	none
screenshot	none

Description Chris Murphy 2019-12-28 22:49:51 UTC

Description of problem:

Unable to startup VMs in virt-manager unless firewalld is stopped first.

Version-Release number of selected component (if applicable):
firewalld-0.8.0-1.fc32.noarch
python3-firewall-0.8.0-1.fc32.noarch
python3-nftables-0.9.3-1.fc32.x86_64
nftables-0.9.3-1.fc32.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Try to create a VM using virt-manager
2. NAT is "inactive" probably due to prior errors, when virt-manager asks to make it active, it results in more errors (see screenshot). VM can't be started.
3.

Actual results:

VM can't be started.

Expected results:

libvirt should be able to make NAT active by default for VM's out of the box.


Additional info:

Comment 1 Chris Murphy 2019-12-28 22:52:07 UTC

Created attachment 1648276 [details]
journal

Comment 2 Chris Murphy 2019-12-28 22:52:46 UTC

Created attachment 1648277 [details]
screenshot

Comment 3 Fedora Blocker Bugs Application 2019-12-28 23:07:18 UTC

Proposed as a Blocker for 32-beta by Fedora user chrismurphy using the blocker tracking app because:

 Beta:
"The release must be able host virtual guest instances of the same release."

Basic says the release must install and boot as a guest of a host running the current release. So that doesn't apply.

Comment 4 Eric Garver 2020-01-06 14:13:38 UTC

The logs show initial firewalld errors:

  [   16.756380] fmac.local firewalld[838]: ERROR: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Operation not supported
  ...
  JSON blob:
  {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"table": {"family": "inet", "name": "firewalld"}}}, {"add": {"table": {"family": "ip", "name": "firewalld"}}}, {"add": {"table": {"family": "ip6", "name": "firewalld"}}}]}


These are the very first rules generated by firewalld and they're simply adding the top-level tables. This may be completely unrelated to libvirt. Getting EOPNOTSUPP at this point is weird.
There was also an AVC denial for modprobe. This might explain the EOPNOTSUPP:

  [   16.254448] fmac.local audit[932]: AVC avc:  denied  { nnp_transition } for  pid=932 comm="(modprobe)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:kmod_t:s0 tclass=process2 permissive=0


Can you try it again with setenforce=0 ?

Comment 5 Eric Garver 2020-01-06 14:14:38 UTC

I forgot to mention, you'll have to setenforce=0, then restart firewalld and libvirt before trying again.

Comment 6 Chris Murphy 2020-01-07 03:59:15 UTC

Confirmed, it boots with enforcing=0 or selinux=0.

Comment 7 Lukas Vrabec 2020-01-10 12:47:56 UTC

commit 789c6593214fa10b15d2c628822cffe985417f5a
Author: Zdenek Pytela <zpytela>
Date:   Wed Dec 18 14:36:14 2019 +0100

    Allow init_t nnp domain transition to kmod_t

Comment 8 Fedora Admin XMLRPC Client 2020-01-23 16:24:48 UTC

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 9 Adam Williamson 2020-02-06 21:43:35 UTC

At the blocker review meeting on Monday cmurf confirmed this is fixed now, so closing.