Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 09:21
    electrofelix commented #1259
  • May 17 18:47
    zzambers commented #1259
  • May 17 17:55
    zzambers commented #1259
  • May 17 16:21
    Hexawolf commented #1259
  • May 17 16:04
    electrofelix commented #1259
  • May 17 15:54
    Hexawolf commented #1259
  • May 17 14:59
    electrofelix commented #1259
  • May 17 14:53
    Hexawolf commented #1259
  • May 17 14:51
    Hexawolf commented #1259
  • May 17 14:40
    Hexawolf commented #1259
  • May 17 14:40
    Hexawolf commented #1259
  • May 16 22:09
    electrofelix commented #272
  • May 16 20:53
    rlbdv commented #272
  • May 16 18:55

    electrofelix on 1011

    (compare)

  • May 16 18:55

    electrofelix on master

    Enable forward ssh-port to host… (compare)

  • May 16 18:55
    electrofelix closed #1284
  • May 16 18:55
    electrofelix closed #1011
  • May 16 18:52
    electrofelix synchronize #1284
  • May 16 18:52

    electrofelix on 1011

    Enable forward ssh-port to host… (compare)

  • May 16 18:29
    electrofelix synchronize #1284
Gerben Meijer
@infernix
/root/.vagrant.d/gems/2.4.3/gems/fog-libvirt-0.4.2/lib/fog/libvirt/models/compute/server.rb:329:in `local_ip_command': undefined local variable or method `ip_command' for #<Fog::Compute::Libvirt::Server:0x0000000002475048> (NameError)
    from /root/.vagrant.d/gems/2.4.3/gems/fog-libvirt-0.4.2/lib/fog/libvirt/models/compute/server.rb:367:in `addresses_ip_command'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-libvirt-0.4.2/lib/fog/libvirt/models/compute/server.rb:290:in `addresses'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/wait_till_up.rb:43:in `block (3 levels) in call'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-core-1.43.0/lib/fog/core/model.rb:72:in `instance_eval'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-core-1.43.0/lib/fog/core/model.rb:72:in `block in wait_for'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-core-1.43.0/lib/fog/core/wait_for.rb:7:in `block in wait_for'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-core-1.43.0/lib/fog/core/wait_for.rb:6:in `loop'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-core-1.43.0/lib/fog/core/wait_for.rb:6:in `wait_for'
    from /root/.vagrant.d/gems/2.4.3/gems/fog-core-1.43.0/lib/fog/core/model.rb:69:in `wait_for'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/wait_till_up.rb:42:in `block (2 levels) in call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/retryable.rb:17:in `retryable'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/wait_till_up.rb:37:in `block in call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/util/timer.rb:9:in `time'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/wait_till_up.rb:34:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/start_domain.rb:302:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/set_boot_order.rb:78:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/create_network_interfaces.rb:182:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/create_networks.rb:84:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/share_folders.rb:20:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/prepare_nfs_settings.rb:18:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/synced_folders.rb:87:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
    from /root/.vagrant.d/gems/2.4.3/gems/vagrant-libvirt-0.0.43/lib/vagrant-libvirt/action/prepare_nfs_valid_ids.rb:12:in `call'
    from /opt/vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vag
i think you have a typo there?
Ingmars Melkis
@zingmars
Hello. Is there a way to configure spice's opengl functionality (specify render device) using vagrant-libvirt?
Ingmars Melkis
@zingmars
An example of the configuration option can be seen in https://libvirt.org/formatdomain.html#elementsGraphics under the SPICE section (<gl enable="yes"(...))
Brad Searle
@bobthebutcher
gday everyone. I am trying to set the cpu model of a host to core2duo but I can seem to get the right options.
       domain.cpu_mode = "custom"
      domain.cpu_model = "core2duo"
I am using these options, but it does not look like they make it to the xml file
not sure if I am going about it in the correct way
if anyone has any advice it would be greatly appreciated
Chandrasekar
@chandru1989_gitlab

@chandru1989_gitlab
Hi All
I am starting docker container in privileged mode as below and running sudo service libvirt-bin start which shows succesfull but libvirt-sock and libvirt-pid is not created
Privileged mode :

