[Ovirt-devel] [PATCH] Add support for vendor hooks during ovirt-early start()

Ryan Harper ryanh at us.ibm.com
Tue Nov 17 14:59:53 UTC 2009


* Alan Pevec <apevec at redhat.com> [2009-11-17 08:16]:
> > > The ovirt-early script uses the standard ip= and ipv6= kernel command line
> > > options to bring up autoconfigured network interfaces.  The interface to
> > > bring up can be specified using the standard BOOTIF= kernel cmdline arg.
> > > So what you're talking about should work fine, as both ip= and ipv6= both
> > > support dhcp as an argument.
> > Sure, except AFAICT, this won't bring up networking until after we've
> > attempted to mount /config ... which is of course too late if we're
> > using an iscsi "local" disk.
> 
> right, ovirt-early is only parsing ip parameters, they're used for the firstboot configuration in stand-alone mode.
> 
> But let me try to understand the use-case here: is this PXE boot of the node image with /config on iSCSI ?
> B/c with iSCSI root networking must be brought up even earlier in initrd, right?

Originally we were iscsi firmware booting (iscsi_ibft.ko module to pass
iscsi params from firmware to Linux).  However, the initrd isn't
quite cut out for that; especially considering we'd need to do that
complex network config (bridged bonding pair) prior to connecting to
iscsi lun.  This forced me to move the connection from the initrd into
ovirt-early.

> In any case, for boot parameters we should reuse or make compatible with Dracut parameters http://sourceforge.net/apps/trac/dracut/wiki/commandline
> 
> > Oddly enough, we pxe from our 1g nics, but want to bond the 10g
> > nics...
> > I'd prefer specifying input for creating a bond, or bonds...
> 
> I guess bonding should be added to Dracut as well, let's propose it there.
> Dracut has bridge parameter which could be extended: http://sourceforge.net/apps/trac/dracut/wiki/commandline#Bridging
> 

Yeah, this looks reasonable if we add bonding.  Something like:

bond=<bondname>,<primary_mac>,<secondary_mac>,<options>

I suppose we could use colons to remain consistent, but splitting up the
fields will be a bit more work.

One other item that we use is DHCP vendor options which require the use
of DHCLIENTARGS.  Not sure if it's reasonable to add a DHCP parameter
that we might be able to use to pass in something like DHCLIENT args?
Besides the args, not sure how many other DHCP options we might want in
a dhcp= parameter.

We'd also want ip= , bond=, and bridge= to be processed in in such a
way as to allow for building the bond, creating the bridge with the bond
as the port and then applying the ip= config to the bridge.  Something
like:

ip=dhcp bond=bond0,00:11:22:33:44:55,00:11:22:33:44:66,'mode=6' \
bridge=brbond0:bond0 dhcp=args="-cf /etc/isan-dhcp.conf -I ISAN" \
iscsi=192.168.68.21::::

would be sufficient to bring up the connection.



> > BONDIF=bond0,bond1
> > bond0_MACS=$primary_mac,$secondary_mac
> > bond0_OPTIONS="mode=6 miimon=100 use_carrier=1"
> > bond0_PROTO="dhcp"
> > bond0_ONBOOT="yes"
> > bond1_MACS=$primary_mac,$secondary_mac
> > bond1_OPTIONS="mode=6 miimon=100 use_carrier=1"
> > 
> > We'd also need bridging parameters so we can configure a bridge with
> > the
> > bond port...
> > BRIDGEIF=brbond0
> 
> > > >> ... But regardless, it is probably worth creating an easy to use interface
> > > >> for vendors to add their own init scripts in without needing to duplicate
> > > >> code, and trampling on ovirt-early.  Perhaps an
> > > >> /etc/insert-your-vendor-script-here.d directory that ovirt-early and
> > > >> ovirt-post reads and executes functions from?  That would provide an easy
> > > >> way to drop in custom functionality and would also not require a new
> > > >> kernel cmdline param.  Thoughts?
> > > > 
> > > > That does seem cleaner; though I do still like having a way to choose
> > > > which set of vendor scripts to run via kernel parameter.  We'd like to
> > > > have a single iso image that we could support different types of startups.
> 
> There's already similar hooks folder /etc/ovirt-config-boot.d/ (scripts there are executed after upgrade).
> What about /etc/ovirt-early.d/ where vendor could put pre-* and post-* scripts and parameter would then select one or more scripts to execute:
>             ovirt_early=*)
>             i=${i#ovirt_early=}
>             ovirt_early=$(echo $i|tr ",:;" " ")
>             ;;
> EARLY_DIR=/etc/ovirt-early.d
> for hook in $ovirt_early; do
>   pre="$EARLY_DIR/pre-$hook"
>   if [ -e "$pre" ]; then
>     . "$pre"
>   fi
> done
> 
> ...
> 
> for hook in $ovirt_early; do
>   post="$EARLY_DIR/post-$hook"
>   if [ -e "$post" ]; then
>     . "$post"
>   fi
> done

Looks good; let me give that a try and post a patch.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com




More information about the ovirt-devel mailing list