mirror of https://github.com/tLDP/LDP
patched from author's github.com repository
Author contacted, responded quickly, provided the missing old files and confirmed that it was acceptable to comment out the reference to ../openMosix-2.6-HOWTO/openMosix-2.6-HOWTO-content.sgml Source available: https://github.com/KrisBuytaert/openmosix-howto
This commit is contained in:
parent
40a544910f
commit
4212b180ab
|
@ -36,13 +36,13 @@ author of Clump/OS.
|
|||
|
||||
<SECT1><TITLE>How does it work </TITLE>
|
||||
|
||||
<PARA> At boot-time, clump/os will
|
||||
<para> At boot-time, clump/os will
|
||||
auto-probe for network cards, and, if any are detected, try to configure
|
||||
them via DHCP. If successful, it will create a mosix.map file based on the
|
||||
assumption that all nodes are on local CLASS C networks, and configure
|
||||
MOSIX using this information.
|
||||
</para>
|
||||
<Para>
|
||||
<para>
|
||||
clump/os Release 4 best supports machines with a single connected network
|
||||
adapter. The MOSIX map created in such cases will consist of a single
|
||||
entry for the CLASS-C network detected, with the node number assigned
|
||||
|
@ -53,13 +53,13 @@ to the order in which network adapters are detected. (Future releases will
|
|||
support complex topologies and feature more intelligent MOSIX map
|
||||
creation.)
|
||||
</para>
|
||||
<Para>
|
||||
<para>
|
||||
|
||||
clump/os will then display a simple SVGA
|
||||
monitor (clumpview) indicating whether the node is configured, and, if it
|
||||
is, showing the load on all active nodes on the network. When you've
|
||||
finished using this node, simply press [ESC] to exit the interface and
|
||||
shutdown. </PARA>
|
||||
shutdown. </para>
|
||||
|
||||
<PARA> Alternatively, or if auto-configuration doesn't work for you, then
|
||||
you can use clump/os in Expert mode. Please note that clump/os is not a
|
||||
|
@ -196,7 +196,8 @@ information you need is somewhere on this page -- please read
|
|||
<PARA>
|
||||
<ITEMIZEDLIST>
|
||||
<LISTITEM><PARA><EMPHASIS>
|
||||
The CD-ROM doesn't boot</EMPHASIS>
|
||||
The CD-ROM doesn't boot
|
||||
</EMPHASIS>
|
||||
</PARA>
|
||||
<PARA>
|
||||
|
||||
|
@ -205,7 +206,7 @@ to boot from the CD-ROM drive; also make
|
|||
sure that the CD-ROM is the first boot device.
|
||||
</PARA>
|
||||
</LISTITEM>
|
||||
<LISTITEM
|
||||
<LISTITEM>
|
||||
<PARA><EMPHASIS>
|
||||
The SVGA interface doesn't work, or the display is incorrect
|
||||
</EMPHASIS></PARA>
|
||||
|
@ -242,7 +243,8 @@ and then configure MOSIX via setpe.
|
|||
advise us. We'd like to solve this problem, if
|
||||
possible, or at least document which network cards auto-probe correctly.
|
||||
</PARA>
|
||||
</LISTITEM><LISTITEM><PARA><EMPHASIS>
|
||||
</LISTITEM>
|
||||
<LISTITEM><PARA><EMPHASIS>
|
||||
Migrating processes generate errors ("Network Unreachable")
|
||||
</EMPHASIS>
|
||||
</PARA>
|
||||
|
@ -254,7 +256,8 @@ configured kernels -- even if you are using the
|
|||
all your nodes, but migrating processes
|
||||
generate errors, then please compare your master node's kernel
|
||||
configuration file with the R4.x kernel .config.
|
||||
</PARA></LISTITEM><LISTITEM><PARA><EMPHASIS>
|
||||
</PARA></LISTITEM>
|
||||
<LISTITEM><PARA><EMPHASIS>
|
||||
|
||||
Migrating processes generate errors ("Process migration failed:
|
||||
incompatible topology")
|
||||
|
@ -300,7 +303,7 @@ recommend doing so at this point.) </PARA>
|
|||
If you want to run clumpview, execute:
|
||||
<PROGRAMLISTING>
|
||||
open -s -w -- clumpview --drone --svgalib
|
||||
</PROgRAMLISTING>
|
||||
</PROGRAMLISTING>
|
||||
|
||||
|
||||
This will force the node into 'drone' mode (local processes will not
|
||||
|
|
|
@ -1,8 +1,7 @@
|
|||
<chapter id="Autodiscovery">
|
||||
<title>Autodiscovery</title>
|
||||
<title>2.4 Autodiscovery</title>
|
||||
|
||||
<sect1><title>Easy Configuration</title>
|
||||
|
||||
<para>
|
||||
The auto-discovery daemon (omdiscd) provides a way to automatically configure
|
||||
an openMosix cluster hence
|
||||
|
|
|
@ -11,8 +11,8 @@
|
|||
<!entity Hints system "openMosix_Hints.sgml">
|
||||
<!entity Administration system "openMosix_Admin.sgml">
|
||||
<!entity ClumpOS system "ClumpOS.sgml">
|
||||
<!entity PlumpOS-HOWTO system "../PlumpOS-HOWTO-sgml/PlumpOS.sgml">
|
||||
<!entity PlumpOS-FAQ system "../PlumpOS-HOWTO-sgml/PlumpOS-FAQ.sgml">
|
||||
<!entity PlumpOS-HOWTO system "PlumpOS-HOWTO-sgml/PlumpOS.sgml">
|
||||
<!entity PlumpOS-FAQ system "PlumpOS-HOWTO-sgml/PlumpOS-FAQ.sgml">
|
||||
<!entity LastChapter system "openMosix_Last_Chapter.sgml">
|
||||
<!entity Distributions system "openMosix_And_Distributions.sgml">
|
||||
<!entity RPM system "openMosix-RPM-Build.sgml">
|
||||
|
@ -28,7 +28,8 @@
|
|||
<!entity Testing system "openMosix_Testing.sgml">
|
||||
<!entity Statistics system "openMosix_Statistics.sgml">
|
||||
<!entity Internals system "openMosix_Internals.sgml">
|
||||
<!entity FAQ system "../openmosixfaq/openMosix-FAQ-Text.sgml">
|
||||
<!entity FAQ system "openmosixfaq/openMosix-FAQ-Text.sgml">
|
||||
<!entity twodotsix system "../openMosix-2.6-HOWTO/openMosix-2.6-HOWTO-content.sgml">
|
||||
]>
|
||||
|
||||
<BOOK ID="openMosix-HOWTO">
|
||||
|
@ -54,6 +55,23 @@ The best way to become acquainted with a subject is to write a book about it.</q
|
|||
|
||||
|
||||
<revhistory>
|
||||
<revision><revnumber>v.1.98p4</revnumber>
|
||||
<date>30 april 2005</date>
|
||||
<revremark>Preparing for 2.6</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>v1.0.5</revnumber>
|
||||
<date>3 march 2005</date>
|
||||
<revremark>Misc Small fixes</revremark>
|
||||
</revision>
|
||||
|
||||
|
||||
<revision>
|
||||
<revnumber>v1.0.4</revnumber>
|
||||
<date>13 december 2004</date>
|
||||
<revremark>Added infor about removing openMosixFS in 2.4.26-om1</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v1.0.3</revnumber>
|
||||
<date>18 june 2004</date>
|
||||
|
@ -190,6 +208,11 @@ The best way to become acquainted with a subject is to write a book about it.</q
|
|||
&Planning
|
||||
&Distributions
|
||||
&autodiscovery
|
||||
<!--
|
||||
<chapter id="twodotsix"><title>openMosix at 2.6</title>
|
||||
&twodotsix
|
||||
</chapter>
|
||||
-->
|
||||
&PlumpOS-HOWTO
|
||||
&Installation
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
<CHAPTER ID="Distributions">
|
||||
<TITLE>Distribution specific installations</TITLE>
|
||||
<TITLE>Distribution specific installations (2.4) </TITLE>
|
||||
<SECT1><TITLE>Installing openMosix</TITLE>
|
||||
|
||||
<para><emphasis>This Chapter deals with openMosix 2.4</emphasis></para>
|
||||
<PARA> This chapter deals with installing openMosix on different
|
||||
distributions. It won't be an exhaustive list of all the possible
|
||||
combinations. However throughout the chapter you should find enough
|
||||
|
@ -313,6 +313,9 @@ Installation is finished now: the cluster is up and running :)
|
|||
|
||||
</SECT2><SECT2><TITLE>oMFS</TITLE>
|
||||
|
||||
<para><emphasis>Note that oMFS has been removed from openMosix as of the 2.4.26-om1 release.
|
||||
</emphasis>
|
||||
</para>
|
||||
<PARA>
|
||||
First of all, the CONFIG_MOSIX_FS option in the kernel configuration
|
||||
has to be enabled. If the current kernel was compiled without this
|
||||
|
|
|
@ -19,13 +19,10 @@
|
|||
<row><entry>DSM is being released soon (late march
|
||||
2003).</entry></row>
|
||||
|
||||
<row><entry>Well integrated with openAFS.</entry></row>
|
||||
|
||||
<row><entry>Port to IA-64 as well as AMD-64 is
|
||||
underway.</entry></row>
|
||||
|
||||
<row><entry>oMFS has been improved much since plain
|
||||
MFS.</entry></row>
|
||||
|
||||
<row><entry>It is a clustering platform with more than 10 products
|
||||
based on it: openMosixView, openMosixWebView, openMosixApplet,
|
||||
|
|
|
@ -282,9 +282,30 @@ Also: Do you have two nic cards on a node? then you have to edit the
|
|||
non-cluster_ip cluster-hostname.cluster-domain cluster-hostname
|
||||
</programlisting>
|
||||
|
||||
You
|
||||
might also
|
||||
need to set up a routing table, which is a whole different subject.
|
||||
Or you can supply a -p option to the setpe script to point to the openmosix id of the node it shoud recognise as "self". For example if your internal cluster IP of the master node is "cnode1", you might have an openmosix.map file like
|
||||
|
||||
<programlisting>
|
||||
1 cnode1 1
|
||||
2 cnode2 1
|
||||
</programlisting>
|
||||
|
||||
in which case the setpe script needs to be invoked with "setpe -p1 ...".
|
||||
In the same case the /etc/hosts file might read
|
||||
<PROGRAMLISTING>
|
||||
127.0.0.1 localhost
|
||||
123.456.7.89 usual.name.domain nickname
|
||||
192.168.0.1 cnode1
|
||||
192.168.0.2 cnode2
|
||||
</PROGRAMLISTING>
|
||||
|
||||
Then
|
||||
<PROGRAMLISTING>
|
||||
setpe -p1 -f /etc/openmosix.map </programlisting>
|
||||
will give you what you want. You may wish to edit the openmosix init
|
||||
script to do this properly.
|
||||
</para>
|
||||
<para>
|
||||
You might also need to set up a routing table, which is a whole different subject.
|
||||
</para>
|
||||
<para>
|
||||
Maybe you used different kernel-parameters on each machine? Especially if
|
||||
|
@ -318,6 +339,7 @@ openmosix, but a fix has been commited.
|
|||
</SECT1>
|
||||
|
||||
<SECT1><TITLE>DFSA ? MFS ? </TITLE>
|
||||
<para>As of 2.4.26-om1 oMFS has been removed from openMosix</para>
|
||||
<PARA>People often get confused about what exactly MFS and DFSA
|
||||
are.
|
||||
As discussed before in the howto MFS is the feature of openMosix
|
||||
|
|
|
@ -298,12 +298,13 @@ The 'forkit' test is similar to the 'eatmem' test but uses fork to create
|
|||
multiple process (3*[processors_in_your_openMosix_cluster]) expect it does
|
||||
not write to files.
|
||||
</para></listitem>
|
||||
<!--
|
||||
<listitem>
|
||||
|
||||
<para><emphasis>mfstest</emphasis>
|
||||
This will create a 10MB file and copy it to all nodes back and forth. It
|
||||
is for checking the oMFS capabilities.</para>
|
||||
</listitem>
|
||||
-->
|
||||
<listitem>
|
||||
|
||||
<para><emphasis> kernel syscall test</emphasis>:
|
||||
|
|
|
@ -167,6 +167,7 @@ standard networks via a router or bridge that supports channel bonding( I just u
|
|||
</PARA>
|
||||
</SECT1>
|
||||
|
||||
<!--
|
||||
<sect1><title>Updatedb</title>
|
||||
<para>
|
||||
Updatedb in combination with mfs can cause some issues, you might want to add
|
||||
|
@ -175,6 +176,7 @@ to disable updatedb from indexing this mountpoints.
|
|||
|
||||
</para>
|
||||
</sect1>
|
||||
-->
|
||||
|
||||
<sect1><title>openMosix and FireWire</title>
|
||||
<para>
|
||||
|
|
|
@ -412,6 +412,10 @@ openMosix takes care of the communication between these 2 processes.
|
|||
|
||||
<SECT2><TITLE>The openMosix File System (oMFS)</TITLE>
|
||||
<PARA>
|
||||
<emphasis>Please note that oMFS has been removed from the openMosix patch as of 2.4.26-om1</emphasis>
|
||||
</para>
|
||||
<para>
|
||||
|
||||
oMFS is a feature of openMosix which allows you to access remote
|
||||
filesystems in a cluster as if they were locally mounted. The
|
||||
filesystems of your other nodes can be mounted on /mfs and you will,
|
||||
|
|
|
@ -280,10 +280,10 @@ The functionality is explained in the following.
|
|||
</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview1.eps" format="eps">
|
||||
<imagedata fileref="images/omview1.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview1.gif" format="gif">
|
||||
<imagedata fileref="images/omview1.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -349,10 +349,10 @@ an "cluster-node"-button is clicked.
|
|||
</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview2.eps" format="eps">
|
||||
<imagedata fileref="images/omview2.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview2.gif" format="gif">
|
||||
<imagedata fileref="images/omview2.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -406,10 +406,10 @@ cluster the "advanced execution"-dialog may help you.
|
|||
</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview3.eps" format="eps">
|
||||
<imagedata fileref="images/omview3.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview3.gif" format="gif">
|
||||
<imagedata fileref="images/omview3.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -495,10 +495,10 @@ This process-box is really useful for managing the processes running on your clu
|
|||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview4.eps" format="eps">
|
||||
<imagedata fileref="images/omview4.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview4.gif" format="gif">
|
||||
<imagedata fileref="images/omview4.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -536,10 +536,10 @@ from the process box is clicked.
|
|||
</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview5.eps" format="eps">
|
||||
<imagedata fileref="images/omview5.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview5.gif" format="gif">
|
||||
<imagedata fileref="images/omview5.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -577,10 +577,10 @@ beneath the process-box is clicked
|
|||
</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview6.eps" format="eps">
|
||||
<imagedata fileref="images/omview6.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview6.gif" format="gif">
|
||||
<imagedata fileref="images/omview6.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -689,10 +689,10 @@ the load-overview</title>
|
|||
</para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview7.eps" format="eps">
|
||||
<imagedata fileref="images/omview7.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview7.gif" format="gif">
|
||||
<imagedata fileref="images/omview7.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -733,10 +733,10 @@ and some more statically and dynamic informations about the specific node or the
|
|||
<title>statistical informations about a cluster-node</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview9.eps" format="eps">
|
||||
<imagedata fileref="images/omview9.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview9.gif" format="gif">
|
||||
<imagedata fileref="images/omview9.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -755,10 +755,10 @@ much easier.
|
|||
<title>the memory-overview</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview8.eps" format="eps">
|
||||
<imagedata fileref="images/omview8.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview8.gif" format="gif">
|
||||
<imagedata fileref="images/omview8.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -799,10 +799,10 @@ they are displayed as a vertical blue line.
|
|||
<title>openMosixhistory</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview10.eps" format="eps">
|
||||
<imagedata fileref="images/omview10.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="omview10.gif" format="gif">
|
||||
<imagedata fileref="images/omview10.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
@ -845,10 +845,10 @@ The start time is displayed on the top/left and you have a 12 hour view in openM
|
|||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="ommigmon2.eps" format="eps">
|
||||
<imagedata fileref="images/ommigmon2.eps" format="eps">
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="ommigmon2.gif" format="gif">
|
||||
<imagedata fileref="images/ommigmon2.gif" format="gif">
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
|
|
Loading…
Reference in New Issue