Re: Investigating MAC Address Conflict Resolution in libvirt: Log Analysis and Code Location Inquiry

Hi Laine, You mentioned: However, the documentation does not *explicitly *state that already-existing tap devices *cannot *be used for interface type='bridge' or interface type='network'. 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(a)laine.org&gt; 于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. > > > > 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 > >