A Quick Warning About Compiling libvirt

If you’ve been reading my site for any length of time, you know that I’ve been working with libvirt, the open source virtualization API, for a while. As part of my testing with libvirt, I’ve needed to stay on the “cutting edge” of libvirt’s development (so to speak), so I’ve been compiling my own version of libvirt from the source packages available from the libvirt HTTP server.

You can see some of the posts I’ve written about compiling libvirt:

Compiling libvirt 1.0.0 on Ubuntu 12.04 and 12.10
Compiling libvirt 0.10.1 on Ubuntu 12.04
Compiling libvirt 0.10.1 on CentOS 6.3

While these instructions work, there is an important consideration to keep in mind here: updating the system. When you compile and install your own binaries, the system has no way of knowing how to apply updates. For example, on Ubuntu, this means that apt-get, aptitude, and Update Manager are not aware that a newer version of libvirt is present on the system. Thus, when you go to update the system—you do keep your system updated, right?—then things will break. (Note that there are workarounds for apt-get and aptitude, but it does not appear that these workarounds also work with Update Manager.)

If you are considering following my instructions to compile your own binaries for libvirt, please be sure to keep this consideration in mind. This sort of “gotcha” might be fine for a small home-based lab like mine, but it probably isn’t the sort of issue you’d like to introduce into any sort of production (or quasi-production) environment.

Thanks to Theron Conrey for highlighting the significance of this concern. Be sure to check out Theron’s comment on this article for more information on a potential Ubuntu PPA that might help with this issue.

Tags: , , , , ,

  1. Chris Bennett’s avatar

    Hi Scott,

    Thanks for the posts on libvirt so far.

    It’s common to install custom-built binaries in an alternative location (say /opt or /usr/local) to avoid any possibility of clobbering by package installations or updates. So your instructions in http://blog.scottlowe.org/2012/11/05/compiling-libvirt-1-0-0-on-ubuntu-12-04-and-12-10/ would specify ‘–prefix=/opt/libvirt’

    It will have an impact on how tools & libaries interact (new library paths to search, custom specification of bin paths) but it ensures you don’t hit a scenario like this blog post describes…

    With all the testing you have been doing, and likely bugs along the way, you can maintain multiple versions under custom location…

    e.g.
    –prefix=/opt/libvirt/1.0
    –prefix=/opt/libvirt/1.0.1
    etc,
    and then possibly symlink your desired version to ‘/opt/libvirt/current’ so you point all your tools at /opt/libvirt/current and then can change the symlink when you play with different versions…

    At least that’s how I do it when I play with new stuff not in package management :)

    Regards,

    Chris Bennett (cgb)