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