Bug 1315435 Submitted. Let me know if there's anything else I can do to help. On Mon, Mar 7, 2016 at 12:04 PM, Dan Kenigsberg <danken@redhat.com> wrote:
The SMBIOS settings were indeed indeed the issue that was blocking me. I investigated how to configure the SMBIOS settings and now restore-nets works, and I'm getting past where I was failing on the hosted-engine --deploy.
FYI, I had to download the "Intel Integrator Toolkit" (which is now EOL) and create a custom BIOS to add those settings in for my system, which is an Intel NUC DN2820FYKH.
I am happy to back this out and test any changes if you'd like, but this has gotten me to where I can continue oVirt testing for now. I'll likely be reinstalling a few times along the way to polish my documentation, so let me know if you want me to revert my BIOS and test anything.
Thanks all! -js
On Mon, Mar 7, 2016 at 11:22 AM, Martin Polednik <mpolednik@redhat.com> wrote:
On 07/03/16 11:09 -0500, Jonathan Sherman wrote:
Thanks for your time on this Dan!
The output from the hostdev looks like it may be unparseable, so I'm hoping this is the issue (and that it can be easily remedied).
I've also create a log of the other items you asked for, available at: https://www.dropbox.com/s/qh0yw1ptpivpatm/typescript?dl=0
[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>
That seems to be the issue. Even bigger issue is that we can not skip this device easily, as it is the root of device tree and must be present in database.
I can think of logging the exception but letting the call go through and create a hook to fake a (minimal) device tree. Dan, what do you
On Mon, Mar 07, 2016 at 11:45:27AM -0500, Jonathan Sherman wrote: think?
But why isn't this a valid xml, Martin? I suspect that we need to utf-8-decode nodedev-xml before using them in Vdsm, similar to what we do with domain-xml? (consider Klingon characters in the <vendor> element).
In any case, this issue merits a bug - could you open it, Jonathan, and attach relevant data to it?
Regards, Dan.