[Users] Customizing node configuration

[Ryan Barry]

> 
> From: users-bounces at ovirt.org (mailto:users-bounces at ovirt.org) <users-bounces at ovirt.org (mailto:users-bounces at ovirt.org)> on behalf of Allen Belletti <allen at ggc.edu (mailto:allen at ggc.edu)>
> Sent: Wednesday, October 02, 2013 4:40 PM
> To: users at ovirt.org (mailto:users at ovirt.org)
> Subject: [Users] Customizing node configuration
> 
> Hello All,
> 
> I've been searching the archives and not yet managed to find anything on the subject, so I'm hoping that someone can point me in the right direction.
> 
> I am using nodes with Intel 10G network cards. The driver for these cards has been tweaked to complain (and fail to start the interface) if a non-Intel approved optical transceiver is in use. It's easy to override with the following options:
> 
> ixgbe.allow_unsupported_sfp=1
> 
> The usual ways of doing this are either to place it on the kernel command line at boot time, or in /etc/modprobe.d/ixgbe.conf where it would read "options ixgbe allow_unsupported_sfp=1". Unfortunately I have no idea how to make either of these permanent on an oVirt node.
> 
> I'm running the ovirt-node-iso-3.0.1-1.0.2.vdsm.el6.iso image. It has an /etc/modprobe.d directory where changes do not persist across reboots. It also has /config/etc where I've added modprobe.d and modprobe.d/ixgbe.conf. By adding this file to /config/files, I've been able to make it appear in /etc/modprobe.d at boot time. This has no effect. It appears to take place after the ixgbe driver has already been started. If I "rmmod ixgbe" and "modprobe ixgbe" manually, it works fine.
> 
> So the general question is, how do I make configuration changes which persist across reboots? Surely others have run into the same situation when trying to support specific devices.
> 
rc.local is probably the easiest way for now. There's a patch at http://gerrit.ovirt.org/#/c/19811/1 which gives us the ability to arbitrarily modify boot loader arguments, but I'm not sure that we have any plans to add a field in the TUI to do so, though it may be a good idea, since this is coming up more and more often.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20131002/42be69e5/attachment-0001.html>