Re: [ovirt-users] Updated Invitation: [Deep dive] Host Network QoS - oVirt 3.6 @ Thu Nov 26, 2015 5pm - 6pm (ibar...@redhat.com)
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
[ovirt-users] hosted engine vm.conf missing
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] Dedicated NICs for gluster network
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
Re: [ovirt-users] Strange permissions on Hosted Engine HA Agent log files
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] Dedicated NICs for gluster network
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
[ovirt-users] Dedicated NICs for gluster network
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] vdsm using 100% CPU, rapidly filling logs with _handle_event messages
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
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 >>> 15:16:06,710::protocoldetector::201::vds.MultiProtocolAcceptor::(_remove_connection) >>> Connection removed from 127.0.0.1:50946 >>> Detector thread::DEBUG::2015-11-26 >>> 1
Re: [ovirt-users] Windows 10
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] timeouts
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 get
Re: [ovirt-users] HA cluster
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 thread::DEBUG::2015-11-26 >> 15:16:06,711::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml over >> http detected fro
Re: [ovirt-users] HA cluster
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 > 15:13:30,234::supervdsmServer::102::SuperVdsm.ServerCallback::(wrapper) > call readMultipathConf with () {} > MainPr
Re: [ovirt-users] timeouts
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 oVirt
Re: [ovirt-users] HA cluster
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 --replace-whitespace --device=/dev/%n"', 'no_path_retry fail', '
Re: [ovirt-users] Bug?
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] Attach Export Domain (NFS) to multiple datacenter
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
Re: [ovirt-users] HA cluster
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 "DF.*"', 'getuid_callout >>> "/lib/udev/scsi_