Josh,
Thank you for that detailed clarification. Appreciate your support.
Regards,
Sunil
On 6/1/11 1:39 PM, Josh Thompson wrote:
Sunil,
The "stateless" image I refer to is what is actually booted on the compute
node containing the image to be captured. It's called stateless because it is
loaded completely in RAM and does not maintain any state when a reboot occurs.
The partimage binary is part of this stateless image and actually runs on the
compute node. It does not run on the management node. The management node
does not have block level access to the disk on the compute node to be able to
capture the image from the disk.
I'll try to describe the process a little better. The management node issues
a reboot command to the compute node. The compute node uses PXE to load and
boot a kernel (vmlinuz), initial RAM disk (initrd.img), and a root filesystem
(rootimg.gz) from the management node. All three of these together make up
the stateless image. Once the compute node is booted with the stateless
image, it uses NFS to mount some things from the management node, and then
runs some xcat postscripts, one of which is the partimageng postscript. This
postscript determines what partitions are on the compute node and, depending
on how the postscript is configured, uses partimage or partimageng to capture
an image of the compute node disk that is then saved to the management node.
When it is finished capturing the image, it notifies xcat on the management
node and then reboots. xcat reconfigures itself to tell the compute node to
boot off of disk at next boot. When the compute node comes up, it uses PXE to
ask the management node how to boot. The management node tells it to boot off
of disk.
I hope that clarifies how the system works. If any of it is unclear, please
ask for further clarification.
Josh
On Wednesday June 01, 2011, Sunil Venkatesh wrote:
Josh,
I had one more clarification.
partimage binaries run in the management node to capture an (stateless)
image from the compute node right? In that case, is there a need for
these binaries to go into the rootimg.gz??
My assumption is, partimage runs on the management node (an intel blade
in our case) to capture a stateless image from a compute node (a power 7
blade) and stores these images under " /install " of the management
node. Please correct me if I am wrong here.
Regards,
Sunil
On 6/1/11 9:58 AM, Josh Thompson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday May 31, 2011, Sunil Venkatesh wrote:
Hi,
I used the steps that were mentioned under
https://cwiki.apache.org/confluence/display/VCL/Adding+support+for+parti
mag e+and+partimage- ng+to+xCAT+2.x+%28unofficial%29
to enable partimage support for xcat. I wasn't sure if I need to change
references to x86& x86_64 (as directories) to reflect the ppc
architecture, as the web page says "The architecture for the node must
always be set to x86 for this..". I have with me the vmlinuz (kernel
image) and initrd for the capture process. The 2 nodeset commands
By this, do you mean you have vmlinuz and initrd for your power blades,
not the ones linked to off of the page you listed above? If you do,
that's a good start. However, you'll also need rootimg.gz. rootimg.gz
is the root filesystem for the stateless image. It also contains the
partimage and partimageng binaries. Assuming partimage or partimageng
can actually capture partitions from power systems, you'll need to
compile at least one of them to run on power. For the rootimg.gz image
I provided, I compiled them statically so that I didn't have to worry
about including any library dependencies in rootimg.gz.
It would be a good idea to research how to use xcat's genimage command to
generate stateless images to learn how to do this.
If there's any part of the above that you don't fully understand, please
ask me to clarify it. Until you have a stateless image that you can
deploy to your power blades, there's no point in trying to debug any VCL
specific items.
Josh
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk3mRYsACgkQV/LQcNdtPQNnVgCbB9ZFJn0+C45RC/g75RqGZY/j
PZYAniP2Eam7nxgiDWUnp5sKPYPO4OMa
=exBV
-----END PGP SIGNATURE-----
