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.
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?
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"
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
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)
The review topic http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:cluster_emulation_modes,n,z
as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)