Bug 1611539
| Summary: | [OVN][NETWORK] Changing provider network mtu does not update with guest after hot-unplug and plug | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-provider-ovn | Reporter: | msheena | ||||
| Component: | provider | Assignee: | Miguel Duarte Barroso <mduarted> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Michael Burman <mburman> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.2.7 | CC: | bugs, danken, dholler, mduarted, msheena, ylavi | ||||
| Target Milestone: | ovirt-4.2.7 | Flags: | rule-engine:
ovirt-4.2+
|
||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-09-26 09:45:37 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1612961 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
According to networking API v2 (the specification can be found at [1]), updating the API is done through the id parameter, not the name. Probably an error message should be thrown to not confuse the user when an update is attempted using the name. [1] - https://developer.openstack.org/api-ref/network/v2/#update-network The exact REST request that triggered the bug should be added, since that was paramount to my reply in Comment #1. After using the correct REST endpoint - using the uuid - the MTU is properly set in the ovn nb database. Miguel,
The exact REST call is:
PUT: https://<ENGINE_fqdn>:9696/v2.0/networks/<net_id>
BODY:
{
"network":{
"status": "ACTIVE",
"tenant_id": "00000000000000000000000000000001",
"mtu": 5000,
"id": "<net_id>",
"name": "ovn1"}
}
===========================================
A note: I have just tried to recreate and didn't succeed, on an env with the following:
- Guest OS: rhel 7.5
- Host OS: rhel 7.6
- Engine: 4.2.7-0.1.el7ev
after changing the MTU via provider, waiting for the sync with Engine, hot-unplugging and then hot-plugging (making sure in between the interface is not reported after the unplug) it seems that when the interface is hot-plugged it comes up with the correct MTU.
Is there still anything related not working, or can we close this bug? I believe we can close. (In reply to msheena from comment #5) > I believe we can close. |
Created attachment 1472643 [details] engine, provider and vdsm logs with relevant screenshots Description of problem: Given a guest that has an ovn provider network vnic profile attached to its vnic, once the networks' mtu is changed via provider, hot unplugging the guests' vnic and then hot plugging does not lead to an mtu change. Version-Release number of selected component (if applicable): ovirt-provider-ovn-1.2.13-1.el7ev.noarch ovirt-engine-4.2.5.2-0.1.el7ev.noarch vdsm-4.20.35-1.el7ev.x86_64 Red Hat Enterprise Linux Server release 7.5 (Maipo) How reproducible: 100% Steps to Reproduce: 1. Create 'ovn1' network over external provider with mtu 9000 and subnet 'sub1' with cidr: 5.0.0.0/24 without gateway leaving the DNS field blank 2. attach a NON-RUNNING vm vnic profile to 'ovn1' 3. Start the vm 4. Make sure the vm has mtu 9000 5. Change mtu to 5000 via provider using REST call 6. Hotunplug the vms' vnic and then hotplug Actual results: Vm mtu remains 9000 Expected results: Vm mtu is 5000 Additional info: * In engine UI the networks mtu changes to 5000 mtu * On host the vms' xml dump shows 5000 mtu * OVN nb db output: DHCP_Options ============ _uuid : 2855ca7e-ac19-43b5-8f28-1400d4890def cidr : "5.0.0.0/24" external_ids : {ovirt_name="sub1", ovirt_network_id="76f2d2f2-886a-4d6f-9a5f-3529aa6bafe5"} options : {lease_time="86400", mtu="9000", server_id="5.0.0.0", server_mac="02:00:00:00:00:00"}