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

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?