LTC Test- Ubuntu18.04: Starting the guest with network filter defined will fail with "cause is unknown".
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
The Ubuntu-power-systems project |
Fix Released
|
High
|
Canonical Server | ||
libvirt |
Fix Committed
|
Undecided
|
|||
libvirt (Ubuntu) |
Fix Released
|
Low
|
Ubuntu on IBM Power Systems Bug Triage | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Artful |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* nwfilters were not usable if configured to use dhcp based learning
* Fix by backporting upstream bug
[Test Case]
* Add the following to the interface section of a guest description in
libvirt:
<filterref filter=
<parameter name='CTRL_
</filterref>
Then start the guest.
Bad case:
error: Failed to start domain VM1
error: An error occurred, but the cause is unknown
Fixed:
Guest starts and works.
[Regression Potential]
* I thought a while on this. On first sight one might say there is a
regression risk due to increasing the size of the buffer. This risk
would arise on hyperscale environments where the memory consumption per
guest would increase by 2*128Kb*
sum up on MANY guests).
But then I realized that this is only true for the use case using
dhcpsnoop which is
a) clearly not the most common case
b) failing to work at all before this fix
So there can't be anyone today with a working setup that then runs OOM,
due to the setup either not using the feature (=no change) or failing
missing this fix.
So I actually think this mem consumption increase is not an issue in
terms of SRU considerations.
Due to that the only remaining regression would be users that had a
self-built libpcap without TPACKET_V3 to drive a workload like the
above, and even then only the rather small size bump is what changes.
[Other Info]
* I have added this case and a few deeper checks on the created rules for
iptables to the regression tests
---
== Comment: #2 - Mallesh N. Koti <email address hidden> - 2018-02-28 05:02:49 ==
Guest Xml
=======
ISSUE
=======
Defining a network filter and Starting a VM with this nwfiter in VM's xml is failing with "cause is unknown".
==================
Recreation Steps
==================
1. Define a network filter as:
virsh nwfilter-define filter.xml
2. Add nwfilter in guest xml and start guest.
virsh start VM1
It fails with :
# virsh start VM1
error: Failed to start domain VM1
error: An error occurred, but the cause is unknown
XML used for defining network filter:
```<?xml version='1.0' encoding='UTF-8'?>
<filter chain="root" name="clean-
<uuid>
<filterref filter=
<mac protocolid="ipv4" /></rule><rule action="accept" direction="inout" priority="-500" statematch="None">
<mac protocolid="arp" /></rule></filter>
```
will be attaching the guest xml
The issue happens with Ubuntu 18.04 host - where not able to start the guest with network defined with value dhcp.
<parameter name='CTRL_
.
Found following commit is not there in 18.04 Ubuntu source. There could be some dependent commit too. we are facing some build issue and hence not able to verify it.
.
https:/
.
Changed in ubuntu-power-systems: | |
importance: | Undecided → High |
assignee: | nobody → Canonical Server Team (canonical-server) |
tags: | added: triage-g |
Changed in ubuntu-power-systems: | |
status: | New → Incomplete |
Changed in ubuntu-power-systems: | |
status: | Incomplete → Confirmed |
Changed in libvirt: | |
importance: | Unknown → Undecided |
status: | Unknown → Confirmed |
Changed in libvirt: | |
status: | Confirmed → Unknown |
Changed in ubuntu-power-systems: | |
status: | Confirmed → Fix Released |
Changed in ubuntu-power-systems: | |
status: | Fix Released → Fix Committed |
Changed in ubuntu-power-systems: | |
status: | Fix Committed → Fix Released |
Changed in libvirt: | |
status: | Unknown → Fix Committed |
Starting with F27, the Fedora-only patch that disabled TPACKET_V3 support was removed with the comment:
Drop TPACKET_V3 patch as it should be fixed in kernel by now
This is apparently not the case since, on a host with F27 packages, including libpcap-1.8.1-6 and kernel 4.15.3-300, the previously- functional libvirt code that uses libpcap to watch for DHCP traffic now fails when pcap_setfilter() returns EBADF.
Here is the excerpt of libvirt code (from the file src/nwfilter/ nwfilter_ dhcpsnoop. c):
[...]
handle = pcap_create(ifname, pcap_errbuf);
if (handle == NULL) {
virReportError (VIR_ERR_ INTERNAL_ ERROR, "%s",
_("pcap_ create failed"));
goto cleanup_nohandle;
}
if (pcap_set_ snaplen( handle, PCAP_PBUFSIZE) < 0 ||
pcap_set_ buffer_ size(handle, PCAP_BUFFERSIZE) < 0 ||
pcap_activate( handle) < 0) {
virReportError (VIR_ERR_ INTERNAL_ ERROR,
_("setup of pcap handle failed: %s"),
pcap_ geterr( handle) );
goto cleanup;
}
if (pcap_compile( handle, &fp, ext_filter, 1, PCAP_NETMASK_ UNKNOWN) != 0) {
virReportError (VIR_ERR_ INTERNAL_ ERROR,
_("pcap_ compile: %s"), pcap_geterr( handle) );
goto cleanup;
}
if (pcap_setfilter (handle, &fp) != 0) { <=== FAILURE HERE
virReportError (VIR_ERR_ INTERNAL_ ERROR,
_("pcap_ setfilter: %s"), pcap_geterr( handle) );
goto cleanup_freecode;
}
[...]
If I add the patch titled "pcap-linux: don't use TPACKETV3 for memory mmapped
capture" back to the F27 build of libpcap (built locally with fedpkg) and install the resulting rpm, the same code magically begins to work.
I haven't checked rawhide, but I assume the behavior is the same.
I think Fedora needs to re-disable TPACKET_V3