Bug 893576

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Nic params, needed for updateDevice are missing i.e. not dispatched by the engine, a patch has been submitted (http://gerrit.ovirt.org/#/c/13920/) to solve this issue.

(In reply to comment #3)
> Nic params, needed for updateDevice are missing i.e. not dispatched by the
> engine, a patch has been submitted (http://gerrit.ovirt.org/#/c/13920/) to
> solve this issue.

I was wrong there's no need of any additional parameter provided by the engine.

Giuseppe, can you please describe how to test this BZ?

on my host I do not see hook called updateDevice or before_device_update etc. /usr/libexec/vdsm/hooks/

which hooks should I test and under what circumstances they should kick in?

Hi Martin, you should find these 2 folders after installing vdsm:
* after_update_device
* before_update_device
(I'm solving this issue right now).

These hooks are triggered when you update a network device. The most important one is the before_update_device which allows to modify the network definition.
You can test a hook by placing a script in the associated folder, have a look here, you can find some examples: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/VDSM_Hooks.html .
You can verify that the configuration has been changed/updated with the influence of an hook script with virsh by dumping the xml configuration.

A trivial patch has been submitted and merged that solve the issue Martin has found.

QA_failed with following stack trace

Thread-3811::DEBUG::2013-06-20 15:50:53,496::vm::2981::vm.Vm::(setLinkAndNetwork) vmId=`f2d3debe-dd10-4f50-a113-2d0089778639`::Rolling back link and net for: net0
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 2975, in setLinkAndNetwork
    hooks.after_update_device_fail(vnicXML, self.conf)
  File "/usr/share/vdsm/hooks.py", line 231, in after_update_device_fail
    raiseError=False, params=params)
  File "/usr/share/vdsm/hooks.py", line 57, in _runHooksDir
    os.write(xmlfd, domxml or '')
TypeError: write() argument 2 must be convertible to a buffer, not XMLElement
Thread-3811::ERROR::2013-06-20 15:50:53,585::BindingXMLRPC::945::vds::(wrapper) unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/BindingXMLRPC.py", line 931, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/BindingXMLRPC.py", line 281, in vmUpdateDevice
    return vm.vmUpdateDevice(params)
  File "/usr/share/vdsm/API.py", line 382, in vmUpdateDevice
    return v.updateDevice(params)
  File "/usr/share/vdsm/vm.py", line 3027, in updateDevice
    return self._updateInterfaceDevice(params)
  File "/usr/share/vdsm/vm.py", line 2942, in _updateInterfaceDevice
    with self.setLinkAndNetwork(netDev, netConf, linkValue, network):
  File "/usr/lib64/python2.6/contextlib.py", line 16, in __enter__
    return self.gen.next()
  File "/usr/share/vdsm/vm.py", line 2975, in setLinkAndNetwork
    hooks.after_update_device_fail(vnicXML, self.conf)
  File "/usr/share/vdsm/hooks.py", line 231, in after_update_device_fail
    raiseError=False, params=params)
  File "/usr/share/vdsm/hooks.py", line 57, in _runHooksDir
    os.write(xmlfd, domxml or '')
TypeError: write() argument 2 must be convertible to a buffer, not XMLElement

Hi Martin, before the error you reported this happens:

Thread-613::INFO::2013-06-21 14:33:57,078::hooks::76::root::(_runHooksDir) Traceback (most recent call last):
  File "/usr/libexec/vdsm/hooks/before_update_device/10_before_update_device.py", line 14, in <module>
    main()
  File "/usr/libexec/vdsm/hooks/before_update_device/10_before_update_device.py", line 9, in main
    logging.basicConfig(filename='/tmp/vdsm_device_update_hooks.log', level=logging.DEBUG, format='%(asctime)s - %(levelname)s - %(message)s')
  File "/usr/lib64/python2.6/logging/__init__.py", line 1402, in basicConfig
    hdlr = FileHandler(filename, mode)
  File "/usr/lib64/python2.6/logging/__init__.py", line 827, in __init__
    StreamHandler.__init__(self, self._open())
  File "/usr/lib64/python2.6/logging/__init__.py", line 846, in _open
    stream = open(self.baseFilename, self.mode)
IOError: [Errno 13] Permission denied: '/tmp/vdsm_device_update_hooks.log'

Which might be the failure that happens later on, I've tried to 
replace your script with logged in /tmp/vdsm_device_update_hooks.log with one
that does the following:

#!/usr/bin/python

import logging
import hooking

def main():
    domxml = hooking.read_domxml()
    hooking.write_domxml(domxml)
   

if __name__ == '__main__':
  main()

and it didn't fail.

Can you verify it by yourself? Thanks Giuseppe.

The relevant information is that for some reasons it seems you can't log in /tmp . Giuseppe

1) Thanks for the pointer Giuseppe, I was testing hooks separately before using them via vdsm, therefore /tmp/vdsm_device_update_hooks.log was created with root permissions and others (vdsm) were not allowed to write in it. That was the cause of the failure Comment 8. 

2)
After fixing permissions on /tmp/vdsm_device_update_hooks.log it turned out that after_update_device hook does not kick in exactly how it should. Giuseppe Vallarelli already fixed it, now the fix needs to be implemented in vdsm code.

