Thread (18 messages) 18 messages, 6 authors, 2011-07-27

Re: IPv6: autoconfiguration and suspend/resume or link down/up

From: Stephen Hemminger <hidden>
Date: 2011-07-25 03:26:15

On Sun, 24 Jul 2011 10:35:58 +0200
Nicolas de Pesloüan [off-list ref] wrote:
Le 24/07/2011 02:18, Herbert Xu a écrit :
quoted
On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
quoted
Would it be possible to do live migration without dropping carrier
or setting interface down?
I think LM uses the same mechanism as suspend and resume so whatever
happens in one case will happen in the other case as well.
So we need to distinguish between two kind of link events:

1/ Really having the link goes down then up. This should trigger a renegotiation.

2/ Having the system suspend then resume :
2a/ This should trigger link down/link up events to force a renegotiation, for normal suspend/resume 
where the network might have changed between suspend and resume.
2/ This should *not* trigger link down/link up events to avoid a renegotiation (for live migration) 
because it is assumed that the network didn't change while suspended.

Can't we allow the user to set a global "link-down-link-up-timeout" and only force a renegotiation 
if the time between link down and link up events is longer than this timeout? Normal user would set 
this timeout close to 0 (default value). Live migration user would set this timeout to about twice 
the time it normally takes to do a live migration. That way, in a VM environment, if the 
suspend/resume cycle happens to take far more than a normal live migration time, the kernel would 
renegotiate, which sounds reasonable, from my point of view.
I hate building infrastructure where it is not needed.

Since virtual machines should be using virtio network devices, shouldn't
the suspend/resume in that device just work. It doesn't need to drop the link.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help