Re: [libvirt-users] macvtap and tagged VLANs to the VM

On 1/3/19 9:23 AM, Marc Haber wrote: Yes, although I wouldn't use the brctl command directly if I were you - much simpler an more stable to set it up in your host's system network config, and let initscripts/NetworkManager/whatever your distro uses take care of creating the bridge / attaching your physical ethernet each time the host boots. Not really. macvtap is useful because it's simple to setup (doesn't require a change to the host's network config), but is also problematic in some ways, e.g. it doesn't allow host<->guest communication (unless you have a switch that reflects all traffic back to the sender). A long time ago people were theorizing that macvtap would provide much better performance than a host bridge connection, but I don't think that has been the case in practice (it may be somewhat better in some situations, but not really in others). These days use of macvtap for guest connection is more the exception than the rule. On my host that has a bridge named "br0", *that* is what is offered for connection of a new guest interface by default, not any macvtap interface. And on another host that has no br0 device, libvirt's own "default" network is the default selection for new network devices, followed in the list by other libvirt virtual networks. In all cases, the selections for macvtap connections to the host's physical ethernets are included all the way at the bottom of the list, below both libvirt virtual networks *and* host bridges. 1) I guess this APU is something other than x86? 15Mbits is *glacially* slow, regardless of what's used for the connection. 2) have you tried the same setup with macvtap (since you can't get vlans working, maybe just try an apples-apples comparison of traffic with no vlans on both setups) and seen markedly better performance? 3) You should be able to get some amount of improvement with host bridges if you define a libvirt network pointing at the bridge you're using, with macTableManager="libvirt" in the definition. e.g. if you have a bridge in your host network config called "br0", define this network: <network> <name>nolearn</name> <bridge name='br0'macTableManager='libvirt'/> <forward mode='bridge'/> </network> then use this for your guest interfaces: <interface type='network'/> <source network='nolearn'/> ... </interface> Setting macTableManager='libvirt' causes libvirt to disable learning on the bridge ports, and manually update the FDB of the bridge with the MAC addresses of the guest interfaces. If learning is disabled on all ports except one (that "one" being the physical ethernet of the host that is attached to the bridge), then the kernel also disables promiscuous mode on the physical ethernet. The combination of disabling learning and disabling promiscuous mode on the physdev should have a noticeable impact on performance (although I'm not certain if this panned out as nicely in practice as it did in the minds of kernel network developers either :-) (note that if you play around with this you'll need to understand that only traffic sent to the broadcast MAC, and to the specific MAC of the guest as specified in the libvirt config for the guest, will actually make it to the guest - no playing tricks with modifying the MAC address only in the guest!)