| View previous topic :: View next topic |
| Author |
Message |
gjy0724
Apprentice
Joined: 11 Jun 2005
Posts: 170
Location: Lock Haven, Pennsylvania
|
 Posted: Wed Dec 26, 2018 5:24 pm Post subject: Vagrant using libvirt and provisioned by ansible |
 |
|
I recently reinstalled Gentoo, after using RHEL based systems for the last few years (Scientific Linux to be specific) on my desktop and there is one last thing I have been trying to work out. I have vagrant (2.2.2-r1) and ansible (2.7.4) installed and I use libvirt/kvm for my virtualization solution. Vagrant alone seems to work fine as I am able to start boxes up (typically CentOS) without issue, however connecting to them through SSH is not working properly as I get the following error.
| Code: | | Permission denied (publickey,gssapi-keyex,gssapi-with-mic). |
However, if I stop the SSH service using systemd (on CentOS 7) or the sshd init script (CentOS 6), then restart using the binary manully (/usr/sbin/sshd -D -u0) I am able to connect to the box just fine with my key.
Another issue I am having which may or may not be related...when I provision the vagrant box with ansible using "config.vm.provision "ansible" do |ansible|". I have been researching this issue over about a week now but haven't found any useful information to assist on the issue.
| Code: | /home/gjy0724/.vagrant.d/gems/2.4.5/gems/fog-libvirt-0.5.0/lib/fog/libvirt/requests/compute/list_domains.rb:9:in `lookup_domain_by_uuid': Call to virDomainLookupByUUID failed: internal error: client socket is closed (Libvirt::RetrieveError)
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/fog-libvirt-0.5.0/lib/fog/libvirt/requests/compute/list_domains.rb:9:in `list_domains'
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/fog-libvirt-0.5.0/lib/fog/libvirt/models/compute/servers.rb:15:in `get'
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/driver.rb:65:in `get_domain'
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/driver.rb:79:in `created?'
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/provider.rb:101:in `state'
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/action/wait_till_up.rb:105:in `terminate'
from /home/gjy0724/.vagrant.d/gems/2.4.5/gems/vagrant-libvirt-0.0.45/lib/vagrant-libvirt/action/wait_till_up.rb:101:in `recover'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:67:in `block in recover'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `each'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `recover'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/builtin/call.rb:61:in `recover'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:67:in `block in recover'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `each'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:64:in `recover'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:53:in `rescue in call'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:28:in `call'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/builder.rb:116:in `call'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/runner.rb:66:in `block in run'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/util/busy.rb:19:in `busy'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/action/runner.rb:66:in `run'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:239:in `action_raw'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:208:in `block in action'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/environment.rb:614:in `lock'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:194:in `call'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/machine.rb:194:in `action'
from /usr/lib64/ruby/gems/2.4.0/gems/vagrant-2.2.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run' |
Keep in mind I am using the same Vagrantfile on my work laptop which is running Scientific Linux, with one minor change "ansible.compatibility_mode = "2.0"" because the version of Vagrant on SL is 1.9.6 which doesn't need the line...yet! And neither of these issues exist there, and I have confirmed that the CentOS vagrant box versions are the same.
I will likely post this in vagrant support as well, however since the biggest difference between my personal desktop and work laptop is the base OS I figured I would post here first. |
|
| Back to top |
|
 |
gjy0724
Apprentice
Joined: 11 Jun 2005
Posts: 170
Location: Lock Haven, Pennsylvania
|
| Posted: Mon Feb 04, 2019 7:05 pm Post subject: |
|
|
This morning, I was able to produce the steps to work-around the issue. It requires the removal of the snapshot from /var/lib/libvirt/images | Code: | | # rm /var/lib/libvirt/images/centos-VAGRANTSLASH-7_vagrant_box_image_1901.01.img |
and the restarting of libvirtd | Code: | | # systemctl restart libvirtd |
prior to creating a new instance. It is not the most elegant solution but it did work 6 times in a row...the first 3 of the six also included removing the box image from my home folder | Code: | | $ vagrant box remove centos/7 |
which I later discovered was not needed.
I have a feeling I may be missing a USE flag that would resolve this issue, this is what I have now.
| Code: | [ebuild R ] app-emulation/qemu-3.1.0::gentoo USE="aio alsa bzip2 caps curl fdt filecaps gtk jpeg ncurses nls numa opengl pin-upstream-blobs png pulseaudio python sdl seccomp spice usb vhost-net vnc xattr -accessibility (-capstone) -debug (-glusterfs) -gnutls -infiniband -iscsi -lzo -nfs -rbd -sasl (-selinux) -smartcard -snappy -ssh (-static) -static-user -systemtap -tci -test -usbredir -vde -virgl -virtfs -vte -xen -xfs" PYTHON_TARGETS="python2_7 python3_6 -python3_4 -python3_5 (-python3_7)" QEMU_SOFTMMU_TARGETS="x86_64 -aarch64 -alpha -arm -cris -hppa -i386 -lm32 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -moxie -nios2 -or1k -ppc -ppc64 -riscv32 -riscv64 -s390x -sh4 -sh4eb -sparc -sparc64 -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="x86_64 -aarch64 -aarch64_be -alpha -arm -armeb -cris -hppa -i386 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -nios2 -or1k -ppc -ppc64 -ppc64abi32 -ppc64le -riscv32 -riscv64 -s390x -sh4 -sh4eb -sparc -sparc32plus -sparc64 -tilegx -xtensa -xtensaeb" 0 KiB
[ebuild R ] app-emulation/libvirt-4.9.0:0/4.9.0::gentoo USE="caps dbus firewalld libvirtd macvtap nls numa policykit qemu udev vepa virt-network -apparmor -audit -fuse -glusterfs -iscsi -libssh -lvm -lxc -nfs (-openvz) -parted -pcap -phyp -rbd -sasl (-selinux) -uml -virtualbox -wireshark-plugins -xen -zeroconf (-zfs)" 0 KiB |
Any assistance would be greatly appreciated. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
