[ovirt-users] restore-nets failing (was: Fresh install failing (Hosted Engine))

[Jonathan Sherman]

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 at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160307/64af14fd/attachment-0001.html>