Thank you
and you say ,"The unsolicited ARP is generated by the network frontend
whenever it is brought up, as would be the case upon resume."
that is , the guestos should be aware of its suspend-and-resume ,but xen
maybe support the transparent migration for the guestos, that is ,the
guestos does not know itself has been suspended ,is it?
but may be some action did the same thing in the net backend, is it ?
and fake_arp() has not been found, it is helpful ,even though ,i have
not found the code
could you or someone help me
i am still interested in the code for sending The unsolicited ARP
after migration
Thanks
Daniel Stodden 写道:
On Sun, 2008-03-09 at 10:50 +0800, tgh wrote:
hi
I try to understand to the mechanism of live migration, and I read the
code ,and have some confusion about the network live connection during
the migration,could you help me, i read the paper about the live
migration,it explaine that in a single switched LAN,host sends
unsolicited ARP,and in router case, broadcastARP will not be accecpted
,and migratedOS need to sends to the interfaces in the ARPcache,while in
a switched net,migrated OS holds the same MAC address,and network switch
could detect the change of location, i am confused about where the
code for all of these , could you give me some more detailed explanation
or tell me where the code for these
The unsolicited ARP is generated by the network frontend whenever it is
brought up, as would be the case upon resume. look out for something i
believe is called fake_arp (?) in netfront. This is a very simple
operation, btw.
Unicasting to peers listed in the ARP cache is, to my knowledge, not
performed. I believe the paper just outlines what the alternatives would
look like.
regards,
daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home