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

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&gt; > 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.