7:49 p.m.
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(a)redhat.com> wrote:
On Mon, Mar 07, 2016 at 11:45:27AM -0500, Jonathan Sherman 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(a)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
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.