Bug 1315435

Summary: vdsm-tool restore-nets fails due to invalid SMBIOS strings
Product: [oVirt] vdsm Reporter: Jonathan Sherman <haviland>
Component: CoreAssignee: Martin Polednik <mpoledni>
Status: CLOSED CURRENTRELEASE QA Contact: sefi litmanovich <slitmano>
Severity: high Docs Contact:
Priority: high    
Version: 4.17.23CC: bugs, danken, haviland, michal.skrivanek, slitmano, tjelinek
Target Milestone: ovirt-3.6.5Flags: michal.skrivanek: ovirt-3.6.z?
rule-engine: planning_ack?
danken: devel_ack+
rule-engine: testing_ack+
Target Release: 4.17.25   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 3.6.5-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-21 14:42:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of: virsh -r nodedev-dumpxml computer none

Description Jonathan Sherman 2016-03-07 17:49:20 UTC
Description of problem:
vdsm-tool restore-nets fails due to invalid SMBIOS strings

Version-Release number of selected component (if applicable):
vdsm-python-4.17.23-1.el7.noarch : VDSM python libraries
Repo        : @centos-ovirt36
Matched from:
Filename    : /bin/vdsm-tool

How reproducible:
Use invalid SMBIOS strings in BIOS - in my case product, vendor, version, and serial were all invalid strings.

Steps to Reproduce:
1. Acquire Intel NUC DN2820FYKH or other motherboard with invalid SMBIOS strings
2. Install latest version of 3.6 packages
3. Modify hostdev.py to provide device debugging information, per:
     diff --git a/lib/vdsm/hostdev.py b/lib/vdsm/hostdev.py
     index 6ba3189..9d22e9e 100644
     --- a/lib/vdsm/hostdev.py
     +++ b/lib/vdsm/hostdev.py
     @@ -113,6 +113,7 @@ def _parse_device_params(device_xml):
          Process device_xml and return dict of found known parameters,
          also doing sysfs lookups for sr-iov related information
          """
     +    print(device_xml)
          address_parser = {'pci': _parse_pci_address,
                            'scsi': _parse_scsi_address,
                            'usb_device': _parse_usb_address}
4. Run /bin/vdsm-tool restore-nets

Actual results:
[root@ovirt01 vdsm]# vdsm-tool restore-nets
<device>
  <name>computer</name>
  <capability type='system'>
    <product>���������������������������������</product>
    <hardware>
      <vendor>���������������������������������</vendor>
      <version>���������������������������������</version>
      <serial>���������������������������������</serial>
      <uuid>d6a3e3c1-c5cb-42e9-a54c-ff8d0df91722</uuid>
    </hardware>
    <firmware>
      <vendor>Intel Corp.</vendor>
      <version>FYBYT10H.86A.0052.2015.0923.1845</version>
      <release_date>09/23/2015</release_date>
    </firmware>
  </capability>
</device>

Traceback (most recent call last):
  File "/usr/share/vdsm/vdsm-restore-net-config", line 429, in <module>
    restore(args)
  File "/usr/share/vdsm/vdsm-restore-net-config", line 387, in restore
    _restore_sriov_numvfs()
  File "/usr/share/vdsm/vdsm-restore-net-config", line 82, in _restore_sriov_numvfs
    sriov_devices = _get_sriov_devices()
  File "/usr/share/vdsm/vdsm-restore-net-config", line 54, in _get_sriov_devices
    devices = hostdev.list_by_caps()
  File "/usr/share/vdsm/hostdev.py", line 177, in list_by_caps
    libvirt_devices = _get_devices_from_libvirt()
  File "/usr/share/vdsm/hostdev.py", line 162, in _get_devices_from_libvirt
    for device in libvirtconnection.get().listAllDevices(0))
  File "/usr/share/vdsm/hostdev.py", line 162, in <genexpr>
    for device in libvirtconnection.get().listAllDevices(0))
  File "/usr/share/vdsm/hostdev.py", line 109, in _parse_device_params

    devXML = etree.fromstring(device_xml)
  File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML
    parser.feed(text)
  File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in feed
    self._raiseerror(v)
  File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 4, column 13
Traceback (most recent call last):
  File "/bin/vdsm-tool", line 219, in main
    return tool_command[cmd]["command"](*args)
  File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line 41, in restore_command
    exec_restore(cmd)
  File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line 54, in exec_restore
    raise EnvironmentError('Failed to restore the persisted networks')
EnvironmentError: Failed to restore the persisted networks

Expected results:
(no response when there are no errors)

Additional info:

Comment 1 Jonathan Sherman 2016-03-07 22:43:39 UTC
Note:  I've been working with the users mailing list and the following people were also engaged on this:
Dan Kenigsberg <danken>
Martin Polednik <mpolednik>,
Yedidyah Bar David <didi>,
mpoledni,
edwardh

Comment 2 Dan Kenigsberg 2016-03-08 07:57:17 UTC
Could you attach a binary form of the output of

  virsh -r nodedev-dumpxml computer > /tmp/computer.xml

Comment 3 Dan Kenigsberg 2016-03-09 14:09:43 UTC
Tomas, we end up failing to restore networking, but the problem here is with the hostdev module, which does not behave when libvirt reports non-ascii data.

Polednik is aware of this issue.

Comment 4 Jonathan Sherman 2016-03-11 16:22:49 UTC
Created attachment 1135298 [details]
Output of: virsh -r nodedev-dumpxml computer

Comment 5 Jonathan Sherman 2016-03-11 16:23:26 UTC
(In reply to Dan Kenigsberg from comment #2)
> Could you attach a binary form of the output of
> 
>   virsh -r nodedev-dumpxml computer > /tmp/computer.xml

Attached!

Comment 6 Jonathan Sherman 2016-03-11 16:24:49 UTC
Comment on attachment 1135298 [details]
Output of: virsh -r nodedev-dumpxml computer

Note that this file was generated on a second device of the same hardware model which has the same issue.

Comment 7 Martin Polednik 2016-03-15 09:06:42 UTC
To make sure that I understand the issue: this happens without any modification to the SMBIOS string? It seems more of a bug on the motherboard.

If that is the case, we'll have to drop invalid fields for motherboards/devices with similar problems as we do not now the encoding of source string.

Comment 8 Jonathan Sherman 2016-03-15 11:43:39 UTC
Correct - this is an unmodified BIOS. I can't argue that Intel should have set those BIOS fields to valid strings, but they did not in the original or updated BIOS firmware. 

(In reply to Martin Polednik from comment #7)
> To make sure that I understand the issue: this happens without any
> modification to the SMBIOS string? It seems more of a bug on the motherboard.
> 
> If that is the case, we'll have to drop invalid fields for
> motherboards/devices with similar problems as we do not now the encoding of
> source string.

Comment 9 Jonathan Sherman 2016-03-19 13:53:23 UTC
Let me know if there's any testing you'd like me to do on this.

Comment 10 sefi litmanovich 2016-04-11 13:09:24 UTC
Verified with vdsm-4.17.25-0.el7ev.noarch.
Forced an xml with non ascii chars as per the description on _parse_device_params method under /usr/share/vdsm/hostdev.py.
Ran vdsClient -s 0 hostdevListByCaps to invoke call to the method.
The non ascii chars are ignored and no exception is raised.
if e.g. the xml is changes so product tag has:
<product>���������������test������������������</product>
then vdsClient -s 0 hostdevListByCap returns pair 'product': 'test' for that device.