Bug 2095967

Description of problem:
When adding a directly attached interface (interface type == direct attachment), the newly created interface is configured in vepa mode (libvirt default). Considering how rare are vepa-capable switches, this means that guests with directly attached interfaces can not talk each others. This choice basically makes directly attached interfaces created via cockpit-machines useless.

For this reason, virt-manager automatically creates bridge mode direct attached interfaces when selecting macvtap networking. Bridge mode enables guests to talk each other, while ensuring the added security guarantees regarding guest to host networking (which is prevented by design).

While "pure" bridge networking (ie: interface type == bridge to lan) is available, it has two significant drawbacks compared to bridge-mode directly attached interfaces: a) it is slower and b) it does not prevent guest to host communication by design.

Please consider changing the default for "interface type == direct attachment" to create bridge-mode macvtap interfaces. Or, at the very least, please add an option to select the interface mode (defaulting to bridge would be recommended).

Version-Release number of selected component (if applicable):
cockpit-machines-263-1.el9.noarch.rpm

How reproducible:
Always

Steps to Reproduce:
1. add a directly attached interface via cockpit to two guests 
2. let a guest ping the other one
3. all packet are lost

Actual results:
No communication between guest is possible

Expected results:
Guest-to-guest communication should work out-of-the-box.

Additional info:
None.