July 2016 - Users - oVirt List Archives

Debug vdsm 4.0.0 report error: libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
by lifuqiong 25 Jul '16

25 Jul '16

This is a multipart message in MIME format. ------=_NextPart_000_001E_01D1E509.19780F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I debugged vdsm with PyCharm, And I logged on my Centos 7.2 with root, and get an error as follows: Problem: Traceback (most recent call last): File "/usr/share/vdsm/vdsm", line 149, in run serve_clients(log) File "/usr/share/vdsm/vdsm", line 104, in serve_clients cif = clientIF.getInstance(irs, log, scheduler) File "/usr/share/vdsm/clientIF.py", line 204, in getInstance cls._instance = clientIF(irs, log, scheduler) File "/usr/share/vdsm/clientIF.py", line 106, in __init__ secret.clear() File "/usr/lib/python2.7/site-packages/vdsm/virt/secret.py", line 92, in clear con = libvirtconnection.get() File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 163, in get password) File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 99, in open_connection return utils.retry(libvirtOpen, timeout=10, sleep=0.2) File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 546, in retry return func() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied Investitate: According to the traceback above, the code in libvirt.py as below, and os.geteuid() get '0' which shows the current user is root; def openAuth(uri, auth, flags=0): #print os.geteuid() ret = libvirtmod.virConnectOpenAuth(uri, auth, flags) if ret is None:raise libvirtError('virConnectOpenAuth() failed') return virConnect(_obj=ret) [root@server117 libvirt]# ll /var/run/libvirt/libvirt-sock srwxrwx---. 1 root qemu 0 Jul 19 23:43 /var/run/libvirt/libvirt-sock According that, root should not get an Permission denied error ? But why? And I setenforce=0 , and still show Perssion denied error. What's the reason? And how to solve it? Thank you. ------=_NextPart_000_001E_01D1E509.19780F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DZH-CN link=3Dblue = vlink=3Dpurple style=3D'text-justify-trim:punctuation'><div = class=3DWordSection1>I debugged = vdsm with PyCharm, And I logged on my Centos 7.2 with root,  and = get an error as follows:<o:p></o:p><o:p> </o:p>Problem:<o:p></o:p><o:p> </o:p>Traceback (most recent call last):<o:p></o:p>  File = "/usr/share/vdsm/vdsm", line 149, in = run<o:p></o:p>    = serve_clients(log)<o:p></o:p>  File "/usr/share/vdsm/vdsm", line 104, in = serve_clients<o:p></o:p>    cif =3D clientIF.getInstance(irs, log, = scheduler)<o:p></o:p>  File "/usr/share/vdsm/clientIF.py", line = 204, in getInstance<o:p></o:p>    cls._instance =3D clientIF(irs, log, = scheduler)<o:p></o:p>  File "/usr/share/vdsm/clientIF.py", line = 106, in __init__<o:p></o:p>    secret.clear()<o:p></o:p>  File = "/usr/lib/python2.7/site-packages/vdsm/virt/secret.py", line = 92, in clear<o:p></o:p>    con =3D = libvirtconnection.get()<o:p></o:p>  File = "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", = line 163, in get<o:p></o:p>    password)<o:p></o:p>  File = "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", = line 99, in open_connection<o:p></o:p>    return = utils.retry(libvirtOpen, timeout=3D10, = sleep=3D0.2)<o:p></o:p>  File = "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 546, in = retry<o:p></o:p>    return func()<o:p></o:p>  File = "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in = openAuth<o:p></o:p>    if ret is None:raise = libvirtError('virConnectOpenAuth() failed')<o:p></o:p>libvirtError: Failed to connect = socket to '/var/run/libvirt/libvirt-sock': Permission = denied<o:p></o:p><o:p> </o:p>Investitate:<o:p></o:p>According to the traceback above, = the code in libvirt.py as below, and  os.geteuid() get = ‘0’ which shows the current user is = root;<o:p></o:p><o:p> </o:p>def openAuth(uri, auth, flags=3D0):<o:p></o:p>         #print = os.geteuid()<o:p></o:p>    ret =3D = libvirtmod.virConnectOpenAuth(uri, auth, flags)<o:p></o:p>    if ret is = None:raise libvirtError('virConnectOpenAuth() = failed')<o:p></o:p>return = virConnect(_obj=3Dret)<o:p></o:p><o:p> </o:p>[root@server117 libvirt]# ll = /var/run/libvirt/libvirt-sock<o:p></o:p>srwxrwx---. 1 root qemu 0 Jul 19 = 23:43 /var/run/libvirt/libvirt-sock<o:p></o:p><o:p> </o:p>According that, root should not get = an Permission denied error ? But why?<o:p></o:p><o:p> </o:p>And I setenforce=3D0 , and still = show Perssion denied error.<o:p></o:p><o:p> </o:p>What’s the reason? And how to = solve it?<o:p></o:p><o:p> </o:p>Thank you.<o:p></o:p></div></body></html> ------=_NextPart_000_001E_01D1E509.19780F20--

3 2

Re: [ovirt-users] how to enable spice on ovirt 4.0
by Sandro Bonazzola 25 Jul '16

25 Jul '16

Il 21/Lug/2016 05:38, "Fernando Fuentes" <ffuentes(a)darktcp.net> ha scritto: > > Any body? :) > Michal? Francesco? > -- > Fernando Fuentes > ffuentes(a)txweather.org > http://www.txweather.org > > On Wed, Jul 20, 2016, at 12:36 PM, Fernando Fuentes wrote: > > Team, > > > > How can I enable spice-xpi to be supported again on oVirt 4.0? > > > > Regards, > > > > -- > > Fernando Fuentes > > ffuentes(a)txweather.org > > http://www.txweather.org > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users

3 2

oVirt 4 master storage down - unable to activate after power loss
by Robin Vanderveken 25 Jul '16

25 Jul '16

Dear oVirt users I've been having several problems with my oVirt nodes utilising GlusterFS after simulating a power loss. Our testing setup for oVirt consists of 3 nodes, 2 with GlusterFS storage and 1 just for computing. Everything seems to be setup correct and was working correctly. Then after simulating a power loss the master storage goes down, and therefore the VMs and data center go down as well. I checked the GlusterFS configuration and it seems to be correct (see attachment). I checked the oVirt configuration and it seems to be correct (see attachment). I tried putting several Nodes in Maintenace several times, even putting in maintenance and reinstalling them. Only when putting the nodes in maintenance (and choosing to stop the GlusterFS service) triggers Contending on the other Nodes. Only then there is a chance that a Node goes from Contending to SPM, which does not always happen. After trying this several times I got a main Node to become SPM, but the master storage remains down. When I select the master storage, go in the Data center, select the data center and click Activate, then both the master storage and the data center go in the state Locked for a few seconds and then Inactive again. Then I upgraded to oVirt 4 (oVirt Engine Version: 4.0.0.6-1.el7.centos) and tried everything again, resulting in the same result. I searched online and found this mailing list which is very similar: http://lists.ovirt.org/pipermail/users/2014-August/026905.html . Unfortunately the solution was not posted/mailed. I also found this: https://www.mail-archive.com/users@ovirt.org/msg08105.html suggesting the kernel version is not correct, but I am unsure how to check this. In the attachment I added relevant logs: - GlusterFS service on both main nodes - /var/log/vdsm/vdsm.log , /var/log/vdsm/supervdsm.log , /var/log/messages , /var/log/sanlock.log , /var/log/ovirt-engine/engine.log-20160725.gz , /var/log/ovirt-engine/engine.log of the oVirt engine as attachments (I clicked on Activate on the data center at 9:45:30 am GMT). It can be possible that I need to send different engine logs, please tell me if necessary. Any help would be highly appreciated. Kind regards Robin Vanderveken -- Robin Vanderveken DLT Technologies Tel. +352 691 412 922 -- *Disclaimer* *Les informations contenues dans ce message sont destinées exclusivement à l’usage de la personne à laquelle elles sont adressées. Elles peuvent contenir des données confidentielles et/ou privilégiées et/ou protégées par des droits de propriété intellectuelle ou d’autres lois. Si vous avez reçu ce message par erreur, veuillez le détruire, ainsi que toutes ses annexes, et notifier son expéditeur ; il vous est interdit de copier ou d’utiliser ce messages ou ses annexes ou de divulguer son contenu à quiconque. La transmission de données par e-mail ne peut être garantie comme un moyen sûr et infaillible, ni comme étant exempt de tout virus. L’expéditeur décline toute responsabilité en cas de perte ou de dommage résultant de ce message ou de son utilisation, quelle qu’elle soit. * *The information contained in this message is intended for the addressee only and may contain confidential and/or privileged information and/or information protected by intellectual property rights or other legal rules. If you are not the intended recipient, please delete this message and any attachment to it and notify the sender; you may not copy or use this message or its attachments in any way nor disclose its contents to anyone. Emails cannot be guaranteed to be secure or to be error or virus free. No liability is accepted by the sender for any loss damage arising in any way from this message or its use. *

2 3

canot cancel a task
by Juan Carlos YJ. Lin 25 Jul '16

25 Jul '16

