search

vagrant-libvirt / vagrant-libvirt

Vagrant provider for libvirt.
https://vagrant-libvirt.github.io/vagrant-libvirt/
MIT License
2.32k stars 498 forks source link

incompatible library version #541

Closed ichilton closed 1 year ago

ichilton commented 8 years ago

I just tried uninstalling and re-installing vagrant-libvirt in the vague hope that it fixed issue #535

However, now I can't get anything other than this:

$ vagrant up
/home/ichilton/.vagrant.d/gems/gems/ruby-libvirt-0.6.0/lib/libvirt.rb:11:in `require': incompatible library version - /home/ichilton/.vagrant.d/gems/extensions/x86_64-linux/2.2.0/ruby-libvirt-0.6.0/_libvirt.so (LoadError)
    from /home/ichilton/.vagrant.d/gems/gems/ruby-libvirt-0.6.0/lib/libvirt.rb:11:in `<top (required)>'
    from /home/ichilton/.vagrant.d/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt.rb:4:in `require'
    from /home/ichilton/.vagrant.d/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt.rb:4:in `<top (required)>'
    from /home/ichilton/.vagrant.d/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/driver.rb:1:in `require'
    from /home/ichilton/.vagrant.d/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/driver.rb:1:in `<top (required)>'
    from /home/ichilton/.vagrant.d/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/provider.rb:29:in `driver'
    from /home/ichilton/.vagrant.d/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/provider.rb:101:in `state'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:501:in `state'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:144:in `initialize'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/vagrantfile.rb:79:in `new'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/vagrantfile.rb:79:in `machine'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:663:in `machine'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:177:in `block in with_target_vms'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:201:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:201:in `block in with_target_vms'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:183:in `each'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:183:in `with_target_vms'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/up/command.rb:89:in `block in execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:278:in `block (2 levels) in batch'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:276:in `tap'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:276:in `block in batch'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:275:in `synchronize'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:275:in `batch'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/up/command.rb:88:in `execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/cli.rb:42:in `execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:302:in `cli'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.8.1/bin/vagrant:174:in `<main>'

O/S is Arch Linux.

I tried swapping in the ruby-libvirt from the AUR, as suggested at: https://wiki.archlinux.org/index.php/Vagrant ...but I just get the same.

Any ideas?

Thanks,

Ian

ichilton commented 8 years ago

ok, i've managed to get a workaround for this.

Doing some testing with ruby-libvirt and irb, I found that it worked fine with Arch's system ruby (2.3.0), but not with Vagrant's embedded ruby - it gave the above error.

So, I manually uninstalled ruby-libvirt and installed it with the environment fudged to use Vagrant's ruby.

This includes the fix for the libcurl issue, as per: https://wiki.archlinux.org/index.php/Vagrant

export PATH=/opt/vagrant/embedded/bin:$PATH
export GEM_HOME=~/.vagrant.d/gems
export GEM_PATH=$GEM_HOME:/opt/vagrant/embedded/gems
gem uninstall ruby-libvirt
sudo mv /opt/vagrant/embedded/lib/libcurl.so{,.backup}
sudo mv /opt/vagrant/embedded/lib/libcurl.so.4{,.backup}
sudo mv /opt/vagrant/embedded/lib/libcurl.so.4.4.0{,.backup}
sudo mv /opt/vagrant/embedded/lib/pkgconfig/libcurl.pc{,.backup}
sudo mv /opt/vagrant/embedded/lib/pkgconfig/libcurl.pc{,.backup}
gem install ruby-libvirt
sudo mv /opt/vagrant/embedded/lib/libcurl.so{.backup,}
sudo mv /opt/vagrant/embedded/lib/libcurl.so.4{.backup,}
sudo mv /opt/vagrant/embedded/lib/libcurl.so.4.4.0{.backup,}
sudo mv /opt/vagrant/embedded/lib/pkgconfig/libcurl.pc{.backup,}

And finally, success!

$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...

So it seems that when doing a 'vagrant plugin install vagrant-libvirt', it's not setting up the environment properly somewhere.

robled commented 8 years ago

@ichilton

Your work-around is confirmed successful on my system. I fixed a small typo/copy issue with the provided script and combined it with the one from the Arch wiki:

https://gist.github.com/robled/070e1922816bbe983623#file-reinstall-vagrant-libvirt-sh

ichilton commented 8 years ago

