Bug 927874 - Support prioritized emulated machines to support .el6 out of the box
Summary: Support prioritized emulated machines to support .el6 out of the box
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.2
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
: 3.3
Assignee: Roy Golan
QA Contact: Jiri Belka
URL: http://www.ovirt.org/Cluster_emulatio...
Whiteboard: virt, Triaged
Depends On:
Blocks: 980901
TreeView+ depends on / blocked
 
Reported: 2013-03-26 12:27 UTC by Yuriy Demchenko
Modified: 2013-12-17 09:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 980901 (view as bug list)
Environment:
Last Closed: 2013-09-23 07:33:16 UTC
oVirt Team: ---


Attachments (Terms of Use)
vdsm log (25.64 KB, application/octet-stream)
2013-03-26 12:27 UTC, Yuriy Demchenko
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 15905 0 None None None Never
oVirt gerrit 15906 0 None None None Never
oVirt gerrit 15907 0 None None None Never
oVirt gerrit 15908 0 None None None Never
oVirt gerrit 15909 0 None None None Never
oVirt gerrit 15910 0 None None None Never
oVirt gerrit 15911 0 None None None Never

Description Yuriy Demchenko 2013-03-26 12:27:33 UTC
Created attachment 716494 [details]
vdsm log

Description of problem:
oVirt engine and nodes, installed from EL6 packages, cannot start any VMs.


Version-Release number of selected component (if applicable):
ovirt-engine.noarch 3.2.1-1.beta1.el6
vdsm.x86_64 4.10.3-10.el6
libvirt.x86_64 0.10.2-18.el6_4.2


How reproducible:
always

Steps to Reproduce:
1. Install ovirt-engine from repo: http://resources.ovirt.org/releases/3.2/rpm/EL/6/
2. Add same repo to Centos 6.4 node system, add&install node to ovirt
3. Add new VM with any parameters (cpu/ram/os/disk/net - doesn't matter)
4. Try to start that VM
  
Actual results:
VM failed to start with error
"libvirtError: internal error process exited while connecting to monitor: Supported machines are:
pc         RHEL 6.4.0 PC (alias of rhel6.4.0)
rhel6.4.0  RHEL 6.4.0 PC (default)
rhel6.3.0  RHEL 6.3.0 PC
rhel6.2.0  RHEL 6.2.0 PC
rhel6.1.0  RHEL 6.1.0 PC
rhel6.0.0  RHEL 6.0.0 PC
rhel5.5.0  RHEL 5.5.0 PC
rhel5.4.4  RHEL 5.4.4 PC
rhel5.4.0  RHEL 5.4.0 PC"

Expected results:
VM succesfully started

Additional info:
According to vdsm.log, engine sets "EmulatedMachine" param to "pc-0.14" in domain configuration, which is not supported by el6 libvirt. 
As engine should be able to work with both el6-based and fedora-based nodes, it should set "EmulatedMachine" param according to hypervisor type it tries to start vm with (or some universal "EmulatedMachine" type, which supported by both el6 and fedora libvirt).

As a workaround, kindly proposed by Juan Hernandez, one can issue "engine-config -s EmulatedMachine=rhel6.4.0 --cver=3.2" and restart engine.

Comment 1 Yuriy Demchenko 2013-03-26 12:42:41 UTC
Some more thoughts: i've looked at supported machines in Centos6 and Fedora 17, and it seems both support "pc" param, which is aliased to highest distro-specific type.
centos 6.4 libvirt:
Supported machines are:
pc         RHEL 6.4.0 PC (alias of rhel6.4.0)
rhel6.4.0  RHEL 6.4.0 PC (default)
rhel6.3.0  RHEL 6.3.0 PC
rhel6.2.0  RHEL 6.2.0 PC
rhel6.1.0  RHEL 6.1.0 PC
rhel6.0.0  RHEL 6.0.0 PC
rhel5.5.0  RHEL 5.5.0 PC
rhel5.4.4  RHEL 5.4.4 PC
rhel5.4.0  RHEL 5.4.0 PC

Fedora 17 libvirt:
Supported machines are:
pc         Standard PC (alias of pc-1.0)
pc-1.0     Standard PC (default)
pc-0.15    Standard PC (default)
pc-0.14    Standard PC
pc-0.13    Standard PC
pc-0.12    Standard PC
pc-0.11    Standard PC, qemu 0.11
pc-0.10    Standard PC, qemu 0.10
isapc      ISA-only PC

So, maybe, as a simple solution - to set "EmulatedMachine" param to "pc" value?

Comment 2 Itamar Heim 2013-04-01 09:47:26 UTC
pc is not migration safe, as gets translated to different things.
better solution would be to have "emulation level" at cluster level per compatibility level.

behaviour would be similar to cpu model: default is empty. first host sets the value. order of values sets the priority. host is non-operation for virt service if doesn't provide the requested emulation level

Config.ClusterEmulationModes(3.0,"rhel6.2.0, pc-1.0"
Config.ClusterEmulationModes(3.1,"rhel6.3.0, pc-1.0"
Config.ClusterEmulationModes(3.2,"rhel6.4.0, pc-1.0"
Config.ClusterEmulationModes(3.3,"rhel6.4.0, pc-1.0"

Comment 3 Deepak C Shetty 2013-04-29 10:23:47 UTC
I just faced this issue and we spent close to 1 hr.. figuring why engine restart is not working.. as per the wrokaround described above.

Later i realsed that I needed to restart ovirt-engine.service. We were always restarting jboss-as.service

So out of curiosity.. isn't restartign jboss restart the engien service running on top of it ? Lots of places in the ovirt wiki pages.. its said "if u change anything in ovirt.. restart jboss" but it didn't work..

In short the workaround worked only after restarting ovirt-engine.service

The engine was installed using ovirt.org repo RPMs on F18

Documenting here so that it might help others!

thanx,
deepak

Comment 4 Itamar Heim 2013-05-01 12:24:11 UTC
we use jboss, but we launch an instance of it under the engine service, not the jboss one.
(I think we are using engine service since 3.1)

Comment 6 Itamar Heim 2013-08-21 16:40:52 UTC
as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)

Comment 7 Itamar Heim 2013-09-23 07:33:16 UTC
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)


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