Description of problem: Fail to run a VM when the cluster's emulated machine is also defined for the VM's custom compatibility version because it is set with wrong emulated machine. We encountered this on rhev.tlv. Severity is medium since it may happen with very specific configuration and has a simple workaround. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Define the cluster's emulated machine as showed below (additional info) 2. Create a VM in cluster 4.0 (architecture x86) with custom compatibility version of 3.6 3. Run the VM Actual results: The VM should run (with emulated machine = pc-i440fx-rhel7.2.0) Expected results: The VM fails to run (its emulated machine = pseries-rhel7.2.0) Additional info: engine=# select * from vdc_options where option_name ilike '%emulated%'; option_id | option_name | option_value | version -----------+-------------------------+-----------------------------------------------------+--------- 1206 | ClusterEmulatedMachines | pc-i440fx-rhel7.2.0,pseries-rhel7.2.0 | 4.0 900 | ClusterEmulatedMachines | pc-i440fx-rhel7.2.0,pseries-rhel7.2.0 | 3.6 1294 | ClusterEmulatedMachines | pc-i440fx-rhel7.3.0,pc-i440fx-2.6,pseries-rhel7.3.0 | 4.1
it seems not to be related to upgrade. The bug allows to sneak an unsupported VM (with unsupported cluster compatibility) to be run. Happened for 3.6 CCV after update of DC to 4.0 which then should allow only 4.0+ compatibility levels.
*** Bug 1437882 has been marked as a duplicate of this bug. ***
Verified: ovirt-engine-4.1.2-0.1.el7 libvirt-client-2.0.0-10.el7_3.5.x86_64 sanlock-3.4.0-1.el7.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64 vdsm-4.19.11-1.el7ev.x86_64