qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"paolo.bonzini@gmail.com" <paolo.bonzini@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Eric Blake <eblake@redhat.com>, Gleb Natapov <gleb@redhat.com>
Cc: Luonengjun <luonengjun@huawei.com>,
	"Huangweidong (C)" <weidong.huang@huawei.com>,
	"chenliang (T)" <chenliang88@huawei.com>
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 12:28:19 +0800	[thread overview]
Message-ID: <5243B7E3.1050304@redhat.com> (raw)
In-Reply-To: <D3E216785288A145B7BC975F83A2ED1043EE029E@szxeml556-mbx.china.huawei.com>

On 09/26/2013 11:42 AM, Zhanghaoyu (A) wrote:
>>> 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. ?

A possible solution is to toggle the link status after migration and
make use of arp_notify. But it may make the migration aware of guest.
Xen guys has posted this idea but get rejected upstream.
>
>> 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?

Looks not. For e1000, if the number of macs tracked by guest is greater
than the number of RAR, it will use unicast promiscuous mode. For
virtio-net, the mac table can be overflowd, and then it will allow all
unicast mac address to be received.

So emulated NIC may not have knowledge of all its MACs, and more
important: how it could be used.
> 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.

See http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01130.html.
>
>>> Thanks,
>>> Zhang Haoyu

      reply	other threads:[~2013-09-26  4:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-22  8:35 [Qemu-devel] [RFC] sync NIC's MAC maintained in NICConf as soon as emualted NIC's MAC changed in guest Zhanghaoyu (A)
2013-09-22  8:59 ` Michael S. Tsirkin
2013-09-25  9:02   ` Zhanghaoyu (A)
2013-09-25  9:31     ` Michael S. Tsirkin
2013-09-25  9:55       ` Zhanghaoyu (A)
2013-09-25 10:06         ` Michael S. Tsirkin
2013-09-25 10:14           ` Zhanghaoyu (A)
2013-09-25 10:53             ` Michael S. Tsirkin
2013-09-25 11:39               ` Markus Armbruster
2013-09-25 12:21                 ` Michael S. Tsirkin
2013-09-26  1:27                   ` Zhanghaoyu (A)
2013-09-26  7:18                   ` Markus Armbruster
2013-09-26  3:24 ` Jason Wang
2013-09-26  3:42   ` Zhanghaoyu (A)
2013-09-26  4:28     ` Jason Wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5243B7E3.1050304@redhat.com \
    --to=jasowang@redhat.com \
    --cc=chenliang88@huawei.com \
    --cc=eblake@redhat.com \
    --cc=gleb@redhat.com \
    --cc=haoyu.zhang@huawei.com \
    --cc=luonengjun@huawei.com \
    --cc=mst@redhat.com \
    --cc=paolo.bonzini@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weidong.huang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).