On Thu, Feb 1, 2018 at 7:19 PM, Simone Tiraboschi <stirabos(a)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.