------=_Part_2103610_137760378.1469454733068 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I start moving a disk to a secondary storage, and one task hungs up try to stop the task several times with vdsClient, but it keeps in running state please let me know how to force stop the task. thanks [root@node5 ~]# vdsClient -s 0 getAllTasksStatuses {'status': {'message': 'OK', 'code': 0}, 'allTasksStatus': {'bc688cfd-a839-43b5-9a35-c8f56df00d19': {'message': 'running job 1 of 1', 'code': 0, 'taskID': 'bc688cfd-a839-43b5-9a35-c8f56df00d19', 'taskResult': '', 'taskState': 'running'}}} [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" stop async task Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" stop async task Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" stop async task Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" stop async task Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsClient -s 0 clearTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" clear async task Operation is not allowed in this task state: ("can't clean in state running",) Juan Carlos Lin Unisoft S.A. +595-993-288330 --------------------------------------------------- "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente" "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." ------=_Part_2103610_137760378.1469454733068 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>I start moving a disk to a secondary storage, and one task hung= s up try to stop the task several times with vdsClient, but it keeps= in running state please let me know how to force stop the task. = thanks [root@node5 ~]# vdsClient -s 0 getAllTasksStatuses {'statu= s': {'message': 'OK', 'code': 0}, 'allTasksStatus': {'bc688cfd-a839-43b5-9a= 35-c8f56df00d19': {'message': 'running job 1 of 1', 'code': 0, 'taskID': 'b= c688cfd-a839-43b5-9a35-c8f56df00d19', 'taskResult': '', 'taskState': 'runni= ng'}}} [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9= a35-c8f56df00d19" Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d1= 9' - code 411 [root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b= 5-9a35-c8f56df00d19" stop async task Task is aborted: u'bc688cfd-a839-43= b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsClient -s 0 stopTask= "bc688cfd-a839-43b5-9a35-c8f56df00d19" stop async task Task is aborted:= u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [root@node5 ~]# vdsC= lient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d19" stop async task<= br>Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d19' - code 411 [= root@node5 ~]# vdsClient -s 0 stopTask "bc688cfd-a839-43b5-9a35-c8f56df00d1= 9" stop async task Task is aborted: u'bc688cfd-a839-43b5-9a35-c8f56df00d= 19' - code 411 [root@node5 ~]# vdsClient -s 0 clearTask "bc688cfd-a839-4= 3b5-9a35-c8f56df00d19" clear async task Operation is not allowed in this= task state: ("can't clean in state running",) <div>Juan Carlos Lin Unisoft S.A. +595-993-288330= </div></div> = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML lang=3D"es"> <HEAD> <TITLE>System-wide Disclaimer</TITLE> </HEAD> <BODY>--------------------------------------------------- "Antes de imprimir, recu=C3=A9rdese de su compromiso con el Medio Ambiente" "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisi=C3=B3n del contenido no est=C3=A1 autorizada fuera del contexto de su env=C3=ADo y a quien corresponde. El uso no autorizado de la informaci=C3=B3n en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor b=C3=B3rrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." </BODY> </HTML> = </body></html> ------=_Part_2103610_137760378.1469454733068--

2 1

Blog post: Monitoring Improvements in oVirt
by Arik Hadas 25 Jul '16

25 Jul '16

Hi all, I wrote a blog post that summarizes the recent improvements in the code that monitors virtual machines in oVirt. It describes the changes that were done and shows a comparison of different aspects of oVirt with these changes (based on the master branch) vs oVirt 3.6 without these changes: http://ahadas.github.io/monitoring-improvements-in-ovirt/ It is mostly a technical post. However, users might find it interesting as well. Note that the measurements were taken on an environment with 1 host and 6000 running VMs (in a pool). Each VM had a network interface and was diskless. Obviously, this is not a typical setup but it was useful to easily expose some of weak sides of the monitoring. Your feedback is always welcome! Regards, Arik

2 2

OVirt API question
by Костя Климук 25 Jul '16

25 Jul '16

Hello, OVirt community! I have some problems in understanding with OVirt (v 3.6.0) API. I'm trying to create user with specifying his roles, by using such signature in POST call: <user> > <user_name>testuser@saml-auth</user_name> > <roles> > <role id="some_role_id1"/> > <role id="some_role_id2"/> > <role id="some_role_id3"/> > </roles> > </user> > The user is created but without the roles. The next issues, that I encountered is associated with updating of existing user (adding the roles to him). I am trying to do PUT call on .../ovirt-engine/api/users/long_user_id/roles : <role id="some_role_id1"/> But this doesn't work. Please, give we insight in what I am doing wrong. ------------- Sincerely, Konstantin Klymuk.

2 1

stuck host in hosted engine migration 3.6->4.0
by Qiong.Wu＠telekom.de 25 Jul '16

25 Jul '16

