Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1600140

Summary: [VDSM] Cannot modify vNic profile of running vm with MTU set in its XML
Product: [oVirt] vdsm Reporter: msheena
Component: CoreAssignee: Francesco Romani <fromani>
Status: CLOSED CURRENTRELEASE QA Contact: msheena
Severity: high Docs Contact:
Priority: medium    
Version: 4.30.0CC: ahadas, bugs, danken, fromani, mburman, michal.skrivanek
Target Milestone: ovirt-4.2.6Flags: rule-engine: ovirt-4.2+
mburman: testing_plan_complete+
mburman: testing_ack+
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: v4.20.37 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-03 15:09:38 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:    
Bug Blocks: 1607704    
Attachments:
Description Flags
logs none

Description msheena 2018-07-11 13:57:43 UTC
Created attachment 1458121 [details]
logs

Description of problem:

[VDSM] Cannot modify vNic profile of a running vm when nic is plugged
Tried changing vm network of a running vm and failed with:
"libvirtError: Operation not supported: cannot modify MTU"

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3234, in setLinkAndNetwork
    libvirt.VIR_DOMAIN_AFFECT_LIVE)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 98, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 130, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in wrapper
    return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2739, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirtError: Operation not supported: cannot modify MTU
2018-07-11 14:40:24,010+0300 WARN  (jsonrpc/4) [virt.vm] (vmId='bfc19c7a-8917-4fc3-a34c-4d5ca096f254') Rolling back link and net for: ua-2a29577d-d05c-440a-bbf3-fb8f8c70d077 (vm:3248)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3243, in setLinkAndNetwork
    raise SetLinkAndNetworkError(str(e))
SetLinkAndNetworkError: Operation not supported: cannot modify MTU
2018-07-11 14:40:24,013+0300 ERROR (jsonrpc/4) [api] FINISH updateDevice error=Operation not supported: cannot modify MTU (api:132)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 122, in method
    ret = func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/API.py", line 383, in updateDevice
    return self.vm.updateDevice(params)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3307, in updateDevice
    return self._updateInterfaceDevice(params)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3197, in _updateInterfaceDevice
    custom, specParams):
  File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 3250, in setLinkAndNetwork
    libvirt.VIR_DOMAIN_AFFECT_LIVE)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 98, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 130, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in wrapper
    return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2739, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirtError: Operation not supported: cannot modify MTU
2018-07-11 14:40:24,014+0300 INFO  (jsonrpc/4) [api.virt] FINISH updateDevice return={'status': {'message': "General Exception: ('Operation not supported: cannot modify MTU',)", 'code': 100}} from=::ffff:10.35.128.45,51704, flow_id=nics_update_44155e25-f638-4cc5, vmId=bfc19c7a-8917-4fc3-a34c-4d5ca096f254 (api:52)


Version-Release number of selected component (if applicable):
libvirt-3.9.0-14.el7_5.6.x86_64
vdsm-4.20.33-1.el7ev.x86_64
4.2.5.1_SNAPSHOT-71.g54dde01.0.scratch.master.el7ev

How reproducible:
100%

Steps to Reproduce:
1. Create a vm network vnet1 and attach to vm host 
2. Edit vm network interfaces and change the vm network to the vnet1 when nic is plugged

Actual results:
The attachment fails, & engine displays "general exception" notice

Expected results:
Vm network changed successfully

Comment 1 Dan Kenigsberg 2018-07-13 22:56:30 UTC
I believe that this affects only VMs where the machineType was set to to rhel7.4 or above, and that Francesco has posted a vdsm-side fix for this https://gerrit.ovirt.org/#/q/topic:update-device-fix
Support for domxml-based updateDevice is required also from Engine, where Alona has a patch in the works.

Comment 2 Francesco Romani 2018-07-18 11:42:32 UTC
(In reply to Dan Kenigsberg from comment #1)
> I believe that this affects only VMs where the machineType was set to to
> rhel7.4 or above, and that Francesco has posted a vdsm-side fix for this
> https://gerrit.ovirt.org/#/q/topic:update-device-fix
> Support for domxml-based updateDevice is required also from Engine, where
> Alona has a patch in the works.

Please note that Vdsm side is NOT finished even after merging all the patches I posted on gerrit (two). The missing step on Vdsm side depends on what Engine wants to send as XML. For example, maybe Engine will send the new desired state of the device, or just the differences to be applied.

Comment 3 Dan Kenigsberg 2018-07-22 15:43:59 UTC
I suspected that Engine would render the complete XML of the updated device. But maybe Alona or Arik had something else in mind.

Arik, would you clone this bug to Engine with a proper definition of what should the Engine/Vdsm API look like for updateDevice?

Comment 4 Arik 2018-07-25 07:09:08 UTC
(In reply to Dan Kenigsberg from comment #3)
> Arik, would you clone this bug to Engine with a proper definition of what
> should the Engine/Vdsm API look like for updateDevice?

I'll leave the bugzilla handling to you.
As for the technical question, the engine should pass the XML that represents the desired state to the vmUpdateDevice verb as an additional field inside the dictionary argument.

Comment 5 Dan Kenigsberg 2018-08-14 21:44:15 UTC
Testable also with nightly build vdsm-0:4.20.22-50.git360bd71.el7ev

Comment 6 msheena 2018-08-15 12:58:19 UTC
verified on:
4.2.6.3-0.0.master.20180813213957.gitf1e5f42.el7
vdsm-4.20.37-2.gitb789857.el7.x86_64