[ovirt-devel] Re: [VDSM] Fedora 28 support - updates

> On 29 Nov 2018, at 06:04, Michal Skrivanek <michal.skrivanek(a)redhat.com&gt; wrote: > > > >> On 28 Nov 2018, at 11:05, Nir Soffer <nsoffer(a)redhat.com <mailto:nsoffer@redhat.com>> wrote: >> >> On Wed, Nov 28, 2018 at 5:53 PM Martin Perina <mperina(a)redhat.com <mailto:mperina@redhat.com>> wrote: >> >> >> On Wed, 28 Nov 2018, 16:29 Yuval Turgeman <yturgema(a)redhat.com <mailto:yturgema@redhat.com> wrote: >> Adding Gal, I think he fixed some of those issues (around add host) >> >> On Wed, Nov 28, 2018 at 5:05 PM Nir Soffer <nsoffer(a)redhat.com <mailto:nsoffer@redhat.com>> wrote: >> If you want to add host running Fedora 28, you need to do few manual steps: >> >> 1. Add hosts fail to configure the firewall >> >> Do not check the "Configure filewall" checkbox >> >> Adding host will fail because engine cannot communicate with vdsm. >> >> Fix - disable the firewall on the host. >> $ iptables -F >> >> There is probably a better way, but I did not find it yet :-) >> >> Sandro, do we have an update about this? >> >> AFAIK this has been fixed more than 2 weeks ago in >> https://gerrit.ovirt.org/95286 <https://gerrit.ovirt.org/95286> >> Could you please retry with updated engine? >> >> I'll test this, thanks. >> >> >> >> 2. Engine fail in Host.getCapabilties >> >> Libvirt changed the location and format of this file. This will cause Host.getCapabilties >> to fai, and the host will become "Unassigned" >> >> This is a new issue revealed by updating our virt-preview repo this week. > > yeah, apparently a change in libvirt 4.7[1]. More changes are about > to follow and we will need to change the logic how we get CPUs from > libvirt eventually. > For now a simple check for both locations should do Bleh, sorry, no it won’t So, Milan, the right way would be to query the capabilities which is not a trivial change…but it is the only way how to stop reading libvirt internal configs. Is that what you’re planning to do?