libvirt support for static Skydive compile

[eranra]

When compiling Skydive static, libvirt is disable. To allow freedom of deployment to various destinations we compile Skydive in static mode, this is used in docker and k8s and it would be beneficial to have the functionality of libvirt also enabled in that type of compilation.

[pierrecregut]

Indeed, that would be nice. But the main problem is the availability of libvirt as a static library. It probably cannot be made as a default but it would be nice to be able to override the flag WITH_LIBVIRT. One solution would be to pass WITH_LIBVIRT as is instead of forcing its value:

static: skydive.clean govendor genlocalfiles
    $(MAKE) compile.static WITH_LIBVIRT=$(WITH_LIBVIRT)

and have target specific defaults:

static: WITH_LIBVIRT?=false
WITH_LIBVIRT?=true

Then we could override it if we can (ie, we have compiled libvirt statically on our own because no distribution does this since somebody disabled the static compilation of libvirt in 2014 to grab a few minutes on their CI/CD https://www.redhat.com/archives/libvir-list/2013-April/msg00148.html ).

Would it be enough for your use case ?

[nplanel]

we need to use pure golang libvirt connector like https://github.com/digitalocean/go-libvirt

[pierrecregut]

We already discussed about it. This library does not support events and you cannot ask it to follow libvirt evolution.

[jonnary]

Any result for the discussion? We met a problem:compile with libvirt in ci machine, then the skydive bin cannot run in some machine if the libvirt.so vesion is lower than ci machine

[lebauce]

@jonnary Where do you get the skydive bin from ?

[lebauce]

@jonnary Regarding the discussion, a pure Go version of the libvirt bindings (such as the digitalocean ones) would be really nice. But right now, they don't fit the bill so it will really depend on someone stepping up and enhance the digitalocean library to support events.

[pierrecregut]

I first thought we could "vendor" a static libvirt but I failed.

Having a static libvirt limited to client communication seems very hard to get. libvirt is awfully monolithic and has a lot of dependencies. eg probably requires a static gnutls that is not available by default etc. So I am afraid that we will have to bite the bullet with the digitalocean library.

For the record, I tried to "extend" the build settings for windows:

./configure --enable-static --without-sasl --without-avahi --without-polkit --without-python\
     --without-libxl --without-qemu --without-lxc --without-openvz --without-libvirtd --without-netcf\
     --without-macvtap --without-readline --without-numactl --without-pm-utils --disable-nls\
     --prefix=$HOME/libvirt-5.1.0/out --without-driver-modules --without-yajl --without-network\
     --without-interface --without-curl --without-dbus --without-firewalld --without-fuse --without-glsterfs\
     --without-hal --without-libpcap --without-libssh --without-nss-plugin --without-openwsman\
     --without-pciaccess

I could not disable gnutls without errors. So I did not manage to include the results inside a static build of skydive. If we have to recompile statically several huge libraries to make it work, then there is something really wrong with the approach.

[jonnary]

@jonnary Where do you get the skydive bin from ?

Build by source code myself

[lebauce]

@pierrecregut @jonnary I just pushed this PR https://github.com/skydive-project/skydive/pull/1761 to address the problem