Hi, Thx a lot. Regards, J.P. -----Original Message----- From: users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of users-request@ovirt.org Sent: lundi 7 mars 2016 20:00 To: users@ovirt.org Subject: Users Digest, Vol 54, Issue 45 Send Users mailing list submissions to users@ovirt.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ovirt.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request@ovirt.org You can reach the person managing the list at users-owner@ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: restore-nets failing (was: Fresh install failing (Hosted Engine)) (Jonathan Sherman) 2. Re: regenerate libvirt-spice keys after libvirtd restart? (Bill James) 3. Re: VM migration by using the Python SDK (Yaniv Kaul) ---------------------------------------------------------------------- Message: 1 Date: Mon, 7 Mar 2016 12:49:56 -0500 From: Jonathan Sherman <haviland@gmail.com> To: Dan Kenigsberg <danken@redhat.com> Cc: Martin Polednik <mpolednik@redhat.com>, users <users@ovirt.org> Subject: Re: [ovirt-users] restore-nets failing (was: Fresh install failing (Hosted Engine)) Message-ID: <CAG7LhDtBRxQUC1Qnzqg6gY_tXQz8MSS3HUJfPO3F789=cVndUg@mail.gmail.com> Content-Type: text/plain; charset="utf-8" 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@redhat.com> 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@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@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

On Mon, Mar 07, 2016 at 11:45:27AM -0500, Jonathan Sherman wrote: 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.