Re: [SSI-devel] iscsi support, secondary IPs

[Brian J. W. <Bri...@hp...>]

Martin Glass wrote:
>   Here are the aspects I see that need some consideration:
> 
> 1) Have cluster_mkinitrd support one or more --iscsid options that can
> get the appropriate iscsi_mod, iscsid, /etc/initiatorname.iscsi and
> /etc/iscsi.conf files, and add the appropriate lines to linuxrc.  Are
> there any preferred syntaxes for this?

In the next release, I plan to make the kernel-ssi RPM's post-install 
script automatically generate the initrd and create the grub.conf 
stanza, like all of Red Hat's kernel RPMs do. A side-effect of this is 
that nothing unusual can be passed to mkinitrd on the command line. I 
made a small change to one of Red Hat's scripts to pass mkinitrd the 
--cfs option, but I prefer not to complicate it much more than that. 
Keeping this in mind, it might be better if mkinitrd could get the iscsi 
information from configuration files.

If you like, you can add command-line options to mkinitrd to override 
the default locations of iscsi files such as /etc/initiatorname.iscsi 
and /etc/iscsi.conf. This gives power users more flexibility, without 
complicating things for the novices.

BTW, don't edit openssi/openssi-tools/sysadmin/cluster_mkinitrd in the 
repository. It's deprecated. Notice that on an installed system, 
cluster_mkinitrd is just a symlink to mkinitrd. I plan to do away with 
the symlink soon. Edit openssi/distro-pkgs/redhat/mkinitrd/mkinitrd, 
instead. Since this is the base mkinitrd command and it must work 
unmodified for generating a base initrd, be sure that your additional 
code is only run if $ssi_boot is set.

Aneesh, I noticed that you checked in the Debian equivalent of mkinitrd. 
Can I do a 'cvs rm' of openssi/openssi-tools/sysadmin/cluster_mkinitrd?

> PS. One of the pitfalls currently with booting the root filesystem from
> iscsi means that you can't free the initrd, since iscsid is running on
> it and providing the required access to the root device.

Perhaps we can figure out a solution to this problem in the future. For 
now, be sure you only start iscsid on the root node and any root 
failover nodes. They should only be nodes marked as potential CLMS 
masters. That way, not all nodes have a chunk of their memory eaten up 
by an unreleasable ramdisk.

Brian