Re: [ovirt-devel] Unable to start VMs

I have same issue with new VM : 2017-09-26 11:07:59,255+03 ERROR [org.ovirt.engine.core.bll. GetArchitectureCapabilitiesQuery] (default task-2) [c066bc1d-4048-4b5f-bdb6-74fd813aa82e] Query ' GetArchitectureCapabilitiesQuery' failed: null 2017-09-26 11:07:59,255+03 ERROR [org.ovirt.engine.core.bll. GetArchitectureCapabilitiesQuery] (default task-2) [c066bc1d-4048-4b5f-bdb6-74fd813aa82e] Exception: java.lang.NullPointerException at org.ovirt.engine.core.common.FeatureSupported.supportedInConfig(FeatureSupported.java:23) [common.jar:] at org.ovirt.engine.core.common.FeatureSupported.hotUnplugMemory(FeatureSupported.java:43) [common.jar:] at org.ovirt.engine.core.bll.GetArchitectureCapabilitiesQue ry.isSupported(GetArchitectureCapabilitiesQuery.java:66) [bll.jar:] at org.ovirt.engine.core.bll.GetArchitectureCapabilitiesQuery.getMap( GetArchitectureCapabilitiesQuery.java:36) [bll.jar:] at org.ovirt.engine.core.bll.GetArchitectureCapabilitiesQue ry.executeQueryCommand(GetArchitectureCapabilitiesQuery.java:22) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:106) [bll.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecutor. execute(DefaultBackendQueryExecutor.java:14) [bll.jar:] Then: 2017-09-26 11:08:08,397+03 ERROR [org.ovirt.engine.core.vdsbroker.CreateVDSCommand] (org.ovirt.thread.EE-ManagedThreadFactory-engine-Thread-11) [9eb76d15-2bd5-49a9-a7d8-c73cfd55282c] Failed to create VM: null 2017-09-26 11:08:08,398+03 ERROR [org.ovirt.engine.core.vdsbroker.CreateVDSCommand] (org.ovirt.thread.EE-ManagedThreadFactory-engine-Thread-11) [9eb76d15-2bd5-49a9-a7d8-c73cfd55282c] Command 'CreateVDSCommand( CreateVDSCommandParameters:{hostId='b6b6a226-8d4f-4929-85d1-b218eceee99e', vmId='f15ddd07-408b-4665-aede-a9efc5716dc7', vm='VM [FEDORA_CINDER]'})' execution failed: java.lang.NullPointerException On Tue, Sep 26, 2017 at 10:26 AM, Tomas Jelinek <tjelinek(a)redhat.com&gt; wrote: > > > On Tue, Sep 26, 2017 at 9:17 AM, Miroslava Voglova <mvoglova(a)redhat.com&gt; > wrote: > >> From 4.0 architecture family was renamed in >> script 04_00_0080_rename_architecture_family. So >> 'HotPlugCpuSupported', 'HotUnplugCpuSupported', 'HotPlugMemo >> rySupported', 'HotUnplugMemorySupported', '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]. >> >> 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. >> > > 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. > > @Alexander: by any chance, was this VM an unmanaged one? Or imported? In > logs you should find something like: > "Illegal architecture type: {}, replacing with x86_64" or "null > architecture type, replacing with x86_64, {}". > > Also, if you create a new VM, can you start it? > > >> >> >> [1] *https://gerrit.ovirt.org/#/c/81464/7/packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql >> <https://gerrit.ovirt.org/#/c/81464/7/packaging/dbscripts/upgrade/pre_upgr... >> >> On Tue, Sep 26, 2017 at 9:00 AM, Tomas Jelinek <tjelinek(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Mon, Sep 25, 2017 at 10:08 PM, Roy Golan <rgolan(a)redhat.com&gt; wrote: >>> >>>> >>>> >>>> On Mon, 25 Sep 2017 at 22:52 Alexander Wels <awels(a)redhat.com&gt; wrote: >>>> >>>>> On Monday, September 25, 2017 3:50:56 PM EDT Roy Golan wrote: >>>>> > So somewhere in the code somebody used the Arch and not the family. >>>>> See the >>>>> > enum getFamily() method >>>>> > >>>>> >>>>> Yep, in particular line 23 of FeatureSupported.java. >>>>> >>>>> 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 ? >>>> >>>> > On Mon, 25 Sep 2017 at 22:31 Alexander Wels <awels(a)redhat.com&gt; >>>>> wrote: >>>>> > > On Monday, September 25, 2017 3:24:14 PM EDT Roy Golan wrote: >>>>> > > > what JRE are you using? any change with that? >>>>> > > >>>>> > > So I just figured out the problem, and its really strange. It has >>>>> nothing >>>>> > > to >>>>> > > do with the SSL as the stack trace is mentioning. I manually >>>>> stepped >>>>> > > through >>>>> > > the code to see what was going on and it turns out it is failing >>>>> in >>>>> > > FeatureSupported.java in supportedInConfig call from >>>>> hotPlugMemory. >>>>> > > >>>>> > > The Config.<Map>getValue(feature, version.getValue()) (version is >>>>> 4.2) is >>>>> > > returning a map containing x86=true and ppc=true. But then it >>>>> compares >>>>> > > this to >>>>> > > ArchitectureType.name() it returns null, because .name() return >>>>> x86_64. No >>>>> > > it >>>>> > > appears that sometime during the last few months we dropped the >>>>> _64 in the >>>>> > > ArchitectureType, or at least in the database. >>>>> >>>> >>> It looks a lot like introduced here: https://gerrit.ovirt.org/#/c/8 >>> 1464/ >>> >>> @Mirka: what you think? >>> >>> >>>> > > >>>>> > > As soon as I added a vdc_options tha contains x86_64 value for >>>>> that key it >>>>> > > started working. Now I have checked with Greg who has a fresh >>>>> database >>>>> > > that he >>>>> > > can start VMs no problem, and his database contains x86 instead >>>>> of x86_64. >>>>> > > >>>>> > > > On Mon, 25 Sep 2017 at 21:12 Alexander Wels <awels(a)redhat.com&gt; >>>>> wrote: >>>>> > > > > Hi guys, >>>>> > > > > >>>>> > > > > I see to be having an issue starting VMs with the latest >>>>> master. >>>>> > > >>>>> > > Whenever >>>>> > > >>>>> > > > > I >>>>> > > > > try to start a VM I get null pointer exception. And the VM >>>>> doesn't >>>>> > > >>>>> > > start. >>>>> > > >>>>> > > > > I >>>>> > > > > have debugged the engine, and it appears that the null >>>>> pointer happens >>>>> > > > > after >>>>> > > > > the engine tries to connect to the host. In the stack trace I >>>>> see >>>>> > > > > SSLPeerUnverifiedException, so it appears something went >>>>> wrong with a >>>>> > > > > certificate somewhere. >>>>> > > > > >>>>> > > > > I have put my hosts in maintaince and re-enrolled the >>>>> certificate, but >>>>> > > > > that >>>>> > > > > doesn't appear to be helping at all. Any other place I need >>>>> to look at >>>>> > > >>>>> > > to >>>>> > > >>>>> > > > > make >>>>> > > > > sure the engine can talk to the hosts? This appears to have >>>>> started >>>>> > > >>>>> > > after >>>>> > > >>>>> > > > > I >>>>> > > > > upgraded Wildfly to 11, so it is possible it has something to >>>>> do with >>>>> > > >>>>> > > that >>>>> > > >>>>> > > > > as >>>>> > > > > well. >>>>> > > > > >>>>> > > > > Any help figuring this out would be appreciated. >>>>> > > > > >>>>> > > > > Alexander >>>>> > > > > _______________________________________________ >>>>> > > > > Devel mailing list >>>>> > > > > Devel(a)ovirt.org >>>>> > > > > http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>> >>> >> > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >