On 2/5/25 1:39 AM, Xuda Zhang wrote:
> 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).
>
> However, the documentation does not *explicitly *state that already-
> existing tap devices *cannot *be used for interface type='bridge' or
> interface type='network'.

Any reasonably large piece of software has many many behaviors that
aren't explicitly stated.

> 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.

That's basically what I told you. It's unfortunate that I ever brought
up the idea of pre-existing tap devices, since they are only allowed in
one very narrow use case.

> 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.

Correct.

> Additionally, each time the VM starts, a new tap device is created with
> slight variations, likely derived from the VM's MAC address.

I guess you mean "... with a MAC address that is the same as the guest
interface's MAC except the first byte is changed to 0xFE." If so then yes.


> Would you agree with this assessment?

Yes.

> Best regards,
>
> Xuda Zhang
>
>
>
> Laine Stump <laine@laine.org <mailto:laine@laine.org>> 于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
>