<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 26, 2017 at 9:17 AM, Miroslava Voglova <span dir="ltr"><<a href="mailto:mvoglova@redhat.com" target="_blank">mvoglova@redhat.com</a>></span> wrote:<br><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">From 4.0 architecture family was renamed in script 04_00_0080_rename_<wbr>architecture_family. So 'HotPlugCpuSupported', '<wbr>HotUnplugCpuSupported', '<wbr>HotPlugMemorySupported', '<wbr>HotUnplugMemorySupported', '<wbr>IsMigrationSupported', 'IsMemorySnapshotSupported' and 'IsSuspendSupported' are all in db with x86 not x86_64. In my point of view nothing wrong with that particular line in [1].<div><br><div>Could be that somewhere in code is not used architecture family, but host architecture, when asked for value of this ConfigValues. But that would throw exception even before my patch, because '{"x86:"true","ppc":"true"}' was default value for HotPlugMemorySupported.<br></div></div></div></blockquote><div><br></div><div>I see a code path where the cluster arch can be set to x86_64 - it is always executed for external VMs (imported from external provider or unmanaged). It does not happen all the time, it is only a fallback if the arch type is not known/reported etc.</div><div><br></div><div>@Alexander: by any chance, was this VM an unmanaged one? Or imported? In logs you should find something like:</div><div>"Illegal architecture type: {}, replacing with x86_64" or "null architecture type, replacing with x86_64, {}".</div><div><br></div><div>Also, if you create a new VM, can you start it?<br></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><div><div><br></div><div><br></div><div><span style="font-size:12.8px">[1] </span><font color="#1155cc"><span style="font-size:12.8px"><u><a href="https://gerrit.ovirt.org/#/c/81464/7/packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql" target="_blank">https://gerrit.ovirt.org/#<wbr>/c/81464/7/packaging/<wbr>dbscripts/upgrade/pre_upgrade/<wbr>0000_config.sql</a></u></span></font><br></div></div></div></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 26, 2017 at 9:00 AM, Tomas Jelinek <span dir="ltr"><<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a>></span> wrote:<br><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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Sep 25, 2017 at 10:08 PM, Roy Golan <span dir="ltr"><<a href="mailto:rgolan@redhat.com" target="_blank">rgolan@redhat.com</a>></span> wrote:<br><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"><br><br><div class="gmail_quote"><span class="gmail-m_-3832170205561208090m_-8422389147944334059gmail-"><div dir="ltr">On Mon, 25 Sep 2017 at 22:52 Alexander Wels <<a href="mailto:awels@redhat.com" target="_blank">awels@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, September 25, 2017 3:50:56 PM EDT Roy Golan wrote:<br>
> So somewhere in the code somebody used the Arch and not the family. See the<br>
> enum getFamily() method<br>
><br>
<br>
Yep, in particular line 23 of FeatureSupported.java.<br>
<br></blockquote></span><div>I meant the caller of the method on this line. Do you have it in the trace so we can see who passed x86_64 as arch ?</div><div><div class="gmail-m_-3832170205561208090m_-8422389147944334059gmail-h5"><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">
> On Mon, 25 Sep 2017 at 22:31 Alexander Wels <<a href="mailto:awels@redhat.com" target="_blank">awels@redhat.com</a>> wrote:<br>
> > On Monday, September 25, 2017 3:24:14 PM EDT Roy Golan wrote:<br>
> > > what JRE are you using? any change with that?<br>
> ><br>
> > So I just figured out the problem, and its really strange. It has nothing<br>
> > to<br>
> > do with the SSL as the stack trace is mentioning. I manually stepped<br>
> > through<br>
> > the code to see what was going on and it turns out it is failing in<br>
> > FeatureSupported.java in supportedInConfig call from hotPlugMemory.<br>
> ><br>
> > The Config.<Map>getValue(feature, version.getValue()) (version is 4.2) is<br>
> > returning a map containing x86=true and ppc=true. But then it compares<br>
> > this to<br>
> > ArchitectureType.name() it returns null, because .name() return x86_64. No<br>
> > it<br>
> > appears that sometime during the last few months we dropped the _64 in the<br>
> > ArchitectureType, or at least in the database.<br></blockquote></div></div></div></div></blockquote><div><br></div></span><div>It looks a lot like introduced here: <a href="https://gerrit.ovirt.org/#/c/81464/" target="_blank">https://gerrit.ovirt.org/#/c/8<wbr>1464/</a></div><div><br></div><div>@Mirka: what you think?<br></div><div><div class="gmail-m_-3832170205561208090h5"><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_quote"><div><div class="gmail-m_-3832170205561208090m_-8422389147944334059gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ><br>
> > As soon as I added a vdc_options tha contains x86_64 value for that key it<br>
> > started working. Now I have checked with Greg who has a fresh database<br>
> > that he<br>
> > can start VMs no problem, and his database contains x86 instead of x86_64.<br>
> ><br>
> > > On Mon, 25 Sep 2017 at 21:12 Alexander Wels <<a href="mailto:awels@redhat.com" target="_blank">awels@redhat.com</a>> wrote:<br>
> > > > Hi guys,<br>
> > > ><br>
> > > > I see to be having an issue starting VMs with the latest master.<br>
> ><br>
> > Whenever<br>
> ><br>
> > > > I<br>
> > > > try to start a VM I get null pointer exception. And the VM doesn't<br>
> ><br>
> > start.<br>
> ><br>
> > > > I<br>
> > > > have debugged the engine, and it appears that the null pointer happens<br>
> > > > after<br>
> > > > the engine tries to connect to the host. In the stack trace I see<br>
> > > > SSLPeerUnverifiedException, so it appears something went wrong with a<br>
> > > > certificate somewhere.<br>
> > > ><br>
> > > > I have put my hosts in maintaince and re-enrolled the certificate, but<br>
> > > > that<br>
> > > > doesn't appear to be helping at all. Any other place I need to look at<br>
> ><br>
> > to<br>
> ><br>
> > > > make<br>
> > > > sure the engine can talk to the hosts? This appears to have started<br>
> ><br>
> > after<br>
> ><br>
> > > > I<br>
> > > > upgraded Wildfly to 11, so it is possible it has something to do with<br>
> ><br>
> > that<br>
> ><br>
> > > > as<br>
> > > > well.<br>
> > > ><br>
> > > > Any help figuring this out would be appreciated.<br>
> > > ><br>
> > > > Alexander<br>
> > > > ______________________________<wbr>_________________<br>
> > > > Devel mailing list<br>
> > > > <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
> > > > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
<br>
<br>
</blockquote></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>