Re: [ovirt-users] Dedicated NICs for gluster network

2015-11-27 Thread Ivan Bulatovic 

Hi Nicolas,

what works for me in 3.6 is creating a new network for gluster within 
oVirt, marking it for gluster use only, optionally setting bonded 
interface upon NIC's that are dedicated for gluster traffic and 
providing it with an IP address without configuring a gateway, and then 
modifying /etc/hosts so that hostnames are resolvable between nodes. 
Every node should have two hostnames, one for ovirtmgmt network that is 
resolvable via DNS (or via /etc/hosts), and the other for gluster 
network that is resolvable purely via /etc/hosts (every node should 
contain entries for themselves and for each gluster node).


Peers should be probed via their gluster hostnames, while ensuring that 
gluster peer status contains only addresses and hostnames that are 
dedicated for gluster on each node. Same goes for adding bricks, 
creating a volume etc.


This way, no communication (except gluster one) should be allowed 
through gluster dedicated vlan. To be on the safe side, we can also 
force gluster to listen only on dedicated interfaces via 
transport.socket.bind-address option (haven't tried this one, will do).


Separation of gluster (or in the future any storage network), live 
migration network, vm and management network is always a good thing. 
Perhaps, we could manage failover of those networks within oVirt, ie. in 
case lm network is down - use gluster network for lm and vice versa. 
Cool candidate for an RFE, but first we need this supported within 
gluster itself. This may prove useful when there is not enough NIC's 
available to do a bond beneath every defined network. But we can still 
separate traffic and provide failover by selecting multiple networks 
without actually doing any load balancing between the two.


As Nathanaël mentioned, marking network for gluster use is only 
available in 3.6. I'm also interested if there is a better way around 
this procedure, or perharps enhancing it.


Kind regards,

Ivan

On 11/27/2015 05:47 PM, Nathanaël Blanchet wrote:

Hello Nicolas,

Did you have a look to this : 
http://www.ovirt.org/Features/Select_Network_For_Gluster ?

But it is only available from >=3.6...

Le 27/11/2015 17:02, Nicolas Ecarnot a écrit :

Hello,

[Here : oVirt 3.5.3, 3 x CentOS 7.0 hosts with replica-3 gluster SD 
on the hosts].


On the switchs, I have created a dedicated VLAN to isolate the 
glusterFS traffic, but I'm not using it yet.
I was thinking of creating a dedicated IP for each node's gluster 
NIC, and a DNS record by the way ("my_nodes_name_GL"), but I fear 
using this hostname or this ip in oVirt GUI host network interface 
tab, leading oVirt think this is a different host.


Not being sure this fear is clearly described, let's say :
- On each node, I create a second ip+(dns record in the soa) used by 
gluster, plugged on the correct VLAN
- in oVirt gui, in the host network setting tab, the interface will 
be seen, with its ip, but reverse-dns-related to a different hostname.
Here, I fear oVirt might check this reverse DNS and declare this NIC 
belongs to another host.


I would also prefer not use a reverse pointing to the name of the 
host management ip, as this is evil and I'm a good guy.


On your side, how do you cope with a dedicated storage network in 
case of storage+compute mixed hosts?






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

[ovirt-users] Dedicated NICs for gluster network

2015-11-27 Thread Nicolas Ecarnot 

Hello,

[Here : oVirt 3.5.3, 3 x CentOS 7.0 hosts with replica-3 gluster SD on 
the hosts].


On the switchs, I have created a dedicated VLAN to isolate the glusterFS 
traffic, but I'm not using it yet.
I was thinking of creating a dedicated IP for each node's gluster NIC, 
and a DNS record by the way ("my_nodes_name_GL"), but I fear using this 
hostname or this ip in oVirt GUI host network interface tab, leading 
oVirt think this is a different host.


Not being sure this fear is clearly described, let's say :
- On each node, I create a second ip+(dns record in the soa) used by 
gluster, plugged on the correct VLAN
- in oVirt gui, in the host network setting tab, the interface will be 
seen, with its ip, but reverse-dns-related to a different hostname.
Here, I fear oVirt might check this reverse DNS and declare this NIC 
belongs to another host.


I would also prefer not use a reverse pointing to the name of the host 
management ip, as this is evil and I'm a good guy.


On your side, how do you cope with a dedicated storage network in case 
of storage+compute mixed hosts?


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

Re: [ovirt-users] Dedicated NICs for gluster network

2015-11-27 Thread Nathanaël Blanchet 

Hello Nicolas,

Did you have a look to this : 
http://www.ovirt.org/Features/Select_Network_For_Gluster ?

But it is only available from >=3.6...

Le 27/11/2015 17:02, Nicolas Ecarnot a écrit :

Hello,

[Here : oVirt 3.5.3, 3 x CentOS 7.0 hosts with replica-3 gluster SD on 
the hosts].


On the switchs, I have created a dedicated VLAN to isolate the 
glusterFS traffic, but I'm not using it yet.
I was thinking of creating a dedicated IP for each node's gluster NIC, 
and a DNS record by the way ("my_nodes_name_GL"), but I fear using 
this hostname or this ip in oVirt GUI host network interface tab, 
leading oVirt think this is a different host.


Not being sure this fear is clearly described, let's say :
- On each node, I create a second ip+(dns record in the soa) used by 
gluster, plugged on the correct VLAN
- in oVirt gui, in the host network setting tab, the interface will be 
seen, with its ip, but reverse-dns-related to a different hostname.
Here, I fear oVirt might check this reverse DNS and declare this NIC 
belongs to another host.


I would also prefer not use a reverse pointing to the name of the host 
management ip, as this is evil and I'm a good guy.


On your side, how do you cope with a dedicated storage network in case 
of storage+compute mixed hosts?




--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

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

Re: [ovirt-users] Strange permissions on Hosted Engine HA Agent log files

2015-11-27 Thread Simone Tiraboschi 
On Wed, Nov 25, 2015 at 11:53 PM, Giuseppe Ragusa <
giuseppe.rag...@hotmail.com> wrote:

> Hi all,
> I'm installing oVirt (3.6) in self-hosted mode, hyperconverged with
> GlusterFS (3.7.6).
>
> I'm using the oVirt snapshot generated the night between the 18th and 19th
> of November, 2015.
>
> The (single, at the moment) host and the Engine are both CentOS 7.1 fully
> up-to-date.
>
> After ovirt-hosted-engine-setup successful completion, I found the
> following (about 3 days after setup completed) "anomalies":
>
> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log
> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log.2015-11-23
> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log
> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log.2015-11-23
>
> The listing above comes from a custom security checking script that gives:
>
> "octal permissions" "number of links" "owner" "group" - "absolute pathname"
>
> Is the ominous "666" mark actually intended/necessary? ;-)
>

