Description of problem:
When virt-manager starts the following is logged in /var/log/messages, one for each inactive domain:
May 10 13:52:27 thor libvirtd: 13:52:27.441: error : qemudDomainGetVcpus:5634 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain
May 10 13:52:27 thor libvirtd: 13:52:27.445: error : qemudDomainGetVcpus:5634 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain
May 10 13:52:27 thor libvirtd: 13:52:27.447: error : qemudDomainGetVcpus:5634 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start virt-manager with a VM shut down
No error message as this could cause confusion confusion.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
virt-manager is trying the GetVcpus command to see if it is actually supported for each VM. We could probably only run this for a single VM and extrapolate from there, but it wouldn't eliminate the logging completely.
There are several other times that virt-manager will make an API call that we expect to fail (like domain name lookup to check for name collision), which will log an error. Libvirt doesn't really know if these errors are 'expected' or not, so will log them all the same. Short of turning off API error logging, not really sure how we could resolve this.
We can certainly change virt-manager in this case to make libvirtd shut up, but any libvirt API user shouldn't really have to consider its API usage based on how libvirtd chooses to log info. I don't really see the benefit of logging to /var/log/messages if the error is from a public API call, it should be up to the app to report or ignore. How we make that determination at the libvirt level isn't clear though.
*** This bug has been marked as a duplicate of bug 587603 ***
I reopen it since INVALID_OPERATION error was not filtered by the final patch in bz587603. FJ hope this message not go to system log. So could you please put "INVALID_OPERATION" into the filters?
Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.
If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.
One line patch posted and commited upstream:
asking for exception, this is trivial, and risk free
Test with libvirt-0.9.4-12.el6.x86_64 and virt-manager-0.9.0-6.el6.x86_64.
There's no such error messages logged in /var/log/messages. So move to VERIFIED.
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.