Bug 690737 - libvirt tries to restore security label for the path passed to "save" even if saving fails.
Summary: libvirt tries to restore security label for the path passed to "save" even if...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-25 08:36 UTC by Osier Yang
Modified: 2014-03-27 01:02 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.8.7-15.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:29:31 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0596 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-05-18 17:56:36 UTC

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


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