Re: [ovirt-users] NullPointerException when changing compatibility version to 4.0

2017-07-23 Thread Michal Skrivanek 

> On 24 Jul 2017, at 08:23, Marcel Hanke  wrote:
> 
> Hi,
> i'm currently running on 4.0.6.3-1.el7.centos

it’s quite an old thing it’s crashing on. I wonder what is the original version 
where those VMs were created? The current cluster is 3.6, right? Does any of 
those VMs have pending changes to be applied?

Thanks,
michal


> 
> On Saturday, July 22, 2017 12:21:17 PM Michal Skrivanek wrote:
>>> On 20 Jul 2017, at 15:56, Marcel Hanke  wrote:
>>> 
>>> Hi,
>>> the Log is >400MB heres a part with the Errors.
>> 
>> ok
>> and which exact version do you have?
>> 
>>> thanks Marcel
>>> 
>>> On Thursday, July 20, 2017 02:43:57 PM Eli Mesika wrote:
 Hi
 
 Please attach full engine.log
 
 On Wed, Jul 19, 2017 at 12:33 PM, Marcel Hanke 
 
 wrote:
> Hi,
> i currently have a problem with changing one of our clusters to
> compatibility
> version 4.0.
> The Log shows a NullPointerException after several successful vms:
> 2017-07-19 11:19:45,886 ERROR
> [org.ovirt.engine.core.bll.UpdateVmCommand]
> (default task-31) [1acd2990] Error during ValidateFailure.:
> java.lang.NullPointerException
> 
>   at
> 
> org.ovirt.engine.core.bll.UpdateVmCommand.validate(
> UpdateVmCommand.java:632)
> [bll.jar:]
> 
>   at
> 
> org.ovirt.engine.core.bll.CommandBase.internalValidate(
> CommandBase.java:886)
> [bll.jar:]
> 
>   at
> 
> org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:391
> )
> [bll.jar:]
> 
>   at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:493)
> 
> [bll.jar:]
> .
> 
> On other Clusters with the exect same configuration the change to 4.0
> was
> successfull without a problem.
> Turning off the cluster for the change is also not possible because of
> 
>> 1200
> 
> Vms running on it.
> 
> Does anyone have an idea what to do, or that to look for?
> 
> Thanks
> Marcel
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>>> 
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] NullPointerException when changing compatibility version to 4.0

2017-07-23 Thread Marcel Hanke 
Hi,
i'm currently running on 4.0.6.3-1.el7.centos

On Saturday, July 22, 2017 12:21:17 PM Michal Skrivanek wrote:
> > On 20 Jul 2017, at 15:56, Marcel Hanke  wrote:
> > 
> > Hi,
> > the Log is >400MB heres a part with the Errors.
> 
> ok
> and which exact version do you have?
> 
> > thanks Marcel
> > 
> > On Thursday, July 20, 2017 02:43:57 PM Eli Mesika wrote:
> >> Hi
> >> 
> >> Please attach full engine.log
> >> 
> >> On Wed, Jul 19, 2017 at 12:33 PM, Marcel Hanke 
> >> 
> >> wrote:
> >>> Hi,
> >>> i currently have a problem with changing one of our clusters to
> >>> compatibility
> >>> version 4.0.
> >>> The Log shows a NullPointerException after several successful vms:
> >>> 2017-07-19 11:19:45,886 ERROR
> >>> [org.ovirt.engine.core.bll.UpdateVmCommand]
> >>> (default task-31) [1acd2990] Error during ValidateFailure.:
> >>> java.lang.NullPointerException
> >>> 
> >>>at
> >>> 
> >>> org.ovirt.engine.core.bll.UpdateVmCommand.validate(
> >>> UpdateVmCommand.java:632)
> >>> [bll.jar:]
> >>> 
> >>>at
> >>> 
> >>> org.ovirt.engine.core.bll.CommandBase.internalValidate(
> >>> CommandBase.java:886)
> >>> [bll.jar:]
> >>> 
> >>>at
> >>> 
> >>> org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:391
> >>> )
> >>> [bll.jar:]
> >>> 
> >>>at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:493)
> >>> 
> >>> [bll.jar:]
> >>> .
> >>> 
> >>> On other Clusters with the exect same configuration the change to 4.0
> >>> was
> >>> successfull without a problem.
> >>> Turning off the cluster for the change is also not possible because of
> >>> 
>  1200
> >>> 
> >>> Vms running on it.
> >>> 
> >>> Does anyone have an idea what to do, or that to look for?
> >>> 
> >>> Thanks
> >>> Marcel
> >>> ___
> >>> Users mailing list
> >>> Users@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/users
> > 
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ovirt-hosted-engine state transition messages

2017-07-23 Thread Christophe TREFOIS 
I have a similar pattern. But it usually works again for 1 week without 
restarting engine.



From: Darrell Budic [mailto:bu...@onholyground.com]
Sent: dimanche 23 juillet 2017 21:32
To: Christophe TREFOIS 
Cc: Jim Kusznir ; users 
Subject: Re: [ovirt-users] ovirt-hosted-engine state transition messages



