Bug 1517119

Summary: virt-manager should not report error after deleting a transient domain
Product: Red Hat Enterprise Linux 7 Reporter: zhoujunqin <juzhou>
Component: virt-managerAssignee: Pavel Hrdina <phrdina>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.5CC: kuwei, lmiksik, mxie, tzheng, xiaodwan
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-manager-1.4.3-3.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 11:43:03 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:

Description zhoujunqin 2017-11-24 09:21:14 UTC
Description of problem:
virt-manager should not report error after deleting a transient domain

Version-Release number of selected component (if applicable):
virt-manager-1.4.3-2.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create a transient domain with an existing xml file.
# virsh create test.xml 
Domain ESX4.1 created from test.xml

# virsh dominfo ESX4.1
Id:             31
Name:           ESX4.1
UUID:           94c96c33-6433-4fde-aebb-2fed6b964f5e
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       7.4s
Max memory:     1048576 KiB
Used memory:    1048576 KiB
Persistent:     no
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c928,c1001 (enforcing)

2. Launch virt-manager.
# virt-manager

3. Delete domain ESX4.1. (Select 'ESX4.1', then right click it, select 'Delete'.)

Actual results:
After step3, 'Delete Virtual Machine' window pops up, click 'Delete' button.
We can see domain ESX4.1 has been deleted, but there always leaves some error message like:

Error deleting virtual machine 'ESX4.1': Domain not found: no domain with matching uuid '94c96c33-6433-4fde-aebb-2fed6b964f5e' (ESX4.1)

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/delete.py", line 185, in _async_delete
    self.vm.delete()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1533, in delete
    self._backend.undefine()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2694, in undefine
    if ret == -1: raise libvirtError ('virDomainUndefine() failed', dom=self)
libvirtError: Domain not found: no domain with matching uuid '94c96c33-6433-4fde-aebb-2fed6b964f5e' (ESX4.1)


Additionally, there were errors removing certain storage devices: 


Expected results:
No error reports after deleting transient domain.

Additional info:

Comment 2 Pavel Hrdina 2017-11-24 16:42:54 UTC
Upstream commit:

commit b9bc3b605a96920d3e225d472d549864205e92ce
Author: Pavel Hrdina <phrdina>
Date:   Fri Nov 24 17:26:59 2017 +0100

    delete: undefine only persistent domain

Comment 5 zhoujunqin 2017-12-19 09:04:46 UTC
Try to verify this bug with new build:
virt-manager-1.4.3-3.el7.noarch

Steps:
1. Create a transient domain with an existing xml file.
# virsh create test.xml
Domain test created from test.xml

# virsh dominfo test
Id:             11
Name:           test
UUID:           aaf2501b-53c6-4f14-9cfc-75b5b8efe6f6
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       17.1s
Max memory:     1048576 KiB
Used memory:    1048576 KiB
Persistent:     no------------------------>It's a transient domain
Autostart:      disable
Managed save:   no
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c301,c1009 (enforcing)


2. Launch virt-manager.
# virt-manager

3. Delete domain test. (Select 'test', then right click it, select 'Delete'.)

Result:
Domain 'test' can be deleted successfully with no error.


So move this bug from ON_QA to VERIFIED status, thanks.

Comment 8 errata-xmlrpc 2018-04-10 11:43:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0726