Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 796510

Summary: Unhelpful error message
Product: Red Hat Enterprise Linux 6 Reporter: Madison Kelly <mkelly>
Component: resource-agentsAssignee: David Vossel <dvossel>
Status: CLOSED NOTABUG QA Contact: Cluster QE <mspqa-list>
Severity: low Docs Contact:
Priority: low    
Version: 6.2CC: agk, cfeist, cluster-maint, fdinitto, lhh, lnovich, mnovacek
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-17 19:39:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Madison Kelly 2012-02-23 03:32:17 UTC
Description of problem:

When you ask clusvcadm to start a VM that does not have a corresponding foo.xml file in the 'path="/..."' attribute, it reports:

=====
Feb 22 22:20:54 an-node02 rgmanager[19481]: [vm] Could not find vm02-win or vm02-win.xml in search path /shared/definitions/
Feb 22 22:20:55 an-node02 rgmanager[19528]: [vm] Cannot find 'xm'; is it installed?
Feb 22 22:20:55 an-node02 rgmanager[19567]: [vm] Could not find vm02-win or vm02-win.xml in search path /shared/definitions/
Feb 22 22:20:55 an-node02 rgmanager[19614]: [vm] Cannot find 'xm'; is it installed?
Feb 22 22:20:55 an-node02 rgmanager[14505]: start on vm "vm02-win" returned 2 (invalid argument(s))
Feb 22 22:20:55 an-node02 rgmanager[14505]: #68: Failed to start vm:vm02-win; return value: 1
Feb 22 22:20:55 an-node02 rgmanager[14505]: Stopping service vm:vm02-win
=====

This provides all the needed info, "Could not find vm02-win or vm02-win.xml in search path /shared/definitions/", but it also shows "Cannot find 'xm'; is it installed?" which seems quite unrelated.

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

rgmanager-3.0.12.1-5.el6.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Use clusvcadm to start a VM without an XML definition file defined
2. Read /var/log/messages
3. ...
4. Profit?
  
Actual results:

unhelpful log messages.

Expected results:

Only helpful log messages.

Additional info:

Lowest priority bug ever.

Comment 2 Fabio Massimo Di Nitto 2012-02-23 05:20:54 UTC
The extra "Cannot find 'xm'; is it installed?" comes from vm.sh resource agent.

Reassigning.

Comment 3 Fabio Massimo Di Nitto 2012-02-23 05:23:20 UTC
If this is a KVM cluster, I also believe that you need to specify:

use_virsh=1

to set the management tools for VM to virsh.

xm is checkd in case it is a xen VM you are managing.

Comment 6 RHEL Program Management 2012-07-10 08:45:26 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 7 RHEL Program Management 2012-07-11 01:48:56 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 8 Chris Feist 2012-10-15 17:42:06 UTC
Bumping to 6.5 since this fix didn't make the devel freeze.  (Feel free to move back to 6.4 with an exception or blocker flag if it's needed for the release).

Comment 11 David Vossel 2013-05-29 20:40:27 UTC
(In reply to Fabio Massimo Di Nitto from comment #3)
> If this is a KVM cluster, I also believe that you need to specify:
> 
> use_virsh=1
> 
> to set the management tools for VM to virsh.
> 
> xm is checkd in case it is a xen VM you are managing.

The log messages actually are related.  The domain's xml file can't be found because it doesn't exist. During the validate function after the xml file isn't found it thinks you are trying to use xen's xm configuration tool and takes that approach.  That's why you see the message about 'xm' not being found.

The agent is telling us something we need to know about its behavior. Set use_virsh=1 and this goes away.

I would like to close this issue if no one has any objections.

-- Vossel