Re: [ovirt-users] Users Digest, Vol 54, Issue 45 VM migration by using the Python SDK

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.