VDFuse replacing GuestFS

Just a week back, we decided to replace GuestFS and use VDFuse. Though GuestFS comes with certain advantages, w.r.t VDFuse in terms
of support for several file formats which makes it easy to extend to other file formats and also python bindings, we faced a lot
of problems working with it. Some of them are:

  • Installing GuestFS is a big headache as there are lot of dependencies to be installed and even after that its not necessary that
    it works always. This might turn out to be one reason for developers to not try out PyTI.
  • GuestFS is not very stable . There were lot of times it didnt work and couple of issues of GuestFS hanging without any reason.
  • It takes a lot of time initializing GuestFS for reading or writing into the disk

Yes, as I mentioned before, we moved to VDFuse for now. It grows out of the difficulties of GuestFS and it is a decent solution for
reading or writing to the disk.


Lessons learnt

Whenever I used a good software before, I never bothered or thought about what are all difficulties the software faced during its
development. And now working on PyTI for over a month, I came to realize that there is a lot of sweat behind any good project.
This reminded me to write a blog on what difficulties we faced for PyTI.

If you have been following my blog , you already know that PyTI uses libvirt for virtualization and libguestfs for mounting the
file system on host. There have been couple of problems we faced using these libraries and I will illustrate how we tackled those problems. Also mentioned is the lessons I learnt through the journey.

1) Snapshot Error:
PyTI is interfaced to Virtualbox using libvirt. There was once a problem occurred that I couldnt take snapshots of any disks , except VMs attached to live boot images. After some amount of searching here and there, I realized that the disk which I was taking snapshot was already to more than one VM . So disconnecting the VM from one of the disk solved the problem .

Lesson learnt : Its always easy to blame others for mistakes. (in this case the “library” libvirt)

2) Support for shared folders:
One of the initial solution we thought of implementing for transferring data from host and guest was
by using shared folders. As you might be aware that Virtual Box has a feature of “shared folders” which allows you to access a host
folder from guest machine. Since any VM used in PyTI does not have network access, this we thought as the most viable solution.We were relying on it a big time. Soon, we realized that libvirt library does not yet support shared folder(at that time). Then we decided to
scrap the idea and go for Flux based solutions . Now we use libguestfs library.

Lesson learnt : Its easy to have a solution and assume that it will always work out.

3) Downloading files from virtual hard disk:
We had a problem downloading files from Virtual Hard disk . After some searches, we realized that VirtualBox creates a diff image
when a snapshot is taken and libguestfs tries to access from diff image and not the original disk. Having two disks solved our problem
one for IO , which we dont take snapshot and another for testing purposes which we take snapshot of (but dont require to access data from it on the host)

Lesson learnt : Read the documentation first

My experience so far

Having never so far contributed to Open Source(except for couple of patches to PSF) , it was an wonderful opportunity helping me to learn a lot about Open Source and Python(as a programming language). Realized that Software Engineering is better understood practically
than theoretically(at school). With my mentors support , I was able to learn a lot of things about how to program better , and also how to program in a Pythonic way. There has been couple of hiccups on my side, but it was always overcome with my mentors help. So, participating in Gsoc has been really amazing. With Mid-Term evaluations coming in three days, I will be a little busy , finishing over my pending work .

Work achieved so far (me and Boris):
1) Have a VManager to handler VM functionalities
2) Have a Diskhandler to transfer data to and fro the Virtual Hard disk
3) Manager functionality which synchronizes all the operations which constitutes downloading the packages, calculates the dependencies, transfer data on to the disk, call the VM, execute the tests and get the results back. (needs to be enhanced little)
4) A communication channel between master and slave(needs to be enhanced little)
5) Creating tasks for execution
6) Creating simple recipes
7) Task Manager for execution of tasks.


This particular module to be included in PyTI is one of the most important part in the architecture. Even though the main goal of vmanager is to manage the vms, there are other secondary goals like getting the data from the virtual hard disk on to the host and viceversa . Even though it is designed with PyTI in mind, I guess it can work out pretty good for the rest of the projects(except the ones which requires networking) which plan to manage VirtualMachines. Ofcourse some tinkering has to be done to cater the project needs.

I will just illustrate with a simple example to start, save the state(snapshot), rollback and stopping the virtual box.

from vms import *
config = {'name': 'test123', 'memory':'123', \
              'disk_location': 'dsl-4.4.10.iso', \
              'hd_location': 'disk.vdi'}
a = VirtualMachine('hey', "vbox:///session", config=config) 
a.createSnapshot('hello', 'blah')

