[Users] Virtuozzo 7 - bridged veth interfaces for container

[Axton]

My host's network uses teaming, bridge, and vlan interfaces.

There are 4 physical interfaces: enp0s20f0-enp0s20f3
The 4 physical interfaces are grouped using lacp via teaming.

[root at cluster-02 ~]# teamdctl team0 config dump actual
{
    "device": "team0",
    "link_watch": {
        "name": "ethtool"
    },
    "ports": {
        "enp0s20f0": {},
        "enp0s20f1": {},
        "enp0s20f2": {},
        "enp0s20f3": {}
    },
    "runner": {
        "active": true,
        "fast_rate": true,
        "name": "lacp",
        "tx_balancer": {
            "name": "basic"
        },
        "tx_hash": [
            "eth",
            "ipv4",
            "ipv6"
        ]
    }
}

The switch is configured to send 802.1q (vlan) encapsulated packets for a
series of vlans.  For each vlan, a vlan interface is configured on the
linux host and a bridge is configured on top of the vlan iface.  Take vlan
80 as an example:

[root at cluster-02 ~]# cat /etc/sysconfig/network-scripts/ifcfg-team0.80
DEVICE=team0.80
VLAN=yes
BOOTPROTO=none
NM_CONTROLLED=no
BRIDGE=vmbr80
IPV6INIT=no
MTU=9000

[root at cluster-02 ~]# cat /etc/sysconfig/network-scripts/ifcfg-vmbr80
VLAN=yes
TYPE=Bridge
DEVICE=vmbr80
PHYSDEV=team0
VLAN_ID=80
REORDER_HDR=0
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=no
IPV6_DEFROUTE=no
IPV6_FAILURE_FATAL=no
NAME=vlan-vlan80
ONBOOT=yes
MTU=9000
BOOTPROTO=none
STP=off
DELAY=0
IPV4_DEFROUTE=no


In a nutshell: physical ifaces (4) -> team0 -> team0.<vlanid> (10) ->
vmbr<vlanid> (bridge).  The bridges are all in place and everything works
as expected with the interface/network configuration on the host:

[root at cluster-02 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
host-routed             8000.000000000000       no
virbr1          8000.525400885137       no              virbr1-nic
vmbr10          8000.0cc47a6b9554       no              team0.10
vmbr20          8000.0cc47a6b9554       no              team0.20
vmbr30          8000.0cc47a6b9554       no              team0.30
vmbr40          8000.0cc47a6b9554       no              team0.40
vmbr5           8000.0cc47a6b9554       no              team0.5
vmbr70          8000.0cc47a6b9554       no              team0.70
vmbr80          8000.0cc47a6b9554       no              team0.80
vmbr90          8000.0cc47a6b9554       no              team0.90
vmbr91          8000.0cc47a6b9554       no              team0.91
vmbr92          8000.0cc47a6b9554       no              team0.92

In openvz on RHEL 6, I added an interface to a container using vzctl like
this:
vzctl set 30000 --netif_add eth4,,veth30000.40,,vmbr40 --save

I am trying to add a veth interface to a container and specify the bridge
interface on Virtuozzo 7.
- vzctl behaves differently, it expects macs.
- prlctl does not have sufficient options; I can add an interface but not
specify the bridge device
- prlsrvctl looks like it only supports physical interfaces (see following
commands)
[root at cluster-02 ~]# ip link show vmbr80
21: vmbr80: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state
UP mode DEFAULT
    link/ether 0c:c4:7a:6b:95:54 brd ff:ff:ff:ff:ff:ff
[root at cluster-02 ~]# ip a show vmbr80
21: vmbr80: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state
UP
    link/ether 0c:c4:7a:6b:95:54 brd ff:ff:ff:ff:ff:ff
[root at cluster-02 ~]# prlsrvctl net add vlan80 -i vmbr90 -t bridged --ip
10.1.0.0/22
Failed to find network adapter vmbr90 on the server.

- vznetcfg does not seem to exist in a state that matches the virtuozzo 7
documentation (only see /usr/libexec/libvzctl/scripts/vznetcfg on my
machine)

I thought maybe I should add a virtual network and bridge it, but I can't
seem to find a way to do this.
I thought maybe I would use vzctl like I did on rhel 6, but that requires
me to provide mac addresses (rhel 6 would autogen macs)

At a bit of a loss.  Any help is appreciated.

Thanks,
Axton Grams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20160212/284d39e8/attachment-0001.html>