Project

General

Profile

Actions

Bug #13695

closed

Can't create VNICs over vioif after 13637

Added by Andy Fiddaman about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

Up until #13637 was integrated, vioif interfaces ignored requests to enable promiscuous mode, but returned success.
This allowed VNICs to be created on top of vioif interfaces and, with some additional configuration, they could be used.

The usual way that I used this was to create a VNIC in the global zone, and assign some secondary mac addresses to it via the secondary-macs property.
That VNIC is then allocated to a bhyve VM, and the guest sees a vioif interface.
The guest creates one or more VNICs over that vioif, explicitly setting the MAC addresses to match those assigned to the GZ VNIC's secondary-macs.

Here is an example configuration that worked prior to #13637

Global zone:

reaper# dladm show-vnic omniosr0
LINK         OVER       SPEED MACADDRESS        MACADDRTYPE VID  ZONE
omniosr0     switch10   0     2:8:20:10:1c:b6   random      0    bloody

reaper# dladm show-linkprop -p secondary-macs omniosr0
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
omniosr0     secondary-macs  rw   a:0:0:0:0:1    --             --

In the bhyve guest that is assigned omniosr0:

bloody% dladm
LINK        CLASS     MTU    STATE    BRIDGE     OVER
vioif0      phys      1400   up       --         --
switch_10   etherstub 9000   up       --         --

bloody% pfexec zadm boot lx

bloody% dladm
LINK        CLASS     MTU    STATE    BRIDGE     OVER
vioif0      phys      1400   up       --         --
switch_10   etherstub 9000   up       --         --
lx0         vnic      1400   up       --         vioif0

bloody% dladm show-vnic
LINK         OVER       SPEED MACADDRESS        MACADDRTYPE VID  ZONE
lx0          vioif0     1000  a:0:0:0:0:9       fixed       0    lx

bloody% pfexec zlogin lx
[Connected to zone 'lx' pts/2]
# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=6.34 ms
^C

Now that vioif properly supports promiscuous mode, but while the bhyve viona driver does not, it would be helpful if the previous behaviour could be restored to allow this type of configuration to continue working.


Related issues

Related to illumos gate - Feature #14716: viona should support a control queue and promiscuous mode.In ProgressAndy Fiddaman

Actions
Actions #1

Updated by Electric Monk about 1 year ago

  • Gerrit CR set to 1402
Actions #2

Updated by Andy Fiddaman about 1 year ago

I tested this change by booting the OmniOS VM shown in the issue description on a patched system. I was again able to boot a variety of zones using VNICs over the vioif interface, and pass traffic to and from the Internet from inside the zone.

Actions #3

Updated by Electric Monk about 1 year ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit 8054a0e4c809d98ffb44f17b9a8b932ca2c24b2c

commit  8054a0e4c809d98ffb44f17b9a8b932ca2c24b2c
Author: Jason King <jason.brian.king@gmail.com>
Date:   2021-04-05T23:47:08.000Z

    13695 Can't create VNICs over vioif after 13637
    Reviewed by: Andy Fiddaman <andy@omnios.org>
    Reviewed by: Andrew Stormont <andyjstormont@gmail.com>
    Approved by: Robert Mustacchi <rm@fingolfin.org>

Actions #4

Updated by Andy Fiddaman about 1 month ago

  • Related to Feature #14716: viona should support a control queue and promiscuous mode. added
Actions

Also available in: Atom PDF