[RFC] dropping network hotplug support from network service

[Bill Nottingham]

I'm considering drop the network hotplug support from the 'network'
service. This is the code that would automatically run ifup when a new
network device appeared, if there was a configuration for it.

The supported solution would be to use NetworkManager for these usage
cases (or wicd, or netplugd, or conman...) Alternatively, just run
ifup yourself.

Currently, this would happen in the following cases:
1. USB and/or expresscard hotplugged ethernet/wireless
2. PCI hotswap of a network card
3. Runtime addition of network interfaces in virtual system
4. Admin manually removes and reloads a driver module

For #1, those systems are generally better served by NM.
For #2, this is something with such heavy admin interaction that I
would suspect that it would be preferred to handle it manually. (Also,
swapping hardware likely invalidates the configuration in any case.)
For #3, you're unlikely to have a configuration written for a freshly
available device.
For #4, bringing up the device automatically can cause more issues
than it solves. (We've seen this happen for vlans, for example.)

I'm curious - are there people that still rely on this behavior? If so,
for what cases?

Thanks,
Bill

[Don Dutile]

On 06/20/2011 05:09 PM, Bill Nottingham wrote:
>  I'm considering drop the network hotplug support from the
> 'network'
>  service. This is the code that would automatically run ifup when a new
>  network device appeared, if there was a configuration for it.
>
>  The supported solution would be to use NetworkManager for these usage
>  cases (or wicd, or netplugd, or conman...) Alternatively, just run
>  ifup yourself.
>
>  Currently, this would happen in the following cases:
>  1. USB and/or expresscard hotplugged ethernet/wireless
>  2. PCI hotswap of a network card
>  3. Runtime addition of network interfaces in virtual system
>  4. Admin manually removes and reloads a driver module
>
>  For #1, those systems are generally better served by NM.
>  For #2, this is something with such heavy admin interaction that I
>  would suspect that it would be preferred to handle it manually. (Also,
>  swapping hardware likely invalidates the configuration in any case.)
>  For #3, you're unlikely to have a configuration written for a freshly
>  available device. 
sorry, I don't understand this statement....
but has me worried for virt hot add/remove of assigned devices

>  For #4, bringing up the device automatically can cause more issues
>  than it solves. (We've seen this happen for vlans, for example.) 
This is done
all the time (on KVM hosts) to take down PF driver & load 
PF+VF drivers for SRIOV-capable devices.

>  I'm curious - are there people that still rely on this behavior? If so,
>  for what cases?
>
>  Thanks,
>  Bill

[Bill Nottingham]

Don Dutile (ddutile(a)redhat.com) said: 
>  On 06/20/2011 05:09 PM, Bill Nottingham wrote:
>  > I'm considering drop the network hotplug support from the 'network'
>  > service. This is the code that would automatically run ifup when a new
>  > network device appeared, if there was a configuration for it.
>  >
>  > The supported solution would be to use NetworkManager for these usage
>  > cases (or wicd, or netplugd, or conman...) Alternatively, just run
>  > ifup yourself.
>  >
>  > Currently, this would happen in the following cases:
>  > 1. USB and/or expresscard hotplugged ethernet/wireless
>  > 2. PCI hotswap of a network card
>  > 3. Runtime addition of network interfaces in virtual system
>  > 4. Admin manually removes and reloads a driver module
>  >
>  > For #1, those systems are generally better served by NM.
>  > For #2, this is something with such heavy admin interaction that I
>  > would suspect that it would be preferred to handle it manually. (Also,
>  > swapping hardware likely invalidates the configuration in any case.)
>  > For #3, you're unlikely to have a configuration written for a freshly
>  > available device.
>  sorry, I don't understand this statement....
>  but has me worried for virt hot add/remove of assigned devices 
Essentially, hot-adding a virtual device would not bring the device
up automatically if you're using the old network service; you'd have
to run 'ifup' by hand.

>  > For #4, bringing up the device automatically can cause more
> issues
>  > than it solves. (We've seen this happen for vlans, for example.)
>  This is done all the time (on KVM hosts) to take down PF driver & load 
>  PF+VF drivers for SRIOV-capable devices. 
This would be a different device with a different hardware address,
correct?

Bill

[Don Dutile]

On 06/21/2011 01:52 PM, Bill Nottingham wrote:
>  Don Dutile (ddutile(a)redhat.com) said:
> > On 06/20/2011 05:09 PM, Bill Nottingham wrote:
> >> I'm considering drop the network hotplug support from the 'network'
> >> service. This is the code that would automatically run ifup when a new
> >> network device appeared, if there was a configuration for it.
> >>
> >> The supported solution would be to use NetworkManager for these usage
> >> cases (or wicd, or netplugd, or conman...) Alternatively, just run
> >> ifup yourself.
> >>
> >> Currently, this would happen in the following cases:
> >> 1. USB and/or expresscard hotplugged ethernet/wireless
> >> 2. PCI hotswap of a network card
> >> 3. Runtime addition of network interfaces in virtual system
> >> 4. Admin manually removes and reloads a driver module
> >>
> >> For #1, those systems are generally better served by NM.
> >> For #2, this is something with such heavy admin interaction that I
> >> would suspect that it would be preferred to handle it manually. (Also,
> >> swapping hardware likely invalidates the configuration in any case.)
> >> For #3, you're unlikely to have a configuration written for a freshly
> >> available device.
> > sorry, I don't understand this statement....
> > but has me worried for virt hot add/remove of assigned devices
>
>  Essentially, hot-adding a virtual device would not bring the device
>  up automatically if you're using the old network service; you'd have
>  to run 'ifup' by hand.
>  
hot-adding a VF-nic to a Linux kvm guest brings up the hot-added (VF) 
nic in the guest today.... am I missing what you mean?

> >> For #4, bringing up the device automatically can cause more
> issues
> >> than it solves. (We've seen this happen for vlans, for example.)
> > This is done all the time (on KVM hosts) to take down PF driver&  load
> > PF+VF drivers for SRIOV-capable devices.
>
>  This would be a different device with a different hardware address,
>  correct?
>  
Nope; typically start up an SRIOV device in PF-only mode (igb, for 
example), then do an rmmod igb; modprobe igb max_vfs=7;  same PF mac;
new VF mac's.

and as VF's are added & removed from guests, they may be removed & added
back to host.

>  Bill

[Bill Nottingham]

Don Dutile (ddutile(a)redhat.com) said: 
>  > Essentially, hot-adding a virtual device would not bring the
> device
>  > up automatically if you're using the old network service; you'd have
>  > to run 'ifup' by hand.
>  >
>  hot-adding a VF-nic to a Linux kvm guest brings up the hot-added (VF) 
>  nic in the guest today.... am I missing what you mean? 
It depends on the network system in use - if NetworkManager is running,
the guest will bring it up. If the old /etc/init.d/network service is
running, it will only bring it up if there's an ifcfg file for that
device (which is usually tied to the hardware address, but is sometimes
just tied to the device name.) 

>  >>> For #4, bringing up the device automatically can cause
> more issues
>  >>> than it solves. (We've seen this happen for vlans, for example.)
>  >> This is done all the time (on KVM hosts) to take down PF driver&  load
>  >> PF+VF drivers for SRIOV-capable devices.
>  >
>  > This would be a different device with a different hardware address,
>  > correct?
>  >
>  Nope; typically start up an SRIOV device in PF-only mode (igb, for 
>  example), then do an rmmod igb; modprobe igb max_vfs=7;  same PF mac;
>  new VF mac's.
>  
>  and as VF's are added & removed from guests, they may be removed & added
>  back to host. 
The MAC addresses in the VF are still pseudo-random, correct?

Bill

[Don Dutile]

On 06/21/2011 03:16 PM, Bill Nottingham wrote:
>  Don Dutile (ddutile(a)redhat.com) said:
> >> Essentially, hot-adding a virtual device would not bring the device
> >> up automatically if you're using the old network service; you'd have
> >> to run 'ifup' by hand.
> >>
> > hot-adding a VF-nic to a Linux kvm guest brings up the hot-added (VF)
> > nic in the guest today.... am I missing what you mean?
>
>  It depends on the network system in use - if NetworkManager is running,
>  the guest will bring it up. If the old /etc/init.d/network service is
>  running, it will only bring it up if there's an ifcfg file for that
>  device (which is usually tied to the hardware address, but is sometimes
>  just tied to the device name.)
>
> >>>> For #4, bringing up the device automatically can cause more issues
> >>>> than it solves. (We've seen this happen for vlans, for example.)
> >>> This is done all the time (on KVM hosts) to take down PF driver&   load
> >>> PF+VF drivers for SRIOV-capable devices.
> >>
> >> This would be a different device with a different hardware address,
> >> correct?
> >>
> > Nope; typically start up an SRIOV device in PF-only mode (igb, for
> > example), then do an rmmod igb; modprobe igb max_vfs=7;  same PF mac;
> > new VF mac's.
> >
> > and as VF's are added&  removed from guests, they may be removed&  added
> > back to host.
>
>  The MAC addresses in the VF are still pseudo-random, correct?
>  
depends on device vendor; some are based on PF value/prefix...

>  Bill

[Richard Z]

On Mon, Jun 20, 2011 at 05:09:55PM -0400, Bill Nottingham wrote:
>  I'm considering drop the network hotplug support from the
> 'network'
>  service. This is the code that would automatically run ifup when a new
>  network device appeared, if there was a configuration for it.
>  
>  The supported solution would be to use NetworkManager for these usage
>  cases (or wicd, or netplugd, or conman...) Alternatively, just run
>  ifup yourself.
>  
>  Currently, this would happen in the following cases:
>  1. USB and/or expresscard hotplugged ethernet/wireless 
>  For #1, those systems are generally better served by NM. 
still using this for ad-hoc WiFI networks very regularly. At some point
I would like to migrate to NM but rather often I hit bugs in NM that make
it necessary to fall back to the old solution.

Richard

---
Name and OpenPGP keys available from pgp key servers