[Engine-devel] Network Wiring

[Simon Grinberg]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, November 15, 2012 3:36:02 PM
> Subject: Re: [Engine-devel] Network Wiring
> 
> 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

If you go trough link state toggle then I think it should be enough.

You are right, lot's of things get go wrong when you move a VM from network to network, but at least we did inform the OS, and the switches in the new network will now know there is a new MAC, the rest will have to wait until (and if) will support guest IP stetting. 


> 
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>