Nice one - though you are duplicating there - you only need to do the libcurl workaround once - you can do both the vagrant-libvirt install and the ruby-libvirt re-install in the middle.

ichilton commented 8 years ago

How odd. I just tried this on another machine - up-to-date Arch Linux and provisioned with the same ansible playbook. This one fixed issue #535 with the re-install of vagrant-libvirt but didn't hit the "incompatible library version" issue.

I still needed the libcurl workaround for the vagrant-libvirt install to successfully install ruby-libvirt, but the one it did as part of a 'vagrant plugin install vagrant-libvirt' worked fine.

romu70 commented 8 years ago

Fantastic, this also fixes my issue on Fedora 23, thanks a lot!

romu70 commented 8 years ago

And so my Ubuntu Server 15.10, really, thanks a lot !

electrofelix commented 8 years ago

The problem was always going to be ruby-libvirt any time the embedded version of ruby that comes with vagrant is changed significantly, since ruby-libvirt contains compiled code against the version of ruby.

I would suspect that it's ruby-libvirt gem + vagrant that is broken here, and it's probably next to impossible for vagrant-libvirt to solve automatically.

Instead need to get ruby-libvirt talking to vagrant and then mask out the incompatible versions in vagrant-libvirt's requirements.

infernix commented 8 years ago

I'm labelling this as invalid as it looks like we won't be able to resolve this issue in ruby-libvirt and it isn't a vagrant-libvirt bug; please make some noise if you feel that's incorrect.

robled commented 8 years ago

If this bug is invalid for vagrant-libvirt, where should it be reported?

infernix commented 8 years ago

As far as I can tell, ruby-libvirt or vagrant. vagrant-libvirt itself isn't causing the issue, and if @electrofelix is correct and we can't resolve this in the build process for vagrant-libvirt there's nothing there to fix. vagrant-kvm has the same problem I believe.

aldum commented 8 years ago

Thank you, kind sir! Why is this not added to the Arch wiki yet?

bebehei commented 8 years ago

I had to use vagrant today my first time. After searching google for the error-message I found this. Thankfully, @ichilton's solution worked fine.

I have no knowlegde about ruby & co.: Could someone please post this bug to the correct bugtracker, that it'll get fixed?

gregjan commented 8 years ago

Many thanks for your fix! (Ubuntu 15)

rwaweber commented 8 years ago

Awesome workaround guys, its a bummer its an upstream problem. @infernix would it be possible if we put a note for special action being necessary for arch linux in the readme?

infernix commented 8 years ago

@rwaweber perhaps; I will add Arch to #590 and from there I will try to provide per-distro install instructions. I just haven't gotten to it yet. In the meantime the Arch wiki is probably best, since that's where all Arch users look first anyway.

eriknelson commented 8 years ago

FYI, I hit this today on Arch Linux and the workaround script posted failed since gem install ruby-libvirt now installs 0.7.0 instead of 0.6.0, (fog-libvirt requires < 0.7.0). Installing ruby-libvirt 0.6.0 explicitly fixed the problem.

gem install ruby-libvirt -v 0.6.0

Error I saw after running the workaround:

Bundler could not find compatible versions for gem "ruby-libvirt":
  In Gemfile:
    vagrant-libvirt was resolved to 0.0.35, which depends on
      fog-libvirt (= 0.0.3) was resolved to 0.0.3, which depends on
        ruby-libvirt (< 0.7.0, >= 0.5.0)
infernix commented 8 years ago

Please retest this against current master which updates fog-libvirt and ruby-libvirt.

You can git clone the repo and do a gem build vagrant-libvirt.gemspec which generates a .gem that can be installed with vagrant plugin install /path/to/gem

jcf commented 7 years ago

I've run into this issue, and have tried all the suggested workarounds and fixes I can find.

Following the instructions to try gem pristine ruby-libvirt --version 0.7.0:

$ CONFIGURE_ARGS='with-ldflags=-L/opt/vagrant/embedded/lib with-libvirt-include=/usr/include/libvirt with-libvirt-lib=/usr/lib' GEM_HOME=~/.vagrant.d/gems/2.2.5/ GEM_PATH=$GEM_HOME:/opt/vagrant/embedded/gems PATH=/opt/vagrant/embedded/bin:$PATH gem pristine ruby-libvirt
Restoring gems to pristine condition...
Building native extensions.  This could take a while...
Restored ruby-libvirt-0.7.0

Please retest this against current master which updates fog-libvirt and ruby-libvirt.

