Bug 1251732
| Summary: | VM fails start sometimes with "libvirtError: internal error: Cannot find suitable CPU model for given data" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | GenadiC <gcheresh> | ||||||
| Component: | ovirt-engine | Assignee: | Francesco Romani <fromani> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ilanit Stein <istein> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 3.6.0 | CC: | fromani, gklein, jdenemar, lpeer, lsurette, mavital, michal.skrivanek, rbalakri, Rhev-m-bugs, srevivo, ykaul | ||||||
| Target Milestone: | ovirt-3.6.0-rc | Keywords: | Automation, TestOnly | ||||||
| Target Release: | 3.6.0 | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | ovirt-3.6.0-9 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-04-20 01:29:06 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 1252363 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
GenadiC
2015-08-09 11:01:54 UTC
It looks like this bz is reproducable if you restart engine Created attachment 1060960 [details]
libvirtd debug logs from the affected host
(In reply to GenadiC from comment #1) > It looks like this bz is reproducable if you restart engine I started from the libvirtd debug logs (https://bugzilla.redhat.com/attachment.cgi?id=1060960) and the CPU matching seems suspicious already. Jiri, could you please have a look to the logs? From the logs it seems quite similar to https://bugzilla.redhat.com/show_bug.cgi?id=1160318 BTW, I don't think there's anything blocking or urgent here. The bug only appears on a misconfigured host where /usr/libexec/qemu-kvm fails to start. And after the misconfiguration is fixed, you need to manually remove qemu-kvm capabilities libvirt cached when the host was in wrong configuration (i.e, rm /var/cache/libvirt/qemu/capabilities/*). With the fixed version of libvirt the manual removal of the cached files is not necessary, but you'd still have to fix the host's configuration to be able to start any virtual machines. decreasing severity as per comment #5 F21 fix is released, EL 7.1 not, but we'll be moving to 7.2 in next build anyway (In reply to Michal Skrivanek from comment #7) > decreasing severity as per comment #5 now I mean it:) should be resolved in EL 7.2's libvirt please make sure you consider comment #5, so only valid upgrade paths would work, or clean installs Jiri, How can this bug (actually bug 1160318) verified please? That is, how to have qemu-kvm capabilities libvirt cached, when the host was in wrong configuration? Thanks, Ilanit. The important thing is what happens once you fix the host configuration. If you have an old libvirt installed and you fix the configuration, you'll see the same "Cannot find suitable CPU model for given data" error. However, if you have a new (fixed) libvirt installed you'll see an error on a wrongly configured host, but once you fix the host configuration everything should just work. Verified on rhevm 3.6.0.3-0.1.el6 libvirt-1.2.17-13.el7 Steps: 1. disable virtualization extensions in host's bios 2. remove libvirt's capabilities cache: rm /var/cache/libvirt/qemu/capabilities/* 3. restart libvirtd Result: Failed to install Host <hostname>. Failed to execute stage 'Setup validation': Hardware does not support virtualization. Step: 1. Enable back virtualization extensions in host's bios. Result: 1. Reinstall host - OK 2. Run VM - OK (with no need to remove libvirt's capabilities cache) The result shows you didn't even have the chance to hit the libvirt bug. It would just work with old libvirt too. Apparently, RHEV needs different steps since it doesn't even start if virtualization extensions are disabled. Francesco, do you have any idea what needs to be done on the host so that RHEV happily starts, but qemu-kvm fails to enable KVM? (In reply to Jiri Denemark from comment #14) > The result shows you didn't even have the chance to hit the libvirt bug. It > would just work with old libvirt too. Apparently, RHEV needs different steps > since it doesn't even start if virtualization extensions are disabled. > > Francesco, do you have any idea what needs to be done on the host so that > RHEV happily starts, but qemu-kvm fails to enable KVM? I never actually tried myself. A couple of ideas: - install host with functioning virt support, let it succeed then perform steps 1..3 as per comment 13 (Not sure I understand why we need install host flow here) Leverage nested virtualization, test vdsm running inside a VM, with and without nested virtualization support in the linux kernel. Not sure kvm unloading will work, but worth a shot. Moving bug to Verified, based on the verification of Libvirt bug 1252363. |