----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "Simon Grinberg" <simon@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