This happened to me again, started last night so it was almost a week from the 
last restart. System was not out of memory, a bit low, and it may have been 
churning buffers or java GC, I’m on vacation and didn’t dig into it very far. 
Restarted the engine and it’s happy. DWH was still working, but web interface 
was a bit slow before the restart. This was 4.1.3 now. Added some ram to the 
Hosted Engine, but looks like I need to restart it and will probably wait until 
I’m back for that.





   On Jul 18, 2017, at 9:22 AM, Darrell Budic 
> wrote:



   I had some of this going on recently under 4.1.2, started with one or two 
warning messages, then a flood of them. Did the upgrade to 4.1.3 and haven’t 
seen it yet, but it’s only been a few days so far. A java process was consuming 
much CPU, and the DataWarehouse appears to not be collecting data (evidenced by 
a blank dashboard). My DWH has since recovered as well.



   I forgot to check, but suspect I was low/out of memory on my engine VM, it’s 
an old one with only 6G allocated currently. Watching for this to happen again, 
and will confirm RAM utilization and bump up appropriately if it looks like 
it’s starved for RAM.





  On Jul 18, 2017, at 5:45 AM, Christophe TREFOIS 
> wrote:



  I have the same as you on 4.1.0



  EngineBadHealth-EngineUp 1 minute later. Sometimes 20 times per day, 
mostly on weekends.



  Cheers,

  --

  Dr Christophe Trefois, Dipl.-Ing.
  Technical Specialist / Post-Doc

  UNIVERSITÉ DU LUXEMBOURG

  LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
  Campus Belval | House of Biomedicine
  6, avenue du Swing
  L-4367 Belvaux
  T: +352 46 66 44 6124
  F: +352 46 66 44 6949
  http://www.uni.lu/lcsb

     
   
   



  
  This message is confidential and may contain privileged information.
  It is intended for the named recipient only.
  If you receive it in error please notify me and permanently delete the 
original message and any copies.
  





 On 17 Jul 2017, at 17:35, Jim Kusznir 
> wrote:



 Ok, I've been ignoring this for a long time as the logs were so 
verbose and didn't show anything I could identify as usable debug info.  
Recently one of my ovirt hosts (currently NOT running the main engine, but a 
candidate) was cycling as much as 40 times a day between "EngineUpBadHealth and 
EngineUp".  Here's the log snippit.  I included some time before and after if 
that's helpful.  In this case, I got an email about bad health at 8:15 and a 
restore (engine up) at 8:16.  I see where the messages are sent, but I don't 
see any explanation as to why / what the problem is.



 BTW: 192.168.8.11 is this computer's physical IP; 192.168.8.12 is the 
computer currently running the engine.  Both are also hosting the gluster store 
(eg, I have 3 hosts, all are participating in the gluster replica 2+arbitrator).



 I'd appreciate it if someone could shed some light on why this keeps 
happening!



 --Jim

 



 MainThread::INFO::2017-07-17 
08:12:06,230::config::485::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_vm_conf)
 Reloading vm.conf from the shared storage domain

 MainThread::INFO::2017-07-17 
08:12:06,230::config::412::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(_get_vm_conf_content_from_ovf_store)
 Trying to get a fresher copy of vm configuration from the OVF_STORE

 MainThread::INFO::2017-07-17 
08:12:08,877::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
 Found OVF_STORE: imgUUID:e10c90a5-4d9c-4e18-b6f7-ae8f0cdf4f57, 
volUUID:a9754d40-eda1-44d7-ac92-76a228f9f1ac

 MainThread::INFO::2017-07-17 
08:12:09,432::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
 Found OVF_STORE: imgUUID:f22829ab-9fd5-415a-9a8f-809d3f7887d4, 
volUUID:9f4760ee-119c-412a-a1e8-49e73e6ba929

 MainThread::INFO::2017-07-17 
08:12:09,925::ovf_store::112::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
 Extracting Engine VM OVF from the OVF_STORE

 MainThread::INFO::2017-07-17

Re: [ovirt-users] ovirt-hosted-engine state transition messages

2017-07-23 Thread Darrell Budic 
This happened to me again, started last night so it was almost a week from the 
last restart. System was not out of memory, a bit low, and it may have been 
churning buffers or java GC, I’m on vacation and didn’t dig into it very far. 
Restarted the engine and it’s happy. DWH was still working, but web interface 
was a bit slow before the restart. This was 4.1.3 now. Added some ram to the 
Hosted Engine, but looks like I need to restart it and will probably wait until 
I’m back for that.


