On Tue, Mar 18, 2025 at 03:31:30PM +0100, Michal Prívozník wrote: > 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. Hmmm, so we avoid confusing existing apps that don't expect MAC to ever change, which I guess I can see as a use case. It also gives apps an indication of what the MAC will revert back to on machine reset, which is NOT guaranteed the same as what the inactive config contains. I find the latter compelling as a reason for reporting both > https://lists.libvirt.org/archives/list/devel@xxxxxxxxxxxxxxxxx/thread/U274MIGIYRGFTPCAPG237JH3P2EGCWIG/#IWFCKHLWHAOIJPJGYKJE7X666FODUM53 Heh, 2 years old, no wonder I couldn't quickly find it :-) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
