In oVirt you can create/apply a network filter on a VM. One use-case for example is to allow the VM to only send traffic from a specified IP. Now this works fine in oVirt, but the big downside here is that a change is only active after shutdown/startup. It would be nice to have network filter parameters changes to be active directly. Like when you want to add an additional IP to a VM, you won't need to reboot it. On the libvirt side this should be possible with an update-device. VDSM seems to have quite some logic for it also: https://github.com/oVirt/vdsm/blob/master/lib/vdsm/virt/vmdevices/network.py A second thing that would be usefull is just to change the network filter itself on the fly.
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.