Bug 690737

Summary: libvirt tries to restore security label for the path passed to "save" even if saving fails.
Product: Red Hat Enterprise Linux 6 Reporter: Osier Yang <jyang>
Component: libvirtAssignee: Eric Blake <eblake>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: ccui, dallan, dyuan, eblake, gren, jdenemar, mzhan, yoyzhang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-0.8.7-15.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 13:29:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Osier Yang 2011-03-25 08:36:18 UTC
Description of problem:
E.g. 

When you use libvirt Python binding to save a domain, if the domain saving fails on send "stop" command to monitor.

======== libvirt debug log ======
14:53:30.826: 21155: debug : qemuHandleMonitorEOF:739 : Received EOF on 0x7f4014002760 'virtlab_test'
14:53:30.826: 21155: debug : qemudShutdownVMDaemon:3406 : Shutting down VM 'virtlab_test' pid=22642 migrated=0
14:53:30.826: 21160: debug : qemuMonitorJSONCommandWithFd:243 : cannot send monitor command '{"execute":"stop"}': Connection reset by peer

======== libvirt Python exception ======
libvir: QEMU error : cannot resolve symlink /tmp/virtlab_test: No such file or directory
Traceback (most recent call last):
  File "libvirt-test-api.py", line 304, in <module>
    libvirt_test_api.run()
  File "libvirt-test-api.py", line 168, in run
    ret = i()
  File "/usr/local/staf/test/RHEL6/libvirt-test-API/generator.py", line 82, in __call__
    retflag = self.generator()
  File "/usr/local/staf/test/RHEL6/libvirt-test-API/generator.py", line 130, in generator
    ret = self.cases_func_ref_dict[case_ref_name](case_params)
  File "/usr/local/staf/test/RHEL6/libvirt-test-API/repos/Python/domain/save.py", line 122, in save
    domobj.save(guestname, filepath)
  File "/usr/local/staf/test/RHEL6/libvirt-test-API/lib/Python/domainAPI.py", line 213, in save
    retval = dom_obj.save(to)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 619, in save
    if ret == -1: raise libvirtError ('virDomainSave() failed', dom=self)
libvirt.libvirtError: cannot resolve symlink /tmp/virtlab_test: No such file or directory


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
libvirt should only try to restore the security lable when the saving is successful.

Additional info:

Comment 2 Osier Yang 2011-03-25 08:55:37 UTC
http://www.redhat.com/archives/libvir-list/2011-March/msg01179.html

patch posted to upstream.

Comment 3 Eric Blake 2011-03-28 15:37:26 UTC
Based on upstream discussion, it appears this function has two logic bugs.
1. Label restore is attempted even if the function fails prior to changing label in the first place (patch still in discussion): https://www.redhat.com/archives/libvir-list/2011-March/msg01243.html
2. Label restore is attempted twice if the function fails after the first label restore (upstream commit 96d5678): https://www.redhat.com/archives/libvir-list/2011-March/msg01206.html

Both issues need to be resolved before this BZ can be moved to POST.

Comment 6 Gunannan Ren 2011-04-19 06:09:48 UTC
This bug has been verified on libvirt-0.8.7-17.el6.

Comment 7 Gunannan Ren 2011-04-20 08:31:53 UTC
The way of verifying the bug is to check if the patch has been added into the source code.

Comment 11 errata-xmlrpc 2011-05-19 13:29:31 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html