On 29 Nov 2018, at 06:04, Michal Skrivanek
<michal.skrivanek(a)redhat.com> 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?