Cluster compatibility level is currently defines that all VMs in the cluster have same features and are considered "the same" by the rest of the product. This causes issues on upgrade where a restart is required to apply new HW and parameters and start the qemu process using the new cluster level features. This includes parameters of QEMU process, HW of the VM(e.g. emulated machine type) as well as behavior of engine regarding which features are supported or not. This feature implements a per VM override of the feature level allowing a "hybrid" cluster running VMs with different set of features. On global cluster level change a currently running VMs are going to be temporarily assigned the original cluster level preserving the unchanged behavior until they are stopped and started. This is described in bug 1356027 which depends on this one.
this landed in oVirt master during Jan/Feb 2016
This seems like quite a RFE, it's basically a new feature and seems like a major one. Can I ask for some wiki page or at least some explanation of how this is supposed to work. Some questions in mind are: 1. Does it mean that on 4.0 cluster e.g. one can set a vm to any older compatibility? 2. does a 3.6 cluster support a 4.0 vm? 3. Does it depend only on the hosts in the cluster? It would be great to know what to expect, only then I can verify the bug as I guess just stating that the new attribute exists on UI and API isn't enough.
(In reply to sefi litmanovich from comment #2) > This seems like quite a RFE, it's basically a new feature and seems like a > major one. > Can I ask for some wiki page or at least some explanation of how this is > supposed to work. Some questions in mind are: sure. Basic explanation is in doc text > 1. Does it mean that on 4.0 cluster e.g. one can set a vm to any older > compatibility? yes > 2. does a 3.6 cluster support a 4.0 vm? yes > 3. Does it depend only on the hosts in the cluster? override itself doesn't depend on anything other than general support of that level (e.g. 3.5 is not supported in 4.0 so you can't use as an override either). Then from the perspective of the VM functionality, whether you can run it, yes you need a host which is capable of running that VM, so e.g. when you have a 3.6 cluster with one VM defined as 4.0 you will be able to run that VM only on 4.0 hosts. > It would be great to know what to expect, only then I can verify the bug as > I guess just stating that the new attribute exists on UI and API isn't > enough. sure, there should be no surprises though, it's a VM-specific override of a feature which is around for a while(cluster level), with analogous constraints.
Verifying this RFE with rhevm-4.0.2.7-0.1.el7ev.noarch. Will add a more detailed polarion test run once polarion is up (currently unavailable for maintenance). Verifying based on functional testing of the new field/attribute in vm/template entities + tested virt features on vms set with cluster compatibility version 3.6 before upgrading a cluster from 3.6 to 4.0. 1. Functional test of new vm/template option: There were 2 bugs which I wouldn't define as feature blockers: https://bugzilla.redhat.com/show_bug.cgi?id=1367405 https://bugzilla.redhat.com/show_bug.cgi?id=1367411 Except for these bugs the feature is working as expected: a. ccv field is editable in vm/template entity (cannot be set on vm pool once pool is created but pool inherits template's value as expected). b. ccv value inheritance is working as expected when:importing/exporting vm/template, when creating template from vm and the other way around, when cloning a vm, when cloning from snapshot. c. Tested upgrade from cluster 3.6 (2 hosts with vdsm-4.17.33-1) to cluster 4.0 (upgraded the hosts to vdsm-4.18.11-1). On 3.6 created and ran vms with custom compatibility set to 3.6, kept vms running during/after upgrade (This will be automatically done when bz#1356027 will be merged). Did some regression testing on virt features: 1. Snapshot creation before upgrade (with and without memory) and restoring after upgrade - passed as expected (snapshot with memory was restored without memory). 2. Snapshot create-preview-undo-clone-remove after upgrade. 3. Migration after upgrade - passed. 4. To catch scheduling filter for migration, tested that vm cannot be migrated if the cluster has one host with 3.6 and one host with 4.0 and the vm is set to ccv 4.0, but works fine if vm has ccv 3.6. 5. Run once + cloud init - Tested run once before upgrade and used cloud init to set hostname/username/password, custom cpu type, set host to start on, changed console from vnc to spice - all configurations works fine as expected. After upgrade poweroff vm - vm's configuration revert back. 6. Consoles - both vnc and spice consoles had no regression after upgrade. On spice checked usb support, file transfer, copy paste support. 7. Memory hotplug after upgrade - passed. 8. Cpu hotplug after upgrade - passed. Tested twice: once when 'HotPlugCpuSupported' is set to 'false' for 3.6 with arch x86_64 - couldn't hot plug and got the expected error message. Once when it set to true - hot plug succeeded. 9. Nic hotplug - passed. 10. disk hotplug - passed. 11. HA vm - after upgrade kill vm's process see that it starts right away - passed. 12. Hyperv enlightenment for windows vm - passed: checked configuration level only - vms created as windows vm had all the hyper-v flags enabled in xml, whereas linux vms did not Further testing should and will be done with the wider scope of https://bugzilla.redhat.com/show_bug.cgi?id=1356027 but I think this is a good indication that the feature doesn't break any obvious action.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-1743.html