------=_NextPart_000_0521_01D1E1B2.668D2750 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0522_01D1E1B2.668D2750" ------=_NextPart_001_0522_01D1E1B2.668D2750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I have another issue with ovirt 4.0 after upgrading my hosted engine using the recommended method athttp://www.ovirt.org/documenta./migration-engine-3.6-to-4.0/ <http://www.ovirt.org/documentation/migration-engine-3.6-to-4.0/> Everything works well, except for the fact that my hosted engine host is kind of broken in the engine. It doesnt show up and neither does the hosted engine storage domain. The hosted engine host from 3.6 is still there, but non responsive. VDSM.log on the hosted engine host gives me lots of errors: JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:12,236::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:13,468::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:13,860::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:20,767::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:20,944::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') Reactor thread::ERROR::2016-07-19 09:56:23,666::m2cutils::301::ProtocolDetector.SSLHandshakeDispatcher::(handl e_read) Error during handshake: unexpected eof JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:25,532::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:29,936::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') Reactor thread::ERROR::2016-07-19 09:56:35,640::m2cutils::301::ProtocolDetector.SSLHandshakeDispatcher::(handl e_read) Error during handshake: unexpected eof JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:48,277::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:49,459::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:49,991::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:56,862::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:56:57,049::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 09:57:01,611::betterAsyncore::113::vds.dispatcher::(recv) SSL error during reading data: (104, 'Connection reset by peer') Does anyone have an idea how to clean this up? Thanks a lot! Cheers & Thanks Qiong Wu ------=_NextPart_001_0522_01D1E1B2.668D2750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 08.00.0681.000"> <TITLE>stuck host in hosted engine migration 3.6->4.0</TITLE> </HEAD> <BODY>  Hi there, I = have another issue with ovirt 4.0 after upgrading my hosted engine using = the recommended method at<A = HREF=3D"http://www.ovirt.org/documentation/migration-engine-3.6-to-4.0/">= http://www.ovirt.org/documenta…/migration-engine-3= .6-to-4.0/</A> Everything = works well, except for the fact that my hosted engine host is kind of = broken in the engine. It doesnt show up and neither does the hosted = engine storage domain. The hosted engine host from 3.6 is still there, = but non responsive. VDSM.log on = the hosted engine host gives me lots of errors: JsonRpc = (StompReactor)::ERROR::2016-07-19 = 09:56:12,236::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:13,468::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:13,860::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:20,767::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:20,944::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') Reactor thread::ERROR::2016-07-19 = 09:56:23,666::m2cutils::301::ProtocolDetector.SSLHandshakeDispatcher::(ha= ndle_read) Error during handshake: unexpected eof JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:25,532::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:29,936::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') Reactor thread::ERROR::2016-07-19 = 09:56:35,640::m2cutils::301::ProtocolDetector.SSLHandshakeDispatcher::(ha= ndle_read) Error during handshake: unexpected eof JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:48,277::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:49,459::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:49,991::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:56,862::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:56:57,049::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') JsonRpc (StompReactor)::ERROR::2016-07-19 = 09:57:01,611::betterAsyncore::113::vds.dispatcher::(recv) SSL error = during reading data: (104, 'Connection reset by peer') Does anyone have = an idea how to clean this up? Thanks a lot! Cheers & = Thanks Qiong = Wu </BODY> </HTML> ------=_NextPart_001_0522_01D1E1B2.668D2750-- ------=_NextPart_000_0521_01D1E1B2.668D2750 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIZtjCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggZTMIIFO6ADAgECAgIBFTANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTEwNDE0 MTEzNzAwWhcNMTkwNDE0MjM1OTU5WjBuMQswCQYDVQQGEwJERTEcMBoGA1UECgwTRGV1dHNjaGUg VGVsZWtvbSBBRzEVMBMGA1UECwwMVHJ1c3QgQ2VudGVyMSowKAYDVQQDDCFEZXV0c2NoZSBUZWxl a29tIEFHIElzc3VpbmcgQ0EgMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQqAIo lWlpBvwutcl5rDIF5YchxxgflAy0k12Wv5YjhCgWQLctHGHqwYTbkHM3jiKNqJKGie4+XP9Zd1Qo qAlIMF/OphWnAJ1dylXniNorhvKwXJIkNTiOW0/3BgQWq5W6eCIz027HdpfNJa4zv87nbRJZG3M7 5O3umGBwmQjtNL3d30QHgqG4c152tupTRxqE3VnW4/3lEUWD9uNvpH3hLi/C1nCh//6gT5YmQ1sr B9XeTHHrVddzMpWy6O9AiY2LgRqfgSDl6+vHYYY97Y5nDBpIP9s1vRzgjdMTQE6LF284hpB8+qNl LfiIZYuquokldGIvAzWcX6QXjg4E3U9HAgMBAAGjggL2MIIC8jAOBgNVHQ8BAf8EBAMCAYYwHQYD VR0OBBYEFIZF5EhCqGy4Ti3FdqvAjPZlUfzzMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMBIGA1UdEwEB/wQIMAYBAf8CAQAwUgYDVR0gBEswSTBHBgkrBgEEAb1HDRowOjA4BggrBgEF BQcCARYsaHR0cDovL2NvcnBvcmF0ZS1wa2kxLnRlbGVrb20uZGUvY3BzL2Nwcy5odG0wgf8GA1Ud HwSB9zCB9DBQoE6gTIZKaHR0cDovL2NvcnBvcmF0ZS1wa2kudGVsZWtvbS5kZS9jZHAvRGV1dHNj aGUlMjBUZWxla29tJTIwUm9vdCUyMENBJTIwMi5jcmwwgZ+ggZyggZmGgZZsZGFwOi8vbGRhcC1j cGtpLnRlbGVrb20uZGUvY249RGV1dHNjaGUlMjBUZWxla29tJTIwUm9vdCUyMENBJTIwMixvdT1U LVRlbGVTZWMlMjBUcnVzdCUyMENlbnRlcixvPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHLEM9REU/ YXV0aG9yaXR5UmV2b2NhdGlvbkxpc3QwggE0BggrBgEFBQcBAQSCASYwggEiMCwGCCsGAQUFBzAB hiBodHRwOi8vb2NzcC1jcGtpLnRlbGVrb20uZGUvb2NzcDBWBggrBgEFBQcwAoZKaHR0cDovL2Nv cnBvcmF0ZS1wa2kudGVsZWtvbS5kZS9haWEvRGV1dHNjaGUlMjBUZWxla29tJTIwUm9vdCUyMENB JTIwMi5jcnQwgZkGCCsGAQUFBzAChoGMbGRhcDovL2xkYXAtY3BraS50ZWxla29tLmRlL0NOPURl dXRzY2hlJTIwVGVsZWtvbSUyMFJvb3QlMjBDQSUyMDIsT1U9VC1UZWxlU2VjJTIwVHJ1c3QlMjBD ZW50ZXIsTz1EZXV0c2NoZSUyMFRlbGVrb20lMjBBRyxDPURFP2NBQ2VydGlmaWNhdGUwDQYJKoZI hvcNAQEFBQADggEBAKOK3UrNSfZ039uR0kWpHzpqWTKBDHH27xAwFadVp1XNSX9O66zs9AONMOff 2OVvTWOY9dP3gAjeyJwCxyS/7w8OCXf0txgPeewMA23xWBQkybY/GEKwkjSg4NByVpZQYM908aYm zsJYhjxcKgoXQ9C3NZrc0CvbnV6J//n8V9uHrFY7871jZ7FnojEhTnCqp0+IdjZzsnKU1AiVYk/a R9Y7lb76sLBSTgE8cL5XM2QY50fgrV4zhpWefl8/fWXfZ77LxrhUTocoRPDR18Mm8I2HQhxij0kZ oF6pLJylcfU8pJzP4iKSp3u55IaypBOW+VpnSLT1Cumjd9LM8L/ihcwwggfZMIIGwaADAgECAgoa 3jLlAAEABmxkMA0GCSqGSIb3DQEBBQUAMG4xCzAJBgNVBAYTAkRFMRwwGgYDVQQKDBNEZXV0c2No ZSBUZWxla29tIEFHMRUwEwYDVQQLDAxUcnVzdCBDZW50ZXIxKjAoBgNVBAMMIURldXRzY2hlIFRl bGVrb20gQUcgSXNzdWluZyBDQSAwMTAeFw0xNjAzMDEwOTAyMDFaFw0xOTAzMDEwOTAyMDFaMH4x DTALBgNVBAoMBERUQUcxDzANBgNVBAsMBlBlcnNvbjERMA8GA1UECwwIRW1wbG95ZWUxEjAQBgNV BAsMCUMtMTIxNDY5NDERMA8GA1UEAwwIUWlvbmcgV3UxIjAgBgkqhkiG9w0BCQEWE1Fpb25nLld1 QHRlbGVrb20uZGUwggEjMA0GCSqGSIb3DQEBAQUAA4IBEAAwggELAoIBAQCutPVH+CY/wevQ57bd HTZxJJTn4H0bFQR7pekAGoplgtMxFmWImMoHfOhQfFazKJw6yXmIPfusjvefqR+korJQHT22qtG8 uG7XtfZYe7Yr60krVmvtp7iomCsPQPEe+UEniUAp+D9t1+97TF84Qx/6ZI3ZMNQlfu3LPTa5gBLP WVPOAGK0HJLCIJok13RFiRPnyekY240ioEOGuojiUBlTcPhqk/Eo/z+d6Kx7SakRok0LMA/0iEgr A1NWMkcmeYXU5cJFIr9McioSXR5MzW1B+pQ1tqqTC+r4ZqNnIgtOayspbB6ZmNvPKhOv9FzrqA4L SCdYeNQBjaJWUpz0cBtJAgRAAACBo4IEZjCCBGIwHQYDVR0OBBYEFKc1sO9NLAsP2EHBhptdO9nL pZREMB8GA1UdIwQYMBaAFIZF5EhCqGy4Ti3FdqvAjPZlUfzzMIIB5gYDVR0fBIIB3TCCAdkwggHV oIIB0aCCAc2GU2h0dHA6Ly9jb3Jwb3JhdGUtcGtpLnRlbGVrb20uZGUvY2RwL0RldXRzY2hlJTIw VGVsZWtvbSUyMEFHJTIwSXNzdWluZyUyMENBJTIwMDEuY3JshoGVbGRhcDovL0xEQVAtY3BraS50 ZWxla29tLmRlL0NOPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHJTIwSXNzdWluZyUyMENBJTIwMDEs T1U9VHJ1c3QlMjBDZW50ZXIsTz1EZXV0c2NoZSUyMFRlbGVrb20lMjBBRyxDPURFP2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3SGgd1sZGFwOi8vL0NOPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHJTIw SXNzdWluZyUyMENBJTIwMDEsQ049aGUxMTMzNjYsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNl cnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2RzLERDPXQtaW50ZXJuYWws REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0 cmlidXRpb25Qb2ludDCCAT0GCCsGAQUFBwEBBIIBLzCCASswLAYIKwYBBQUHMAGGIGh0dHA6Ly9v Y3NwLWNwa2kudGVsZWtvbS5kZS9vY3NwMGIGCCsGAQUFBzAChlZodHRwOi8vY29ycG9yYXRlLXBr aS50ZWxla29tLmRlL2FpYS9EZXV0c2NoZSUyMFRlbGVrb20lMjBBRyUyMElzc3VpbmclMjBDQSUy MDAxKDEpLmNydDCBlgYIKwYBBQUHMAKGgYlsZGFwOi8vTERBUC1jcGtpLnRlbGVrb20uZGUvQ049 RGV1dHNjaGUlMjBUZWxla29tJTIwQUclMjBJc3N1aW5nJTIwQ0ElMjAwMSxPVT1UcnVzdCUyMENl bnRlcixPPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHLEM9REU/Y0FDZXJ0aWZpY2F0ZTALBgNVHQ8E BAMCB4AwOwYJKwYBBAGCNxUHBC4wLAYkKwYBBAGCNxUItvtCg6bBLo2bEYe3x2aCuNURBIHl/3uG saNkAgFkAgEOMBMGA1UdJQQMMAoGCCsGAQUFBwMEMFEGA1UdIARKMEgwRgYJKwYBBAG9Rw0aMDkw NwYIKwYBBQUHAgEWK2h0dHA6Ly9jb3Jwb3JhdGUtcGtpLnRlbGVrb20uZGUvY3BzL2Nwcy5odG0w QwYDVR0RBDwwOqAjBgorBgEEAYI3FAIDoBUME1Fpb25nLld1QHRlbGVrb20uZGWBE1Fpb25nLld1 QHRlbGVrb20uZGUwDQYJKoZIhvcNAQEFBQADggEBACYWvdG3jWWcjv1UuSGltbLvvIXgUUWZGylN Vug7wwVb5FJvwS/pyDxmHoW79VQ6v3vqLl18VFom8Ut5bcqeubMfnoP0OfO7SCRhanrdja6UQ37O tkr1BUiQQ8Hx2X5ofAp+fVppvox034D1iItK3Wot6zqIns99lZQWVuJye0J01LHQmXOtuGhNbNdE 7PVHGa9iCDzL/SULTCqrk64MsoLmpFbHwaL+DKo7QEx4kIiUIR9DdanzYVPvYL1WvEbmE6p9BTr+ 4WZUumxJUoWtm5MUTwIkPPno2JsU3hDsI5snq2IuK9uJsOaVaQFayEG5GAnS7KVH12xI0vOEfWLj HzIwggfbMIIGw6ADAgECAgoa3j+IAAEABmxlMA0GCSqGSIb3DQEBBQUAMG4xCzAJBgNVBAYTAkRF MRwwGgYDVQQKDBNEZXV0c2NoZSBUZWxla29tIEFHMRUwEwYDVQQLDAxUcnVzdCBDZW50ZXIxKjAo BgNVBAMMIURldXRzY2hlIFRlbGVrb20gQUcgSXNzdWluZyBDQSAwMTAeFw0xNjAzMDEwOTAyMDRa Fw0xOTAzMDEwOTAyMDRaMH4xDTALBgNVBAoMBERUQUcxDzANBgNVBAsMBlBlcnNvbjERMA8GA1UE CwwIRW1wbG95ZWUxEjAQBgNVBAsMCUMtMTIxNDY5NDERMA8GA1UEAwwIUWlvbmcgV3UxIjAgBgkq hkiG9w0BCQEWE1Fpb25nLld1QHRlbGVrb20uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCs36i30ascevNLivnE2qZCSQfNXXY3gh1z+04j/OFt+/2+doUuhnAkZqWakizWUULHD3Xh MnGONnWF610LaRWvlCskSkftJy2yGOJ4krHtN5cA9yLeqsbgrYJSwQ4kcBqP50OnMKExtfKjv96h qqglcTh7npCsbglJQTtjHKfgwPT7z5n3gH6bjWylhlJ7/4C6ZRVH0c7wDJtPEvrHUoWoT4ifWKRe jc3C85tyoM7T3BX1dAPJklAf8fuvLD2XXW8wpIftAE2IrGVfhrDOoQ0vFBAWYKzZiMhMi8Z4C1rO TKvvHijXHaR35fr2fbrLuQsGO8bQwQVKnMHxmiNpSBBTAgMBAAGjggRpMIIEZTAdBgNVHQ4EFgQU yfGIPRJZswFS3p6bPxJrcdV543kwDgYDVR0PAQH/BAQDAgQwMB8GA1UdIwQYMBaAFIZF5EhCqGy4 Ti3FdqvAjPZlUfzzMIIB5gYDVR0fBIIB3TCCAdkwggHVoIIB0aCCAc2GU2h0dHA6Ly9jb3Jwb3Jh dGUtcGtpLnRlbGVrb20uZGUvY2RwL0RldXRzY2hlJTIwVGVsZWtvbSUyMEFHJTIwSXNzdWluZyUy MENBJTIwMDEuY3JshoGVbGRhcDovL0xEQVAtY3BraS50ZWxla29tLmRlL0NOPURldXRzY2hlJTIw VGVsZWtvbSUyMEFHJTIwSXNzdWluZyUyMENBJTIwMDEsT1U9VHJ1c3QlMjBDZW50ZXIsTz1EZXV0 c2NoZSUyMFRlbGVrb20lMjBBRyxDPURFP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3SGgd1sZGFw Oi8vL0NOPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHJTIwSXNzdWluZyUyMENBJTIwMDEsQ049aGUx MTMzNjYsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9Y2RzLERDPXQtaW50ZXJuYWwsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAT0GCCsGAQUF BwEBBIIBLzCCASswLAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwLWNwa2kudGVsZWtvbS5kZS9vY3Nw MGIGCCsGAQUFBzAChlZodHRwOi8vY29ycG9yYXRlLXBraS50ZWxla29tLmRlL2FpYS9EZXV0c2No ZSUyMFRlbGVrb20lMjBBRyUyMElzc3VpbmclMjBDQSUyMDAxKDEpLmNydDCBlgYIKwYBBQUHMAKG gYlsZGFwOi8vTERBUC1jcGtpLnRlbGVrb20uZGUvQ049RGV1dHNjaGUlMjBUZWxla29tJTIwQUcl MjBJc3N1aW5nJTIwQ0ElMjAwMSxPVT1UcnVzdCUyMENlbnRlcixPPURldXRzY2hlJTIwVGVsZWtv bSUyMEFHLEM9REU/Y0FDZXJ0aWZpY2F0ZTA7BgkrBgEEAYI3FQcELjAsBiQrBgEEAYI3FQi2+0KD psEujZsRh7fHZoK41REEg8jyMoKY+HICAWQCAQ0wEwYDVR0lBAwwCgYIKwYBBQUHAwQwUQYDVR0g BEowSDBGBgkrBgEEAb1HDRowOTA3BggrBgEFBQcCARYraHR0cDovL2NvcnBvcmF0ZS1wa2kudGVs ZWtvbS5kZS9jcHMvY3BzLmh0bTBDBgNVHREEPDA6oCMGCisGAQQBgjcUAgOgFQwTUWlvbmcuV3VA dGVsZWtvbS5kZYETUWlvbmcuV3VAdGVsZWtvbS5kZTANBgkqhkiG9w0BAQUFAAOCAQEAimTSoYZZ j953if0qGqu0bvoK6DxhBFubo8ELXAnauj+50fVJv8bMz1W3AIENYtFHci/k63L/KedJmSkaI7By b4NHuQwNkYfc1e42Qj53gqd9jAyWNgusO7Z0nijhxrQucU7i3uQP2kmdy3qesu0O0/euwXoYgDsC Vi2NM39fitQg+yosd9NNVbB3mJgi4VV948WUrM+Ci9cAexlHKuGiEGxiGT8ORQv3GPyNCIbNWVHL l8L7ZSrZP8OBjJLteMDdBbXOYhSbXc8FWrDVoMYl/eFdup7K6ievioi1uAomn16H4qDhPQCD8AyY cZBCjxsJLcgLxjBykXIu9G/MBDyUYzGCA9wwggPYAgEBMHwwbjELMAkGA1UEBhMCREUxHDAaBgNV BAoME0RldXRzY2hlIFRlbGVrb20gQUcxFTATBgNVBAsMDFRydXN0IENlbnRlcjEqMCgGA1UEAwwh RGV1dHNjaGUgVGVsZWtvbSBBRyBJc3N1aW5nIENBIDAxAgoa3jLlAAEABmxkMAkGBSsOAwIaBQCg ggI1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDcxOTA5NDA1 MVowIwYJKoZIhvcNAQkEMRYEFIzSaNdbvOd+rNq+0VpASIyPEVqiMIGLBgkrBgEEAYI3EAQxfjB8 MG4xCzAJBgNVBAYTAkRFMRwwGgYDVQQKDBNEZXV0c2NoZSBUZWxla29tIEFHMRUwEwYDVQQLDAxU cnVzdCBDZW50ZXIxKjAoBgNVBAMMIURldXRzY2hlIFRlbGVrb20gQUcgSXNzdWluZyBDQSAwMQIK Gt4/iAABAAZsZTCBjQYLKoZIhvcNAQkQAgsxfqB8MG4xCzAJBgNVBAYTAkRFMRwwGgYDVQQKDBNE ZXV0c2NoZSBUZWxla29tIEFHMRUwEwYDVQQLDAxUcnVzdCBDZW50ZXIxKjAoBgNVBAMMIURldXRz Y2hlIFRlbGVrb20gQUcgSXNzdWluZyBDQSAwMQIKGt4/iAABAAZsZTCBtwYJKoZIhvcNAQkPMYGp MIGmMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4G CCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUr DgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTAN BgkqhkiG9w0BAQEFAASCAQB531AvYBVlYgt8L6/3bIP/OJy1ab1q06F2EL9Co4mBBbz11S5JiAov JBQzoMkqLhTZHnSnhxi3x+PPcMpgLHW6UOQhC8cM0oy1vrdsoLSo1uZAA5L6F92xXNvY8RR0icSb wAlvwOaTnGm4pDdWHM3ZprUcmddt2SaXtmHLgLLthqAuYhgSK2aC+jJYFVpunMFMz84y70frXHdA N+CQMP9OW4RSB6iZs3wKVZPU3Su/e4wnPm9cyR+7ig3ZJYaDSOskqnesqJ9xZqQJ8DZ+3C/Ab2nz JSxz3MBrE6zQX/oJeQ7D7coVdKU12exoMuMeZTV8ENoInLcGTqim56jGuZ74AAAAAAAA ------=_NextPart_000_0521_01D1E1B2.668D2750--

