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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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?


Regards,

   Stefan

would be to introduce a new config option indicating that specialized HW is
necessary since currently the test case kind of abuses the config option
assigning a virtual interface directly to the guest which in this case is a
necessary condition, but not a sufficient one. However, with the Avocado<->TCK
joined work happening, I'd rather not spent more time with Perl than necessary.

[1]
virNetDevVPortProfileOpSetLink:823 : error during virtual port configuration of ifindex 8: No such device or address
virNetDevVPortProfileOpCommon:958 : internal error: sending of PortProfileRequest failed.

Thanks,
Erik







[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux