[libvirt-TCK] Disabling the vepa VSI test 300-vsitype.t

Erik Skultety eskultet at redhat.com
Thu Feb 6 09:56:10 UTC 2020


On Wed, Feb 05, 2020 at 01:47:24PM -0500, Stefan Berger wrote:
> On 2/5/20 11:00 AM, Erik Skultety wrote:
> > Hi list,
> > so since the beginning of this week I've been poking at the last failure [1]
> > in the nwfilter segment of the TCK suite. So, the errors come from libnl
> > although I haven't been able to extract what the true underlying issue is since
> > interface with ID '8' definitely exist on my system.
> >
> > A bit of background (you can either clone the repo or look at the Perl script
> > attached), we're configuring the guest network interface as 'direct' with mode
> > VEPA. IIUC, for proper VEPA support you need a compliant external switch which
> > 1) I don't have
> > 2) upstream CI planned to run in a nested env won't have either.
> >
> > The main issue lies in the test trying to set <virtualport> parameters on the
> > interface. I've tried with regular network interfaces, vlan-tagged interfaces
> > (as one of the other error messages complained about a missing vlan tag - which
> > is something VEPA switches supposedly do on their own), and SR-IOV VFs with no
> > luck. I'd be happy for any networking insights here, but given the setup
> > which had clearly been tested with specialized HW I'd suggest simply disabling
> > the test from the suite for upstream purposes - well, the correct approach
>
>
> I was involved in this a few years ago... without having the hardware
> myself. I am fine with you disabling the test case.

Interesting, can you elaborate on the details then how it's supposed to work?
Laine mentioned that the code paths being exercised work only on top of SRIOV
VFs, so I guess you made use of those at least?

>
> The only other thing I'd be curious about is whether some changes were
> occurring in the past that broke this test case (suddenly). You may not
> know... I don't recall it having been broken, but cannot say for sure. Is
> there something sensing (now) that the right network setup is not available
> and therefore it behaves differently and things start failing?

It's been a looong time since the tests were run on a regular basis, so it's
very much possible that the XML interface params results into a slightly
different network setup in real world, it may not be just libvirt, but also the
underlying stack, the question is whether it's really worth pursuing or rather
try coming up with a new test case since this one hasn't been updated for about
8 years or so.

Erik




More information about the libvir-list mailing list