qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] sync NIC's MAC maintained in NICConf as soon as e


From: Zhanghaoyu (A)
Subject: Re: [Qemu-devel] [RFC] sync NIC's MAC maintained in NICConf as soon as emualted NIC's MAC changed in guest
Date: Thu, 26 Sep 2013 03:42:50 +0000

>> 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.
>>
>> 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 2. sync NIC's (more 
>> precisely, queue) MAC to corresponding NICConf in NIC's migration load 
>> handler
>>
>> Any better ideas?
>
>As Michael points out. The only possible solution is to use do it inside the 
>guest instead of qemu ( and using a pv device). You can have a look at my RFCs 
>in http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01127.html
>which let virtio driver send the gARP. Xen, Hyperv does the same thing.
>
How about other emulated NICs, like etl8139, etc. ?

>The point is qemu does not know how the macs was used. So your method only 
>solves the issue partially becuase:
>
>- A card can have several macs, see virtio_net and e1000's mac table and it 
>can be overflowed also.
>- Vlan could be used so we need to send tagged gARP instead of untagged.

Does the emulated NIC in qemu have knowledge of all of its MACs?
We can provide an interface nic_announce_self(NetClientState *nc, uint8_t 
*mac_addr) which will try several times to send RARP just as same as 
what qemu_announce_self does, all emulated NICs' migration load handler can 
call nic_announce_self to announce itself for its all MACs.


>>
>> Thanks,
>> Zhang Haoyu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]