Bug 1251732 - VM fails start sometimes with "libvirtError: internal error: Cannot find suitable CPU model for given data"
Summary: VM fails start sometimes with "libvirtError: internal error: Cannot find suit...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.6.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Francesco Romani
QA Contact: Ilanit Stein
URL:
Whiteboard:
Depends On: 1252363
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-09 11:01 UTC by GenadiC
Modified: 2016-04-20 01:29 UTC (History)
11 users (show)

Fixed In Version: ovirt-3.6.0-9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-20 01:29:06 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
engine, vdsm and qemu logs (745.59 KB, application/zip)
2015-08-09 11:01 UTC, GenadiC
no flags Details
libvirtd debug logs from the affected host (67.09 KB, application/x-gzip)
2015-08-10 07:41 UTC, Francesco Romani
no flags Details

Description GenadiC 2015-08-09 11:01:54 UTC
Created attachment 1060722 [details]
engine, vdsm and qemu logs

Description of problem:
Trying to start VM fails with internal libvirt error.
Similiar bug was opened for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1160318.
The walkaround described their solved the problem

Comment 1 GenadiC 2015-08-09 12:00:56 UTC
It looks like this bz is reproducable if you restart engine

Comment 2 Francesco Romani 2015-08-10 07:41:37 UTC
Created attachment 1060960 [details]
libvirtd debug logs from the affected host

Comment 3 Francesco Romani 2015-08-10 07:43:27 UTC
(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

Comment 4 Jiri Denemark 2015-08-10 10:51:11 UTC
Yes, it's https://bugzilla.redhat.com/show_bug.cgi?id=1160318.

Comment 5 Jiri Denemark 2015-08-10 11:04:36 UTC
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.

Comment 7 Michal Skrivanek 2015-08-11 11:32:36 UTC
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

Comment 8 Michal Skrivanek 2015-08-13 12:08:46 UTC
(In reply to Michal Skrivanek from comment #7)
> decreasing severity as per comment #5
now I mean it:)

Comment 9 Michal Skrivanek 2015-08-13 12:11:03 UTC
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

Comment 11 Ilanit Stein 2015-11-15 14:52:50 UTC
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.

Comment 12 Jiri Denemark 2015-11-16 09:11:42 UTC
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.

Comment 13 Ilanit Stein 2015-11-19 16:22:34 UTC
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)

Comment 14 Jiri Denemark 2015-11-19 18:07:36 UTC
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?

Comment 15 Francesco Romani 2015-11-25 12:04:18 UTC
(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.

Comment 16 Ilanit Stein 2016-02-10 09:18:42 UTC
Moving bug to Verified, based on the verification of Libvirt bug 1252363.


Note You need to log in before you can comment on or make changes to this bug.