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 1082124 - RHEL7 libvirt vs older qemu: unable to execute QEMU command 'qom-get': The command qom-get has not been found
Summary: RHEL7 libvirt vs older qemu: unable to execute QEMU command 'qom-get': The co...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-28 17:41 UTC by Dr. David Alan Gilbert
Modified: 2015-03-05 07:33 UTC (History)
6 users (show)

Fixed In Version: libvirt-1.2.7-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 07:33:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0323 0 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2015-03-05 12:10:54 UTC

Description Dr. David Alan Gilbert 2014-03-28 17:41:05 UTC 
Description of problem:
(This is an unsupported configuration, but chatting to danpb he asked me to file a bz so we could track it)
On a RHEL7 host, with an older qemu binary (in this case a RHEL6 qemu built from source, the libvirt won't start a guest with the error 'The command qom-get has not been found'

Version-Release number of selected component (if applicable):
libvirt-daemon-1.1.1-29.el7.x86_64
libvirt-daemon-driver-qemu-1.1.1-29.el7.x86_64
libvirt-client-1.1.1-29.el7.x86_64
libvirt-daemon-kvm-1.1.1-29.el7.x86_64

with a RHEL6 qemu built from source

How reproducible:
100%

Steps to Reproduce:
1. Take a happy RHEL7 host with qemu/kvm installed and working
2. Install an ancient qemu (e.g. a RHEL6 version built from source)
3. virsh edit your guests XML to point to your qemu (remembering to set your machine type to something it will take)
4. Attempt to start the vm

Actual results:
Error starting domain: internal error: unable to execute QEMU command 'qom-get': The command qom-get has not been found

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1355, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 708, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: unable to execute QEMU command 'qom-get': The command qom-get has not been found


Expected results:
A running VM

Additional info:
Daniel asked me to try commit 730af8f, however it looks like the function in question has changed a lot (including return type), I suspect it may be fixed in the upstream version.
Comment 2 Peter Krempa 2014-03-28 19:33:06 UTC 
This should already be fixed upstream with:

commit 730af8f2cd7bc0e4c98b97200857909f42ea817f
Author: Michal Privoznik <mprivozn>
Date:   Tue Nov 19 15:42:28 2013 +0100

    qemuMonitorJSONGetCPUx86Data: Don't fail on ancient qemus
    
    On the domain startup, this function is called to dump some info about
    the CPUs. At the beginning of the function we check if we aren't running
    older qemu which is not exposing the CPUs via 'qom-list'. However, we
    are not checking for even older qemus, which throw 'CommandNotFound'
    error.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit 84f69602143551433e3e0a5226dc572ecb33c059
Author: Peter Krempa <pkrempa>
Date:   Mon Nov 11 16:34:53 2013 +0100

    qemu: Check for presence of device and properities when getting CPUID
    
    The QOM path in qemu that contains the CPUID registers of a running VM
    may not be present (introduced in QEMU 1.5).
    
    Since commit d94b7817719 we have a regression with QEMU that don't
    support reporting of the CPUID register state via the monitor as the
    process startup code expects the path to exist.
    
    This patch adds code that checks with the monitor if the requested path
    already exists and uses it only in this case.

commit a6a6f84af92a506f83fdecf56f292bcb89905492
Author: Peter Krempa <pkrempa>
Date:   Mon Nov 11 14:47:08 2013 +0100

    qemu: Change return type of qemuMonitorGetGuestCPU()
    
    To allow returning more granular errors, change the error type to an
    integer.


Given that this is not a supported configuration I don't think we will ever attempt to fix this in RHEL-7.0 thus I'm moving it to 7.1.
Comment 4 Luyao Huang 2014-10-10 03:33:53 UTC 
Hi Michal,
i have tried to verify this bug with the latest libvirt and old qemu.but i found my vm cannot start .


Version-Release number of selected component (if applicable):
libvirt-python-debuginfo-1.2.8-3.el7.x86_64
libvirt-daemon-driver-storage-1.2.8-5.el7.x86_64
libvirt-daemon-driver-lxc-1.2.8-5.el7.x86_64
libvirt-client-1.2.8-5.el7.x86_64
libvirt-gobject-0.1.7-3.el7.x86_64
libvirt-daemon-kvm-1.2.8-5.el7.x86_64
libvirt-daemon-driver-nwfilter-1.2.8-5.el7.x86_64
libvirt-sandbox-devel-0.5.0-9.el7.x86_64
libvirt-debuginfo-1.2.8-5.el7.x86_64
libvirt-daemon-driver-network-1.2.8-5.el7.x86_64
libvirt-login-shell-1.2.8-5.el7.x86_64
libvirt-python-1.2.8-3.el7.x86_64
libvirt-daemon-driver-interface-1.2.8-5.el7.x86_64
libvirt-docs-1.2.8-5.el7.x86_64
libvirt-gconfig-0.1.7-3.el7.x86_64
libvirt-daemon-driver-nodedev-1.2.8-5.el7.x86_64
libvirt-daemon-lxc-1.2.8-5.el7.x86_64
libvirt-sandbox-0.5.0-9.el7.x86_64
libvirt-1.2.8-5.el7.x86_64
libvirt-daemon-1.2.8-5.el7.x86_64
libvirt-lock-sanlock-1.2.8-5.el7.x86_64
libvirt-daemon-driver-qemu-1.2.8-5.el7.x86_64
libvirt-glib-0.1.7-3.el7.x86_64
libvirt-daemon-config-network-1.2.8-5.el7.x86_64
libvirt-daemon-config-nwfilter-1.2.8-5.el7.x86_64
libvirt-sandbox-libs-0.5.0-9.el7.x86_64
libvirt-devel-1.2.8-5.el7.x86_64
libvirt-daemon-driver-secret-1.2.8-5.el7.x86_64

qemu:
qemu-img-rhev-0.12.1.2-2.446.el6.x86_64
qemu-kvm-rhev-tools-0.12.1.2-2.446.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.446.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Take a happy RHEL7 host with qemu/kvm installed and working
2. Install an ancient qemu (e.g. a RHEL6 version built from source)
3. virsh edit your guests XML to point to your qemu (remembering to set your machine type to something it will take)
4. Attempt to start the vm

# virsh start test34
error: Failed to start domain test34
error: internal error: unable to execute QEMU command 'qom-list': The command qom-list has not been found

I use rpm -Uvh --force --nodeps install the old qemu.
Maybe i use the wrong way to install old qemu?

Thanks,
Luyao Huang
Comment 5 Michal Privoznik 2014-10-20 11:54:18 UTC 
(In reply to Luyao Huang from comment #4)
> Hi Michal,
> i have tried to verify this bug with the latest libvirt and old qemu.but i
> found my vm cannot start .
> 
> 
> Version-Release number of selected component (if applicable):
> libvirt-python-debuginfo-1.2.8-3.el7.x86_64
> libvirt-daemon-driver-storage-1.2.8-5.el7.x86_64
> libvirt-daemon-driver-lxc-1.2.8-5.el7.x86_64
> libvirt-client-1.2.8-5.el7.x86_64
> libvirt-gobject-0.1.7-3.el7.x86_64
> libvirt-daemon-kvm-1.2.8-5.el7.x86_64
> libvirt-daemon-driver-nwfilter-1.2.8-5.el7.x86_64
> libvirt-sandbox-devel-0.5.0-9.el7.x86_64
> libvirt-debuginfo-1.2.8-5.el7.x86_64
> libvirt-daemon-driver-network-1.2.8-5.el7.x86_64
> libvirt-login-shell-1.2.8-5.el7.x86_64
> libvirt-python-1.2.8-3.el7.x86_64
> libvirt-daemon-driver-interface-1.2.8-5.el7.x86_64
> libvirt-docs-1.2.8-5.el7.x86_64
> libvirt-gconfig-0.1.7-3.el7.x86_64
> libvirt-daemon-driver-nodedev-1.2.8-5.el7.x86_64
> libvirt-daemon-lxc-1.2.8-5.el7.x86_64
> libvirt-sandbox-0.5.0-9.el7.x86_64
> libvirt-1.2.8-5.el7.x86_64
> libvirt-daemon-1.2.8-5.el7.x86_64
> libvirt-lock-sanlock-1.2.8-5.el7.x86_64
> libvirt-daemon-driver-qemu-1.2.8-5.el7.x86_64
> libvirt-glib-0.1.7-3.el7.x86_64
> libvirt-daemon-config-network-1.2.8-5.el7.x86_64
> libvirt-daemon-config-nwfilter-1.2.8-5.el7.x86_64
> libvirt-sandbox-libs-0.5.0-9.el7.x86_64
> libvirt-devel-1.2.8-5.el7.x86_64
> libvirt-daemon-driver-secret-1.2.8-5.el7.x86_64
> 
> qemu:
> qemu-img-rhev-0.12.1.2-2.446.el6.x86_64
> qemu-kvm-rhev-tools-0.12.1.2-2.446.el6.x86_64
> qemu-kvm-rhev-0.12.1.2-2.446.el6.x86_64
> 
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. Take a happy RHEL7 host with qemu/kvm installed and working
> 2. Install an ancient qemu (e.g. a RHEL6 version built from source)
> 3. virsh edit your guests XML to point to your qemu (remembering to set your
> machine type to something it will take)
> 4. Attempt to start the vm
> 
> # virsh start test34
> error: Failed to start domain test34
> error: internal error: unable to execute QEMU command 'qom-list': The
> command qom-list has not been found
> 
> I use rpm -Uvh --force --nodeps install the old qemu.
> Maybe i use the wrong way to install old qemu?

No, it's not about qemu installation. The combination of RHEL-7 and RHEL-6 packages is problematic an unsupported. I'm not sure if it is worth fixing. Even if it were, I'd say only as an upstream patch.
Comment 6 Luyao Huang 2014-10-24 08:56:53 UTC 
Hi Dr. David Alan Gilbert,

I am try to reproduce and verify this bug,but I found the issue still exist with my step in comment 4.Maybe I use a wrong way to reproduce and verify this bug, so I want to confirm some steps with you,Would you please help me?Thanks.

1.The rhel6 version?

2.From the step 2 you give,you mean you need 2 qemu(one rhel7 another rhel6) in your host?

3.If you still have the environment, could you please try it again with libvirt-1.2.7-1.el7 or the latest libvirt?Thanks a lot.



Luyao Huang
Comment 7 Dr. David Alan Gilbert 2014-12-01 12:59:50 UTC 
(In reply to Luyao Huang from comment #6)
> Hi Dr. David Alan Gilbert,
> 
> I am try to reproduce and verify this bug,but I found the issue still exist
> with my step in comment 4.Maybe I use a wrong way to reproduce and verify
> this bug, so I want to confirm some steps with you,Would you please help
> me?Thanks.
> 
> 1.The rhel6 version?
> 
> 2.From the step 2 you give,you mean you need 2 qemu(one rhel7 another rhel6)
> in your host?

I'm running RHEL7 host with the rhel6 .432.el6 qemu build.
 
> 3.If you still have the environment, could you please try it again with
> libvirt-1.2.7-1.el7 or the latest libvirt?Thanks a lot.

1.2.8-8.el7 seems to work fine.

(I don't think it's important to verify this bug, it's an unsupported configuration but I reported it because danpb said he wanted a record of it).
> 
> 
> 
> Luyao Huang
Comment 8 Luyao Huang 2014-12-05 10:00:26 UTC 
(In reply to Dr. David Alan Gilbert from comment #7)
> (In reply to Luyao Huang from comment #6)
> > Hi Dr. David Alan Gilbert,
> > 
> > I am try to reproduce and verify this bug,but I found the issue still exist
> > with my step in comment 4.Maybe I use a wrong way to reproduce and verify
> > this bug, so I want to confirm some steps with you,Would you please help
> > me?Thanks.
> > 
> > 1.The rhel6 version?
> > 
> > 2.From the step 2 you give,you mean you need 2 qemu(one rhel7 another rhel6)
> > in your host?
> 
> I'm running RHEL7 host with the rhel6 .432.el6 qemu build.
>  
> > 3.If you still have the environment, could you please try it again with
> > libvirt-1.2.7-1.el7 or the latest libvirt?Thanks a lot.
> 
> 1.2.8-8.el7 seems to work fine.
> 
> (I don't think it's important to verify this bug, it's an unsupported
> configuration but I reported it because danpb said he wanted a record of it).

Yes, it's a unsupported configuration.And i am very happy it works well on your machine.
So can you close this bug to worksforme or some other status?

Thanks in advance for your answer.
> > 
> > 
> > 
> > Luyao Huang
Comment 9 Dr. David Alan Gilbert 2014-12-05 10:11:52 UTC 
(In reply to Luyao Huang from comment #8)

> Yes, it's a unsupported configuration.And i am very happy it works well on
> your machine.
> So can you close this bug to worksforme or some other status?

OK, marking WORKSFORME (although that's probably not quite the right one I guess)
Comment 12 errata-xmlrpc 2015-03-05 07:33:31 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://rhn.redhat.com/errata/RHSA-2015-0323.html
Note You need to log in before you can comment on or make changes to this bug.