SuSe Studio is a online/standalone software appliance build tool. We typically use it to generate appliances based on SLES O.S. We can use the online utility for free but the standalone utility is licensed.
But SuSe Studio is just a web interface. The core of the appliance building is done by a command line utility - Kiwi. Kiwi is part of OpenSuse and it is maintained by Open Source community (I guess it's funded by Novell).
Generating appliances through online is good for initial exploration, but if need to generate appliances frequently, can we do this manual task everyday? No. We need to automate. This blog explains how to automate appliance building process using Kiwi tool.
Step 1: Configure your appliance on SuSe Studio Standalone (preferably), build, deploy and validate your appliance.
Step 2: Export your appliance's Kiwi configuration, for building your appliance locally.
In the build tab of Suse Studio, in the bottom you can find the link to download Kiwi config files.
Step 3: Copy the Kiwi config files to a SLES build machine, where kiwi is installed. Try to use the same kiwi version, the Suse studio have used to build it. Refer README file for details.
Step 4: Compile it using the script create_appliance.sh which comes along with kiwi config files when you export. It has 2 phases
1) Boot build - 2 sub process
a) Prepare (generates boot-prepare.log)
b) Create ( generates boot-create.log)
2) Actual image build - 2 sub process
a) Prepare (generates prepare.log)
b) Create ( generates create.log)
You can generate the appliance in ISO format or Virtual appliance ( .vmdk , OVF) or some other format.
Step 5: Deploy it either on physical machine or on virtual machine like (VMWare ESX server).
If it gets deployed without any error, then you are lucky. Otherwise you may get error like
VFS: Cannot open root device "<NULL>" or unknown-block
Or some Kernel Panic message.
Actually when we download Kiwi configuration files from Suse Studio, it is not exporting the same config files it used to build. It is providing some modified set of files. Is it fooling us?
Here are the steps to overcome it.
Step 6: Login to the machine where you installed Standalone suse studio. If you don't have stand alone installation and got config files from online suse studio, then you may need to contact Suse Studio for help.
Step 7: Go to /studio/runner/ directory (cd /studio/runner/). You will notice 2 directories of interest bootsource & source.
Step 8: When you start the build on Suse studio, in the build log file you can notice which config files it used for that build. Like
Running Step 3: Setting up build environment
'/studio/runner/bootsource/a24-0.0.3-vmx-x86_64/' 'bootsource'
'/studio/runner/source/a24-0.0.3-vmx-x86_64/' 'source'
From the above output you can locate where on the Studio machines the actual config files for 'boorsource' and 'source' are getting stored
Copy these 2 folders to your build machine mentioned in Step 3
Step 9: You may not be able to directly use the config files obtained in Step 8. Instead replace few selected files obtained from config files in step 8, with the existing config files on build machine ( Obtained in Step 2)
Some of the files which we replaced/added to make it work are
bootsource/config.xml
bootsource/root/config.oempartition
bootsource/root/dump
bootsource/root/include
bootsource/root/linuxrc
bootsource/root/preinit
bootsource/root/repart
source/config.xml
All the files mentioned above may not be needed to replace/add, but this is what worked for us.
Step 10: If you have local repository, don't forget to mention it in config.xml files ( source & bootsource)
Step 11: Build & deploy it again (Step 4 & 5).
Hopefully now your appliance should get deployed without any issues.
But SuSe Studio is just a web interface. The core of the appliance building is done by a command line utility - Kiwi. Kiwi is part of OpenSuse and it is maintained by Open Source community (I guess it's funded by Novell).
Generating appliances through online is good for initial exploration, but if need to generate appliances frequently, can we do this manual task everyday? No. We need to automate. This blog explains how to automate appliance building process using Kiwi tool.
Step 1: Configure your appliance on SuSe Studio Standalone (preferably), build, deploy and validate your appliance.
Step 2: Export your appliance's Kiwi configuration, for building your appliance locally.
In the build tab of Suse Studio, in the bottom you can find the link to download Kiwi config files.
Step 3: Copy the Kiwi config files to a SLES build machine, where kiwi is installed. Try to use the same kiwi version, the Suse studio have used to build it. Refer README file for details.
Step 4: Compile it using the script create_appliance.sh which comes along with kiwi config files when you export. It has 2 phases
1) Boot build - 2 sub process
a) Prepare (generates boot-prepare.log)
b) Create ( generates boot-create.log)
2) Actual image build - 2 sub process
a) Prepare (generates prepare.log)
b) Create ( generates create.log)
You can generate the appliance in ISO format or Virtual appliance ( .vmdk , OVF) or some other format.
Step 5: Deploy it either on physical machine or on virtual machine like (VMWare ESX server).
If it gets deployed without any error, then you are lucky. Otherwise you may get error like
VFS: Cannot open root device "<NULL>" or unknown-block
Or some Kernel Panic message.
Actually when we download Kiwi configuration files from Suse Studio, it is not exporting the same config files it used to build. It is providing some modified set of files. Is it fooling us?
Here are the steps to overcome it.
Step 6: Login to the machine where you installed Standalone suse studio. If you don't have stand alone installation and got config files from online suse studio, then you may need to contact Suse Studio for help.
Step 7: Go to /studio/runner/ directory (cd /studio/runner/). You will notice 2 directories of interest bootsource & source.
Step 8: When you start the build on Suse studio, in the build log file you can notice which config files it used for that build. Like
Running Step 3: Setting up build environment
'/studio/runner/bootsource/a24-0.0.3-vmx-x86_64/' 'bootsource'
'/studio/runner/source/a24-0.0.3-vmx-x86_64/' 'source'
From the above output you can locate where on the Studio machines the actual config files for 'boorsource' and 'source' are getting stored
Copy these 2 folders to your build machine mentioned in Step 3
Step 9: You may not be able to directly use the config files obtained in Step 8. Instead replace few selected files obtained from config files in step 8, with the existing config files on build machine ( Obtained in Step 2)
Some of the files which we replaced/added to make it work are
bootsource/config.xml
bootsource/root/config.oempartition
bootsource/root/dump
bootsource/root/include
bootsource/root/linuxrc
bootsource/root/preinit
bootsource/root/repart
source/config.xml
All the files mentioned above may not be needed to replace/add, but this is what worked for us.
Step 10: If you have local repository, don't forget to mention it in config.xml files ( source & bootsource)
Step 11: Build & deploy it again (Step 4 & 5).
Hopefully now your appliance should get deployed without any issues.
0 comments:
Post a Comment