qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V7 0/5] Send the gratuitous by guest


From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH V7 0/5] Send the gratuitous by guest
Date: Mon, 11 Mar 2013 15:45:48 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3

On 03/08/2013 07:03 PM, Stefan Hajnoczi wrote:
> On Thu, Mar 07, 2013 at 12:52:42PM +0200, Michael S. Tsirkin wrote:
>> On Thu, Mar 07, 2013 at 06:33:30PM +0800, Jason Wang wrote:
>>> On 03/07/2013 06:25 PM, Michael S. Tsirkin wrote:
>>>> On Thu, Mar 07, 2013 at 06:13:41PM +0800, Jason Wang wrote:
>>>>> On 03/07/2013 06:04 PM, Michael S. Tsirkin wrote:
>>>>>> On Thu, Mar 07, 2013 at 04:23:46PM +0800, Jason Wang wrote:
>>>>>>> This series tries to let guest instead of qemu to send the gratuitous 
>>>>>>> packets
>>>>>>> after migration when guest is capable of doing this. This is needed 
>>>>>>> since it's
>>>>>>> impossible for qemu to keep track of all configurations (e.g 802.1Q) 
>>>>>>> and mac
>>>>>>> addresses (more than one mac address may be used by guest). So qemu 
>>>>>>> can't build
>>>>>>> gratuitous packets for all those configurations properly. The only 
>>>>>>> solution is
>>>>>>> let guest driver who knew all needed information to do this.
>>>>>>>
>>>>>>> The series first introduces a new runstate which just tracks the state 
>>>>>>> when the
>>>>>>> migration is finished and guest is about to start. And then we can just 
>>>>>>> trying
>>>>>>> to notify the guest to send the GARP after changing from this state to
>>>>>>> running. A model specific announcing method were also also introduced 
>>>>>>> to let
>>>>>>> each kinds of nic do its own notification. When there's no such method 
>>>>>>> register
>>>>>>> for the nic, the old style of sending RARP were kept. And the last two 
>>>>>>> patches
>>>>>>> implemented the virtio-net method of notification.
>>>>>> Do we want to retry SELF_ANNOUNCE_ROUNDS?
>>>>> Yes, we do the announcement several times like in the past.
>>>>>>> Changes from V6:
>>>>>>> - introduce a new runstate instead of using a global variable check the 
>>>>>>> state
>>>>>>>
>>>>>>> Changes from V5:
>>>>>>> - use a global variable to decide whether an announcement is needed 
>>>>>>> after migration
>>>>>>> - align with virtio spec and let guest ack the announcement 
>>>>>>> notification through
>>>>>>>   control vq instead of config status writing
>>>>>>>
>>>>>>> Changes from V4:
>>>>>>> - keep the old behavior that send the gratuitous packets only after 
>>>>>>> migration
>>>>>> I wonder why it's a sane thing to do. How about simply sending the event 
>>>>>> after load?
>>>>> The aim is to limit the change of the behaviour to focus on migration.
>>>>> We may also need this after cont,
>>>> Hmm why after cont?
>>> If we stop the vm for a long period, the mac will be missed in the
>>> forward table of the bridge also.
>> Hmm okay, needs some thought.
> One case where a physical machine is offline for a long time is
> Wake-on-LAN.  Broadcast is used exactly for this reason.
>
> If a switch receives a packet to an unknown MAC it must broadcast.  If a
> host doesn't have a IP-to-MAC table entry (due to timeout) it must send
> an ARP request.
>
> So I think this is all handled by existing behavior.  If other hosts
> have forgotten about the VM's MAC they will send an ARP request, which
> the VM will respond to if it is running again.
>
> Stefan

Right, thanks for the clarification. So the only thing qemu needs to
care is migration.



reply via email to

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