chandru@chandru-OptiPlex-790:/var/run/libvirt$ sudo docker run --privileged -ti cucumber bash

'[' -v INTERFACES ']'
'[' -v JOB_NAME ']'
bash
root@9adcf711c019:/# kvm
Could not initialize SDL(No available video device) - exiting
root@9adcf711c019:/#
root@9adcf711c019:/#
root@9adcf711c019:/#
root@9adcf711c019:/# kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used
root@9adcf711c019:/# ls -l /dev/kvm
crw-rw---- 1 root 132 10, 232 Nov 21 15:00 /dev/kvm
root@9adcf711c019:/#
root@9adcf711c019:/#
root@9adcf711c019:/# sudo service libvirt-bin start

Starting libvirt management daemon libvirtd /var/run/libvirt/libvirt-sock ready.
[ OK ]
root@9adcf711c019:/# cd /var/run/libvirt/
root@9adcf711c019:/var/run/libvirt# ls
network qemu uml-guest
root@9adcf711c019:/var/run/libvirt#
root@9adcf711c019:/var/run/libvirt#
root@9adcf711c019:/var/run/libvirt# ls -lrt
total 12
drwxrwxrwx 1 root root 4096 Nov 12 18:12 uml-guest
drwxrwxrwx 1 root root 4096 Nov 12 18:12 qemu
drwxrwxrwx 1 root root 4096 Nov 15 10:19 network
root@9adcf711c019:/var/run/libvirt#
root@9adcf711c019:/var/run/libvirt#
root@9adcf711c019:/var/run/libvirt# sudo virsh list
error: failed to connect to the hypervisor
error: no valid connection
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

Please help me to fix this issue

Darragh Bailey
@electrofelix
@chandru1989_gitlab possibly you should just use a volume mount from the host to expose the libvirt-sock into the container instead of trying to run libvirtd inside of a container as I'm guessing that it probably does not have the same user/group as the libvirtd running on the host that you are trying to use and thus is unlikely to be granted access
Dan Čermák
@dcermak
Hi folks, I've got a problem with vagrant-libvirt on aarch64: my vagrant boxes get generated with NVRAM, which causes issues when these should get deleted, as vagrant libvirt doesn't pass the correct flags to libvirt
I get such a backtrace on vagrant destroy -f: https://paste.fedoraproject.org/paste/sedOD1byIF-vHFsMG7lXSA
This can be solved on the CLI via virsh undefine $vagrant_libvirt_boxname --nvram --remove-all-storage
the trick is the missing --nvram flag
does anyone know where this has to be added in the code?
Gerben Meijer
@infernix
@electrofelix ping
sahanaha1234
@sahanaha1234
Hi Folks, I am trying to install vagrant-libvirt plugin without having internet access. I tried the steps mentioned in https://alwaystinkering.wordpress.com/2016/07/08/manually-installing-plugins-in-vagrant . This needs ruby version >=2.3.0 for package nokogiri-1.10.5.gem to be installed. Is there any way I can install vagrant-libvirt offline with out having requirement for ruby version to be 2.3.0 ? I see that vagrant-libvirt is having dependency of nokogiri >=1.6.0, hence if you could help me on how we can replace nokogiri-1.6.0 instead of nokogiri-1.10.5 in the above mentioned method will be great!
AnPham
@phamduchongan93
/@infernix I'm too is having the same gme issue
you folks found out the problem yet?
Roberto Ciatti
@gekorob
Hi guys I'm trying to package a running centos 8.1 as box, but after package box when I try to us it in a vagrant file the vagrant up hangs on waiting for ssh
default: Waiting for SSH to become available...
Does anybody has some hints?
elreydetoda
@elreydetoda

Is this were people are talking about this issue? vagrant-libvirt/vagrant-libvirt#1069

I don't know how I can help, but I would love to!

