Description of problem: I have 2 machines configured in quite the same way. One runs Fedora Workstation, the other one Fedora Server. Both have qemu, libvirt, vagrant, etc... installed and configured in the same way. Adding a vagrant box (e.g. fedora/23-cloud-base) and just calling vagrant up in stock configuration starts the box without any problems on Fedora Workstation but hangs in Fedora Server at: ==> default: Waiting for domain to get an IP address... vagrant debug constantly outputs: INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded> The machines single core is at 100%. I've searched the net but all results were old problems that should already be fixed. Version-Release number of selected component (if applicable): Vagrant 1.7.4 vagrant-libvirt-0.0.30-5.fc23.noarch How reproducible: Install Fedora Server with virtualization and vagrant and try to bring a fedora box up. Steps to Reproduce: 1.Run vagrant init 2.Change the box name in Vagrantfile to a desired box 3.run vagrant up Actual results: Vagrant hangs at: ==> default: Waiting for domain to get an IP address... Expected results: Vagrant creates and starts the box properly Additional info: Both configurations (Workstation and Server are stock)
I tried the following: 1, I installed a fresh Fedora 23 Server in virt-manager 2, Installed vagrant-libvirt package (same version and release) 3, $ vagrant init fedora/23-cloud-base 3, Edited the Vagrantfile to use qemu instead of kvm driver (I did not have kvm capabilities) 4 $ vagrant up It worked. How long did you wait for vagrant up to finish? Do other boxes work for you? When you wait for Vagrant can you use the VM from other tools like virt-manager? I would probably need you to do some debugging and testing, otherwise I cannot reproduce...
I waited for at least one hour (went for lunch) Virt manager said guest has not initialised display yet. Same problem with centos/7 box. Both systems use bridged networking, so actually there were three bridges running. The one i build for my virtual machines to give them access to the physical network 'bridge0', virb0 that comes with libvirt and then virb1 build by vagrant. Maybe there is something wrong because logs tell me that the machine is waiting for an ip address and times out with the virtual network device on virb1. But why is this only happening on the 'server' machine and not workstation :-/
Its strange that only Server variant fails you. Can you reproduce your setup with exact steps/script that one can run? E.g. what exactly you do and how on the fresh machine so I can make sure I have the same?
I have been seeing this trying to start Fedora 23 VMs with F24 vagrant-libvirt. (E.g. with 'vagrant init fedora/23-atomic-host; vagrant up) When I look at the console, I see: [ 1.432596] AES CTR mode by8 optimization enabled [ 1.456489] invalid opcode: 0000 [#1] SMP [ 1.458197] Modules linked in: [ 1.459577] CPU: 0 PID: 107 Comm: cryptomgr_test Not tainted 4.4.3-300.fc23.x86_64 #1 [ 1.463859] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 [ 1.466193] task: ffff8800773db980 ti: ffff8800350f4000 task.ti: ffff8800350f4000 [ 1.468699] RIP: 0010:[<ffffffff810934aa>] [<ffffffff810934aa>] aes_ctr_enc_128_avx_by8+0xa/0x1250 [ 1.471637] RSP: 0018:ffff8800350f78c8 EFLAGS: 00010206 [ 1.473218] RAX: 0000000000000010 RBX: 0000000000000000 RCX: ffff8800350d6000 [ 1.475085] RDX: ffff8800350b1850 RSI: ffff8800350f7d70 RDI: ffff8800350d6000 [ 1.477134] RBP: ffff8800350f78d0 R08: 0000000000000040 R09: ffff8800350d6000 [ 1.479206] R10: ffff8800350d6000 R11: 0000000000000000 R12: ffff8800350b1850 [ 1.481261] R13: ffff8800350f79d0 R14: ffff8800350f7d70 R15: ffff8800350d6000 [ 1.483106] FS: 0000000000000000(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 1.485240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.486570] CR2: 00007f912b64f944 CR3: 0000000001c09000 CR4: 00000000001006f0 [ 1.488831] Stack: [ 1.489992] ffffffff8107d181 ffff8800350f79c0 ffffffff8107ca49 00000000b48faa52 [ 1.493464] 0000000000000000 ffffea0000d43580 ffff8800350d6000 ffffea0000d43580 [ 1.496752] ffff8800350d6000 ffff8800350f7b70 0000000000000000 ffff880000000040 [ 1.502141] Call Trace: [ 1.503407] [<ffffffff8107d181>] ? aesni_ctr_enc_avx_tfm+0x41/0x50[..] This led me to edit /usr/lib/vagrant-libvirt/templates/domain.xml.erb and replace the <cpu> element with: <cpu mode='host-passthrough'> <feature policy='disable' name='aes'/> </cpu> Which worked. Entirely disabling the <cpu/> element didn't obviously work. I haven't seen this behavior when using libvirt through GNOME Boxes, so I'm a bit confused why only vagrant-libvirt is exhibiting this for me. There is almost certainly some libvirt, qemu, or Fedora kernel bug here as well. Not sure if this is the same as what the original reporter was seeing - the console output on booting would say
Description of problem: Image Fedora-Cloud-Base-Vagrant-24-1.2.x86_64.vagrant-libvirt.box doesn't want to boot. "vagrant up" hangs on "Waiting for domain to get an IP address...". With --debug flag it says: INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded> Tryed this image on fedora 24, also on debian sid.
(In reply to go.wigust from comment #5) > Description of problem: > > Image Fedora-Cloud-Base-Vagrant-24-1.2.x86_64.vagrant-libvirt.box doesn't > want to boot. > > "vagrant up" hangs on "Waiting for domain to get an IP address...". > > With --debug flag it says: > INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The > specified wait_for timeout (2 seconds) was exceeded> > > Tryed this image on fedora 24, also on debian sid . Does adding: config.vm.provider "libvirt" do |lv| lv.cpu_mode = 'host-passthrough' end to your Vagrantfile help?
(In reply to Owen Taylor from comment #6) > Does adding: > > config.vm.provider "libvirt" do |lv| > lv.cpu_mode = 'host-passthrough' > end > > to your Vagrantfile help? Yes, it is. Output is: /usr/share/gems/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:67:in `initia lize': Object#timeout is deprecated, use Timeout.timeout instead. But i get shell prompt and can 'vagrant ssh' now, thanks. Maybe need add some info about it at https://getfedora.org/en/cloud/download/
So what is the status here? This seems to be upstream issue to me, if the workaround suggested in comment 6 works. Does anybody reported this issue upsteram? Can we close this?
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.