Bug 1221304
Summary: | Storage can't be used a second time | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | James (purpleidea) <jshubin> | ||||
Component: | vagrant | Assignee: | Vít Ondruch <vondruch> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 26 | CC: | 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: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
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. 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 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 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 /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). (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! > 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?
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 (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 (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 :) Is this still an issue? (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! 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' 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. This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'. 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. 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. |
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 $