Bug 1221304

Summary: Storage can't be used a second time
Product: [Fedora] Fedora Reporter: James (purpleidea) <jshubin>
Component: vagrantAssignee: Vít Ondruch <vondruch>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: cryan, hhorak, madam, podvody, sdharane, thrcka, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-29 12:01:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
longer version of the log none

Description James (purpleidea) 2015-05-13 16:41:34 UTC
Created attachment 1025120 [details]
longer version of the log

Description of problem:
Storage error when trying to up box.
Usually happens on the second time.


Version-Release number of selected component (if applicable):
vagrant-1.7.2-5.fc21.1.noarch


Additional info:

$ time vup omv1
Bringing machine 'omv1' up with 'libvirt' provider...
/usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/tmp/systemd-private-f9a8cf791c5c4f9ab77c1aefe7633bae-systemd-machined.service-60R41A' (Libvirt::RetrieveError)
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `volume_to_attributes'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:10:in `block (2 levels) in list_volumes'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `each'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `block in list_volumes'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:44:in `block in raw_volumes'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `each'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `raw_volumes'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:8:in `list_volumes'
	from /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/models/compute/volumes.rb:11:in `all'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:43:in `block in call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `synchronize'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:24:in `block in call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `synchronize'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/set_name_of_domain.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/action/builtin/call.rb:53:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/machine.rb:214:in `action_raw'
	from /usr/share/vagrant/lib/vagrant/machine.rb:191:in `block in action'
	from /usr/share/vagrant/lib/vagrant/environment.rb:516:in `lock'
	from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `call'
	from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `action'
	from /usr/share/vagrant/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

real	0m2.206s
user	0m1.908s
sys	0m0.249s
$

Comment 1 James (purpleidea) 2015-05-13 17:10:21 UTC
NOTE: I sometimes have trouble reproducing this bug, so when I figure out what causes it exactly, I'll ping here, but I know others have been able to repro more reliably, so maybe they can help.

As a workaround, delete the relevant storage from /var/lib/libvirt/images/ and restart libvirtd. Should start working again until it gets borked.

Comment 2 James (purpleidea) 2015-05-27 20:09:27 UTC
Present in F22 version: 1.7.2-5.fc22
Seems to be easily reproducible.
On the second vup, you get:

$ time vup omv1
Bringing machine 'omv1' up with 'libvirt' provider...
/home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/tmp/vagrant20150527-14783-lr906a' (Libvirt::RetrieveError)
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `volume_to_attributes'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:10:in `block (2 levels) in list_volumes'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `each'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `block in list_volumes'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:44:in `block in raw_volumes'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `each'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `raw_volumes'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/requests/compute/list_volumes.rb:8:in `list_volumes'
	from /home/james/.vagrant.d/gems/gems/fog-libvirt-0.0.1/lib/fog/libvirt/models/compute/volumes.rb:11:in `all'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/handle_box_image.rb:43:in `block in call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `synchronize'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/handle_storage_pool.rb:24:in `block in call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `synchronize'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/set_name_of_domain.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/action/builtin/call.rb:53:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /home/james/.vagrant.d/gems/gems/vagrant-libvirt-0.0.29/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/machine.rb:214:in `action_raw'
	from /usr/share/vagrant/lib/vagrant/machine.rb:191:in `block in action'
	from /usr/share/vagrant/lib/vagrant/environment.rb:516:in `lock'
	from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `call'
	from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `action'
	from /usr/share/vagrant/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

real	0m1.356s
user	0m1.193s
sys	0m0.148s

Comment 3 James (purpleidea) 2015-07-08 04:49:54 UTC
This no longer happens often, but from time to time (maybe when you switch the image being used, or when a vagrant command is interrupted) and is still annoying.

It still only happens with the Fedora packages. My 1.6.5 build from the upstream never does this.

The good news is a:

vdestroy
sudo systemctl restart libvirtd.service
vdestroy

reliably fixes this, but only until it happens again.
If anyone can reproduce, I'd like to hear about it.
If anyone can patch, I'd *really* like to hear about it.

Cheers,
James

Comment 4 Jan Kurik 2015-07-15 14:09:54 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 5 Pavel Odvody 2015-08-19 16:05:36 UTC
/usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/home/podvody/Downloads/.~lock.attachment.odt#' (Libvirt::RetrieveError)

