On 3/18/25 15:10, Daniel P. Berrangé wrote: > On Tue, Mar 18, 2025 at 02:58:18PM +0100, Michal Privoznik via Devel wrote: >> From: Michal Privoznik <mprivozn@xxxxxxxxxx> >> >> If a guest changes MAC address on its vNIC, then QEMU emits >> NIC_RX_FILTER_CHANGED event (the event is emitted in other cases >> too, but that's not important right now). Now, domain XML allows >> users to chose whether to trust these events or not: >> >> <interface trustGuestRxFilters='yes|no'/> >> >> For the 'no' case no action is performed and the event is >> ignored. But for the 'yes' case, some host side features of >> corresponding vNIC (well tap/macvtap device) are tweaked to >> reflect changed MAC address. But what is missing is reflecting >> this new MAC address in domain XML. >> >> Basically, what happens is: the host sees traffic with new MAC >> address, all tools inside the guest see the new MAC address >> (including 'virsh domifaddr --source agent') which makes it >> harder to match device in the guest with the one in the domain >> XML. >> >> Therefore, report this new MAC address as another attribute of >> the <mac/> element: >> >> <mac address="52:54:00:a4:6f:91" guestAddress="00:11:22:33:44:55"/> > > What happens when the guest OS reboots, or rather the > machine is reset ? Will the virtio-net device revert > back to its original configured MAC, or if the guest > MAC change persistent until QEMU is shut off. In my testing, when the domain is reset then the MAC address is changed back. > > If the former, we would need to be clearly guestAddress > at reset time. Yes, and this is handled properly, because as of v8.9.0-rc1~27 the MAC address is refreshed more often. > > I wonder a little whether 'address' has any purpose > at all if the guest MAC is changed ? ie should we > just be updating 'address' in-place, and letting > apps request "inactive" XML if they want the original > configured MAC ? > > The 'address' is used by the NW filter code to apply > rules tied to guest MAC, which presumably need updating > if the guest changes its MAC And so does TC rules when QoS is in place. Updating MAC address in place is what I initially had in my RFC patches but Marting proposed adding new attribute instead. https://lists.libvirt.org/archives/list/devel@xxxxxxxxxxxxxxxxx/thread/U274MIGIYRGFTPCAPG237JH3P2EGCWIG/#IWFCKHLWHAOIJPJGYKJE7X666FODUM53 Michal