Thanks for the report Giuseppe, I double checked on one of my test systems.

[root@c71het20151028 ~]# ls -l /var/log/ovirt-hosted-engine-ha/*
-rw-r--r--. 1 root root10136 Nov 27 18:08
/var/log/ovirt-hosted-engine-ha/agent.log
-rw-r--r--. 1 root root  1769029 Oct 29 17:20
/var/log/ovirt-hosted-engine-ha/agent.log.2015-10-28
-rw-rw-rw-. 1 vdsm kvm 97685 Oct 29 18:21
/var/log/ovirt-hosted-engine-ha/agent.log.2015-10-29
-rw-r--r--. 1 root root  3620102 Nov 25 12:09
/var/log/ovirt-hosted-engine-ha/agent.log.2015-11-24
-rw-rw-rw-. 1 vdsm kvm715086 Nov 25 17:01
/var/log/ovirt-hosted-engine-ha/agent.log.2015-11-25
-rw-r--r--. 1 root root13904 Nov 27 18:09
/var/log/ovirt-hosted-engine-ha/broker.log
-rw-r--r--. 1 root root  9711872 Oct 29 17:20
/var/log/ovirt-hosted-engine-ha/broker.log.2015-10-28
-rw-rw-rw-. 1 vdsm kvm468475 Oct 29 18:21
/var/log/ovirt-hosted-engine-ha/broker.log.2015-10-29
-rw-r--r--. 1 root root 14066693 Nov 25 12:09
/var/log/ovirt-hosted-engine-ha/broker.log.2015-11-24
-rw-rw-rw-. 1 vdsm kvm   4505277 Nov 25 17:01
/var/log/ovirt-hosted-engine-ha/broker.log.2015-11-25


So I've something 644 root:root and something at 666 vdsm:kvm depending
from the rotation date (???).
The directory is 700 vdsm:kvm so it's not really an issue but I think it's
still worth to open a bug on that.



> Do I need to open a bugzilla notification for this?
>
> Many thanks in advance for your attention.
>
> Regards,
> Giuseppe
> ___
> 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] timeouts

2015-11-27 Thread p...@email.cz 

Hi,
all glusterd daemons was runnig correctly at this time, no 
firewalls/iptables restrictions

But  "not connected" bricks are changing during the time without any touch .
It looks that glusterd  has non-stable cross  communication , especially 
with different LAN range  as nodes in Ovirt environmet

( Volumes bricks in 16.0.0.0 net and ovirt nodes in 172.0.0.0 net )
So I desided reinstall whole cluster, but I'm afraid that these problems 
will occure again - will you know


regs.for your answers
Pavel

On 27.11.2015 10:16, knarra wrote:

On 11/27/2015 11:04 AM, knarra wrote:

Hi Paf1,

Looks like when you reboot the nodes, glusterd does not start up 
in one node and due to this the node gets disconnected from other 
node(that is what i see from logs). After reboot, once your systems 
are up and running , can you check if glusterd is running on all the 
nodes? Can you please let me know which build of gluster are you using ?


For more info please read, 
http://www.gluster.org/pipermail/gluster-users.old/2015-June/022377.html 
- (please ignore this line)




Thanks
kasturi

On 11/27/2015 10:52 AM, Sahina Bose wrote:

[+ gluster-users]

On 11/26/2015 08:37 PM, p...@email.cz wrote:

Hello,
can anybody  help me with this timeouts ??
Volumes are not active yes ( bricks down )

desc. of gluster bellow ...