I managed to "fix" this by opening storage settings in virt-manager and reloading the offending storage pool (had a hunch since I downloaded & sourced the box file straight from my downloads directory)
It seems that if you operate over the files in the storage pool it'll blow, while virt-manager/virsh has no problem with it, I suppose it's a bug in vagrant or it's libvirt bindings (like that it doesn't check whether the path supplied by the pool is [still] valid).

Comment 6 James (purpleidea) 2015-08-19 16:13:14 UTC
(In reply to Pavel Odvody from comment #5)
> /usr/share/gems/gems/fog-1.22.1/lib/fog/libvirt/requests/compute/
> list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage
> volume not found: no storage vol with matching path
> '/home/podvody/Downloads/.~lock.attachment.odt#' (Libvirt::RetrieveError)
> 
> I managed to "fix" this by opening storage settings in virt-manager and
> reloading the offending storage pool (had a hunch since I downloaded &
> sourced the box file straight from my downloads directory)
> It seems that if you operate over the files in the storage pool it'll blow,
> while virt-manager/virsh has no problem with it, I suppose it's a bug in
> vagrant or it's libvirt bindings (like that it doesn't check whether the
> path supplied by the pool is [still] valid).

Yeah, I definitely think it's a bug. Strangely I never experienced this with upstream packages, only Fedora ones. In any case, any help finding a reproducer and a fix would be appreciated! There could even be a bounty of some number of beverages!

Comment 7 Josef Stribny 2015-08-21 08:54:29 UTC
> Strangely I never experienced this with upstream packages, only Fedora ones.

This is strange, I suppose this is an issue of vagrant-libvirt plugin.

James, do you have a reproducer that works 100% of times so I can have a look?

Comment 8 Pavel Odvody 2015-08-21 14:20:04 UTC
I believe that this is a race-condition where you first fetch all items in the storage pool, cache them, then one of the items in the cache gets deleted from the FS and the client application consuming the cache cannot deal with that.
In James' case, the pool was in /tmp, in my case the offending file in the pool was LibreOffice's lock-file.

A reliable reproducer with the help of virt-manager:
 1) Download a box file into a directory, say ~/vagrant-test/
 2) touch ~/vagrant-test/problem
 3) virt-manager -> connection details -> storage and refresh the ~/vagrant-test/ volume (verify that the box and the file 'problem' is there)
 4) rm ~/vagrant-test/problem
 5) vagrant up 

(Unreliable reproducer: http://pastebin.test.redhat.com/307266 - run more these in parallel)

Boom!
> Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/home/podvody/vagrant-test/problem'

Here's a patch for `list_volumes.rb` that fixes the problem for me (sorry, I've never written a line of Ruby so the code may suck):
http://pastebin.test.redhat.com/307264

Comment 9 Vít Ondruch 2015-08-21 14:51:10 UTC
(In reply to Pavel Odvody from comment #8)
> I believe that this is a race-condition where you first fetch all items in
> the storage pool, cache them, then one of the items in the cache gets
> deleted from the FS and the client application consuming the cache cannot
> deal with that.
> In James' case, the pool was in /tmp, in my case the offending file in the
> pool was LibreOffice's lock-file.
> 
> A reliable reproducer with the help of virt-manager:
>  1) Download a box file into a directory, say ~/vagrant-test/
>  2) touch ~/vagrant-test/problem
>  3) virt-manager -> connection details -> storage and refresh the
> ~/vagrant-test/ volume (verify that the box and the file 'problem' is there)
>  4) rm ~/vagrant-test/problem
>  5) vagrant up 

Isn't this generic problem of libvirt? Doesn't sound right co return incomplete information. This should be fixed in libvirt not in fog-libvirt IMO.

At the end, fog-libvirt is not doing anything else then parsing incomplete XML, which would be probably malformed if validated against some schema.


> 
> (Unreliable reproducer: http://pastebin.test.redhat.com/307266 - run more
> these in parallel)
> 
> Boom!
> > Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/home/podvody/vagrant-test/problem'
> 
> Here's a patch for `list_volumes.rb` that fixes the problem for me (sorry,
> I've never written a line of Ruby so the code may suck):
> http://pastebin.test.redhat.com/307264

