Hide Forgot
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:
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
Could you attach a binary form of the output of virsh -r nodedev-dumpxml computer > /tmp/computer.xml
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.
Created attachment 1135298 [details] Output of: virsh -r nodedev-dumpxml computer
(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 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.
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.
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.
Let me know if there's any testing you'd like me to do on this.
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.