>> >> >> Hi, all >> >> >> >> >> >> Do live migration if emulated NIC's MAC has been changed, RARP >> >> >> with wrong MAC address will broadcast via qemu_announce_self in >> >> >> destination, so, long time network disconnection probably happen. >> >> > >> >> >Good catch. >> >> > >> >> >> I want to do below works to resolve this problem, 1. change >> >> >> NICConf's MAC as soon as emulated NIC's MAC changed in guest >> >> > >> >> >This will make it impossible to revert it correctly on reset, won't it? >> >> > >> >> You are right. >> >> virsh reboot <domain>, or virsh reset <domain>, or reboot VM from guest, >> >> will revert emulated NIC's MAC to original one maintained in NICConf. >> >> During the reboot/reset flow in qemu, emulated NIC's reset handler >> >> will sync the MAC address in NICConf to the MAC address in emulated NIC >> >> structure, e.g., virtio_net_reset sync the MAC address in NICConf to >> >> VirtIONet'mac. >> >> >> >> BTW, in native scenario, reboot will revert the changed MAC to original >> >> one, too. >> >> >> >> >> 2. sync NIC's (more precisely, queue) MAC to corresponding >> >> >> NICConf in NIC's migration load handler >> >> >> >> >> >> Any better ideas? >> >> >> >> >> >> Thanks, >> >> >> Zhang Haoyu >> >> > >> >> >I think announce needs to poke at the current MAC instead of the default >> >> >one in NICConf. >> >> >We can make it respect link down state while we are at it. >> >> > >> >> NICConf structures are incorporated in different emulated NIC's >> >> structure, e.g., VirtIONet, E1000State_st, RTL8139State, etc., since so >> >> many kinds of emulated NICs, they are described by different structures, >> >> how to find all NICs' current MAC? >> >> >> >> Maybe we can introduce a pointer member 'current_mac' to NICConf >> >> structure, which points to the current MAC, then we can find all current >> >> MACs from NICConf.current_mac. >> > >> >I wouldn't make it a pointer, just a buffer with the mac, copy it there. >> >Maybe call it "softmac" that's what it is really. >> > >> >> Can we broadcast the RARP with current MAC in NIC's migration load >> >> handler respectively? >> >> >> >> Thanks, >> >> Zhang Haoyu >> > >> >It's not so simple, you need to retry several times. >> > >> Could you make a statement for 'retry several times' ? >> Is it the process of retrying several times to sending RARP in >> qemu_announce_self_once? > >yes > >> 'broadcast the RARP with current MAC in NIC's migration load handler >> respectively' is distributing the job of what qemu_announce_self does to >> every NIC's migration load handler, e.g., in virtio NIC's migration load >> handler virtio_net_load, we can create a timer to retry several times to >> send ARAP with current MAC for this NIC, just as same as qemu_announce_self >> does. > >I don't see a lot of value in this yet. > In my opinion, it's not so good to introduce a 'softmac' member to NICConf, which is not essential function of NICConf. And, distributing the job of what qemu_announce_self does to every NIC's migration load handler has no disadvantages over qemu_announce_self, maybe more immediately to updating the forwarding table of switches/bridges.
>> >> >Happily recent linux guests aren't affected since they do announcements >> >> >from guest. >> >> > >> >> >-- >> >> >MST