How to hack on a local copy of libvirt

So you want to run a version of libvirt other than packaged version on your system.  You might want to do this to see if a bug you found has been fixed in a later release, or to develop your own new feature.  Since libvirt can be very tightly integrated with the rest of the distribution, there are a few things to look out for when building your own version.  Here’s how I do it:

Step 0: Install your distribution’s libvirt package
The first thing you should do is install libvirt and its dependencies using your distribution’s usual method.  This ensures that the directories, config files, and security policies that are required for your system get installed.  Rather than starting from scratch, you’ll want to make use of these things.

Step 1: Get the source code
In order to hack on libvirt you first need to get the source.  You can use git or grab a release tarball.  Find the details here.  Once you have the source, unpack or checkout a copy and change to that directory.

Step 2: Build it
Our goal is to run our own copy of libvirt directly from the build tree (without overwriting the system version).  To do this we execute these simple commands:

./autogen.sh --system
make

The --system argument to autogen.sh causes libvirt to use the regular system paths for configuration files, sockets, logs, etc.  Note that we do not install (as that would overwrite the system installed version).

Step 3: Start the daemon
It is easy to start the daemon from the build root:

sudo ./daemon/libvirtd -d

This will create a system-level daemon listening at the libvirt URI qemu:///system which you can connect to using virsh:

sudo tools/virsh -c qemu:///system

Using GDB
Both libvirtd and virsh use libtool wrapper scripts around the actual binaries.  This means that:

gdb ./daemon/libvirtd

Will not work as expected.  The easiest way to work around this problem is to launch the daemon as suggested in Step 3 and then attach to the running process:

gdb -p `pidof lt-libvirtd`

If you cannot do this (because you want to place a breakpoint in initialization code), you can use this workaround.  First, run libvirtd once as normal and stop it.  This will create a binary which can then be directly executed:

gdb ./daemon/.libs/lt-libvirtd

This same trick can be used with virsh.  Run it once normally, then:

gdb ./tools/.libs/lt-virsh

I hope this gets you off to a good start with libvirt development.  Happy hacking!

Advertisements

About aglitke

I am a software engineer working on Linux, open source software, and virtualization. I am proud to work at Red Hat on oVirt and Red Hat Virtualization with a focus on software defined storage. Other notable projects I have been involved in include: The Linux ppc64 architecture, Linux kernel crash dumps (kdump), Linux huge pages and libhugetlbfs, qemu, libvirt, and the Memory Overcommitment Manager.
This entry was posted in libvirt. Bookmark the permalink.

5 Responses to How to hack on a local copy of libvirt

  1. Stefan says:

    Thanks for posting this! I’ll use this to debug the image format issue I mentioned yesterday :).

  2. Eric Blake says:

    It is actually preferred to use ‘./run gdb daemon/libvirtd’ instead of ‘gdb daemon/.libs/lt-libvirtd’.

  3. cooldharma06 says:

    I am getting some error when destroying the VM.
    how to do the gdb for this. i am newbie for this.:)

    • aglitke says:

      You can still run gdb on libvirtd for this. I would take a look at /var/log/libvirtd.log and the logs in /var/log/libvirt to figure out where the failure is happening and then you can set breakpoints in libvirtd using gdb.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s