I found two styles to define, the latter being the more common one I knew.
Testing both to be sure.
1. macvtap via forward mode bridge network
<network>
<name>macvtap-net</name>
<uuid>157ecf3d-14fc-4157-ace9-9c7c05597252</uuid>
<forward dev='eno2' mode='bridge'>
<interface dev='eno2'/>
</forward>
</network>
Then in the guest
<interface type='network'>
<source network='macvtap-net'/>
<model type='virtio'/>
</interface>
2. macvtap via direct guest interface
<interface type='direct' >
<source dev='eno3'/>
</interface>
Both work nowadays.
This already generates (changing as needed):
/etc/apparmor.d/libvirt/libvirt-26dedac7-b8de-4772-9f59-a5bb962394c5.files:15:
"/dev/tap12" rw,
/etc/apparmor.d/libvirt/libvirt-26dedac7-b8de-4772-9f59-a5bb962394c5.files:16:
"/dev/tap13" rw,
This is actually doen since ages via domainSetSecurityTapFDLabel ->
AppArmorSetFDLabel.
Time to drop the following patch next merge:
0002-apparmor-libvirt-qemu-Allow-macvtap-access.patch:+ /dev/tap* rw,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1704744
Title:
apparmor, libvirt-qemu: Allow macvtap access
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1704744/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
