Thanks, it fixed my issue. On Tue, Sep 26, 2017 at 1:04 PM, Miroslava Voglova <[email protected]> wrote:
> Promised patch: https://gerrit.ovirt.org/#/c/82203/ > > On Tue, Sep 26, 2017 at 11:44 AM, Miroslava Voglova <[email protected]> > wrote: > >> So we found where is problem. There was patch before some time that was >> reverted and had two badly formatted jsons in value of vdc_option. If you >> have db from that time, the bug will appear, because the values are not >> updated (because they are already in db). >> >> To fix this, its enough to change 'HotPlugMemorySupported' to value >> '{"x86":"true","ppc":"true"}' for versions 4.0 - 4.2 and >> 'HotUnplugMemorySupported' to '{"x86":"true","ppc":"true"}' for 4.2. >> >> Will do the patch that will include this update in 0000_config in case >> anyone else had the same problem. >> >> On Tue, Sep 26, 2017 at 10:12 AM, Fred Rolland <[email protected]> >> wrote: >> >>> 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.GetArchitectureCapabilitiesQuery.i >>> sSupported(GetArchitectureCapabilitiesQuery.java:66) [bll.jar:] >>> at org.ovirt.engine.core.bll.GetArchitectureCapabilitiesQuery.g >>> etMap(GetArchitectureCapabilitiesQuery.java:36) [bll.jar:] >>> at org.ovirt.engine.core.bll.GetArchitectureCapabilitiesQuery.e >>> xecuteQueryCommand(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.DefaultBackendQueryExecut >>> or.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 <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Sep 26, 2017 at 9:17 AM, Miroslava Voglova <[email protected] >>>> > 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_upgrade/0000_config.sql>* >>>>> >>>>> On Tue, Sep 26, 2017 at 9:00 AM, Tomas Jelinek <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 25, 2017 at 10:08 PM, Roy Golan <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, 25 Sep 2017 at 22:52 Alexander Wels <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>> 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 >>>>>>>> > > > > [email protected] >>>>>>>> > > > > http://lists.ovirt.org/mailman/listinfo/devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> [email protected] >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> [email protected] >>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>> >>> >> >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