*/var/log/glusterfs/**etc-glusterfs-glusterd.vol.log*
[2015-11-26 14:44:47.174221] I [MSGID: 106004] 
[glusterd-handler.c:5065:__glusterd_peer_rpc_notify] 0-management: 
Peer <1hp1-SAN> (<87fc7db8-aba8-41f2-a1cd-b77e83b17436>), in state 
, has disconnected from glusterd.
[2015-11-26 14:44:47.174354] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 1HP12-P1 not held
[2015-11-26 14:44:47.17] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 1HP12-P3 not held
[2015-11-26 14:44:47.174521] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 2HP12-P1 not held
[2015-11-26 14:44:47.174662] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 2HP12-P3 not held
[2015-11-26 14:44:47.174532] W [MSGID: 106118] 
[glusterd-handler.c:5087:__glusterd_peer_rpc_notify] 0-management: 
Lock not released for 2HP12-P1
[2015-11-26 14:44:47.174675] W [MSGID: 106118] 
[glusterd-handler.c:5087:__glusterd_peer_rpc_notify] 0-management: 
Lock not released for 2HP12-P3
[2015-11-26 14:44:49.423334] I [MSGID: 106488] 
[glusterd-handler.c:1472:__glusterd_handle_cli_get_volume] 
0-glusterd: Received get vol req
The message "I [MSGID: 106488] 
[glusterd-handler.c:1472:__glusterd_handle_cli_get_volume] 
0-glusterd: Received get vol req" repeated 4 times between 
[2015-11-26 14:44:49.423334] and [2015-11-26 14:44:49.429781]
[2015-11-26 14:44:51.148711] I [MSGID: 106163] 
[glusterd-handshake.c:1193:__glusterd_mgmt_hndsk_versions_ack] 
0-management: using the op-version 30702
[2015-11-26 14:44:52.177266] W [socket.c:869:__socket_keepalive] 
0-socket: failed to set TCP_USER_TIMEOUT -1000 on socket 12, 
Invalid argument
[2015-11-26 14:44:52.177291] E [socket.c:2965:socket_connect] 
0-management: Failed to set keep-alive: Invalid argument
[2015-11-26 14:44:53.180426] W [socket.c:869:__socket_keepalive] 
0-socket: failed to set TCP_USER_TIMEOUT -1000 on socket 17, 
Invalid argument
[2015-11-26 14:44:53.180447] E [socket.c:2965:socket_connect] 
0-management: Failed to set keep-alive: Invalid argument
[2015-11-26 14:44:52.395468] I [MSGID: 106163] 
[glusterd-handshake.c:1193:__glusterd_mgmt_hndsk_versions_ack] 
0-management: using the op-version 30702
[2015-11-26 14:44:54.851958] I [MSGID: 106488] 
[glusterd-handler.c:1472:__glusterd_handle_cli_get_volume] 
0-glusterd: Received

Re: [ovirt-users] HA cluster

2015-11-27 Thread Maxim Kovgan 
Maybe even makes sense to open a bugzilla ticket already. Better safe than
sorry.
On Nov 27, 2015 11:35 AM, "Simone Tiraboschi"  wrote:

>
> On Fri, Nov 27, 2015 at 10:10 AM, Budur Nagaraju 
> wrote:
>
>> I do not know what logs you are expecting ? the logs which I got is
>> pasted in the mail if you require in pastebin let me know I will upload
>> there .
>>
>
>
> Please run sosreport utility and share the resulting archive where you
> prefer.
> You can follow this guide:
> http://www.linuxtechi.com/how-to-create-sosreport-in-linux/
>
>>
>>
>> On Fri, Nov 27, 2015 at 1:58 PM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 27, 2015 at 8:34 AM, Budur Nagaraju 
>>> wrote:
>>>
 I got only 10lines to in the vdsm logs and are below ,


>>> Can you please provide full sos report?
>>>
>>>
>>>

 [root@he /]# tail -f /var/log/vdsm/vdsm.log
 Thread-100::DEBUG::2015-11-27
 12:58:57,360::resourceManager::616::Storage.ResourceManager::(releaseResource)
 Trying to release resource 'Storage.HsmDomainMonitorLock'
 Thread-100::DEBUG::2015-11-27
 12:58:57,360::resourceManager::635::Storage.ResourceManager::(releaseResource)
 Released resource 'Storage.HsmDomainMonitorLock' (0 active users)
 Thread-100::DEBUG::2015-11-27
 12:58:57,360::resourceManager::641::Storage.ResourceManager::(releaseResource)
 Resource 'Storage.HsmDomainMonitorLock' is free, finding out if anyone is
 waiting for it.
 Thread-100::DEBUG::2015-11-27
 12:58:57,360::resourceManager::649::Storage.ResourceManager::(releaseResource)
 No one is waiting for resource 'Storage.HsmDomainMonitorLock', Clearing
 records.
 Thread-100::INFO::2015-11-27
 12:58:57,360::logUtils::47::dispatcher::(wrapper) Run and protect:
 stopMonitoringDomain, Return response: None
 Thread-100::DEBUG::2015-11-27
 12:58:57,361::task::1191::Storage.TaskManager.Task::(prepare)
 Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::finished: None
 Thread-100::DEBUG::2015-11-27
 12:58:57,361::task::595::Storage.TaskManager.Task::(_updateState)
 Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::moving from state preparing ->
 state finished
 Thread-100::DEBUG::2015-11-27
 12:58:57,361::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll)
 Owner.releaseAll requests {} resources {}
 Thread-100::DEBUG::2015-11-27
 12:58:57,361::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll)
 Owner.cancelAll requests {}
 Thread-100::DEBUG::2015-11-27
 12:58:57,361::task::993::Storage.TaskManager.Task::(_decref)
 Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::ref 0 aborting False



 On Thu, Nov 26, 2015 at 4:20 PM, Simone Tiraboschi  wrote:

>
>
> On Thu, Nov 26, 2015 at 11:05 AM, Budur Nagaraju 
> wrote:
>
>>
>>
>>
>> *Below are the entire logs*
>>
>>
> Sorry, with the entire log I mean if you can attach or share somewhere
> the whole /var/log/vdsm/vdsm.log  cause the latest ten lines are not 
> enough
> to point out the issue.
>
>
>>
>>
>>
>>
>> *[root@he ~]# tail -f /var/log/vdsm/vdsm.log *
>>
>> Detector thread::DEBUG::2015-11-26
>> 15:16:05,622::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>> Detected protocol xml from 127.0.0.1:50944
>> Detector thread::DEBUG::2015-11-26
>> 15:16:05,623::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>> http detected from ('127.0.0.1', 50944)
>> Detector thread::DEBUG::2015-11-26
>> 15:16:05,703::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
>> Adding connection from 127.0.0.1:50945
>> Detector thread::DEBUG::2015-11-26
>> 15:16:06,101::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
>> Connection removed from 127.0.0.1:50945
>> Detector thread::DEBUG::2015-11-26
>> 15:16:06,101::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>> Detected protocol xml from 127.0.0.1:50945
>> Detector thread::DEBUG::2015-11-26
>> 15:16:06,101::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>> http detected from ('127.0.0.1', 50945)
>> Detector thread::DEBUG::2015-11-26
>> 15:16:06,182::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
>> Adding connection from 127.0.0.1:50946
>> Detector thread::DEBUG::2015-11-26
>> 15:16:06,710::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
>> Connection removed from 127.0.0.1:50946
>> Detector thread::DEBUG::2015-11-26
>> 15:16:06,711::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>> Detected protocol xml from 127.0.0.1:50946
>> Detector

Re: [ovirt-users] Windows 10

2015-11-27 Thread Raymond 
I use Win10 since 3.5.4 on CentOS6 

Today I upgraded to 3.5.5 -> 3.6 
Tried it and boots previous machine fine, installs new machine also fine 

kind regards 
Raymond 




From: "Koen Vanoppen"  
To: "Yaniv Dary"  
Cc: "users"  
Sent: Friday, November 27, 2015 7:14:11 AM 
Subject: Re: [ovirt-users] Windows 10 

Thanks! 

On 26 November 2015 at 16:27, Yaniv Dary < yd...@redhat.com > wrote: 



Windows 10 guest will only work on 3.6 with fedora or el7.2 hosts. Might work 
with el6 as some point. but currently doesn't. 

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306 8272306
Email: yd...@redhat.com IRC : ydary 

On Tue, Oct 6, 2015 at 8:53 AM, Koen Vanoppen < vanoppen.k...@gmail.com > 
wrote: 

BQ_BEGIN

Dear all, 

Yes, onther question :-). This time it's about windows 10. 
I'm running ovirt 3.5.4 and I don't manage to install windows 10 on it. Keeps 
giving me a blue screen (yes, I know, it's still a windows... ;-) ) on reboot. 

Are there any special settings you need to enable when creating the vm? Which 
OS do I need to select? Or shall I just wait untile the relase of ovirt 3.6 :-) 
? 

Kind regards, 

Koen 

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






BQ_END



___ 
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] HA cluster

2015-11-27 Thread Simone Tiraboschi 
On Fri, Nov 27, 2015 at 12:42 PM, Maxim Kovgan  wrote:

> Maybe even makes sense to open a bugzilla ticket already. Better safe than
> sorry.
>

We still need at least one log file to understand what happened.


> On Nov 27, 2015 11:35 AM, "Simone Tiraboschi"  wrote:
>
>>
>> On Fri, Nov 27, 2015 at 10:10 AM, Budur Nagaraju 
>> wrote:
>>
>>> I do not know what logs you are expecting ? the logs which I got is
>>> pasted in the mail if you require in pastebin let me know I will upload
>>> there .
>>>
>>
>>
>> Please run sosreport utility and share the resulting archive where you
>> prefer.
>> You can follow this guide:
>> http://www.linuxtechi.com/how-to-create-sosreport-in-linux/
>>
>>>
>>>
>>> On Fri, Nov 27, 2015 at 1:58 PM, Sandro Bonazzola 
>>> wrote:
>>>


 On Fri, Nov 27, 2015 at 8:34 AM, Budur Nagaraju 
 wrote:

> I got only 10lines to in the vdsm logs and are below ,
>
>
 Can you please provide full sos report?



>
> [root@he /]# tail -f /var/log/vdsm/vdsm.log
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::616::Storage.ResourceManager::(releaseResource)
> Trying to release resource 'Storage.HsmDomainMonitorLock'
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::635::Storage.ResourceManager::(releaseResource)
> Released resource 'Storage.HsmDomainMonitorLock' (0 active users)
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::641::Storage.ResourceManager::(releaseResource)
> Resource 'Storage.HsmDomainMonitorLock' is free, finding out if anyone is
> waiting for it.
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::649::Storage.ResourceManager::(releaseResource)
> No one is waiting for resource 'Storage.HsmDomainMonitorLock', Clearing
> records.
> Thread-100::INFO::2015-11-27
> 12:58:57,360::logUtils::47::dispatcher::(wrapper) Run and protect:
> stopMonitoringDomain, Return response: None
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::task::1191::Storage.TaskManager.Task::(prepare)
> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::finished: None
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::task::595::Storage.TaskManager.Task::(_updateState)
> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::moving from state preparing 
> ->
> state finished
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll)
> Owner.releaseAll requests {} resources {}
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll)
> Owner.cancelAll requests {}
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::task::993::Storage.TaskManager.Task::(_decref)
> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::ref 0 aborting False
>
>
>
> On Thu, Nov 26, 2015 at 4:20 PM, Simone Tiraboschi <
> stira...@redhat.com> wrote:
>
>>
>>
>> On Thu, Nov 26, 2015 at 11:05 AM, Budur Nagaraju 
>> wrote:
>>
>>>
>>>
>>>
>>> *Below are the entire logs*
>>>
>>>
>> Sorry, with the entire log I mean if you can attach or share
>> somewhere the whole /var/log/vdsm/vdsm.log  cause the latest ten lines 
>> are
>> not enough to point out the issue.
>>
>>
>>>
>>>
>>>
>>>
>>> *[root@he ~]# tail -f /var/log/vdsm/vdsm.log *
>>>
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:05,622::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>>> Detected protocol xml from 127.0.0.1:50944
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:05,623::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>>> http detected from ('127.0.0.1', 50944)
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:05,703::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
>>> Adding connection from 127.0.0.1:50945
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,101::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
>>> Connection removed from 127.0.0.1:50945
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,101::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>>> Detected protocol xml from 127.0.0.1:50945
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,101::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>>> http detected from ('127.0.0.1', 50945)
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,182::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
>>> Adding connection from 127.0.0.1:50946
>>> Detector thread::DEBUG::2015-11-26
>>>

[ovirt-users] hosted engine vm.conf missing

2015-11-27 Thread Thomas Scofield 
I have recently setup a ovirt hosted engine on iscsi storage and after a
reboot of the system I am unable to start the hosted engine.  The agent.log
gives errors indicating there is a missing value in the vm.conf file, but
the vm.conf file does not appear in the location indicated.  There is no
error indicated when the agent attempts to reload the vm.conf.  Any ideas
on how to get the hosted engine up and running?

MainThread::INFO::2015-11-26
21:31:13,071::hosted_engine::699::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_sanlock)
Ensuring lease for lockspace hosted-engine, host id 1 is acquired (file:
/var/run/vdsm/storage/ddf4a26b-61ff-49a4-81db-9f82da35e44b/6ed6d868-aaf3-4b3f-bdf0-a4ad262709ae/1fe5b7fc-eae7-4f07-a2fe-5a082e14c876)
MainThread::INFO::2015-11-26
21:31:13,072::upgrade::836::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(upgrade)
Host configuration is already up-to-date
MainThread::INFO::2015-11-26
21:31:13,072::hosted_engine::422::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
Reloading vm.conf from the shared storage domain
MainThread::ERROR::2015-11-26
21:31:13,100::agent::205::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent)
Error: ''Configuration value not found:
file=/var/run/ovirt-hosted-engine-ha/vm.conf,
key=memSize'' - trying to restart agent
MainThread::WARNING::2015-11-26
21:31:18,105::agent::208::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent)
Restarting agent, attempt '9'
MainThread::ERROR::2015-11-26
21:31:18,106::agent::210::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent)
Too many errors occurred, giving up. Please review the log and consider
filing a bug.
MainThread::INFO::2015-11-26
21:31:18,106::agent::143::ovirt_hosted_engine_ha.agent.agent.Agent::(run)
Agent shutting down
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Updated Invitation: [Deep dive] Host Network QoS - oVirt 3.6 @ Thu Nov 26, 2015 5pm - 6pm (ibar...@redhat.com)

2015-11-27 Thread Gervais de Montbrun 
Did this event date change? I tried to participate and it never seemed to 
start. If it was recorded, I'd love the link.

Cheers,
Gervais

> On Nov 24, 2015, at 9:08 AM, ibar...@redhat.com wrote:
> 
> This event has been changed.
> more details »
> [Deep dive] Host Network QoS - oVirt 3.6
> Hangouts on air: https://plus.google.com/events/c3la9vdse911atq991qflogtq0g
> you tube link: https://plus.google.com/events/c3la9vdse911atq991qflogtq0g
> When
> Changed: Thu Nov 26, 2015 5pm – 6pm Jerusalem
> Calendar
> ibar...@redhat.com
> Who
> • 
> ibar...@redhat.com - organizer
> • 
> users@ovirt.org
> Going?   Yes - Maybe - Nomore options »
> Invitation from Google Calendar
> 
> You are receiving this courtesy email at the account users@ovirt.org because 
> you are an attendee of this event.
> 
> To stop receiving future updates for this event, decline this event. 
> Alternatively you can sign up for a Google account at 
> https://www.google.com/calendar/ and control your notification settings for 
> your entire calendar.
> 
> Forwarding this invitation could allow any recipient to modify your RSVP 
> response. Learn More.
> 
>  Attachment.ics>___
> 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] vdsm using 100% CPU, rapidly filling logs with _handle_event messages

2015-11-27 Thread Robert Story 
On Wed, 18 Nov 2015 07:28:23 -0500 Robert wrote:
RS> On Wed, 18 Nov 2015 12:35:17 +0100 Vinzenz wrote:
RS> VF> On 11/12/2015 03:16 PM, Robert Story wrote:
RS> VF> > On Thu, 12 Nov 2015 16:02:59 +0200 Dan wrote:
RS> VF> > DK> On Thu, Nov 12, 2015 at 08:45:43AM -0500, Robert Story wrote:
RS> VF> > DK> > I'm running oVirt 3.5.x with a hosted engine. This morning I
RS> VF> > DK> > noticed that 2 of my 5 hosts were showing 99-100% cpu usage.
RS> VF> > DK> > Logging in to them, vdsmd seemed to be the culprit, and it
RS> VF> > DK> > was filling the log file with these messages:
RS> VF> > DK>
RS> VF> > DK> You're probably seeing
RS> VF> > DK> Bug 1226911 - vmchannel thread consumes 100% of CPU
RS> VF> > DK>
RS> VF> > DK> which was closed due to missing information. Do you have any
RS> VF> > DK> information on when this pops up? Is it reproducible? Would
RS> VF> > DK> you be bale to test a suggested patch
RS> VF> > DK>
RS> VF> > DK> https://gerrit.ovirt.org/#/c/42570/
RS> VF> >
RS> VF> > Hi Dan,
RS> VF> >
RS> VF> > Thanks for the pointers. If it comes up again, I'll try this
RS> VF> > patch and report back on the bug...
RS> VF> >
RS> VF> Out of curiosity, did you happen again to see that happening again?
RS> 
RS> No, I have not.

So naturally it shows up again during a holiday. I came in today to find 1
of my 5 nodes (the SPM and host where hosted engine is running) with two
vdsmd threads chewing up 90-100% of the CPU. I applied the patch from above
and restarted vdsmd. This resulted in another node being selected as the
SPM, and within about 15 minutes, that node had the same issue. Applied the
patch to the new node, and restarted vdsmd, and the SPM went back to the
previous (now patched) node. Hopefully things will stay stable.

I've attached snippets of the logs from the SPM when the problem started,
along with the server/engine log snippets from the hosted engine around the
same time..




Robert

-- 
Senior Software Engineer @ Parsons


vdsm-runaway.tgz
Description: application/compressed-tar


pgpT38OiTML4U.pgp
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] HA cluster

2015-11-27 Thread Simone Tiraboschi 
On Fri, Nov 27, 2015 at 10:10 AM, Budur Nagaraju  wrote:

> I do not know what logs you are expecting ? the logs which I got is pasted
> in the mail if you require in pastebin let me know I will upload there .
>


Please run sosreport utility and share the resulting archive where you
prefer.
You can follow this guide:
http://www.linuxtechi.com/how-to-create-sosreport-in-linux/

>
>
> On Fri, Nov 27, 2015 at 1:58 PM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Fri, Nov 27, 2015 at 8:34 AM, Budur Nagaraju 
>> wrote:
>>
>>> I got only 10lines to in the vdsm logs and are below ,
>>>
>>>
>> Can you please provide full sos report?
>>
>>
>>
>>>
>>> [root@he /]# tail -f /var/log/vdsm/vdsm.log
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,360::resourceManager::616::Storage.ResourceManager::(releaseResource)
>>> Trying to release resource 'Storage.HsmDomainMonitorLock'
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,360::resourceManager::635::Storage.ResourceManager::(releaseResource)
>>> Released resource 'Storage.HsmDomainMonitorLock' (0 active users)
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,360::resourceManager::641::Storage.ResourceManager::(releaseResource)
>>> Resource 'Storage.HsmDomainMonitorLock' is free, finding out if anyone is
>>> waiting for it.
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,360::resourceManager::649::Storage.ResourceManager::(releaseResource)
>>> No one is waiting for resource 'Storage.HsmDomainMonitorLock', Clearing
>>> records.
>>> Thread-100::INFO::2015-11-27
>>> 12:58:57,360::logUtils::47::dispatcher::(wrapper) Run and protect:
>>> stopMonitoringDomain, Return response: None
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,361::task::1191::Storage.TaskManager.Task::(prepare)
>>> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::finished: None
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,361::task::595::Storage.TaskManager.Task::(_updateState)
>>> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::moving from state preparing ->
>>> state finished
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,361::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll)
>>> Owner.releaseAll requests {} resources {}
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,361::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll)
>>> Owner.cancelAll requests {}
>>> Thread-100::DEBUG::2015-11-27
>>> 12:58:57,361::task::993::Storage.TaskManager.Task::(_decref)
>>> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::ref 0 aborting False
>>>
>>>
>>>
>>> On Thu, Nov 26, 2015 at 4:20 PM, Simone Tiraboschi 
>>> wrote:
>>>


 On Thu, Nov 26, 2015 at 11:05 AM, Budur Nagaraju 
 wrote:

>
>
>
> *Below are the entire logs*
>
>
 Sorry, with the entire log I mean if you can attach or share somewhere
 the whole /var/log/vdsm/vdsm.log  cause the latest ten lines are not enough
 to point out the issue.


>
>
>
>
> *[root@he ~]# tail -f /var/log/vdsm/vdsm.log *
>
> Detector thread::DEBUG::2015-11-26
> 15:16:05,622::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
> Detected protocol xml from 127.0.0.1:50944
> Detector thread::DEBUG::2015-11-26
> 15:16:05,623::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
> http detected from ('127.0.0.1', 50944)
> Detector thread::DEBUG::2015-11-26
> 15:16:05,703::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
> Adding connection from 127.0.0.1:50945
> Detector thread::DEBUG::2015-11-26
> 15:16:06,101::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
> Connection removed from 127.0.0.1:50945
> Detector thread::DEBUG::2015-11-26
> 15:16:06,101::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
> Detected protocol xml from 127.0.0.1:50945
> Detector thread::DEBUG::2015-11-26
> 15:16:06,101::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
> http detected from ('127.0.0.1', 50945)
> Detector thread::DEBUG::2015-11-26
> 15:16:06,182::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
> Adding connection from 127.0.0.1:50946
> Detector thread::DEBUG::2015-11-26
> 15:16:06,710::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
> Connection removed from 127.0.0.1:50946
> Detector thread::DEBUG::2015-11-26
> 15:16:06,711::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
> Detected protocol xml from 127.0.0.1:50946
> Detector thread::DEBUG::2015-11-26
> 15:16:06,711::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
> http detected from ('127.0.0.1', 50946)
>
>
>
>
> *[root@he ~]# tail -f /var/log/vdsm/supervdsm.log *
>
> MainProcess::DEBUG::2015-11-26
>

Re: [ovirt-users] Bug?

2015-11-27 Thread Ondra Machacek 

Hi,

this error usually mean, that your user can't be translated to 
userprincipalname.

The strange thing is that it worked, but stopped.
Can you please assure, that your user has userprincipalname atttribute?

$ ldapsearch -H ldap://ldapserver:3268/ -x -D 'searchu...@company.be' -w 
password -b '' '(cn=users)' userPrincipalName


If your user has some special upn suffix, then please use whole 
userprincipalname in user_name field.


Ondra

On 11/27/2015 07:07 AM, Koen Vanoppen wrote:

Hi All,

One of our users on ovirt who always was able to login with the AD 
account, now all of a sudden can't login anymore... I already tried 
kicking him out and putting him back in again, but no change... 
Following error is appearing in the log file when he logs in:


2015-11-27 07:01:00,418 ERROR 
[org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand] 
(ajp--127.0.0.1-8702-1) Error during CanDoActionFailure.: Class: class 
org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException

Input:
{Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class 
org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class 
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0, 
Extkey[name=EXTENSION_LICENSE;type=class 
java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL 
2.0, Extkey[name=EXTENSION_NOTES;type=class 
java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display 
name: ovirt-engine-extension-aaa-ldap-1.0.2-1.el6, 
Extkey[name=EXTENSION_HOME_URL;type=class 
java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-f969-42d4-b399-72d192e18304];]=http://www.ovirt.org, 
Extkey[name=EXTENSION_LOCALE;type=class 
java.lang.String;uuid=EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US, 
Extkey[name=EXTENSION_NAME;type=class 
java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authz, 
Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class 
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0, 
Extkey[name=EXTENSION_CONFIGURATION;type=class 
java.util.Properties;uuid=EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***, 
Extkey[name=EXTENSION_AUTHOR;type=class 
java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The 
oVirt Project, Extkey[name=AAA_AUTHZ_QUERY_MAX_FILTER_SIZE;type=class 
java.lang.Integer;uuid=AAA_AUTHZ_QUERY_MAX_FILTER_SIZE[2eb1f541-0f65-44a1-a6e3-014e247595f5];]=50, 
Extkey[name=EXTENSION_INSTANCE_NAME;type=class 
java.lang.String;uuid=EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=BRU_AIR-authz, 
Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class 
java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0, 
Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface 
java.util.Collection;uuid=EXTENSION_CONFIGURATION_SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[], 
Extkey[name=EXTENSION_GLOBAL_CONTEXT;type=class 
org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_GLOBAL_CONTEXT[9799e72f-7af6-4cf1-bf08-297bc8903676];]=*skip*, 
Extkey[name=EXTENSION_VERSION;type=class 
java.lang.String;uuid=EXTENSION_VERSION[fe35f6a8-8239-4bdb-ab1a-af9f779ce68c];]=1.0.2, 
Extkey[name=AAA_AUTHZ_AVAILABLE_NAMESPACES;type=interface 
java.util.Collection;uuid=AAA_AUTHZ_AVAILABLE_NAMESPACES[6dffa34c-955f-486a-bd35-0a272b45a711];]=[DC=brussels,DC=airport, 
DC=airport], Extkey[name=EXTENSION_MANAGER_TRACE_LOG;type=interface 
org.slf4j.Logger;uuid=EXTENSION_MANAGER_TRACE_LOG[863db666-3ea7-4751-9695-918a3197ad83];]=org.slf4j.impl.Slf4jLogger(org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace.ovirt-engine-extension-aaa-ldap.authz.BRU_AIR-authz), 
Extkey[name=EXTENSION_PROVIDES;type=interface 
java.util.Collection;uuid=EXTENSION_PROVIDES[8cf373a6-65b5-4594-b828-0e275087de91];]=[org.ovirt.engine.api.extensions.aaa.Authz], 
Extkey[name=EXTENSION_CONFIGURATION_FILE;type=class 
java.lang.String;uuid=EXTENSION_CONFIGURATION_FILE[4fb0ffd3-983c-4f3f-98ff-9660bd67af6a];]=/etc/ovirt-engine/extensions.d/BRU_AIR-authz.properties}, 
Extkey[name=AAA_AUTHZ_QUERY_FLAGS;type=class 
java.lang.Integer;uuid=AAA_AUTHZ_QUERY_FLAGS[97d226e9-8d87-49a0-9a7f-af689320907b];]=3, 
Extkey[name=EXTENSION_INVOKE_COMMAND;type=class 
org.ovirt.engine.api.extensions.ExtUUID;uuid=EXTENSION_INVOKE_COMMAND[485778ab-bede-4f1a-b823-77b262a2f28d];]=AAA_AUTHZ_FETCH_PRINCIPAL_RECORD[5a5bf9bb-9336-4376-a823-26efe1ba26df], 
Extkey[name=AAA_AUTHN_AUTH_RECORD;type=class 
org.ovirt.engine.api.extensions.ExtMap;uuid=AAA_AUTHN_AUTH_RECORD[e9462168-b53b-44ac-9af5-f25e1697173e];]={Extkey[name=AAA_AUTHN_AUTH_RECORD_PRINCIPAL;type=class 
java.lang.String;uuid=AAA_AUTHN_AUTH_RECORD_PRINCIPAL[c3498f07-11fe-464c-958c-8bd7490b119a];]=us...@company.be

Re: [ovirt-users] HA cluster

2015-11-27 Thread Budur Nagaraju 
I do not know what logs you are expecting ? the logs which I got is pasted
in the mail if you require in pastebin let me know I will upload there .

On Fri, Nov 27, 2015 at 1:58 PM, Sandro Bonazzola 
wrote:

>
>
> On Fri, Nov 27, 2015 at 8:34 AM, Budur Nagaraju  wrote:
>
>> I got only 10lines to in the vdsm logs and are below ,
>>
>>
> Can you please provide full sos report?
>
>
>
>>
>> [root@he /]# tail -f /var/log/vdsm/vdsm.log
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,360::resourceManager::616::Storage.ResourceManager::(releaseResource)
>> Trying to release resource 'Storage.HsmDomainMonitorLock'
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,360::resourceManager::635::Storage.ResourceManager::(releaseResource)
>> Released resource 'Storage.HsmDomainMonitorLock' (0 active users)
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,360::resourceManager::641::Storage.ResourceManager::(releaseResource)
>> Resource 'Storage.HsmDomainMonitorLock' is free, finding out if anyone is
>> waiting for it.
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,360::resourceManager::649::Storage.ResourceManager::(releaseResource)
>> No one is waiting for resource 'Storage.HsmDomainMonitorLock', Clearing
>> records.
>> Thread-100::INFO::2015-11-27
>> 12:58:57,360::logUtils::47::dispatcher::(wrapper) Run and protect:
>> stopMonitoringDomain, Return response: None
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,361::task::1191::Storage.TaskManager.Task::(prepare)
>> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::finished: None
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,361::task::595::Storage.TaskManager.Task::(_updateState)
>> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::moving from state preparing ->
>> state finished
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,361::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll)
>> Owner.releaseAll requests {} resources {}
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,361::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll)
>> Owner.cancelAll requests {}
>> Thread-100::DEBUG::2015-11-27
>> 12:58:57,361::task::993::Storage.TaskManager.Task::(_decref)
>> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::ref 0 aborting False
>>
>>
>>
>> On Thu, Nov 26, 2015 at 4:20 PM, Simone Tiraboschi 
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 26, 2015 at 11:05 AM, Budur Nagaraju 
>>> wrote:
>>>



 *Below are the entire logs*


>>> Sorry, with the entire log I mean if you can attach or share somewhere
>>> the whole /var/log/vdsm/vdsm.log  cause the latest ten lines are not enough
>>> to point out the issue.
>>>
>>>




 *[root@he ~]# tail -f /var/log/vdsm/vdsm.log *

 Detector thread::DEBUG::2015-11-26
 15:16:05,622::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
 Detected protocol xml from 127.0.0.1:50944
 Detector thread::DEBUG::2015-11-26
 15:16:05,623::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
 http detected from ('127.0.0.1', 50944)
 Detector thread::DEBUG::2015-11-26
 15:16:05,703::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
 Adding connection from 127.0.0.1:50945
 Detector thread::DEBUG::2015-11-26
 15:16:06,101::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
 Connection removed from 127.0.0.1:50945
 Detector thread::DEBUG::2015-11-26
 15:16:06,101::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
 Detected protocol xml from 127.0.0.1:50945
 Detector thread::DEBUG::2015-11-26
 15:16:06,101::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
 http detected from ('127.0.0.1', 50945)
 Detector thread::DEBUG::2015-11-26
 15:16:06,182::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
 Adding connection from 127.0.0.1:50946
 Detector thread::DEBUG::2015-11-26
 15:16:06,710::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
 Connection removed from 127.0.0.1:50946
 Detector thread::DEBUG::2015-11-26
 15:16:06,711::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
 Detected protocol xml from 127.0.0.1:50946
 Detector thread::DEBUG::2015-11-26
 15:16:06,711::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
 http detected from ('127.0.0.1', 50946)




 *[root@he ~]# tail -f /var/log/vdsm/supervdsm.log *

 MainProcess::DEBUG::2015-11-26
 15:13:30,234::supervdsmServer::102::SuperVdsm.ServerCallback::(wrapper)
 call readMultipathConf with () {}
 MainProcess::DEBUG::2015-11-26
 15:13:30,234::supervdsmServer::109::SuperVdsm.ServerCallback::(wrapper)
 return readMultipathConf with ['# RHEV REVISION 1.1', '', 'defaults {',
 'polling_interval5', 'getuid_callout
 "/lib/udev/scsi_id --whitelisted

Re: [ovirt-users] timeouts

2015-11-27 Thread knarra 

On 11/27/2015 11:04 AM, knarra wrote:

Hi Paf1,

Looks like when you reboot the nodes, glusterd does not start up 
in one node and due to this the node gets disconnected from other 
node(that is what i see from logs). After reboot, once your systems 
are up and running , can you check if glusterd is running on all the 
nodes? Can you please let me know which build of gluster are you using ?


For more info please read, 
http://www.gluster.org/pipermail/gluster-users.old/2015-June/022377.html 
- (please ignore this line)




Thanks
kasturi

On 11/27/2015 10:52 AM, Sahina Bose wrote:

[+ gluster-users]

On 11/26/2015 08:37 PM, p...@email.cz wrote:

Hello,
can anybody  help me with this timeouts ??
Volumes are not active yes ( bricks down )

desc. of gluster bellow ...

*/var/log/glusterfs/**etc-glusterfs-glusterd.vol.log*
[2015-11-26 14:44:47.174221] I [MSGID: 106004] 
[glusterd-handler.c:5065:__glusterd_peer_rpc_notify] 0-management: 
Peer <1hp1-SAN> (<87fc7db8-aba8-41f2-a1cd-b77e83b17436>), in state 
, has disconnected from glusterd.
[2015-11-26 14:44:47.174354] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 1HP12-P1 not held
[2015-11-26 14:44:47.17] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 1HP12-P3 not held
[2015-11-26 14:44:47.174521] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 2HP12-P1 not held
[2015-11-26 14:44:47.174662] W 
[glusterd-locks.c:681:glusterd_mgmt_v3_unlock] 
(-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_big_locked_notify+0x4c) 
[0x7fb7039d44dc] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(__glusterd_peer_rpc_notify+0x162) 
[0x7fb7039de542] 
-->/usr/lib64/glusterfs/3.7.6/xlator/mgmt/glusterd.so(glusterd_mgmt_v3_unlock+0x58a) 
[0x7fb703a79b4a] ) 0-management: Lock for vol 2HP12-P3 not held
[2015-11-26 14:44:47.174532] W [MSGID: 106118] 
[glusterd-handler.c:5087:__glusterd_peer_rpc_notify] 0-management: 
Lock not released for 2HP12-P1
[2015-11-26 14:44:47.174675] W [MSGID: 106118] 
[glusterd-handler.c:5087:__glusterd_peer_rpc_notify] 0-management: 
Lock not released for 2HP12-P3
[2015-11-26 14:44:49.423334] I [MSGID: 106488] 
[glusterd-handler.c:1472:__glusterd_handle_cli_get_volume] 
0-glusterd: Received get vol req
The message "I [MSGID: 106488] 
[glusterd-handler.c:1472:__glusterd_handle_cli_get_volume] 
0-glusterd: Received get vol req" repeated 4 times between 
[2015-11-26 14:44:49.423334] and [2015-11-26 14:44:49.429781]
[2015-11-26 14:44:51.148711] I [MSGID: 106163] 
[glusterd-handshake.c:1193:__glusterd_mgmt_hndsk_versions_ack] 
0-management: using the op-version 30702
[2015-11-26 14:44:52.177266] W [socket.c:869:__socket_keepalive] 
0-socket: failed to set TCP_USER_TIMEOUT -1000 on socket 12, Invalid 
argument
[2015-11-26 14:44:52.177291] E [socket.c:2965:socket_connect] 
0-management: Failed to set keep-alive: Invalid argument
[2015-11-26 14:44:53.180426] W [socket.c:869:__socket_keepalive] 
0-socket: failed to set TCP_USER_TIMEOUT -1000 on socket 17, Invalid 
argument
[2015-11-26 14:44:53.180447] E [socket.c:2965:socket_connect] 
0-management: Failed to set keep-alive: Invalid argument
[2015-11-26 14:44:52.395468] I [MSGID: 106163] 
[glusterd-handshake.c:1193:__glusterd_mgmt_hndsk_versions_ack] 
0-management: using the op-version 30702
[2015-11-26 14:44:54.851958] I [MSGID: 106488] 
[glusterd-handler.c:1472:__glusterd_handle_cli_get_volume] 
0-glusterd: Received get vol req
[2015-11-26 14:44:57.183969] W [socket.c:869:__socket_keepalive] 
0-socket: failed to set TCP_USER_TIMEOUT -1000 on socket 19, Invalid 
argument
[2015-11-26 14:44:57.183990] E [socket.c:2965:socket_connect] 
0-management: Failed to set keep-alive: Invalid argument


After volumes creation all works fine ( volumes up ) , but then, 
after several reboots ( yum updates) volumes failed due timeouts .


Gluster description:

4 nodes with 4 volumes replica 2
oVirt 3.6 - the last
gluster 3.7.6 - the last
vdsm 4.17.999 - from git repo

Re: [ovirt-users] HA cluster

2015-11-27 Thread Sandro Bonazzola 
On Fri, Nov 27, 2015 at 8:34 AM, Budur Nagaraju  wrote:

> I got only 10lines to in the vdsm logs and are below ,
>
>
Can you please provide full sos report?



>
> [root@he /]# tail -f /var/log/vdsm/vdsm.log
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::616::Storage.ResourceManager::(releaseResource)
> Trying to release resource 'Storage.HsmDomainMonitorLock'
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::635::Storage.ResourceManager::(releaseResource)
> Released resource 'Storage.HsmDomainMonitorLock' (0 active users)
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::641::Storage.ResourceManager::(releaseResource)
> Resource 'Storage.HsmDomainMonitorLock' is free, finding out if anyone is
> waiting for it.
> Thread-100::DEBUG::2015-11-27
> 12:58:57,360::resourceManager::649::Storage.ResourceManager::(releaseResource)
> No one is waiting for resource 'Storage.HsmDomainMonitorLock', Clearing
> records.
> Thread-100::INFO::2015-11-27
> 12:58:57,360::logUtils::47::dispatcher::(wrapper) Run and protect:
> stopMonitoringDomain, Return response: None
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::task::1191::Storage.TaskManager.Task::(prepare)
> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::finished: None
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::task::595::Storage.TaskManager.Task::(_updateState)
> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::moving from state preparing ->
> state finished
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll)
> Owner.releaseAll requests {} resources {}
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll)
> Owner.cancelAll requests {}
> Thread-100::DEBUG::2015-11-27
> 12:58:57,361::task::993::Storage.TaskManager.Task::(_decref)
> Task=`0128b179-fdb3-474b-a196-8cc81a72a837`::ref 0 aborting False
>
>
>
> On Thu, Nov 26, 2015 at 4:20 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, Nov 26, 2015 at 11:05 AM, Budur Nagaraju 
>> wrote:
>>
>>>
>>>
>>>
>>> *Below are the entire logs*
>>>
>>>
>> Sorry, with the entire log I mean if you can attach or share somewhere
>> the whole /var/log/vdsm/vdsm.log  cause the latest ten lines are not enough
>> to point out the issue.
>>
>>
>>>
>>>
>>>
>>>
>>> *[root@he ~]# tail -f /var/log/vdsm/vdsm.log *
>>>
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:05,622::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>>> Detected protocol xml from 127.0.0.1:50944
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:05,623::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>>> http detected from ('127.0.0.1', 50944)
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:05,703::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
>>> Adding connection from 127.0.0.1:50945
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,101::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
>>> Connection removed from 127.0.0.1:50945
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,101::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>>> Detected protocol xml from 127.0.0.1:50945
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,101::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>>> http detected from ('127.0.0.1', 50945)
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,182::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection)
>>> Adding connection from 127.0.0.1:50946
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,710::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection)
>>> Connection removed from 127.0.0.1:50946
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,711::protocoldetector::247::vds.MultiProtocolAcceptor::(_handle_connection_read)
>>> Detected protocol xml from 127.0.0.1:50946
>>> Detector thread::DEBUG::2015-11-26
>>> 15:16:06,711::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over
>>> http detected from ('127.0.0.1', 50946)
>>>
>>>
>>>
>>>
>>> *[root@he ~]# tail -f /var/log/vdsm/supervdsm.log *
>>>
>>> MainProcess::DEBUG::2015-11-26
>>> 15:13:30,234::supervdsmServer::102::SuperVdsm.ServerCallback::(wrapper)
>>> call readMultipathConf with () {}
>>> MainProcess::DEBUG::2015-11-26
>>> 15:13:30,234::supervdsmServer::109::SuperVdsm.ServerCallback::(wrapper)
>>> return readMultipathConf with ['# RHEV REVISION 1.1', '', 'defaults {',
>>> 'polling_interval5', 'getuid_callout
>>> "/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/%n"',
>>> 'no_path_retry   fail', 'user_friendly_names no', '
>>> flush_on_last_del   yes', 'fast_io_fail_tmo5', '
>>> dev_loss_tmo30', 'max_fds 4096', '}', '',
>>> 'devices {', 'device {', 'vendor  "HITACHI"', '
>>> product

Re: [ovirt-users] Attach Export Domain (NFS) to multiple datacenter

2015-11-27 Thread Simone Tiraboschi 
On Fri, Nov 27, 2015 at 5:17 AM, Punit Dambiwal  wrote:

> Hi Simone,
>
> Thanks..but how i can upload my existing OS template to docker glance ??
> Is there any good how to for the same..
>


http://docs.openstack.org/developer/python-glanceclient/man/glance.html


>
>
> On Thu, Nov 26, 2015 at 4:41 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, Nov 26, 2015 at 7:06 AM, Punit Dambiwal 
>> wrote:
>>
>>> Hi Simone,
>>>
>>> Yes.. i can but i want to use the same NFS storage with OS template
>>> inside..to use all the local storage server to provision the guest VM's..
>>>
>>> Thanks,
>>> punit
>>>
>>>
>>
>> Did you checked the glance integration?
>> http://www.ovirt.org/Features/Glance_Integration
>>
>> Now on 3.6 you can also deploy and configure glance via docker from
>> engine-setup:
>> http://www.ovirt.org/CinderGlance_Docker_Integration
>>
>>
>>
>>> On Wed, Nov 25, 2015 at 6:24 PM, Simone Tiraboschi 
>>> wrote:
>>>


 On Wed, Nov 25, 2015 at 5:50 AM, Punit Dambiwal 
 wrote:

> Hi,
>
> I want to attach the same nfs (export) volume to multiple datacenter
> in the ovirt..is it possible to do so..or any workaround for the same..
>


 As far as I know not at the same time.
 You have to detach and then attach do the new datacenter.


>
> Thanks.
> Punit
>
> ___
> 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