> On Jul 18, 2017, at 9:22 AM, Darrell Budic  wrote:
> 
> I had some of this going on recently under 4.1.2, started with one or two 
> warning messages, then a flood of them. Did the upgrade to 4.1.3 and haven’t 
> seen it yet, but it’s only been a few days so far. A java process was 
> consuming much CPU, and the DataWarehouse appears to not be collecting data 
> (evidenced by a blank dashboard). My DWH has since recovered as well.
> 
> I forgot to check, but suspect I was low/out of memory on my engine VM, it’s 
> an old one with only 6G allocated currently. Watching for this to happen 
> again, and will confirm RAM utilization and bump up appropriately if it looks 
> like it’s starved for RAM.
> 
> 
>> On Jul 18, 2017, at 5:45 AM, Christophe TREFOIS > > wrote:
>> 
>> I have the same as you on 4.1.0
>> 
>> EngineBadHealth-EngineUp 1 minute later. Sometimes 20 times per day, mostly 
>> on weekends.
>> 
>> Cheers,
>> -- 
>> 
>> Dr Christophe Trefois, Dipl.-Ing.  
>> Technical Specialist / Post-Doc
>> 
>> UNIVERSITÉ DU LUXEMBOURG
>> 
>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
>> Campus Belval | House of Biomedicine  
>> 6, avenue du Swing 
>> L-4367 Belvaux  
>> T: +352 46 66 44 6124 
>> F: +352 46 66 44 6949  
>> http://www.uni.lu/lcsb 
>>        
>>    
>>    
>> 
>> 
>> This message is confidential and may contain privileged information. 
>> It is intended for the named recipient only. 
>> If you receive it in error please notify me and permanently delete the 
>> original message and any copies. 
>> 
>>   
>> 
>>> On 17 Jul 2017, at 17:35, Jim Kusznir >> > wrote:
>>> 
>>> Ok, I've been ignoring this for a long time as the logs were so verbose and 
>>> didn't show anything I could identify as usable debug info.  Recently one 
>>> of my ovirt hosts (currently NOT running the main engine, but a candidate) 
>>> was cycling as much as 40 times a day between "EngineUpBadHealth and 
>>> EngineUp".  Here's the log snippit.  I included some time before and after 
>>> if that's helpful.  In this case, I got an email about bad health at 8:15 
>>> and a restore (engine up) at 8:16.  I see where the messages are sent, but 
>>> I don't see any explanation as to why / what the problem is.
>>> 
>>> BTW: 192.168.8.11 is this computer's physical IP; 192.168.8.12 is the 
>>> computer currently running the engine.  Both are also hosting the gluster 
>>> store (eg, I have 3 hosts, all are participating in the gluster replica 
>>> 2+arbitrator).
>>> 
>>> I'd appreciate it if someone could shed some light on why this keeps 
>>> happening!
>>> 
>>> --Jim
>>> 
>>> 
>>> MainThread::INFO::2017-07-17 
>>> 08:12:06,230::config::485::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_vm_conf)
>>>  Reloading vm.conf from the shared storage domain
>>> MainThread::INFO::2017-07-17 
>>> 08:12:06,230::config::412::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(_get_vm_conf_content_from_ovf_store)
>>>  Trying to get a fresher copy of vm configuration from the OVF_STORE
>>> MainThread::INFO::2017-07-17 
>>> 08:12:08,877::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
>>>  Found OVF_STORE: imgUUID:e10c90a5-4d9c-4e18-b6f7-ae8f0cdf4f57, 
>>> volUUID:a9754d40-eda1-44d7-ac92-76a228f9f1ac
>>> MainThread::INFO::2017-07-17 
>>> 08:12:09,432::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan)
>>>  Found OVF_STORE: imgUUID:f22829ab-9fd5-415a-9a8f-809d3f7887d4, 
>>> volUUID:9f4760ee-119c-412a-a1e8-49e73e6ba929
>>> MainThread::INFO::2017-07-17 
>>> 08:12:09,925::ovf_store::112::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
>>>  Extracting Engine VM OVF from the OVF_STORE
>>> MainThread::INFO::2017-07-17 
>>> 08:12:10,324::ovf_store::119::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF)
>>>  OVF_STORE volume path: 
>>> /rhev/data-center/mnt/glusterSD/192.168.8.11:_engine/c0acdefb-7d16-48ec-9d76-659b8fe33e2a/images/f22829ab-9fd5-415a-9a8f-809d3f7887d4/9f4760ee-119c-412a-a1e8-49e73e6ba929
>>>  
>>> MainThread::INFO::2017-07-17 
>>>

Re: [ovirt-users] Problemas with ovirtmgmt network used to connect VMs

2017-07-23 Thread Edward Haas 
Have you tried to use tcpdump at the VM vNIC to examine if there is traffic
trying to get out from there? And with what source mac address?

Thanks,
Edy,

On Fri, Jul 21, 2017 at 5:36 PM, FERNANDO FREDIANI <
fernando.fredi...@upx.com> wrote:

> Has anyone had problem when using the ovirtmgmt bridge to connect VMs ?
>
> I am still facing a bizarre problem where some VMs connected to this
> bridge stop passing traffic. Checking the problem further I see its mac
> address stops being learned by the bridge and the problem is resolved only
> with a VM reboot.
>
> When I last saw the problem I run brctl showmacs ovirtmgmt and it shows me
> the VM's mac adress with agening timer 200.19. After the VM reboot I see
> the same mac with agening timer 0.00.
> I don't see it in another environment where the ovirtmgmt is not used for
> VMs.
>
> Does anyone have any clue about this type of behavior ?
>
> Fernando
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users