[Engine-devel] Network Wiring

[Dan Kenigsberg]

On Thu, Nov 15, 2012 at 02:43:23PM +0200, Yaniv Kaul wrote:
> On 11/15/2012 02:33 PM, Itamar Heim wrote:
> >On 11/15/2012 02:29 PM, Dan Kenigsberg wrote:
> >>On Wed, Nov 14, 2012 at 02:12:07PM -0500, Simon Grinberg wrote:
> >>>>
> >>>>The intention is to use the new API VDSM.libvirtVm.updateVmInteface
> >>>>for
> >>>>performing the network rewire in a single command.
> >>>
> >>>What does it do? I could not find updateVmInteface in vdsm git.
> >>>Where is this defined?
> >>>
> >>>It's critical.
> >>>
> >>>- You can change the interface directly by moving the VM from
> >>>one network to another
> >>>- You can do that but toggle the ling state so the VM will be aware.
> >>>
> >>>Which if these two?
> >>>If you do only the first then it's not the common use case. In
> >>>most cases you must toggle the link status to the VM.
> >>>This will cause:
> >>>1. Speed negotiation + arp request that also informs the
> >>>switched about the change
> >>>2. In case it's DHCP (which most likely the case for guests)
> >>>it will trigger new DHCP request.
> >>>
> >>>If you don't baaad things will happen :)
> >>
> >>I think that baaaaad things are going to happen anyway. In "baaaaad
> >>things", I mean "stuff that require guest intervension".
> >>
> >>The guest may be moved from one subnet into another one, maybe on
> >>different VLAN or physical LAN. We can not expect that the applications
> >>running on it will be happy about these changes. A similar case appears
> >>if we rewire the network while the VM is down (or hibernated). When the
> >>VM is restarted, it is going to use mismatching IP addresses.
> >>
> >>You are right that it may make sense to request an new IP address after
> >>the rewiring, however, a little test I just did on my desktop
> >>showed that
> >>dhclient does not initiate a new request just because the carrier
> >>dropped for few seconds. So we should try harder if we want to refresh
> >>dhcp after rewiring: I think that it would be cool to have a
> >>guest agent verb
> >>that does it.
> 
> Blame your OS if it doesn't do media sensing at all (or correctly).

Media is sensed:

Nov 15 14:15:46 kernel: [3379655.213183] e1000e: eth0 NIC Link is Down
Nov 15 14:15:52 kernel: [3379661.265946] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
Nov 15 14:15:52 kernel: [3379661.265951] e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO

but dhcp does not cancel its leases due to this. And I would not expect it to:
my dhcp server could change without carrier loss (e.g. vlan change on my
nearest switch, or dhcp reconfiguration)

> 
> >
> >shouldn't this simulate a link disconnect/connect event to the OS?
> 
> I sincerely hope it does.

Itamar, what is "this"? Setting link state to down does just that.

I was suggesting a guest agent verb that clears all pending dhcp leases after
the guest is connected again.

Dan.