Jisha makes its easy to deploy guest operating system images on a host running the Xen virtual machine monitor. Jisha is based on functionality implemented in the xen-get utility. In a nutshell, Jisha works by caching the image metadata advertised by image servers. A Jisha user can then search this metadata to find a particular guest os image they wish to install. Once a user has found their desired the image, Jisha will take care of fetching the image and communicating with Xend (via libvirt) to automatically start the guest domain.
Jisha maintains a local cache of all images it is aware of in a file called 'feed_cache'. Before you can really do anything useful with Jisha the feed cache needs to populated by combing the image servers listed in image_feeds.list. This can be done by running 'ruby jisha.rb update'. This will build a cache of metadata (in YAML format) for all images advertised over RSS 2.0 by the image servers. The figure below illustrates this process. The image servers in the figure are the ones listed in image_feeds.list.
If you wish to offer guest os images for use with Jisha that you must create an RSS 2.0 feed. Click here to see an example image feed.
Both ParserFactory and Jisha are singletons. We use factories, since in the future, images will be advertised in a variety of forms (ATOM, RSS 2.0, etc.) and we want to be able to figure out what types of feeds Jisha can handle without creating an actual parser. All classes except for VirtualMachine have been implemented. VirtualMachine will make the actual libvirt calls to start or stop an image. Futher information is provided in the Development Status section
Jisha is currently in alpha release and is very close to fully functional prototype. The only missing piece is the necessary libvirt calls to create and destroy the actual guest domains. Since libvirt is a C based API, a wrapper is necessary to use the API in Ruby. Unfortunately, the current libvirt release only includes bindings for python. This means that we had to create our own Ruby module to make calls to the libvirt API.
After exploring several possibilities, we settled on taking the SWIG route. The SWIG tool can automatically generate wrappers for C/C++ APIs so that they can be used in higher level scripting languages. In order to build a Ruby module for a
Now that we have 'libvirt.i' we can use SWIG to generate the wrapper code which is dumped into a file called 'libvirt_wrap.c'.
Now we need to build the libvirt Ruby module. In order to build the module, we need a Makefile. Fortunately Ruby makes this easy, just create a file called extconf.rb.
Run 'extconf.rb' through Ruby to generate the Makefile.
After running the above command, we now have a Makefile to build libvirt_wrap.c into a Ruby module.
We can now access the libvirt API through Ruby. For example:
Unfortunately, at this point, I'm getting an unresolved symbol error at virConnectOpenReadOnly even though I can see the symbol in the library using nm. I'm still working on getting past this point.