Dan Čermák
@dcermak
@elreydetoda I guess so? This channel is unfortunately not very active though…
elreydetoda
@elreydetoda
is there an "official" communication method that the other people who are going to be maintainers will have? or just any other communication methods?
Dan Čermák
@dcermak
I'd try this channel and github issues
Darragh Bailey
@electrofelix
@dcermak mostly the problem is due to most of the past maintainers not actively using vagrant-libvirt as much so difficult to devote time to it as part of work. I'm trying to keep the ball rolling so to speak, but it's clear I'm not in a viable position to actively maintain
Dan Čermák
@dcermak
@electrofelix That is a pity, as I (and probably a bunch of others) are actively using vagrant-libvirt
unfortunately Ruby is like black magic to me, so I also don't see myself contributing a lot :-(
however, I could try to look a bit into creating tests and test cases and a CI to prevent regressions, as they'd eventually bite me as well (I'm the current vagrant & vagrant-libvirt maintainer in openSUSE)
unfortunately won't have time for that until June
Darragh Bailey
@electrofelix
@dcermak the good news is I'm getting a little bit more time and there looks like a few others are helping get some PRs in good shape, so a little bit from a number of people may be enough to get it all rolling forward again
Dan Čermák
@dcermak
anyone knows if it is possible to modify the cmdline of the existing kernel of an existing vagrant box?
Darragh Bailey
@electrofelix
@dcermak I think it's only possible if you are setting the kernel and initrd to be used from the host as otherwise qemu is just launching the default bootloader in the disk image passed to it. The alternative is to boot, use the provision steps to modify from within the guest and then use the reload plugin to trigger a reboot to use the new settings
Dan Čermák
@dcermak
@electrofelix Thanks for your reply, so it's as I thought
matrixbot
@matrixbot
@mattiasb:matrix.org Hi! I regularly create vagrant boxes for testing ansible roles. Sometimes there's a lot of data to download before the playbook is done. Recently I've been bitten by this issue a lot: vagrant-libvirt/vagrant-libvirt#1122
@mattiasb:matrix.org According to the Vagrant developers this is an issue with the vagrant-libvirt plugin: https://github.com/hashicorp/vagrant/issues/11692#issuecomment-642133380
@mattiasb:matrix.org I say "issue" but it might very well be intended behaviour.
@mattiasb:matrix.org The problem is that when I forget to add the --no-destroy-on-error flag I might very well lose 30 minutes having to reprovision the machine from the beginning again while trying to find the issue with my playbook.
@mattiasb:matrix.org Is it possible somehow (without resorting to wrapping vagrant in a shell script) to configure vagrant-libvirt to not destroy the domain on error?
Darragh Bailey
@electrofelix
@matrixbot I think this will require me asking questions of the vagrant developers, because it looks like the CLI option documentation and what they intended to occur by default don't match. In the past there were issues because vagrant-libvirt always destroyed and didn't match the expected behaviour with the CLI option. The only thing I could think of is to expose a config option in vagrant-libvirt that overrides the command behaviour with an explicit warning, usually you'd always take the requested behaviour from the CLI but in this case vagrant will default to always setting destroy_on_error
Darragh Bailey
@electrofelix
@matrixbot I've logged hashicorp/vagrant#12098 to try and get them to explain what the intention of that option is, if it's not to perform a destroy on error as is currently documented
matrixbot
@matrixbot
@mattiasb:matrix.org Thanks! :)
defolos
@defolos:matrix.org
[m]
Hey @electrofelix, I've seen that the newest release of vagrant-libvirt contains the contextual_proc gem
Could that please, please be removed?
I'm currently looking into updating vagrant-libvirt to 0.4.0 in openSUSE, but the contextual_proc gem is effectively unpackageable, because it contains no license at all (i.e. it is proprietary from a legal pov and cannot be included in most Linux distros)
also, that gem is effectively just a single class, maybe it would be possible to completely omit it?
Darragh Bailey
@electrofelix
@defolos:matrix.org yes it should be removed shortly, the original maintainers have added a license to their repo and I'll look to work with them to get a subsequent release, my apologies for missing that there was no license
1 reply
Darragh Bailey
@electrofelix
@defolos:matrix.org just pushed a 0.4.1 release there with the contextual_proc gem removed, along with 2 small bugfixes, I'll look to avoid landing anything other than bugfixes for another week
defolos
@defolos:matrix.org
[m]
Plus it was really simple to rip out even for a ruby noob like myself