That behaviour is not a desired one, a patch which addresses this issue has been already submitted http://gerrit.ovirt.org/#/c/15982/ . Giuseppe

Created attachment 786069 [details]
logs files of engine and vdsm

Hooks not workings when I change name of vnic in all other cases hooks works fine.
See vdsm and engine log

tested on is9.1

(In reply to Artyom from comment #17)
> Created attachment 786069 [details]
> logs files of engine and vdsm
> 
> Hooks not workings when I change name of vnic in all other cases hooks works
> fine.
> See vdsm and engine log

Can you add more details of what wasn't working and what did you do for testing the update device hooks? Looking at the logs it's not clear, also would be cool if you extract the relevant part when submitting the logs, thanks.

script under directory /usr/libexec/vdsm/hooks/before_update_device not performed when I change name of vnic, if I change something else(status, custom properties...) script was performed, script just was write some string to my log file(it no problem with permission, because I other cases, not changing name, script was performed and was writing string to log file)
I cut last hour of logs, that you can see that script was performed when I updated state and custom properties

Hi Artyom I've seen the logs and also I've tried it by myself and I've seen that when you change vnic name the vmUpdateDevice verb is not triggered, there is no trace of vmUpdateDevice call in the vdsm logs - if vmUpdateDevice is not triggered neither the hook script is. From the UI that when you edit a vnic name the change happens instead when you edit the other options it takes a little more because he's using the vmUpdateDevice verb. Now the question is if a change in the vnic name should trigger an updateDevice call.

Andrew what you think about comment 21, if a change in the vnic name should trigger an updateDevice call?

artyom - please open a separate bug for further discussion/prioritization on this specific use case (vnic name change). thanks.

I did this task a few months ago so I don't recall exactly if the vnic name change can be considered as a possible scenario. What I can tell for sure is that the xml definition of libvirt doesn't use the same UI name:
For nic1 the convention used is by libvirt is target dev 'vnet0' alias name 'net0' with nic2 vnet1 and net1 and so on:

<interface type='bridge'>
      <mac address='00:1a:4a:09:65:10'/>
      <source bridge='rhevm'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <link state='up'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</interface>
<interface type='bridge'>
      <mac address='00:1a:4a:09:65:14'/>
      <source bridge='rhevm'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <link state='up'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Hope this helps, cheers Giuseppe

Looking at the engine code it seems that editing a VNIC name isn't designed to update anything on the host, probably due to it not actually being used by libvirt as Giuseppe pointed out.

Created attachment 787742 [details]
logs for is10

From version is10 before_update_device and after_update_device hooks stopped working no matter what I change under vnic settings
See logs for more details

Created attachment 788078 [details]
is10 vdsm logs giuseppe

(In reply to Artyom from comment #26)
> Created attachment 787742 [details]
> logs for is10
> 
> From version is10 before_update_device and after_update_device hooks stopped
> working no matter what I change under vnic settings
> See logs for more details

Hi Artyom I've built is10 of both vdsm and the engine and I can't reproduce the scenario you're describing. By looking at your logs (vdsm) I can't find the call at the verb vmUpdateDevice which triggers the related hooks. I've attached my log detail.

Thanks Giuseppe

Hi, I did checking on another host and only when I change link state of nic vmUpdateDevice is appear in vdsm.log, when change name or profile of nic no vmUpdateDevice is appear(I think it ok, because it updated just rhevm database and not send command to vdsm). But when I unplug nic and update mac or type of nic, vmUpdateDevice also not appear(I can update type or mac of nic on running vm, just when it unplugged). So please say if update of type and mac of unplugged nic on running vm must trigger vmUpdateDevice and if not I can verified bug, else will attach logs.
Thanks

(In reply to Artyom from comment #29)
> Hi, I did checking on another host and only when I change link state of nic
> vmUpdateDevice is appear in vdsm.log, when change name or profile of nic no
> vmUpdateDevice is appear(I think it ok, because it updated just rhevm
> database and not send command to vdsm).

Ok

> But when I unplug nic and update mac
> or type of nic, vmUpdateDevice also not appear(I can update type or mac of
> nic on running vm, just when it unplugged).

For nic unplugging there are different hooks like before_nic_hotunplug and after_nic_hotunplug

> So please say if update of type
> and mac of unplugged nic on running vm must trigger vmUpdateDevice and if
> not I can verified bug, else will attach logs.
> Thanks

For unplugging a different flow is executed, that's why you don't seen any vmUpdateDevice in the logs, hope this helps.

Thanks, Giuseppe

Ok so vmUpdateDevice hook run just in case when I change link state of vnic
Verified on is10

This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHBA-2014-0040.html