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@xxxxxxxxx <mailto: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
