qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [V5 PATCH 0/4] Send gratuitous packets by guest


From: Jason Wang
Subject: Re: [Qemu-devel] [V5 PATCH 0/4] Send gratuitous packets by guest
Date: Tue, 27 Mar 2012 11:40:55 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

On 03/27/2012 06:10 AM, Anthony Liguori wrote:
On 03/16/2012 03:54 AM, Jason Wang wrote:
This an update of series that let guest and qemu to be co-operated to
send gratuitous packets when needed such as after migration, loadvm
and continuing.

As it's hard for qemu to track the network configuration in guest such
as bondings, vlans or ipv6. So current gratuitous may not work under
those situations.

Can you be more specific about the failure scenarios?

The failure can happen when:

- Guest does not use primary mac address. Current qemu only send rarp packets for primary mac address. This looks could be solved by iterating nic with mac address table, but their size are limited and guest could use all-uni/promisc mode to use more mac addresses. So it's almost impossible to track all addresses in qemu side.

- Guest have some network configuration such as 802.1Q vlan, in this case, we need to send tagged gratuitous packet which qemu can't handle.

The point is qemu does not know the network configuration in guest or how mac addresses are used, so it's better for us to let guest choose the correct way to do this if they can. If guest could not do the announcement, the rarp packets would be sent as in the past.

Does this mean that migration cannot work today with guests using ipv6? I don't think just pushing this to the guest is an acceptable solution in the short term.


I haven't check, but w/o this patch a ipv4 rarp would be sent even guest are using ipv6; w/ this patch, a ipv6 neighbor advertisement would be sent by guest which looks pretty reasonable.

Did you see any drawbacks of this method? Xen and hyper-v also let guest to send gratuitous packet for their para-virtualized network card.
Are there scenarios we cannot handle no matter what in the host? Does this mean that for emulated drivers, we're completely out of luck?


A possible improvement but not a final solution is to send garp for all address in the mac table I think.
Regards,

Anthony Liguori




reply via email to

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