----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Yaniv Kaul" <yk...@redhat.com> > Cc: "Simon Grinberg" <si...@redhat.com>, engine-devel@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel