Bug 1082124
| Summary: | RHEL7 libvirt vs older qemu: unable to execute QEMU command 'qom-get': The command qom-get has not been found | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Dr. David Alan Gilbert <dgilbert> |
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | dgilbert, dyuan, mprivozn, mzhan, pkrempa, rbalakri |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-1.2.7-1.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 07:33:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.
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 (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. 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 (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 (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 (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) 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 |
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.