Bug 1283989 - Vagrant up hangs on waiting for ip address
Vagrant up hangs on waiting for ip address
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: vagrant-libvirt (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Vít Ondruch
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-20 08:19 EST by Bernd Putsche
Modified: 2016-12-20 11:08 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 11:08:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bernd Putsche 2015-11-20 08:19:42 EST
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)
Comment 1 Josef Stribny 2015-11-23 03:34:16 EST
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...
Comment 2 Bernd Putsche 2015-11-23 15:53:10 EST
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 :-/
Comment 3 Josef Stribny 2015-11-24 04:39:34 EST
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?
Comment 4 Owen Taylor 2016-03-31 12:48:36 EDT
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
Comment 5 Oleg Pykhalov 2016-06-23 12:33:39 EDT
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.
Comment 6 Owen Taylor 2016-06-23 13:58:36 EDT
(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?
Comment 7 Oleg Pykhalov 2016-06-23 14:14:38 EDT
(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/
Comment 8 Vít Ondruch 2016-08-08 07:46:30 EDT
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?
Comment 9 Fedora End Of Life 2016-11-24 08:36:50 EST
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.
Comment 10 Fedora End Of Life 2016-12-20 11:08:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.