It is pretty clear from the above examples , each of the operations performed. Since vmanager uses libvirt library, it wont be difficult to migrate to other hypervisors if ever the need arises.

For reading the virtual hard disk , I wrote a diskhandler code , which uses libguestfs library .

A small illustration for mounting the disk , uploading and downloading data from and to the host machine

from diskhandler import *
d = DiskOperations('/home/yeswanth/a.vdi')
d.upload("/home/yeswanth/a.txt", "/root/a.txt")
d.download("/root/b.txt", "/home/yeswanth/b.txt")

Fore extensive read on vmanager or PyTI , please do read our documentation

Fun with VirtualMachines

Over the last one week , all I did was play with Virtual Machines. The tests on the distributions will happen over a Virtual Machine . So its very important that we can control these VMs with a script.

Candidate : VirtualBox
Operating System : Damn Small Linux
Virtual Hard disk : A VDI image of 2.5 GB
RAM: 256 MB
Library: used libvirt to control the virtual machines
Features tested: Start, Stop, Snapshot, Rollback

Using libvirt was nice. It supports a range of hypervisors to be controlled with the same library, though I had my fair share of difficulties especially with the documentation.

Another feature I worked on this week is mounting the virtual hard disk image on the host. I used libguestfs library to achieve this. The features I have added for PyTI for now are
uploading and downloading files from and to the virtual hard disk on to the host machine.

Would really thank Alexis, one of my mentor for his help in giving me feedback , refactoring my code and testing it .

Which VirtualMachine to use ??

Let me just illustrate my findings after searching for a good VM to be used.

Our requirements :
1) Supported by libvirt.
2) Open Source and Free (as in freedom)
3) Has a good community with active developers.
4) Fast.

How did I evaluate ?
1) Read blogs
2) Google searches (eg . which is better VBox or KVM? ,etc)
3) Look for references.
4) Benchmarks on performances ( again subject to other people’s findings and reporting)

1) Some of the websites were biased about their solution
2) I got caught between community wars( one saying VM ‘X’ is the best , another VM ‘Y’ is the best, both were convincing enough)
3) Libvirt lack of good documentation about the different features available for different VMs.

A comparision table:

Criteria Xen Qemu+KQemu KVM VirtualBox
Host OS Linux,Solaris,BSD Most Linux
Guest OS Most(Kernel needto
be modified)
Most Most Most
Speed Performance loss on
diskintensive operations
Qemu is usually slow.But Kqemu has

good performance

Goodperformance Goodperformance
Virtual Hard
DiskImage Format




Community Support Community not very
active in the

past few years

Support droppedfor KQemu RedHat is currentlysupporting it Oracle is currentlysupporting  it

Now considering this table I had a rough idea of shortlisting the list to two candidates : KVM and VirtualBox.

Reasons for choosing Vbox over KVM
1)Vbox support for multiple platforms
2)KVM’s native disk image QCOW2 is very slow. Ofcourse I could use other disk images but that would require external tools.
3)KVM’s dependency on linux kernel

And the winner is VirtualBox

Dependent Part of the Project

Till now I have always blogged on the environment part of the project. I should give some emphasis on the dependent part too. As you might have already guessed , Dependent part is the one which bridges the Environment part and the Execution part. So It mostly consists of API to carry information to and fro the two parts(execution and environment).

We need the following information being sent to the slave.

  • Distributions to be tested along with their dependencies
  • Configuration file

The configuration file includes :

  1. Name of the distribution
  2. Lists of tasks to be executed ( static at the beginning , configured by the slave)
  3. Where to send back information through raw data API ( probably IP address)

These are the initial idea. Having a config file means that we can include other data in the future if and when required.

So the slave sends the distributions and the vm executes the tasks as mentioned by the configuration file.
The raw data (obtained after the tests) has to be reported back to the slave(after all the tests have been conducted.
This is done by having a raw data API .
So raw data API need to accommodate these :

  1. Task id
  2. Raw data of this task + additional informations (time of execution, memory usage, cpu usage…)

We decided on using JSON-RPC format to construct Raw data API.
Core philosophy which we are following for taking decisions : Keep the implementation simple . This helps us to have a prototype early on .

Ideally I thought I should also mention the lessons I learn through gsoc . So heres the first one
Gsoc Lesson 1
I always thought that I would directly work upon coding first as soon as the bell rings in gsoc. But here over the past few weeks , I have come to realize that for a completely new project,PyTI (though it was worked upon last year), design decisions are very important than implementation. I would have been working blind if I directly started coding 🙂