Understood completely. I appreciate your patience. Best Regards, Xuda Zhang
Laine Stump <la...@redhat.com> 于2025年2月5日周三 21:41写道： > 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 <la...@laine.org <mailto:la...@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 > > > >
