Hi Laine,
You mentioned:
But again, already-existing tap devices can't be used for interface type='bridge' or type='network' (which also connects the tap to a bridge).
I also conducted another test, which confirmed that whenever the VM is shut down, the existing tap device is deleted.
This suggests that the correct understanding is recreation rather than modification.
Can I conclude that, in a bridge network type, libvirt is expected to create and manage the tap device automatically?
This would mean that the tap device is always created by libvirt, its lifecycle is tied to the VM (guest OS), and it is deleted when the VM stops.
Additionally, each time the VM starts, a new tap device is created with slight variations, likely derived from the VM's MAC address.
Would you agree with this assessment?
Best regards,
Xuda Zhang
Laine Stump <laine@xxxxxxxxx> 于2025年2月5日周三 14:03写道：
On 2/4/25 11:04 PM, Xuda Zhang wrote:
> Could you help confirm the exact behavior in this case? Specifically:
>
> 1. If a target tap device already exists, does libvirt modify the MAC
> address instead of recreating the device?
Sorry, I needed to qualify that detail a bit (and actually I probably
shouldn't have even brought it up, since it doesn't apply to tap devices
used to connect to a bridge device) - *only for
"<interface type='ethernet' managed='no'>" * an already-existing tap
device can be specified in the XML (with <target dev='blah'/>).
type='ethernet' is used for tap devices that aren't connected to any
bridge (all communication with the guest must then be *routed* by the
host at the IP level, rather than being bridged).
And a detail that I misremembered - when libvirt uses a pre-existing tap
device, it assumes that the creator of the tap already set the MAC
appropriately, so it doesn't modify it.
But again, already-existing tap devices can't be used for interface
type='bridge' or type='network' (which also connects the tap to a bridge).
> 2. Under what circumstances does libvirt destroy and recreate the tap
> device instead of modifying its attributes?
Another detail that I've forgotten over the long time since I last
looked at this code. libvirt doesn't explicitly delete the tap device,
it just closes the device. In the case of tap devices that libvirt
itself created, they are automatically deleted when they are closed.
In the case of pre-existing tap devices (which again doesn't apply in
your use case), 1) libvirt assumes that the creator of the pre-existing
device has already set the MAC address to something appropriate, so it
doesn't attempt to change it, and 2) again libvirt won't explicitly
delete the tap device. If it was created as a persistent device, then
closing it doesn't cause it to be auto-deleted, but if the original
creator of the tap device didn't create it as persistent, and no other
process has an open handle for the device, then again closing the device
will auto-delete it.
But again, for your use case (where the tap is connected to a bridge)
the creator of the tap device is always libvirt, and so it will always
be auto-deleted when libvirt closes the final handle it has open on the
device.
> Looking forward to your insights!
>
> Best regards,
> Xuda Zhang
