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
