On Thu, Feb 1, 2018 at 7:19 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:

You definitively hit this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1539040
host-deploy stops libvirt-guests triggering a shutdown of all the running VMs (including HE one)

We rebuilt host-deploy with a fix for that today.
It affects only the host where libvirt-guests has already been configured by a 4.2 host-deploy in the past.
As a workaround you have to manually stop libvirt-guests before and deconfigure it on /etc/sysconfig/libvirt-guests.conf before running hosted-engine-setup again.

Ok.

This is a test env that I want to give to power users to have a feel about 4.2 nw GUI and so I decided to go from scratch redeploying the OS of the host, and with the initial correct nfs permissions all went good at first attempt.

Now I have a reachaility problem of engine vm from outside, but it is a differen tproblem and I'm going to open a new thread for it if I don't solve..

If I understood corrctly it seems that libvirtd took in charge the ip assignement, using the default 192.168.122.x network, while my host and my engine should be on 10.4.4.x...??

This is absolutely fine.
Let me explain: with the new ansible based flow we completely reverted the hosted-engine deployment flow.

Thanks for the new workflow explanation.

Indeed during my change&try options I also tried to destroy and undefine the "default" libvirt network and the deploy complained about it.

BTW: on host I have network managed by NetworkManager. It is supported now in upcoming 4.2.1, isn't it?

Yes, it is.

Ok. I confirm that in my new deploy I let NetworkManager up in host configuration and all went good.