Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vagrant-libvirt: plugin won't install (debian stretch 9.1.0) #9285

Closed
ribamar-santarosa opened this issue Dec 19, 2017 · 3 comments
Closed

Comments

@ribamar-santarosa
Copy link

Vagrant version

vagrant -v
Vagrant 2.0.1

Host operating system

lsb_release  -a
Distributor ID: Debian
Description:    Debian GNU/Linux 9.1 (stretch)
Release:        9.1
Codename:       stretch

Guest operating system

vagrant not yet installed

Vagrantfile

vagrant not yet installed

Debug output

https://gist.github.com/ribamar-santarosa/02a441d8d6f4dfa555ab57993553c2c7

Expected behavior

vagrant-libvirt installed.

Actual behavior

Installation fails:

ERROR: Failed to build gem native extension.

    current directory: /home/ribamar/.vagrant.d/gems/2.4.2/gems/ruby-libvirt-0.7.0/ext/libvirt
/opt/vagrant/embedded/bin/ruby -r ./siteconf20171219-22266-nuqqmh.rb extconf.rb
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Steps to reproduce

wget -c https://releases.hashicorp.com/vagrant/2.0.1/vagrant_2.0.1_x86_64.deb
sudo dpkg -i vagrant_2.0.1_x86_64.deb
vagrant plugin install vagrant-mutate
vagrant plugin install vagrant-libvirt

References

Looks related:
#5118

@ribamar-santarosa
Copy link
Author

ribamar-santarosa commented Dec 19, 2017

sudo apt-get install libffi-dev libvirt-dev and then I could install the plugin. But it remais pretty much unusable, since vagrant still thinks that I want to use virtualbox, and won't let me destroy the machine (even with --force):

vagrant init debian/stretch64 
vagrant up --provider=libvirt
# An active machine was found with a different provider. Vagrant
# currently allows each machine to be brought up with only a single
# Machine name: default
# Active provider: virtualbox
# Requested provider: libvirt
 vagrant destroy default
# The provider 'virtualbox' that was requested to back the machine
#'default' is reporting that it isn't usable on this system. The
# reason is shown below:
# ...

vagrant global-status 
# 434a01b  default virtualbox poweroff /home/ribamar/to-merge/wt/virt/vagrant 
 
 vagrant destroy 434a01b
# The provider 'virtualbox' that was requested to back the machine
# ...

vagrant destroy --force 434a01b 
# The provider 'virtualbox' that was requested to back the machine
# 'default' is reporting that it isn't usable on this system. The
#  reason is shown below:

@ribamar-santarosa
Copy link
Author

ribamar-santarosa commented Dec 19, 2017

reinstalling the package virtualbox solved the unusability issue above, so destroy succeeded (although for me it's still a bug that -f didn't work).

vagrant destroy --force 434a01b 
sudo apt-get install nfs-kernel-server
sudo usermod --append --groups libvirt `whoami`
sudo login
cd $HOME/vagrant
 vagrant up --provider=libvirt
vagrant global-status 
id       name    provider state   directory                              
-------------------------------------------------------------------------
2ba53d4  default libvirt running $HOME/vagrant 

I still can't ssh to it:

vagrant ssh
The provider for this Vagrant-managed machine is reporting that it
is not yet ready for SSH. Depending on your provider this can carry
different meanings. Make sure your machine is created and running and
try again. Additionally, check the output of `vagrant status` to verify
that the machine is in the state that you expect. If you continue to
get this error message, please view the documentation for the provider
you're using.

But, the vm machine seems to be running, this ticket (" won't install") could be closed.

Update -- for those who interest, I had a key password id_rsa in my ~/.ssh . Removing it -- not the ideal solution, but as a proof of concept -- allowed me to ssh to the image.

@ghost
Copy link

ghost commented Mar 31, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant