Description of problem: Currently it's possible to attach a profile with unsupported features (except QoS) to a vNIC. This should be blocked depending on the cluster version for the VM which has the vNIC. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a 3.0 DC + cluster 2. Edit the default profile (for the management network) and change to port mirroring + add some custom properties via REST 3. Create a VM in the 3.0 cluster 4. Add a vNIC that's attached to the default profile Actual results: The vNIC gets attached to the profile. Expected results: The vNIC should fail to create, as port mirroring and device custom properties are unsupported in cluster level 3.0 Additional info: This behavior should also be checked on edit vNIC, and on places such as import VM or change VM cluster. Please notice the feature port mirroring is supported since 3.1 and custom device properties is supported since 3.2.
The approach taken with this bug fix was to permit any configuration of vnic profile features: The vnic profile is defined on a network level, which is defined on the data-center level. The supported features of the vnic profile are determined on the cluster level. Therefore in a mixed data-center which contains clusters from various versions (either support or not all the features in the vnic profile), there is no option to prevent with the current entities model usage of the vnic profile by a vm. Instead of introducing a mass of protective code blocking various scenarios, an event log marked as a warning will be reported in case of a misuse of a vnic profile by a vm. If a vnic profile contains a feature not supported by the cluster level in which the vm runs, the vnic will be attached to the vnic profile's network, without the feature enabled for it (i.e. without port mirroring/network QoS/custom properties) and the indication of it will be in the events log. In order to prevent floods, the frequency of issuing the event per vnic is once a day (either by running a vm or by hot-plugging the nic).
cannot see any warning on unsupported profile property in GUI nor in log, VM starts without problem, in fact port mirroring is not working (cannot see traffic of VM1 from VM2 using tcpdump) port mirroring is displayed as enabled in the GUI -> confusing for users (see screenshot) tested on Red Hat Enterprise Virtualization Manager Version: 3.3.0-0.33.beta1.el6ev
Created attachment 823963 [details] screenshot 1
Created attachment 823964 [details] screenshot 2
Created attachment 823965 [details] log_collector
(In reply to Martin Pavlik from comment #2) > cannot see any warning on unsupported profile property in GUI nor in log, > VM starts without problem, > in fact port mirroring is not working (cannot see traffic of VM1 from VM2 > using tcpdump) > port mirroring is displayed as enabled in the GUI -> confusing for users > (see screenshot) > > tested on Red Hat Enterprise Virtualization Manager Version: > 3.3.0-0.33.beta1.el6ev With the current fix the audit log will be issues only for clusters 3.1 and above. Running VMs on cluster 3.0 is done differently and that code path should be covered by the next patch. Please verify both clusters 3.0 and 3.1 or 3.2 once the patch is merged.
Works in is25 VM aaaa has network interface nic1 which is using profile rhevm with unsupported feature(s) 'Port Mirroring, Network QoS' by VM cluster CL30_2 (version 3.0). VM 30_pm has network interface nic1 which is using profile rhevm with unsupported feature(s) 'Network QoS, Port Mirroring' by VM cluster CL30 (version 3.1). Cannot set value {type=interface;prop={speed=^([0-9]{1,5})$;duplex=^(full|half)$}} to key CustomDeviceProperties. Device custom properties are not supported in version 3.2
Closing - RHEV 3.3 Released