@infernix I've cloned the repo, built the gem from the gemspec, and installed with vagrant plugin install and still getting the same error.

Bringing machine 'default' up with 'libvirt' provider...
Ignoring ruby-libvirt-0.7.0 because its extensions are not built.  Try: gem pristine ruby-libvirt --version 0.7.0
/opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require': incompatible library version - /home/jcf/.vagrant.d/gems/2.2.5/gems/ruby-libvirt-0.7.0/lib/_libvirt.so (LoadError)
    from /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /home/jcf/.vagrant.d/gems/2.2.5/gems/ruby-libvirt-0.7.0/lib/libvirt.rb:11:in `<top (required)>'
    from /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /home/jcf/.vagrant.d/gems/2.2.5/gems/fog-libvirt-0.3.0/lib/fog/libvirt.rb:4:in `<top (required)>'
    from /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /home/jcf/.vagrant.d/gems/2.2.5/gems/vagrant-libvirt-0.0.36/lib/vagrant-libvirt/driver.rb:1:in `<top (required)>'
    from /home/jcf/.vagrant.d/gems/2.2.5/gems/vagrant-libvirt-0.0.36/lib/vagrant-libvirt/provider.rb:29:in `driver'
    from /home/jcf/.vagrant.d/gems/2.2.5/gems/vagrant-libvirt-0.0.36/lib/vagrant-libvirt/action/create_networks.rb:26:in `initialize'

UPDATE: VirtualBox works!

If you can't wait, you can switch provider to VirtualBox.

vagrant up --provider virtualbox

If you have created libvirt VMs, you may need to blow away your .vagrant directory to rid yourself of errors like this:

$ vagrant up --provider virtualbox
The provider 'libvirt' could not be found, but was requested to
back the machine 'default'. Please use a provider that exists.

Unsetting VAGRANT_DEFAULT_PROVIDER may also be required depending on the contents of your Vagrantfile.

ericpulvino commented 7 years ago

I'm hitting this as well. Ubuntu 16.04, vagrant-libvirt from source, ruby-libvirt from source, vagrant from upstream 1.9.1. I've tried everything I can think of.

For me the message appears to be cosmetic because I can still turn up a vagrant-libvirt VM. `vagrant status Ignoring ruby-libvirt-0.7.0 because its extensions are not built. Try: gem pristine ruby-libvirt --version 0.7.0 Current machine states:

oob-mgmt-server not created (libvirt) oob-mgmt-switch not created (libvirt) leaf1 not created (libvirt) leaf2 not created (libvirt)

