Bug 1092739 - Unable to delete a domain/uncaught exception due to now-missing storage file
Summary: Unable to delete a domain/uncaught exception due to now-missing storage file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-29 21:06 UTC by Dr. David Alan Gilbert
Modified: 2014-09-19 10:13 UTC (History)
3 users (show)

Fixed In Version: virt-manager-1.0.1-4.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-19 10:13:22 UTC


Attachments (Terms of Use)
XML description for the VM I couldn't delete (3.55 KB, text/xml)
2014-04-29 21:44 UTC, Dr. David Alan Gilbert
no flags Details

Description Dr. David Alan Gilbert 2014-04-29 21:06:14 UTC
Description of problem:

I got into a state where I couldn't delete a domain I'd created using vmm; I managed to delete it in the end using virsh undefine.   I didn't get any error dialog but I spotted the following in the log

[Tue, 29 Apr 2014 21:40:46 virt-manager 19468] DEBUG (create:177) Closing new vm wizard
[Tue, 29 Apr 2014 21:40:46 virt-manager 19468] DEBUG (storagebrowse:86) Closing storage browser
[Tue, 29 Apr 2014 21:40:48 virt-manager 19468] DEBUG (delete:71) Showing delete wizard
[Tue, 29 Apr 2014 21:40:48 virt-manager 19468] DEBUG (cli:182) Uncaught exception:
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 1154, in _do_delete_domain
    self.delete_dialog.show(vm, src.topwin)
  File "/usr/share/virt-manager/virtManager/delete.py", line 75, in show
    self.reset_state()
  File "/usr/share/virt-manager/virtManager/delete.py", line 108, in reset_state
    self.vm, self.conn)
  File "/usr/share/virt-manager/virtManager/delete.py", line 260, in populate_storage_list
    vol = conn.get_vol_by_path(path)
  File "/usr/share/virt-manager/virtManager/connection.py", line 757, in get_vol_by_path
    if vol.get_target_path() == path:
  File "/usr/share/virt-manager/virtManager/storagepool.py", line 68, in get_target_path
    return self.get_xmlobj().target_path or ""
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 141, in get_xmlobj
    xml = self._get_raw_xml(inactive, refresh_if_nec)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 197, in _get_raw_xml
    self.refresh_xml()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 160, in refresh_xml
    self._xml = self._XMLDesc(self._active_xml_flags)
  File "/usr/share/virt-manager/virtManager/storagepool.py", line 44, in _XMLDesc
    return self._backend.XMLDesc(flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2697, in XMLDesc
    if ret is None: raise libvirtError ('virStorageVolGetXMLDesc() failed', vol=self)
libvirtError: cannot stat file '/home/dg/trusty-server-cloudimg-amd64-disk1.img': No such file or directory

Version-Release number of selected component (if applicable):
virt-manager-1.0.1-2.fc20.noarch
libvirt-client-1.1.3.4-4.fc20.x86_64

How reproducible:
Not sure, I'm not 100% sure how I got to this point...

Steps to Reproduce:
(not 100% sure about the start of this...)
1. I created a domain from an existing .img file that was in my home directory, it warned that it might not have perms on the file, but I told it to continue anyway.
2. That failed, so I mv'd the .img file into my normal image directory
3. Then I managed to boot that VM ok
4. Then I aborted creating the domain again (I was trying to import and ovf but decided I wasn't sure how)
....
5. and then I tried to delete the VM that had been created by right click to get the menu on the domain and hitting delete (it was off anyway)

Actual results:
No apparent action at all, VM was still there in the list, no error dialog - see backtrace above.

Expected results:
The VM gets deleted.

Additional info:

Note the path shown in the backtrace is the original path I had.

Comment 1 Dr. David Alan Gilbert 2014-04-29 21:44:21 UTC
Created attachment 890948 [details]
XML description for the VM I couldn't delete

Comment 2 Cole Robinson 2014-04-30 20:04:10 UTC
Thanks for the report. I pushed two patches upstream: one to actually raise in error from the delete dialog, and another to handle storage volumes that were deleted behind virt-manager's back:

commit 5c28a00d3e28ba7446f323a31ac47a194eb200b1
Author: Cole Robinson <crobinso@redhat.com>
Date:   Wed Apr 30 16:00:34 2014 -0400

    connection: Call path_exists before getting storage volume (bz 1092739)
    
    path_exists will check to ensure the volume actually survives a pool
    refresh, incase it was deleted behind libvirt's back. This makes the
    delete dialog happier at least.

commit f35438a01bbf3ba54b4e448d14e7981110a74f08
Author: Cole Robinson <crobinso@redhat.com>
Date:   Wed Apr 30 15:54:00 2014 -0400

    engine: Show error if launching delete dialog fails

Comment 3 Fedora Update System 2014-09-08 15:29:55 UTC
virt-manager-1.0.1-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.1-4.fc20

Comment 4 Fedora Update System 2014-09-09 22:06:08 UTC
Package virt-manager-1.0.1-4.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.1-4.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10332/virt-manager-1.0.1-4.fc20
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2014-09-19 10:13:22 UTC
virt-manager-1.0.1-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


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