6 11

oVIRT 4.0.1 Hosted Engine Agent stops and can't be started anymore
by Matt . 25 Jul '16

25 Jul '16

Hi Guys, I'm having an issues just at once that my HA Agent stops running and can't be restarted or won't start anymore after the following error. I'm able to start the HE manually on the commandline on each host. Exception: Failed to start monitoring domain (sd_uuid=4093ad17-bef5-4e4b-9a16-259a98e20321, host_id=1): timeout during domain acquisition MainThread::WARNING::2016-07-22 13:20:05,059::hosted_engine::477::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:: (start_monitoring) Error while monitoring engine: Failed to start monitoring domain (sd_uuid=4093ad17-bef5-4e4b-9a16-259a98e20321, host_id=1): timeout during domain acquisition MainThread::WARNING::2016-07-22 13:20:05,059::hosted_engine::480::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:: (start_monitoring) Unexpected error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 451, in start_monitoring self._initialize_domain_monitor() File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 831, in _initialize_domain_monitor raise Exception(msg) Exception: Failed to start monitoring domain (sd_uuid=4093ad17-bef5-4e4b-9a16-259a98e20321, host_id=1): timeout during domain acquisition MainThread::ERROR::2016-07-22 13:20:05,060::hosted_engine::493::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:: (start_monitoring) Shutting down the agent because of 3 failures in a row! MainThread::INFO::2016-07-22 13:20:07,096::hosted_engine::860::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:: (_get_domain_monitor_status) VDSM domain monitor status: PENDING MainThread::INFO::2016-07-22 13:20:07,122::hosted_engine::786::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:: (_stop_domain_monitor) Failed to stop monitoring domain (sd_uuid=4093ad17-bef5-4e4b-9a16-259a98e20321): Error 900 from stopMonitoringDomain: Storage domain is member of pool: 'domain=4093ad17-bef5-4e4b-9a16-259a98e20321' MainThread::INFO::2016-07-22 13:20:07,129::agent::143::ovirt_hosted_engine_ha.agent.agent.Agent::(run) Agent shutting down This part concerns me actually: Error 900 from stopMonitoringDomain: Storage domain is member of pool: 'domain=4093ad17-bef5-4e4b-9a16-259a98e20321' I'm running oVirt 4.0.1 Or do you guys want a bugreport for this ? Thanks! Matt

2 1

hosted-engine-deploy error
by qinglong.dong＠horebdata.cn 25 Jul '16

25 Jul '16

