9:29 p.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Yaniv Kaul" <ykaul(a)redhat.com>
Cc: "Simon Grinberg" <simon(a)redhat.com>, engine-devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel