During the the last couple of years, I have needed to build and rebuild many virtual machines. As a SUSE Sales Engineer, I demonstrate SUSE solutions to customers and need to be able to rebuild demonstration VMs quickly using a repeatable method.
Machinery and KIWI are tools that have helped me build customized SUSE Linux Enterprise Server systems for demonstrations and testing. While both of these tools are valuable on their own, together they make a great team! I am going to describe a simple process using Machinery to inspect an existing system and, using that resulting inspection data, build a matching system image using KIWI.
Machinery is used to create a system description of an existing system. These descriptions can be used for several purposes. You can compare descriptions from like systems, or compare the same system at different points in time inn order to see what might have changed. Maybe you have several web servers that need to be the same. Comparing machinery descriptions from each server can help you find differences between those systems. Yet another use is to document systems by exporting the system descriptions to an html format, which will create a nice, readable, web page for each system.
KIWI is a tool that is used to create system images. SUSE uses it for building product images and it is also used for building images in the Open Build Service. KIWI can build many different types of images, including iso, pre-load iso, docker containers, qcow2 and vmdk to name a few. I use it often for building qcow2 files for use with KVM or vmdk files for use with VMware.
Both KIWI and machinery are included with SLES 12. KIWI is in the base repository and machinery is in the Advanced Systems Management Module. The Advanced Systems Management module is included with a SLES 12 subscription.
Both tools can be installed in a management server or workstation and run from there. Since I run SLES 12 on my laptop, I install and run them both from there. Machinery will use ssh to connect to the system that needs to be inspected and gather the data. KIWI will need access to the needed repositories in order to build the system images. Since I have a local SMT server, that works well.
After installing machinery and kiwi, the process of using them to inspect and create a duplicate system is not difficult. To begin, we need to use machinery to inspect a system. With machinery installed on a system, we’re going to inspect system test1.
machinery inspect test1 --extract-files
The –extract-files options tells machinery to extract (gather) changed configuration and unmanaged files from the inspected system. These files can then be used with KIWI and put back into the proper locations on the new system image that is created, so those changes to the original system are not lost and are carried forward onto the new system image.
The next step is to export the description information into something that kiwi can use to create a new system image.
machinery export-kiwi -k /dir test1
This creates a directory under /dir with the resulting kiwi files. The files can be edited to add any customizations, or used as is to duplicate the original system. For example, by default a qcow2 file is specified as the resulting image type. If I wanted a vmdk file, I could edit the configuration file so kiwi will produce that file type instead. Anything about the image can be changed, file systems, disk size, packages installed are all able to be customized. Once everything is ready to go, an image can be created.
kiwi -b /dir/test1-kiwi -d /tmp/test1-kiwi
After the build process is complete, there will be several things in the destination directory. First will be the results of your build, in my case a qcow2 file. There will also be a build directory that contains the unpacked system that was just created. The resulting qcow2 file can then be used with KVM and booted from directly, without any further processing.
More information about KIWI
More information about machinery
More information about SUSE Linux Enterprise Modules