--3oCie2+XPXTnK5a5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hey all,
As you have all seen I have been putting in the required elements of ppc64
iSeries support for SystemImager. This has been done by forward porting a
working version of OSCAR on iSeries that was done as a summer project at
IBM.
The iSeries (and potential zSeries) folks want to do something a little
different with image transfer than is done in the x86 case. Let me explain
a little background on the platform so this all makes sense.
(I'll admit I'm not an expert here, so statements might not all be as
accurate as they could be.)
iSeries is the new name for the AS/400 machines. These are "small
mainframes" in many ways. They support Logical Partitioning like the
zSeries mainframes (the whole 10,000 Linux images running at once idea), but
on a smaller scale. On and iSeries box (which is a 64bit PowerPC chip),
there is a low level operating system (OS/400) which abstracts the hardware
to the Logical Partitions. These LPARs can then run Linux, AIX, or other=
=20
PPC based OSes.
| | | | | |
| SuSE | | RedHat | | |
| Linux | AIX5L | Linux | | |
| | | | | |
| | | | | |
-----------------------------------------------
| |
| OS/400 |
| |
-----------------------------------------------
| |
| Physical Devices |
| |
For iSeries the abstracted diskes look like IDE devices to the Linux
partition. They are attached to the Linux Image via a set of OS/400
commands.
The iSeries team has a version that works the traditional way in
SystemImager, but would also like to use another methodology as well.
1) Build Image on the Image Server (which is an iSeries Image).
2) Attach the would be client's disks to the Image Server
3) Split the autoinstall script into 2 halves.
4) 1st half partitions the newly attached drives, formats them, and copies
the image to them.
5) Dettach the client's disks from the Image Server
6) Attach the client's disks to the client LPAR
7) Boot the client.
8) Have the client run the 2nd half of the autoinstall script (which sets up
hardware, network, bootloader etc.)
This requires that the 1st half of the install script actually has different
devices for partitioning and formatting than would normally be in there.=20
(I.E. there is a disconnect between what ends up in the fstab, and what is
done during partitioning). It also requires that the filehandle used to
write out the content of the script is parametrized by the subroutines which
generate the autoinstall script so that it could be changed for each
subroutine. (It would probably make sense to build a top level sub with
functional steps in it that we could break out of based on architecture.)
The advantages for large platforms for this methodology is that the client
node only needs one bringup (vs. a bring up, reboot, and rebring up) to be
put into production. It then makes it really easy to deploy a large number
of virtual systems very quickly.
The way that this was done in the back port for iSeries, was to build a copy
of Server.pm as Server/iSeries.pm, and have the code branch if --vdisk was
passed to mkautoinstallscript. I could do that solution, which would be
minimally invasive on the existing code, however wouldn't really be solving
the problem genericly for other platforms. The local disk copy is also
what the Sherbrooke University folks are looking at for building NFS roots
from images, so it would be useful to abstract the building of the
autoinstall script to support that as well.
At any rate, I'm looking for comments about the right way to go about this.
So please respond when given a chance.
-Sean
--=20
_______________________________________________________________________
=09
Sean Dague [EMAIL PROTECTED] http://dague.net
There is no silver bullet. Plus, werewolves make better neighbors than
zombies, and they tend to keep the vampire population down.
_______________________________________________________________________
--3oCie2+XPXTnK5a5
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9bRgbSamXem9TdyYRAv78AJ9lHwlKcGAVeOZR7ya31Z9srTBGWgCeKGRl
dDNrp9e/Jw7oa2IYOkF+USY=
=ElGK
-----END PGP SIGNATURE-----
--3oCie2+XPXTnK5a5--
-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