This is a multi-part message in MIME format. ------=_001_NextPart571367160775_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbDoNCiAgICAgICAgSSB0cmllZCB0byBkZXBsb3kgYW4gaG9zdGVkIGVuZ2luZSwgYnV0 IEkgZ290IGFuIGVycm9yOg0KW3Jvb3RAbm9kZSB+XSMgaG9zdGVkLWVuZ2luZSAtLWRlcGxveQ0K Li4uLi4uDQogICAgICAgICAgLS09PSBDT05GSUdVUkFUSU9OIFBSRVZJRVcgPT0tLQ0KDQogICAg ICAgICAgQnJpZGdlIGludGVyZmFjZSAgICAgICAgICAgICAgICAgICA6IGVucDZzMGYwDQogICAg ICAgICAgRW5naW5lIEZRRE4gICAgICAgICAgICAgICAgICAgICAgICA6IGVuZ2luZS5ob3JlYmRh dGEuY24NCiAgICAgICAgICBCcmlkZ2UgbmFtZSAgICAgICAgICAgICAgICAgICAgICAgIDogb3Zp cnRtZ210DQogICAgICAgICAgSG9zdCBhZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICA6IG5v ZGUuaG9yZWJkYXRhLmNuDQogICAgICAgICAgU1NIIGRhZW1vbiBwb3J0ICAgICAgICAgICAgICAg ICAgICA6IDIyDQogICAgICAgICAgRmlyZXdhbGwgbWFuYWdlciAgICAgICAgICAgICAgICAgICA6 IGlwdGFibGVzDQogICAgICAgICAgR2F0ZXdheSBhZGRyZXNzICAgICAgICAgICAgICAgICAgICA6 IDE5Mi4xNjguMS4xDQogICAgICAgICAgSG9zdCBuYW1lIGZvciB3ZWIgYXBwbGljYXRpb24gICAg ICA6IG5vZGUNCiAgICAgICAgICBTdG9yYWdlIERvbWFpbiB0eXBlICAgICAgICAgICAgICAgIDog aXNjc2kNCiAgICAgICAgICBIb3N0IElEICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogMQ0K ICAgICAgICAgIExVTiBJRCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOiAyMzg2NjM3NjMz MjMyMzkzMg0KICAgICAgICAgIEltYWdlIHNpemUgR0IgICAgICAgICAgICAgICAgICAgICAgOiAy NQ0KICAgICAgICAgIGlTQ1NJIFBvcnRhbCBJUCBBZGRyZXNzICAgICAgICAgICAgOiAxOTIuMTY4 LjEyOC4xMTUNCiAgICAgICAgICBpU0NTSSBUYXJnZXQgTmFtZSAgICAgICAgICAgICAgICAgIDog ZW5naW5lDQogICAgICAgICAgaVNDU0kgUG9ydGFsIHBvcnQgICAgICAgICAgICAgICAgICA6IDMy NjANCiAgICAgICAgICBpU0NTSSBQb3J0YWwgdXNlciAgICAgICAgICAgICAgICAgIDoNCiAgICAg ICAgICBDb25zb2xlIHR5cGUgICAgICAgICAgICAgICAgICAgICAgIDogdm5jDQogICAgICAgICAg TWVtb3J5IHNpemUgTUIgICAgICAgICAgICAgICAgICAgICA6IDQwOTYNCiAgICAgICAgICBNQUMg YWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgIDogMDA6MTY6M2U6NDg6ZGI6OWUNCiAgICAg ICAgICBCb290IHR5cGUgICAgICAgICAgICAgICAgICAgICAgICAgIDogY2Ryb20NCiAgICAgICAg ICBOdW1iZXIgb2YgQ1BVcyAgICAgICAgICAgICAgICAgICAgIDogMg0KICAgICAgICAgIElTTyBp bWFnZSAoY2Ryb20gYm9vdC9jbG91ZC1pbml0KSAgOiAvdG1wLzEuaXNvDQogICAgICAgICAgQ1BV IFR5cGUgICAgICAgICAgICAgICAgICAgICAgICAgICA6IG1vZGVsX1NhbmR5QnJpZGdlDQoNCiAg ICAgICAgICBQbGVhc2UgY29uZmlybSBpbnN0YWxsYXRpb24gc2V0dGluZ3MgKFllcywgTm8pW1ll c106DQpbIElORk8gIF0gU3RhZ2U6IFRyYW5zYWN0aW9uIHNldHVwDQpbIElORk8gIF0gU3RhZ2U6 IE1pc2MgY29uZmlndXJhdGlvbg0KWyBJTkZPICBdIFN0YWdlOiBQYWNrYWdlIGluc3RhbGxhdGlv bg0KWyBJTkZPICBdIFN0YWdlOiBNaXNjIGNvbmZpZ3VyYXRpb24NClsgSU5GTyAgXSBDb25maWd1 cmluZyBsaWJ2aXJ0DQpbIElORk8gIF0gQ29uZmlndXJpbmcgVkRTTQ0KWyBJTkZPICBdIFN0YXJ0 aW5nIHZkc21kDQpbIElORk8gIF0gQ29uZmlndXJpbmcgdGhlIG1hbmFnZW1lbnQgYnJpZGdlDQpb IElORk8gIF0gQ3JlYXRpbmcgVm9sdW1lIEdyb3VwDQpbIEVSUk9SIF0gRXJyb3IgY3JlYXRpbmcg Vm9sdW1lIEdyb3VwOiBGYWlsZWQgdG8gaW5pdGlhbGl6ZSBwaHlzaWNhbCBkZXZpY2U6ICgiW3Un L2Rldi9tYXBwZXIvMjM4NjYzNzYzMzIzMjM5MzInXSIsKQ0KICAgICAgICAgIFRoZSBzZWxlY3Rl ZCBkZXZpY2UgaXMgYWxyZWFkeSB1c2VkLg0KICAgICAgICAgIFRvIGNyZWF0ZSBhIHZnIG9uIHRo aXMgZGV2aWNlLCB5b3UgbXVzdCB1c2UgRm9yY2UuDQogICAgICAgICAgV0FSTklORzogVGhpcyB3 aWxsIGRlc3Ryb3kgZXhpc3RpbmcgZGF0YSBvbiB0aGUgZGV2aWNlLg0KICAgICAgICAgIChGb3Jj ZSwgQWJvcnQpW0Fib3J0XT8gRm9yY2UNClsgSU5GTyAgXSBDcmVhdGluZyBTdG9yYWdlIERvbWFp bg0KWyBJTkZPICBdIENyZWF0aW5nIFN0b3JhZ2UgUG9vbA0KWyBJTkZPICBdIENvbm5lY3Rpbmcg U3RvcmFnZSBQb29sDQpbIElORk8gIF0gVmVyaWZ5aW5nIHNhbmxvY2sgbG9ja3NwYWNlIGluaXRp YWxpemF0aW9uDQpbIEVSUk9SIF0gRmFpbGVkIHRvIGV4ZWN1dGUgc3RhZ2UgJ01pc2MgY29uZmln dXJhdGlvbic6IFtFcnJubyAxMDFdIE5ldHdvcmsgaXMgdW5yZWFjaGFibGUNClsgSU5GTyAgXSBT dGFnZTogQ2xlYW4gdXANClsgSU5GTyAgXSBHZW5lcmF0aW5nIGFuc3dlciBmaWxlICcvdmFyL2xp Yi9vdmlydC1ob3N0ZWQtZW5naW5lLXNldHVwL2Fuc3dlcnMvYW5zd2Vycy0yMDE2MDcyNTEwMTIw NS5jb25mJw0KWyBJTkZPICBdIFN0YWdlOiBQcmUtdGVybWluYXRpb24NClsgSU5GTyAgXSBTdGFn ZTogVGVybWluYXRpb24NClsgRVJST1IgXSBIb3N0ZWQgRW5naW5lIGRlcGxveW1lbnQgZmFpbGVk OiB0aGlzIHN5c3RlbSBpcyBub3QgcmVsaWFibGUsIHBsZWFzZSBjaGVjayB0aGUgaXNzdWUsIGZp eCBhbmQgcmVkZXBsb3kNCiAgICAgICAgICBMb2cgZmlsZSBpcyBsb2NhdGVkIGF0IC92YXIvbG9n L292aXJ0LWhvc3RlZC1lbmdpbmUtc2V0dXAvb3ZpcnQtaG9zdGVkLWVuZ2luZS1zZXR1cC0yMDE2 MDcyNTEwMDUzNS1oMnk3OGMubG9nDQpbcm9vdEBub2RlIH5dIyBjYXQgL3Zhci9sb2cvb3ZpcnQt aG9zdGVkLWVuZ2luZS1zZXR1cC9vdmlydC1ob3N0ZWQtZW5naW5lLXNldHVwLTIwMTYwNzI1MTAw NTM1LWgyeTc4Yy5sb2cgfCBncmVwIEVSUk9SDQoyMDE2LTA3LTI1IDEwOjA3OjAxIEVSUk9SIG90 b3BpLnBsdWdpbnMuZ3JfaGVfc2V0dXAuc3RvcmFnZS5ibG9ja2QgYmxvY2tkLl9taXNjOjY2NCBF cnJvciBjcmVhdGluZyBWb2x1bWUgR3JvdXA6IEZhaWxlZCB0byBpbml0aWFsaXplIHBoeXNpY2Fs IGRldmljZTogKCJbdScvZGV2L21hcHBlci8yMzg2NjM3NjMzMjMyMzkzMiddIiwpDQoyMDE2LTA3 LTI1IDEwOjExOjU5IEVSUk9SIG90b3BpLmNvbnRleHQgY29udGV4dC5fZXhlY3V0ZU1ldGhvZDox NTEgRmFpbGVkIHRvIGV4ZWN1dGUgc3RhZ2UgJ01pc2MgY29uZmlndXJhdGlvbic6IFtFcnJubyAx MDFdIE5ldHdvcmsgaXMgdW5yZWFjaGFibGUNCjIwMTYtMDctMjUgMTA6MTI6MDUgRVJST1Igb3Rv cGkucGx1Z2lucy5ncl9oZV9zZXR1cC5jb3JlLm1pc2MgbWlzYy5fdGVybWluYXRlOjk5IEhvc3Rl ZCBFbmdpbmUgZGVwbG95bWVudCBmYWlsZWQ6IHRoaXMgc3lzdGVtIGlzIG5vdCByZWxpYWJsZSwg cGxlYXNlIGNoZWNrIHRoZSBpc3N1ZSwgZml4IGFuZCByZWRlcGxveQ0KW3Jvb3RAbm9kZSB+XSMg Y2F0IC92YXIvbG9nL3Zkc20vdmRzbS5sb2cgfCBncmVwIEVSUk9SDQpqc29ucnBjLkV4ZWN1dG9y LzQ6OkVSUk9SOjoyMDE2LTA3LTI1IDEwOjA3OjAxLDQ5MTo6bHZtOjo3Mzc6OlN0b3JhZ2UuTFZN OjooX2luaXRwdnMpIHB2Y3JlYXRlIGZhaWxlZCB3aXRoIHJjPTUNCmpzb25ycGMuRXhlY3V0b3Iv NDo6RVJST1I6OjIwMTYtMDctMjUgMTA6MDc6MDEsNDkyOjpsdm06OjczODo6U3RvcmFnZS5MVk06 OihfaW5pdHB2cykgW10sIFsnICBXQVJOSU5HOiBsdm1ldGFkIGlzIHJ1bm5pbmcgYnV0IGRpc2Fi bGVkLiBSZXN0YXJ0IGx2bWV0YWQgYmVmb3JlIGVuYWJsaW5nIGl0IScsICcgIC9kZXYvbWFwcGVy LzIzODY2Mzc2MzMyMzIzOTMyOiByZWFkIGZhaWxlZCBhZnRlciAwIG9mIDQwOTYgYXQgMDogSW5w dXQvb3V0cHV0IGVycm9yJywgJyAgL2Rldi9tYXBwZXIvMjM4NjYzNzYzMzIzMjM5MzI6IHJlYWQg ZmFpbGVkIGFmdGVyIDAgb2YgNDA5NiBhdCA0Mjk0OTYwNzQyNDogSW5wdXQvb3V0cHV0IGVycm9y JywgJyAgL2Rldi9tYXBwZXIvMjM4NjYzNzYzMzIzMjM5MzI6IHJlYWQgZmFpbGVkIGFmdGVyIDAg b2YgNDA5NiBhdCA0Mjk0OTY2NDc2ODogSW5wdXQvb3V0cHV0IGVycm9yJywgJyAgV0FSTklORzog RXJyb3IgY291bnRzIHJlYWNoZWQgYSBsaW1pdCBvZiAzLiBEZXZpY2UgL2Rldi9tYXBwZXIvMjM4 NjYzNzYzMzIzMjM5MzIgd2FzIGRpc2FibGVkJywgJyAgRmFpbGVkIHRvIHdpcGUgbmV3IG1ldGFk YXRhIGFyZWEgYXQgdGhlIHN0YXJ0IG9mIHRoZSAvZGV2L21hcHBlci8yMzg2NjM3NjMzMjMyMzkz MicsICcgIEZhaWxlZCB0byBhZGQgbWV0YWRhdGEgYXJlYSBmb3IgbmV3IHBoeXNpY2FsIHZvbHVt ZSAvZGV2L21hcHBlci8yMzg2NjM3NjMzMjMyMzkzMicsICcgIEZhaWxlZCB0byBzZXR1cCBwaHlz aWNhbCB2b2x1bWUgIi9kZXYvbWFwcGVyLzIzODY2Mzc2MzMyMzIzOTMyIiddDQpqc29ucnBjLkV4 ZWN1dG9yLzQ6OkVSUk9SOjoyMDE2LTA3LTI1IDEwOjA3OjAxLDQ5Mjo6dGFzazo6ODY4OjpTdG9y YWdlLlRhc2tNYW5hZ2VyLlRhc2s6Oihfc2V0RXJyb3IpIFRhc2s9YGExYjU1ZGMxLTJjMjMtNGU5 Zi1iODFhLTQzYjE4OTU1NzAyOGA6OlVuZXhwZWN0ZWQgZXJyb3INCmpzb25ycGMuRXhlY3V0b3Iv NDo6RVJST1I6OjIwMTYtMDctMjUgMTA6MDc6MDEsNDk2OjpkaXNwYXRjaGVyOjo3Nzo6U3RvcmFn ZS5EaXNwYXRjaGVyOjood3JhcHBlcikgeydzdGF0dXMnOiB7J21lc3NhZ2UnOiAnRmFpbGVkIHRv IGluaXRpYWxpemUgcGh5c2ljYWwgZGV2aWNlOiAoIlt1XCcvZGV2L21hcHBlci8yMzg2NjM3NjMz MjMyMzkzMlwnXSIsKScsICdjb2RlJzogNjAxfX0NCmpzb25ycGMuRXhlY3V0b3IvMjo6RVJST1I6 OjIwMTYtMDctMjUgMTA6MTA6NDcsMTE2OjpzZGM6OjE0MDo6U3RvcmFnZS5TdG9yYWdlRG9tYWlu Q2FjaGU6OihfZmluZERvbWFpbikgbG9va2luZyBmb3IgdW5mZXRjaGVkIGRvbWFpbiBjYWY4YTFm Ny0xNmRiLTRhMDItOWFiOS04NzI5ODdjY2VmNmYNCmpzb25ycGMuRXhlY3V0b3IvMjo6RVJST1I6 OjIwMTYtMDctMjUgMTA6MTA6NDcsMTE2OjpzZGM6OjE1Nzo6U3RvcmFnZS5TdG9yYWdlRG9tYWlu Q2FjaGU6OihfZmluZFVuZmV0Y2hlZERvbWFpbikgbG9va2luZyBmb3IgZG9tYWluIGNhZjhhMWY3 LTE2ZGItNGEwMi05YWI5LTg3Mjk4N2NjZWY2Zg0KanNvbnJwYy5FeGVjdXRvci8yOjpFUlJPUjo6 MjAxNi0wNy0yNSAxMDoxMDo0NywxNTY6OnNkYzo6MTQ2OjpTdG9yYWdlLlN0b3JhZ2VEb21haW5D YWNoZTo6KF9maW5kRG9tYWluKSBkb21haW4gY2FmOGExZjctMTZkYi00YTAyLTlhYjktODcyOTg3 Y2NlZjZmIG5vdCBmb3VuZA0KanNvbnJwYy5FeGVjdXRvci81OjpFUlJPUjo6MjAxNi0wNy0yNSAx MDoxMDo0OSw2NzE6OnNkYzo6MTQwOjpTdG9yYWdlLlN0b3JhZ2VEb21haW5DYWNoZTo6KF9maW5k RG9tYWluKSBsb29raW5nIGZvciB1bmZldGNoZWQgZG9tYWluIGVlMDFkMGE3LTRlMTItNGM1Ny05 MzFlLTg4MDA4OTgwY2E5OA0KanNvbnJwYy5FeGVjdXRvci81OjpFUlJPUjo6MjAxNi0wNy0yNSAx MDoxMDo0OSw2NzE6OnNkYzo6MTU3OjpTdG9yYWdlLlN0b3JhZ2VEb21haW5DYWNoZTo6KF9maW5k VW5mZXRjaGVkRG9tYWluKSBsb29raW5nIGZvciBkb21haW4gZWUwMWQwYTctNGUxMi00YzU3LTkz MWUtODgwMDg5ODBjYTk4DQpqc29ucnBjLkV4ZWN1dG9yLzU6OkVSUk9SOjoyMDE2LTA3LTI1IDEw OjEwOjQ5LDcwMjo6c2RjOjoxNDY6OlN0b3JhZ2UuU3RvcmFnZURvbWFpbkNhY2hlOjooX2ZpbmRE b21haW4pIGRvbWFpbiBlZTAxZDBhNy00ZTEyLTRjNTctOTMxZS04ODAwODk4MGNhOTggbm90IGZv dW5kDQpKc29uUnBjIChTdG9tcFJlYWN0b3IpOjpFUlJPUjo6MjAxNi0wNy0yNSAxMDoxMjowNSw0 ODQ6OmJldHRlckFzeW5jb3JlOjoxMTM6OnZkcy5kaXNwYXRjaGVyOjoocmVjdikgU1NMIGVycm9y IGR1cmluZyByZWFkaW5nIGRhdGE6IHVuZXhwZWN0ZWQgZW9mDQpbcm9vdEBub2RlMiB+XSMgaWZj b25maWcNCmVucDZzMGYwOiBmbGFncz00MTYzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLE1VTFRJQ0FT VD4gIG10dSAxNTAwDQogICAgICAgIGV0aGVyIDAwOjFlOjY3OmE1OjFiOmVlICB0eHF1ZXVlbGVu IDEwMDAgIChFdGhlcm5ldCkNCiAgICAgICAgUlggcGFja2V0cyAzNjY1MyAgYnl0ZXMgMjk0Mzky NDUgKDI4LjAgTWlCKQ0KICAgICAgICBSWCBlcnJvcnMgMCAgZHJvcHBlZCAxNyAgb3ZlcnJ1bnMg MCAgZnJhbWUgMA0KICAgICAgICBUWCBwYWNrZXRzIDc5ODIwICBieXRlcyAxMDMwNjU1MzEgKDk4 LjIgTWlCKQ0KICAgICAgICBUWCBlcnJvcnMgMCAgZHJvcHBlZCAwIG92ZXJydW5zIDAgIGNhcnJp ZXIgMCAgY29sbGlzaW9ucyAwDQogICAgICAgIGRldmljZSBtZW1vcnkgMHhkMTE2MDAwMC1kMTE3 ZmZmZiAgDQoNCmVucDZzMGYxOiBmbGFncz00MTYzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLE1VTFRJ Q0FTVD4gIG10dSAxNTAwDQogICAgICAgIGluZXQgMTkyLjE2OC4xLjYyICBuZXRtYXNrIDI1NS4y NTUuMjU1LjAgIGJyb2FkY2FzdCAxOTIuMTY4LjEuMjU1DQogICAgICAgIGV0aGVyIDAwOjFlOjY3 OmE1OjFiOmVmICB0eHF1ZXVlbGVuIDEwMDAgIChFdGhlcm5ldCkNCiAgICAgICAgUlggcGFja2V0 cyA3ODU4ICBieXRlcyAxMTEzMTE2ICgxLjAgTWlCKQ0KICAgICAgICBSWCBlcnJvcnMgMCAgZHJv cHBlZCAwICBvdmVycnVucyAwICBmcmFtZSAwDQogICAgICAgIFRYIHBhY2tldHMgNDY4ICBieXRl cyAyMTM3NSAoMjAuOCBLaUIpDQogICAgICAgIFRYIGVycm9ycyAwICBkcm9wcGVkIDAgb3ZlcnJ1 bnMgMCAgY2FycmllciAwICBjb2xsaXNpb25zIDANCiAgICAgICAgZGV2aWNlIG1lbW9yeSAweGQx MTQwMDAwLWQxMTVmZmZmICANCg0KbG86IGZsYWdzPTczPFVQLExPT1BCQUNLLFJVTk5JTkc+ICBt dHUgNjU1MzYNCiAgICAgICAgaW5ldCAxMjcuMC4wLjEgIG5ldG1hc2sgMjU1LjAuMC4wDQogICAg ICAgIGxvb3AgIHR4cXVldWVsZW4gMCAgKExvY2FsIExvb3BiYWNrKQ0KICAgICAgICBSWCBwYWNr ZXRzIDM0NCAgYnl0ZXMgMTIyNzc2ICgxMTkuOCBLaUIpDQogICAgICAgIFJYIGVycm9ycyAwICBk cm9wcGVkIDAgIG92ZXJydW5zIDAgIGZyYW1lIDANCiAgICAgICAgVFggcGFja2V0cyAzNDQgIGJ5 dGVzIDEyMjc3NiAoMTE5LjggS2lCKQ0KICAgICAgICBUWCBlcnJvcnMgMCAgZHJvcHBlZCAwIG92 ZXJydW5zIDAgIGNhcnJpZXIgMCAgY29sbGlzaW9ucyAwDQoNCm92aXJ0bWdtdDogZmxhZ3M9NDE2 MzxVUCxCUk9BRENBU1QsUlVOTklORyxNVUxUSUNBU1Q+ICBtdHUgMTUwMA0KICAgICAgICBpbmV0 IDE5Mi4xNjguMTI4LjYwICBuZXRtYXNrIDI1NS4yNTUuMjU1LjAgIGJyb2FkY2FzdCAxOTIuMTY4 LjEyOC4yNTUNCiAgICAgICAgZXRoZXIgMDA6MWU6Njc6YTU6MWI6ZWUgIHR4cXVldWVsZW4gMCAg KEV0aGVybmV0KQ0KICAgICAgICBSWCBwYWNrZXRzIDE2MzcyICBieXRlcyAyNDMyMjI0OCAoMjMu MSBNaUIpDQogICAgICAgIFJYIGVycm9ycyAwICBkcm9wcGVkIDAgIG92ZXJydW5zIDAgIGZyYW1l IDANCiAgICAgICAgVFggcGFja2V0cyA4ODkzICBieXRlcyA5Nzk2NDg1NyAoOTMuNCBNaUIpDQog ICAgICAgIFRYIGVycm9ycyAwICBkcm9wcGVkIDAgb3ZlcnJ1bnMgMCAgY2FycmllciAwICBjb2xs aXNpb25zIDANCg0KdmlyYnIwOiBmbGFncz00MDk5PFVQLEJST0FEQ0FTVCxNVUxUSUNBU1Q+ICBt dHUgMTUwMA0KICAgICAgICBpbmV0IDE5Mi4xNjguMTIyLjEgIG5ldG1hc2sgMjU1LjI1NS4yNTUu MCAgYnJvYWRjYXN0IDE5Mi4xNjguMTIyLjI1NQ0KICAgICAgICBldGhlciA1Mjo1NDowMDowYTph ZTo1YyAgdHhxdWV1ZWxlbiAwICAoRXRoZXJuZXQpDQogICAgICAgIFJYIHBhY2tldHMgMCAgYnl0 ZXMgMCAoMC4wIEIpDQogICAgICAgIFJYIGVycm9ycyAwICBkcm9wcGVkIDAgIG92ZXJydW5zIDAg IGZyYW1lIDANCiAgICAgICAgVFggcGFja2V0cyAwICBieXRlcyAwICgwLjAgQikNCiAgICAgICAg VFggZXJyb3JzIDAgIGRyb3BwZWQgMCBvdmVycnVucyAwICBjYXJyaWVyIDAgIGNvbGxpc2lvbnMg MA0KDQogICAgICAgIEl0IHNlZW1zIHRoYXQgdGhlcmUgaXMgc29tZXRoaW5nIHdyb25nIHdpdGgg dGhlIG5ldHdvcmsgb3IgdGhlIHN0b3JhZ2UuIEkgZ290IHRoZSBzYW1lIGVycm9yIHdoZW4gdGhl IGlzY3NpIHN0b3JhZ2Ugd2FzIHJlcGxhY2VkIGJ5IGFuIG5mcyBzdG9yYWdlLiBJIGhhdmUgZGVw bG95ZWQgaXQgb24gdGhlIHNhbWUgaG9zdCB1c2luZyB0aGUgc2FtZSBzdG9yYWdlIHN1Y2Nlc3Nm dWxseSBhIGZldyBkYXlzIGFnbywgYnV0IG5vdyBJIGNhbid0LiBBbnlvbmUgY2FuIGhlbHA/IFRo YW5rcyENCg== ------=_001_NextPart571367160775_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3Dutf-8"><style>body { line-height: 1.5; }body { font-size: 10.5pt; font= -family: =E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91; color: rgb(0, 0, 0); line-h= eight: 1.5; }body { font-size: 10.5pt; color: rgb(0, 0, 0); line-height: 1= .5; }</style></head><body>=0A<div>Hi, all:</div><div>  &= nbsp;     I tried to deploy an hosted= engine, but I got an error:</div><div>[roo= t@node ~]# hosted-engine --deploy</div><div>......</div><= div>          --=3D=3D CONFIGURATION PR= EVIEW =3D=3D--        &nbsp= ;  Bridge interface      &nbs= p;            = : enp6s0f0          &= nbsp;Engine FQDN        &nbsp= ;            &= nbsp;  : engine.horebdata.cn     &nb= sp;     Bridge name    &= nbsp;           &nb= sp;       : ovirtmgmt  &nb= sp;        Host address =             &n= bsp;         : node.hore= bdata.cn           SS= H daemon port        &nb= sp;           :&nbs= p;22           Firewa= ll manager         &nbsp= ;         : iptables =           Gateway a= ddress           &n= bsp;        : 192.168.1.1 =           Host name=  for web application      :&n= bsp;node           St= orage Domain type       &nbsp= ;        : iscsi  &nb= sp;        Host ID &nbsp= ;            &= nbsp;           &nb= sp; : 1         &nbsp= ; LUN ID         &n= bsp;           &nbs= p;       : 23866376332323932 &n= bsp;         Image size&= nbsp;GB           &= nbsp;          : 25=           iSCSI&nbsp= ;Portal IP Address       &nbs= p;    : 192.168.128.115    &nbs= p;      iSCSI Target Name &nb= sp;           &nbsp= ;    : engine      &n= bsp;    iSCSI Portal port   &= nbsp;           &nb= sp;  : 3260        &n= bsp;  iSCSI Portal user     &= nbsp;           &nb= sp;:           Consol= e type          &nb= sp;           &nbsp= ;: vnc          &nbsp= ;Memory size MB        &= nbsp;           &nb= sp;: 4096          &n= bsp;MAC address         =             &n= bsp;  : 00:16:3e:48:db:9e      =      Boot type     =             &n= bsp;        : cdrom  =          Number of = CPUs           &nbs= p;         : 2  =          ISO image = (cdrom boot/cloud-init)  : /tmp/1.iso   &= nbsp;       CPU Type  &n= bsp;           &nbs= p;            = : model_SandyBridge        =    Please confirm installation settings&nbsp= ;(Yes, No)[Yes]: [ INFO  ] Stage: Transac= tion setup [ INFO  ] Stage: Misc con= figuration [ INFO  ] Stage: Package insta= llation [ INFO  ] Stage: Misc configurati= on [ INFO  ] Configuring libvirt [ INF= O  ] Configuring VDSM [ INFO  ]&nbsp= ;Starting vdsmd [ INFO  ] Configuring the=  management bridge [ INFO  ] Creating&nbs= p;Volume Group [ ERROR ] Error creating V= olume Group: Failed to initialize physical d= evice: ("[u'/dev/mapper/23866376332323932']",)    &= nbsp;      The selected device&nbs= p;is already used.        =    To create a vg on this dev= ice, you must use Force.     &n= bsp;     WARNING: This will destro= y existing data on the device.   &nb= sp;       (Force, Abort)[Abort]?&n= bsp;Force [ INFO  ] Creating Storage Doma= in [ INFO  ] Creating Storage Pool [&n= bsp;INFO  ] Connecting Storage Pool [ INF= O  ] Verifying sanlock lockspace initializat= ion [ ERROR ] Failed to execute stage&nbs= p;'Misc configuration': [Errno 101] Network is&nb= sp;unreachable [ INFO  ] Stage: Clean up<= br>[ INFO  ] Generating answer file '/v= ar/lib/ovirt-hosted-engine-setup/answers/answers-20160725101205.conf' [=  INFO  ] Stage: Pre-termination [ INFO&nb= sp; ] Stage: Termination [ ERROR ] Hosted=  Engine deployment failed: this system is&nb= sp;not reliable, please check the issue, fix=  and redeploy        &nbsp= ;  Log file is located at /var/log/ovir= t-hosted-engine-setup/ovirt-hosted-engine-setup-20160725100535-h2y78c.log<= br>[root@node ~]# cat /var/log/ovir= t-hosted-engine-setup/ovirt-hosted-engine-setup-20160725100535-h2y78c.log&= nbsp;| grep ERROR 2016-07-25 10:07:01 ERROR&= nbsp;otopi.plugins.gr_he_setup.storage.blockd blockd._misc:664 E= rror creating Volume Group: Failed to initia= lize physical device: ("[u'/dev/mapper/23866376332323932']"= ,) 2016-07-25 10:11:59 ERROR otopi.context context.= _executeMethod:151 Failed to execute stage 'Misc&= nbsp;configuration': [Errno 101] Network is unrea= chable 2016-07-25 10:12:05 ERROR otopi.plugins.gr_he_set= up.core.misc misc._terminate:99 Hosted Engine deployme= nt failed: this system is not reliable,&nbsp= ;please check the issue, fix and redeploy</d= iv><div>[root@node ~]# cat /var/log= /vdsm/vdsm.log | grep ERROR jsonrpc.Executor/4::E= RROR::2016-07-25 10:07:01,491::lvm::737::Storage.LVM::(_initpvs)&nbsp= ;pvcreate failed with rc=3D5 jsonrpc.Executor/4::ERROR::= 2016-07-25 10:07:01,492::lvm::738::Storage.LVM::(_initpvs) [],&n= bsp;['  WARNING: lvmetad is running but&nbsp= ;disabled. Restart lvmetad before enabling it!',&= nbsp;'  /dev/mapper/23866376332323932: read failed&nbs= p;after 0 of 4096 at 0: Input/output er= ror', '  /dev/mapper/23866376332323932: read fail= ed after 0 of 4096 at 42949607424: Inpu= t/output error', '  /dev/mapper/23866376332323932:&nbs= p;read failed after 0 of 4096 at 429496= 64768: Input/output error', '  WARNING: Erro= r counts reached a limit of 3. Device&n= bsp;/dev/mapper/23866376332323932 was disabled', ' &nb= sp;Failed to wipe new metadata area at = the start of the /dev/mapper/23866376332323932', = '  Failed to add metadata area for&nbsp= ;new physical volume /dev/mapper/23866376332323932', '=   Failed to setup physical volume "/dev= /mapper/23866376332323932"'] jsonrpc.Executor/4::ERROR::2016-07-25&nbsp= ;10:07:01,492::task::868::Storage.TaskManager.Task::(_setError) Task= =3D`a1b55dc1-2c23-4e9f-b81a-43b189557028`::Unexpected error jsonrp= c.Executor/4::ERROR::2016-07-25 10:07:01,496::dispatcher::77::Storage= .Dispatcher::(wrapper) {'status': {'message': 'Failed = to initialize physical device: ("[u\'/dev/mapper/23866= 376332323932\']",)', 'code': 601}} jsonrpc.Executor/2::ERROR:= :2016-07-25 10:10:47,116::sdc::140::Storage.StorageDomainCache::(_fin= dDomain) looking for unfetched domain caf8a1f7-16= db-4a02-9ab9-872987ccef6f jsonrpc.Executor/2::ERROR::2016-07-25 10= :10:47,116::sdc::157::Storage.StorageDomainCache::(_findUnfetchedDomain)&n= bsp;looking for domain caf8a1f7-16db-4a02-9ab9-872987ccef6f= jsonrpc.Executor/2::ERROR::2016-07-25 10:10:47,156::sdc::146::Sto= rage.StorageDomainCache::(_findDomain) domain caf8a1f7-16db-4a02= -9ab9-872987ccef6f not found jsonrpc.Executor/5::ERROR::2016-= 07-25 10:10:49,671::sdc::140::Storage.StorageDomainCache::(_findDomai= n) looking for unfetched domain ee01d0a7-4e12-4c5= 7-931e-88008980ca98 jsonrpc.Executor/5::ERROR::2016-07-25 10:10:49= ,671::sdc::157::Storage.StorageDomainCache::(_findUnfetchedDomain) lo= oking for domain ee01d0a7-4e12-4c57-931e-88008980ca98 js= onrpc.Executor/5::ERROR::2016-07-25 10:10:49,702::sdc::146::Storage.S= torageDomainCache::(_findDomain) domain ee01d0a7-4e12-4c57-931e-= 88008980ca98 not found JsonRpc (StompReactor)::ERROR::20= 16-07-25 10:12:05,484::betterAsyncore::113::vds.dispatcher::(recv)&nb= sp;SSL error during reading data: unexpected&nbsp= ;eof</div><div>[root@node2 ~]# ifconfig<= /font> </div><div>enp6s0f0: flags=3D4163<UP,BROADCAST,RUNNING,M= ULTICAST>  mtu 1500      &nb= sp;  ether 00:1e:67:a5:1b:ee  txqueuelen 100= 0  (Ethernet)        &nbsp= ;RX packets 36653  bytes 29439245 (28.0&nbsp= ;MiB)         RX errors&nb= sp;0  dropped 17  overruns 0  fram= e 0         TX packet= s 79820  bytes 103065531 (98.2 MiB) &nbsp= ;       TX errors 0 &nbs= p;dropped 0 overruns 0  carrier 0 &nbsp= ;collisions 0         devi= ce memory 0xd1160000-d117ffff   enp6s0f1: = flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 150= 0         inet 192.168.1.6= 2  netmask 255.255.255.0  broadcast 192.168.= 1.255         ether 00:1e:= 67:a5:1b:ef  txqueuelen 1000  (Ethernet) &nbsp= ;       RX packets 7858 =  bytes 1113116 (1.0 MiB)     &n= bsp;   RX errors 0  dropped 0&nbsp= ; overruns 0  frame 0     =     TX packets 468  bytes 213= 75 (20.8 KiB)        &nbsp= ;TX errors 0  dropped 0 overruns 0&nbsp= ; carrier 0  collisions 0    &n= bsp;    device memory 0xd1140000-d115ffff&nb= sp;  lo: flags=3D73<UP,LOOPBACK,RUNNING> &nbsp= ;mtu 65536         inet&nb= sp;127.0.0.1  netmask 255.0.0.0     =     loop  txqueuelen 0  (Loca= l Loopback)         RX&nbs= p;packets 344  bytes 122776 (119.8 KiB) &= nbsp;       RX errors 0 =  dropped 0  overruns 0  frame 0<br= >        TX packets 344&= nbsp; bytes 122776 (119.8 KiB)    &n= bsp;    TX errors 0  dropped = 0 overruns 0  carrier 0  collisions&nbs= p;0 ovirtmgmt: flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST&= gt;  mtu 1500        =  inet 192.168.128.60  netmask 255.255.255.0 =  broadcast 192.168.128.255      &nbs= p;  ether 00:1e:67:a5:1b:ee  txqueuelen 0&nb= sp; (Ethernet)         RX&= nbsp;packets 16372  bytes 24322248 (23.1 MiB= )         RX errors 0=   dropped 0  overruns 0  frame&nbs= p;0         TX packets&nbs= p;8893  bytes 97964857 (93.4 MiB)   =       TX errors 0  dropp= ed 0 overruns 0  carrier 0  collis= ions 0 virbr0: flags=3D4099<UP,BROADCAST,MULTICAST>=   mtu 1500        &nb= sp;inet 192.168.122.1  netmask 255.255.255.0 &nbs= p;broadcast 192.168.122.255       &n= bsp; ether 52:54:00:0a:ae:5c  txqueuelen 0 &= nbsp;(Ethernet)         RX&nbsp= ;packets 0  bytes 0 (0.0 B)   &= nbsp;     RX errors 0  droppe= d 0  overruns 0  frame 0  &nbsp= ;      TX packets 0  byt= es 0 (0.0 B)        &= nbsp;TX errors 0  dropped 0 overruns 0&= nbsp; carrier 0  collisions 0</div><div> </div= ><div>        I= t seems that there is something wrong with the network or the storage. I g= ot the same error when the iscsi storage was replaced by an nfs storage. I= have deployed it on the same host using the same storage successfully&nbs= p;a few days ago, but now I can't. Anyone can= help? Thanks!</div>=0A</body></html> ------=_001_NextPart571367160775_=------

2 1

Hosted Engine 4.0.1 GUI takes long time to be available after Engine start
by Matt . 25 Jul '16

25 Jul '16

Hi guys, On a 4.0.1 install where I use an hosted engine the engine itself starts very quick, this works great. The issue I see happening is that when the engine is started it can take up to minutes before you can visit the GUI of the engine. Is this known and also happening on 3.6 ? Thanks! Matt

3 3