<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 1, 2018 at 7:19 PM, Simone Tiraboschi <span dir="ltr">&lt;<a href="mailto:stirabos@redhat.com" target="_blank">stirabos@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div></blockquote></div></div>You definitively hit this one:<br><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1539040" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1539040</a><br>host-deploy stops libvirt-guests triggering a shutdown of all the running VMs (including HE one)<div> </div><div>We rebuilt host-deploy with a fix for that today.</div><div>It affects only the host where libvirt-guests has already been configured by a 4.2 host-deploy in the past.</div><div>As a workaround you have to manually stop libvirt-guests before and deconfigure it on /etc/sysconfig/libvirt-guests.<wbr>conf before running hosted-engine-setup again.</div></div></div></div></blockquote><div><br></div><div>Ok.</div><div>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.</div><div>Now I have a reachaility problem of engine vm from outside, but it is a differen tproblem and I&#39;m going to open a new thread for it if I don&#39;t solve..</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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...??</div></div></div></div></blockquote><div><br></div></span><div>This is absolutely fine.</div><div>Let me explain: with the new ansible based flow we completely reverted the hosted-engine deployment flow.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Thanks for the new workflow explanation.</div><div>Indeed during my change&amp;try options I also tried to destroy and undefine the &quot;default&quot; libvirt network and the deploy complained about it.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>BTW: on host I have network managed by NetworkManager. It is supported now in upcoming 4.2.1, isn&#39;t it?</div></div></div></div></blockquote><div><br></div></span><div>Yes, it is.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_4828597942036314506gmail-HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>Ok. I confirm that in my new deploy I let NetworkManager up in host configuration and all went good. </div></div></div></div>