Comment 10 Pavel Odvody 2015-08-21 16:00:01 UTC
(In reply to Vít Ondruch from comment #9)
> Isn't this generic problem of libvirt? Doesn't sound right co return
> incomplete information. This should be fixed in libvirt not in fog-libvirt
> IMO.
> 
> At the end, fog-libvirt is not doing anything else then parsing incomplete
> XML, which would be probably malformed if validated against some schema.

Yes, this seems like a lack of error checking somewhere down in libvirt (or its Ruby bindings):

(Volume is in the pool, but not on the file system)
virsh # vol-dumpxml --pool vagrant-test test
error: Storage volume not found: no storage vol with matching path '/home/podvody/vagrant-test/test'

(Volume is neither in the pool nor the file system)
virsh # vol-dumpxml --pool vagrant-test test
error: failed to get vol 'test'
error: Storage volume not found: no storage vol with matching path 'test'

But at least you have root cause & reproducer now :)

Comment 12 Vít Ondruch 2016-08-03 13:27:28 UTC
Is this still an issue?

Comment 13 James (purpleidea) 2016-08-03 20:31:03 UTC
(In reply to Vít Ondruch from comment #12)
> Is this still an issue?

I haven't been working on vagrant things lately, so IDK, but unless you know that someone has fixed it, then I doubt it's fixed!

Comment 14 Chris Ryan 2016-11-05 22:59:59 UTC
Still seeing this exact issue:

4.7.4-200.fc24.x86_64
vagrant-1.8.1-4.fc24.noarch
vagrant-libvirt-0.0.32-2.fc24.noarch
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
rvm 1.26.11

The dump.sql.gz file that the error complains about is a new file since the last time vagrant was run. I can fix this issue by following the advice here:
https://kushaldas.in/posts/storage-volume-error-in-libvirt-with-vagrant.html

Where my virsh pools look like:
$ sudo virsh pool-list
 Name                 State      Autostart 
-------------------------------------------
 alternate            active     yes       
 default              active     yes       
 Development          active     yes       
 Downloads            active     yes 

$ sudo vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Box 'centos/7' could not be found. Attempting to find and install...
    default: Box Provider: libvirt
    default: Box Version: >= 0
==> default: Loading metadata for box 'centos/7'
    default: URL: https://atlas.hashicorp.com/centos/7
==> default: Adding box 'centos/7' (v1609.01) for provider: libvirt
    default: Downloading: https://atlas.hashicorp.com/centos/boxes/7/versions/1609.01/providers/libvirt.box
==> default: Box download is resuming from prior download progress
==> default: Successfully added box 'centos/7' (v1609.01) for 'libvirt'!
/usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/home/user/Downloads/dump.sql.gz' (Libvirt::RetrieveError)
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `volume_to_attributes'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:10:in `block (2 levels) in list_volumes'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `each'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `block in list_volumes'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:44:in `block in raw_volumes'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `each'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `raw_volumes'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/requests/compute/list_volumes.rb:8:in `list_volumes'
	from /usr/share/gems/gems/fog-libvirt-0.0.3/lib/fog/libvirt/models/compute/volumes.rb:11:in `all'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/action/handle_box_image.rb:63:in `block in call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/action/handle_box_image.rb:60:in `synchronize'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/action/handle_box_image.rb:60:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/action/handle_storage_pool.rb:50:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.32/lib/vagrant-libvirt/action/set_name_of_domain.rb:35:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/action/builtin/call.rb:53:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/machine.rb:224:in `action_raw'
	from /usr/share/vagrant/lib/vagrant/machine.rb:199:in `block in action'
	from /usr/share/vagrant/lib/vagrant/environment.rb:561:in `lock'
	from /usr/share/vagrant/lib/vagrant/machine.rb:185:in `call'
	from /usr/share/vagrant/lib/vagrant/machine.rb:185:in `action'
	from /usr/share/vagrant/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

Comment 15 Fedora End Of Life 2016-11-24 11:47:15 UTC
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 16 Fedora End Of Life 2017-02-28 09:43:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 17 Fedora End Of Life 2018-05-03 08:50:55 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. 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 '26'.

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 26 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 18 Fedora End Of Life 2018-05-29 12:01:29 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
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.