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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH V7 0/5] Send the gratuitous by guest
Date: Fri, 8 Mar 2013 12:03:17 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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