Bug 1899583

The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

Manually running virsh update-device with a modified device XML works fine!
The rules are correctly created etc.

So oVirt should call an update-device when the rules/parameters changed. And we're set :)

Hi jean-louis,

Thank you for your input and time invested in this issue. 
Reviewing this RFE and related ovirt-engine patch [1] I would like to ask the following:

1. From the bug title is can be inferred that both network filter(s) and parameter(s) are to be live-updated. But in the description of the bug only an update of the parameter(s) is discussed. Also, the patch itself only addresses an update to the parameter(s) and not to the filter(s). Can you clarify or make the title consistent with the rest?
2. Why is only live-update action addressed by the patch and not live-add and live-remove? We would like to be consistent with either supporting all conventional actions (think CRUD) or none. A partial support is confusing and unexpected, for example if an existing parameter is updated and at the same time another is added: only the update is propagated to vdsm.
3. Assuming that only parameters are to be updated, the following flow breaks this assumption as well: 
- update the network filter of a vnic profile
- update the filter parameter(s) of the corresponding vnic.
--> result: both the filter and the parameters are live-updated
4. If the intention is to handle all above scenarios (add\update\remove filter(s) and parameter(s)) maybe it would be better to move the implementation to [3]
5. What happens if the write to the db fails? Should the update device request be sent to vdsm?
6. What happens if the request sent to vdsm fails? How are errors and\or exceptions handled (see usages of [2])?


Thanks a lot


[1] https://gerrit.ovirt.org/c/vdsm/+/112384
[2] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/CommandBase.java#L2118
[3] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/network/vm/UpdateVmInterfaceCommand.java

Hi Eitan,

Thanks for the review.

[1] is referring to the VDSM patch. This one is complete now.
The ovirt-engine patch was indeed incomplete (thats why it was still in WIP state)

1. I updated the titles. Add/Remove/Update should be handled!
2. See 1.
3. Both are safe to get udpated
4. See updated ovirt-engine patch [2]. Moved the code to UpdateVmInterfaceCommand. So its always run when something changed in the parameters.
5. This is currently handled the same way as the updateHost() in UpdateVmInterfaceCommand (as far as I can see: not handled :))
6. See 5


[1] https://gerrit.ovirt.org/c/vdsm/+/112384
[2] https://gerrit.ovirt.org/c/ovirt-engine/+/112363/

The implementation in patch [1] currently provides the following functionality:

- add\update\remove network filter parameters on a vnic is immediately propagated as an 'update device' directive to vdsm provided the regular conditions for hot update are met: the VM is up and the vnic is plugged.
- if the network filter of a vnic profile has been modified, the new network filter will be updated on the VM's vnic as well when the vnic filter-parameters or link-state are updated.

[1] https://gerrit.ovirt.org/#/c/ovirt-engine/+/112363/  (patch-set 7)

Verified that on 4.4.4 and 4.3 when changing the vnic profile of a plugged vnic, engine reports the error "General Exception: ('Operation not supported: cannot modify MTU',)" in the following cases:
- to a vnic profile with a different MTU value
- to no profile (MTU any value to null)
- from no profile to profile (MTU null to any value)

No other attribute of the network, vnic profile or vnic invokes this error when hot updating the vnic.
Therefore decided to allow hot update of filter parameters on the vnic as suggested by the fix to this bug without handling the MTU issue: the user is expected to replug the vnic after an MTU change before hot-updating any vnic attirbutes.

The following scenarions were tested:

* live update (add,remove,update) of the clean-traffic filter

* live update (add,remove,update) of the clean-traffic-gateway filter

verified in vdsm-4.40.50.3-1.el8ev.x86_64 and ovirt-engine-4.4.5.3-0.14.el8ev.noarch

(In reply to Guy from comment #12)
> The following scenarions were tested:
> 
> * live update (add,remove,update) of the clean-traffic filter
> 
> * live update (add,remove,update) of the clean-traffic-gateway filter

live update (add,remove,update) of the clean-traffic filter's parameters

live update (add,remove,update) of the clean-traffic-gateway filter's parameters

This bugzilla is included in oVirt 4.4.5 release, published on March 18th 2021.

Since the problem described in this bug report should be resolved in oVirt 4.4.5 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.