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.