802.1q VLAN ifaces: does it matter whether created in guest or on host?

I have a couple of LXD hosts on the same network, where for no very strong reason I’ve implemented 801.1q interfaces by two different methods.

On one host I use method 1: they’re defined in the lxc configs and the fact that they’re tagged VLAN ports is hidden from the guest, e.g.

    hwaddr: xx:xx:xx:xx:xx:xx
    name: eth0
    nictype: macvlan
    parent: p1p3
    type: nic
    vlan: "10"

So the guest only sees “eth0” and is unaware it’s a VLAN sub-interface.

On another host I use method 2: the raw interface is passed in the config as, e.g. eth0 macvlan and the guest creates the (for example) eth0.10 interface if it want to using its own network tools.

Both methods work fine, seem to behave the same way from a guest perspective and interoperate with each other on the shared physical switch fabric. But is there a reason to prefer one over the other?

Clearly some differences include:

  • Method 1 allows the guest to be unaware of the raw interface; useful if you want it to have no access to the untagged vlan or any other vlans on that interface
  • Method 1 useful for limited guests which do not have tools for setting up vlans internally
  • Method 2 allows the guest the same VLAN access on that raw interface the host has, to use or not as needed
  • Method 2 does not leave much visible clutter in the host network namespace; ip link list and ifconfig don’t even indicate the existence of the guests’ vlan interfaces.

But I’m not sure I’m seeing everything that matters: are there additional, possibly important differences as far as performance and overhead, etc. that would cause one to choose one approach over the other, or have I hit the main points?

The main difference is that in approach 1 the container cannot access a VLAN outside of the one specified in the config, whereas in approach 2 the container can setup access to which ever VLAN they like. This might be a security problem depending on how trustworthy the container is.