This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run vagrant status NAME. ` But the message shows up with every vagrant command which is very annoying.

jhamhader commented 7 years ago

I'm running into the same issue with Arch. gem pristine ruby-libvirt --version 0.7.0 doesn't seem to help.

addi-abel commented 7 years ago

I am getting this error ... /opt/vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require': incompatible library version - /home/addi/.vagrant.d/gems/2.2.5/gems/ruby-libvirt-0.7.0/lib/_libvirt.so (LoadError)

j883376 commented 7 years ago

I was able to work around this on Arch by changing the Gem path. It seems that Vagrant is installing the gems, linked against Ruby 2.3, into ~/.vagrant.d/gems/2.2.5 not ~/.vagrant.d/gems. Changing the Gem path to ~/.vagrant.d/gems/2.2.5 and reinstalling ruby-libvirt seems to fix this.

https://gist.github.com/j883376/d90933620c7ed14daa4e0963e005377f

It does continue to spew the "incompatible library version" on every command, but it seems to be cosmetic because I was able to successfully start and provision a machine.

gavinB-orange commented 7 years ago

Seeing same cosmetic issue on Linux Mint 18 = Ubuntu 16.04 LTS after upgrading vagrant from 1.8.6 to 1.9.1

stefancocora commented 7 years ago

The workaround presented in https://gist.github.com/j883376/d90933620c7ed14daa4e0963e005377f doesn't work by itself anymore on the latest Archlinux software snapshot

Kernel: 4.11.3-1-ARCH x86_64 (64 bit)
Distro: Arch Linux

pacman -Q|grep vagrant
vagrant 1.9.5-1
vagrant-substrate-605.0566498 ( as pulled from an update with pacman -Syu )
vagrant-substrate 599.d7cedfe-2 (after downgrade)

I've updated both the link to the aforementioned gist and the Archlinux wiki for the workaround for vagrant 1.9.5-1

mcandre commented 6 years ago

Good news! I was able to resolve the incompatible library version error in macOS by:

  1. Upgrading to Vagrant 2.0.1.
  2. rm -rf ~/.vagrant.d
  3. vagrant destroy -f; rm -rf .vagrant
  4. CONFIGURE_ARGS="with-libvirt-include=/usr/include/libvirt with-libvirt-lib=/usr/lib" vagrant plugin install vagrant-libvirt
  5. vagrant up --provider libvirt

At this point, the error is no longer to do with incompatible library version, though hilariously enough after resolving all manner of issues setting up libvirt for vagrant on macOS, I do get a new error:

$ vagrant up --provider libvirt
==> default: VM not created. Moving on...
Bringing machine 'default' up with 'libvirt' provider...
Error while connecting to libvirt: Error making a connection to libvirt URI qemu:///system?no_verify=1&keyfile=/Users/andrew/.ssh/id_rsa&socket=/var/run/libvirt/libvirt-sock:
Call to virConnectOpen failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

Configuring virtd or whatever is beyond me, but at least with a fresh Vagrant including removing the $HOME/.vagrant.d and $(pwd)/.vagrant directories, I don't see the incompatibility error anymore. Oh well, I'll look into how to get the libvirt daemon thingy up and running in macOS... The tutorials online keep insisting on using user@hostname in the virtd connection URL, and no combination of values there gets that working.

Also posting to the Homebrew Discourse in case any Homebrew users know how to deal with this socket setup: https://discourse.brew.sh/t/failed-to-connect-socket-to-var-run-libvirt-libvirt-sock-no-such-file-or-directory/1297

electrofelix commented 3 years ago

I think for some https://github.com/vagrant-libvirt/vagrant-libvirt#additional-notes-for-fedora-and-similar-linux-distributions will help and for others use of CONFIGURE_ARGS will help, the move by vagrant to put plugins under a versioned directory will also help, but in general until vagrant doesn't require an embedded ruby version with specific libraries to be distributed there are going to be issues when linking between system libraries and the vagrant embedded ruby.

ssbarnea commented 3 years ago

Sadly I am afraid that will never change for the good as @hashicorp lost interest in vagrant and there is nobody with enough money/time to drive the project. That is one of the reasons I would see molecule-libvirt driver more likely to replace molecule-vagrant for local VM provisioning, removing vagrant from the equation. I hope I am wrong as I really liked the simplicity of the vagrant command line.

electrofelix commented 3 years ago

It looks like there are plans afoot to resolve this, as the maintainers of vagrant are planning to port the core to golang and make use of gRPC as the interface between the core and plugins. https://www.hashicorp.com/blog/toward-vagrant-3-0 contains the announcement and https://discuss.hashicorp.com/t/blog-toward-vagrant-3-0/25104 is the discussion topic that I'll be keeping an eye on.

This would likely solve most of the problems for vagrant-libvirt in that ruby-libvirt would be built and linked against the system ruby and libvirt along with any libraries they need. And instead of having conflicts between libraries bundled with vagrant and what libvirt/ruby-libvirt need, they would be separate and just use interfaces/helpers via a gRPC API. I've not idea how well this is going to work, but I guess at least it's a possible path.

Whether this will happen soon enough or whether many projects will end up using libvirt directly instead due to the time lag remains to be seen.

In the mean time I put together a docker image that should now be extendible that contains vagrant + vagrant-libvirt with a working install, the one matching the tip of master vagrantlibvirt/vagrant-libvirt:edge should work a little better as it contains some recent fixes (latest tag is actually the most recent release rather than latest of the default branch, perhaps I should change that). I've just spotted it's using the 2.2.10 release of vagrant so will bump that shortly. Otherwise this should provide something that works consistently with only requiring that the system has docker and libvirt (and is x86_64), nothing else should be needed.

https://github.com/vagrant-libvirt/vagrant-libvirt#using-docker-based-installation contains some instructions.

electrofelix commented 1 year ago

Recently I put together better documentation combined with a helper script for installing this plugin on distros when using the upstream vagrant

https://vagrant-libvirt.github.io/vagrant-libvirt/installation.html

I'll look to keep on top of adding recent distros to the test matrix in https://GitHub com/vagrant-libvirt/vagrant-libvirt-qa as well

Based on this, I'm going to close this as not planned in that it's unlikely to ensure it can't happen again, but at least when it does there will be a specific way to encode workarounds that can be consumed a little easier.