<div dir="ltr">Bug 1315435 Submitted. Let me know if there's anything else I can do to help.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 12:04 PM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Mar 07, 2016 at 11:45:27AM -0500, Jonathan Sherman wrote:<br>
> The SMBIOS settings were indeed indeed the issue that was blocking me. I<br>
> investigated how to configure the SMBIOS settings and now restore-nets<br>
> works, and I'm getting past where I was failing on the hosted-engine<br>
> --deploy.<br>
><br>
> FYI, I had to download the "Intel Integrator Toolkit" (which is now EOL)<br>
> and create a custom BIOS to add those settings in for my system, which is<br>
> an Intel NUC DN2820FYKH.<br>
><br>
> I am happy to back this out and test any changes if you'd like, but this<br>
> has gotten me to where I can continue oVirt testing for now. I'll likely<br>
> be reinstalling a few times along the way to polish my documentation, so<br>
> let me know if you want me to revert my BIOS and test anything.<br>
><br>
> Thanks all!<br>
> -js<br>
><br>
> On Mon, Mar 7, 2016 at 11:22 AM, Martin Polednik <<a href="mailto:mpolednik@redhat.com">mpolednik@redhat.com</a>><br>
> wrote:<br>
><br>
> > On 07/03/16 11:09 -0500, Jonathan Sherman wrote:<br>
> ><br>
> >> Thanks for your time on this Dan!<br>
> >><br>
> >> The output from the hostdev looks like it may be unparseable, so I'm<br>
> >> hoping<br>
> >> this is the issue (and that it can be easily remedied).<br>
> >><br>
> >> I've also create a log of the other items you asked for, available at:<br>
> >> <a href="https://www.dropbox.com/s/qh0yw1ptpivpatm/typescript?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/qh0yw1ptpivpatm/typescript?dl=0</a><br>
> >><br>
> >> [root@ovirt01 vdsm]# vdsm-tool restore-nets<br>
> >> <device><br>
> >> <name>computer</name><br>
> >> <capability type='system'><br>
> >> <product>���������������������������������</product><br>
> >> <hardware><br>
> >> <vendor>���������������������������������</vendor><br>
> >> <version>���������������������������������</version><br>
> >> <serial>���������������������������������</serial><br>
> >> <uuid>d6a3e3c1-c5cb-42e9-a54c-ff8d0df91722</uuid><br>
> >> </hardware><br>
> >> <firmware><br>
> >> <vendor>Intel Corp.</vendor><br>
> >> <version>FYBYT10H.86A.0052.2015.0923.1845</version><br>
> >> <release_date>09/23/2015</release_date><br>
> >> </firmware><br>
> >> </capability><br>
> >> </device><br>
> >><br>
> ><br>
> > That seems to be the issue. Even bigger issue is that we can<br>
> > not skip this device easily, as it is the root of device tree and must<br>
> > be present in database.<br>
> ><br>
> > I can think of logging the exception but letting the call go through<br>
> > and create a hook to fake a (minimal) device tree. Dan, what do you think?<br>
<br>
<br>
</div></div>But why isn't this a valid xml, Martin? I suspect that we need to<br>
utf-8-decode nodedev-xml before using them in Vdsm, similar to what we<br>
do with domain-xml? (consider Klingon characters in the <vendor><br>
element).<br>
<br>
In any case, this issue merits a bug - could you open it, Jonathan, and<br>
attach relevant data to it?<br>
<br>
Regards,<br>
Dan.<br>
</blockquote></div><br></div>