Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357513 - [RFE] Support per-VM override for cluster compatibility level
Summary: [RFE] Support per-VM override for cluster compatibility level
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.0.0-rc
: 4.0.0
Assignee: Michal Skrivanek
QA Contact: sefi litmanovich
URL:
Whiteboard:
Depends On: 1348907 1356194
Blocks: 1356027
TreeView+ depends on / blocked
 
Reported: 2016-07-18 12:05 UTC by Michal Skrivanek
Modified: 2016-08-23 20:44 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
A virtual machine can now override the cluster compatibility version, meaning that within a cluster with a 4.0 compatibility level, there can be virtual machines with 3.6 compatibility, retaining the configuration and behavior of 3.6. That is 4.0 features are not applied to them.
Clone Of: 1356194
Environment:
Last Closed: 2016-08-23 20:44:29 UTC
oVirt Team: Virt


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 48158 None None None 2016-07-18 12:23:48 UTC
oVirt gerrit 48159 None None None 2016-07-18 12:23:22 UTC
oVirt gerrit 48160 None None None 2016-07-18 12:22:29 UTC
oVirt gerrit 48161 None None None 2016-07-18 12:21:12 UTC
oVirt gerrit 48162 None None None 2016-07-18 12:20:41 UTC
oVirt gerrit 51244 None None None 2016-07-18 12:22:49 UTC
oVirt gerrit 56277 None None None 2016-07-18 12:24:50 UTC
Red Hat Bugzilla 1367405 None None None Never
Red Hat Bugzilla 1367411 None None None Never
Red Hat Bugzilla 1368942 None None None Never
Red Hat Knowledge Base (Solution) 2442801 None None None 2016-07-18 12:05:43 UTC
Red Hat Product Errata RHEA-2016:1743 normal SHIPPED_LIVE Red Hat Virtualization Manager 4.0 GA Enhancement (ovirt-engine) 2016-09-02 21:54:01 UTC

Internal Links: 1367405 1367411 1368942

Description Michal Skrivanek 2016-07-18 12:05:43 UTC
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.

Comment 1 Michal Skrivanek 2016-07-18 12:30:08 UTC
this landed in oVirt master during Jan/Feb 2016

Comment 2 sefi litmanovich 2016-08-01 08:20:09 UTC
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.

Comment 3 Michal Skrivanek 2016-08-01 09:57:15 UTC
(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.

Comment 4 sefi litmanovich 2016-08-22 12:14:50 UTC
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.

Comment 6 errata-xmlrpc 2016-08-23 20:44:29 UTC
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


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