http://l4ka.org/projects/pistachio/ia32/gettingstarted.php
Ihor Kuz gives a step by step to start L4Ka::Pistachio using floppy, actually we can use hard disk start L4Ka::Pistachio, It is direct and simple. Blow is what I have done.
Building L4, same as descript of Ihor Kuz. I only gives steps.
CVS or Unpacking the tarball
cd pistachio-0.4/kernel
make BUILDDIR=$(pwd)/../ia32-kernel-build
cd ../ia32-kernel-build
make menuconfig
make
Configuring the kernel
In make menuconfig type `x' to save the configuration and exit, `q' to exit without saving. In make xconfig choose File->Save & Exit from the menu.
mkdir pistachio-0.4/ia32-user-build
cd pistachio-0.4/ia32-user-build
../user/configure
make
make install
Configuring user-level
It may be a good idea to copy the kernel to the same directory as the servers, e.g., then copy all boot need files to boot directory
cp pistachio-0.4/ia32-kernel-build/ia32-kernel pistachio-0.4/ia32-user-install/libexec/l4/
cp pistachio-0.4/ia32-user-install/libexec/l4/* /boot/
Then modify the file /boot/grub/grub.conf with the following contents
# serial --port=0x3f8 --speed=115200
# terminal --timeout=0 serial
title L4Ka::Pistachio
kernel /kickstart
module /ia32-kernel
module /sigma0
module /pingpong
Reboot system, select L4Ka::Pistachio from grub menu. You will enter L4Ka::Pistachio test if all is OK.
Note: I just download the snapshot tarball and build them on redhat EL4, maybe this can help you build success.
Monday, June 4, 2007
Thursday, May 31, 2007
PDO remove period in MPIO DDK
The PDO remove period is used when the last path to the LUN has gone missing and allows the virtual PDO (the one seen by disk) to stick around for a short while. A delay in removing it covers the case where the path comes back quickly (such as a transient condition) and avoids excessive processing time for PnP to scan luns, and rebuild stacks. You want to keep this as short as possible to avoid I/O hangs in the system.
An updated Storport storage driver
People may find problems when they using MPIO software on Windows platform with dual controller storage subsystem. I have encounter such problems like failback failed while failover is pass. The root cause is that storport driver of HBA need update with Microsoft's fix. Which fix can be downloaded at
http://support.microsoft.com/kb/932755.
This update addressed IOCTL_STORAGE_BREAK_RESERVATION issues.This update modifies the port drivers so that an IOCTL_STORAGE_BREAK_RESERVATION request that is sent to the port LUN (which is the physical device object (PDO)) is forwarded to the adapter (which is the filter device object (FDO))
I used this update adressed ALUA issue and link failed issues like link plug off.
http://support.microsoft.com/kb/932755.
This update addressed IOCTL_STORAGE_BREAK_RESERVATION issues.This update modifies the port drivers so that an IOCTL_STORAGE_BREAK_RESERVATION request that is sent to the port LUN (which is the physical device object (PDO)) is forwarded to the adapter (which is the filter device object (FDO))
I used this update adressed ALUA issue and link failed issues like link plug off.
Tuesday, May 1, 2007
Using Xen as Build Server.
Over the past few years Our build server machines have increased to meet differece Windows and Linux platforms. For example on Linux 2.4 kernel and Linux 2.6 kernel Platform, each platform should installation on two and more machines for deploying specialized toolchain compilers.
However, this adoption of build servers, particularly for stabilization solutions, has led to machine bloat -- towers and racks of multicolored boxes, each performing a specialized build.
About half years ago, I installed a Xen 3.0.3 server with 2 GB memory, moved the Linux build server's function to the Xen server. After two weeks of stabilization test, all runs smoothly .
However, this adoption of build servers, particularly for stabilization solutions, has led to machine bloat -- towers and racks of multicolored boxes, each performing a specialized build.
About half years ago, I installed a Xen 3.0.3 server with 2 GB memory, moved the Linux build server's function to the Xen server. After two weeks of stabilization test, all runs smoothly .
Sunday, April 22, 2007
FreeNAS over Xen
FreeNAS can run over VMware, see http://www.vmware.com/vmtn/appliances/directory/168.
But I have not seen somebody have run FreeNAS over Xen. So I will trying to run FreeNAS over Xen in next days
But I have not seen somebody have run FreeNAS over Xen. So I will trying to run FreeNAS over Xen in next days
Friday, April 20, 2007
ALUA definition
5.8.2 Asymmetric logical unit access
5.8.2.1 Introduction to asymmetric logical unit access
Asymmetric logical unit access occurs when the access characteristics of one port may differ from those of another
port. SCSI target devices with target ports implemented in separate physical units may need to designate differing
levels of access for the target ports associated with each logical unit. While commands and task management
functions (see SAM-3) may be routed to a logical unit through any target port, the performance may not be optimal,
and the allowable command set may be less complete than when the same commands and task management
functions are routed through a different target port. When a failure on the path to one target port is detected, the
SCSI target device may perform automatic internal reconfiguration to make a logical unit accessible from a different
set of target ports or may be instructed by the application client to make a logical unit accessible from a different set
of target ports.
A target port characteristic called target port asymmetric access state (see 5.8.2.4) defines properties of a target
port and the allowable command set for a logical unit when commands and task management functions are routed
through the target port maintaining that state.
A target port group is defined as a set of target ports that are in the same target port asymmetric access state at all
times. A target port group asymmetric access state is defined as the target port asymmetric access state common
to the set of target ports in a target port group. The grouping of target ports is vendor specific.
A logical unit may have commands and task management functions routed through multiple target port groups.
Logical units support asymmetric logical unit access if different target port groups may be in different target port
group asymmetric access states.
An example of asymmetric logical unit access is a SCSI controller device with two separated controllers where all
target ports on one controller are in the same asymmetric access state with respect to a logical unit and are
members of the same target port group. Target ports on the other controller are members of another target port
group. The behavior of each target port group may be different with respect to a logical unit, but all members of a
single target port group are always in the same target port asymmetric access state with respect to a logical unit.
5.8.2.1 Introduction to asymmetric logical unit access
Asymmetric logical unit access occurs when the access characteristics of one port may differ from those of another
port. SCSI target devices with target ports implemented in separate physical units may need to designate differing
levels of access for the target ports associated with each logical unit. While commands and task management
functions (see SAM-3) may be routed to a logical unit through any target port, the performance may not be optimal,
and the allowable command set may be less complete than when the same commands and task management
functions are routed through a different target port. When a failure on the path to one target port is detected, the
SCSI target device may perform automatic internal reconfiguration to make a logical unit accessible from a different
set of target ports or may be instructed by the application client to make a logical unit accessible from a different set
of target ports.
A target port characteristic called target port asymmetric access state (see 5.8.2.4) defines properties of a target
port and the allowable command set for a logical unit when commands and task management functions are routed
through the target port maintaining that state.
A target port group is defined as a set of target ports that are in the same target port asymmetric access state at all
times. A target port group asymmetric access state is defined as the target port asymmetric access state common
to the set of target ports in a target port group. The grouping of target ports is vendor specific.
A logical unit may have commands and task management functions routed through multiple target port groups.
Logical units support asymmetric logical unit access if different target port groups may be in different target port
group asymmetric access states.
An example of asymmetric logical unit access is a SCSI controller device with two separated controllers where all
target ports on one controller are in the same asymmetric access state with respect to a logical unit and are
members of the same target port group. Target ports on the other controller are members of another target port
group. The behavior of each target port group may be different with respect to a logical unit, but all members of a
single target port group are always in the same target port asymmetric access state with respect to a logical unit.
Virtualization thoughts
Subscribe to:
Posts (Atom)