December 2016 - Users - oVirt List Archives

oVirt 3.6.7 upgrade to 4.0.5 and CentOS 7.3
by ovirt＠timmi.org 22 Dec '16

22 Dec '16

This is a multi-part message in MIME format. --------------32AAAA2813839A67E3A601C9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi oVirt List, I wanted to upgrade our oVirt 3.6.7 installation in the next couple of days to oVirt 4.0.5. My hosts are running CentOS 7.2 currently. It is safe to perform the upgrade also to CentOS 7.3? Is 4.0.5 also support this version of CentOS? It is correct that the upgrade to 4.0 is the same as always? Just I need to install the new repositories? I guess I have to delete the old 3.6 repos or not? |# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm # yum update "ovirt-engine-setup*" # engine-setup| Best regards and thank you for your answers Christoph --------------32AAAA2813839A67E3A601C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi oVirt List, I wanted to upgrade our oVirt 3.6.7 installation in the next couple of days to oVirt 4.0.5. My hosts are running CentOS 7.2 currently. It is safe to perform the upgrade also to CentOS 7.3? Is 4.0.5 also support this version of CentOS? It is correct that the upgrade to 4.0 is the same as always? Just I need to install the new repositories? I guess I have to delete the old 3.6 repos or not? <pre class="highlight plaintext"><code> # yum install <a class="moz-txt-link-freetext" href="http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm">http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm</a> # yum update "ovirt-engine-setup*" # engine-setup</code></pre> Best regards and thank you for your answers Christoph </body> </html> --------------32AAAA2813839A67E3A601C9--

1 0

oVirt / OVN / MTU
by Devin Acosta 22 Dec '16

22 Dec '16

We are running oVirt 4.0.5 and we have OVN working to provide a Virtual Layer 2 network. We are noticing that because the OVN is using Geneve and between all the firewalls and networks it crosses we are running into an MTU issue. What is the best suggested way to lower say the entire OVN network to say MTU of 1400, and also allow for fragmenting packets? -- Devin Acosta Red Hat Certified Architect, LinuxStack 602-354-1220 || devin(a)linuxguru.co

6 13

ovirtmgmt network change
by Bill Bill 22 Dec '16

22 Dec '16

--_000_SN2PR0801MB0752AB712D2E46F2E92CD53EA6900SN2PR0801MB0752_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhvdyBjYW4gdGhlIElQIG9mIHRoZSBob3N0cyBiZSBjaGFuZ2VkPyBJdCBpcyBn cmV5ZWQgb3V0IGFuZCBJIG5lZWQgdG8gY2hhbmdlIHRob3NlLiBJdOKAmXMgdGhlIG9ubHkgdGhp bmcgSeKAmW0gbm90IGFibGUgdG8gY2hhbmdlLi4NCg== --_000_SN2PR0801MB0752AB712D2E46F2E92CD53EA6900SN2PR0801MB0752_ Content-Type: text/html; charset="utf-8" Content-ID: <05640483046E4C41AD151F9E20E91A5C(a)sct-15-1-789-14-msonline-outlook-8b04f.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs bG8sPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ib3cgY2FuIHRoZSBJUCBvZiB0aGUgaG9zdHMgYmUgY2hhbmdlZD8g SXQgaXMgZ3JleWVkIG91dCBhbmQgSSBuZWVkIHRvIGNoYW5nZSB0aG9zZS4gSXTigJlzIHRoZSBv bmx5IHRoaW5nIEnigJltIG5vdCBhYmxlIHRvIGNoYW5nZS4uDQo8L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_SN2PR0801MB0752AB712D2E46F2E92CD53EA6900SN2PR0801MB0752_--

4 5

Regarding old mail access
by TranceWorldLogic . 21 Dec '16

21 Dec '16

Hi, While using this tool I try to do search and got some link (user ovirt mail links) where problem is already discussed. But when I try to open those link it not visible. Can some one help me to know how to view previous mail discussion ? Thanks, ~Rohit

2 1

EventProcessingPoolSize
by joost＠familiealbers.nl 21 Dec '16

21 Dec '16

Hi All, there is an engine config option named EventProcessingPoolSize: default value is 10. I am wondering how to determine what it is and if the setting is right for my setup. I have around 36 dc's at the moment with two hosts running between 2 -3 vm;s should this value be increased?

1 0

News from oVirt CI: Introducing 'build-on-demand'
by Eyal Edri 21 Dec '16

21 Dec '16

FYI, Following last announcement on the manual build from patch job [1], we got some feedback and requests from developers on ability to improve the flow of building artifacts from a patch. I'm happy to announce that after some coding, the infra team was able to add a new feature to the 'standard CI' framework, that will allow any oVirt project to build rpms from any VERSION or OS DISTRO using a single comment in the patch. Full details can be found on the new oVirt blog 'ci please build' [2], but to give the TL;DR version here, All you have to do is write '*ci please build*' on a comment and CI will trigger a job for you with new RPMs (or tarballs). The projects which already have this feature enabled are: - ovirt-engine - vdsm - vdsm-jsonrpc-java - ovirt-engine-dashboard Adding new project is a single line of code in the project YAML file and its fully described on the blog post [2], so feel free to add your project as well. So let the builds roll... Happy Xmas! [1] http://lists.phx.ovirt.org/pipermail/devel/2016-December/028967.html [2] https://www.ovirt.org/blog/2016/12/ci-please-build/ -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

Re: [ovirt-users] Python stack trace for VDSM while monitoring GlusterFS volumes in HC HE oVirt 3.6.7 / GlusterFS 3.7.17
by Giuseppe Ragusa 21 Dec '16

21 Dec '16

On Tue, Dec 20, 2016, at 09:16, Ramesh Nachimuthu wrote: > ----- Original Message ----- > > From: "Giuseppe Ragusa" <giuseppe.ragusa(a)hotmail.com> > > To: "Ramesh Nachimuthu" <rnachimu(a)redhat.com> > > Cc: users(a)ovirt.org, gluster-users(a)gluster.org, "Ravishankar Narayanankutty" <ranaraya(a)redhat.com> > > Sent: Tuesday, December 20, 2016 4:15:18 AM > > Subject: Re: [ovirt-users] Python stack trace for VDSM while monitoring GlusterFS volumes in HC HE oVirt 3.6.7 / > > GlusterFS 3.7.17 > > > > On Fri, Dec 16, 2016, at 05:44, Ramesh Nachimuthu wrote: > > > ----- Original Message ----- > > > > From: "Giuseppe Ragusa" <giuseppe.ragusa(a)hotmail.com> > > > > To: "Ramesh Nachimuthu" <rnachimu(a)redhat.com> > > > > Cc: users(a)ovirt.org > > > > Sent: Friday, December 16, 2016 2:42:18 AM > > > > Subject: Re: [ovirt-users] Python stack trace for VDSM while monitoring > > > > GlusterFS volumes in HC HE oVirt 3.6.7 / > > > > GlusterFS 3.7.17 > > > > > > > > Giuseppe Ragusa ha condiviso un file di OneDrive. Per visualizzarlo, fare > > > > clic sul collegamento seguente. > > > > > > > > > > > > <https://1drv.ms/u/s!Am_io8oW4r10bw5KMtEtKgpcRoI> > > > > [https://r1.res.office365.com/owa/prem/images/dc-generic_20.png]<https://1drv.ms/u/s!Am_io8oW4r10bw5KMtEtKgpcRoI> > > > > > > > > vols.tar.gz<https://1drv.ms/u/s!Am_io8oW4r10bw5KMtEtKgpcRoI> > > > > > > > > > > > > > > > > Da: Ramesh Nachimuthu <rnachimu(a)redhat.com> > > > > Inviato: lunedì 12 dicembre 2016 09.32 > > > > A: Giuseppe Ragusa > > > > Cc: users(a)ovirt.org > > > > Oggetto: Re: [ovirt-users] Python stack trace for VDSM while monitoring > > > > GlusterFS volumes in HC HE oVirt 3.6.7 / GlusterFS 3.7.17 > > > > > > > > On 12/09/2016 08:50 PM, Giuseppe Ragusa wrote: > > > > > Hi all, > > > > > > > > > > I'm writing to ask about the following problem (in a HC HE oVirt 3.6.7 > > > > > GlusterFS 3.7.17 3-hosts-replica-with-arbiter sharded-volumes setup all > > > > > on > > > > > CentOS 7.2): > > > > > > > > > > From /var/log/messages: > > > > > > > > > > Dec 9 15:27:46 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > Dec 9 15:27:47 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore:Extracting > > > > > Engine > > > > > VM OVF from the OVF_STORE > > > > > Dec 9 15:27:47 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore:OVF_STORE volume > > > > > path: > > > > > /rhev/data-center/mnt/glusterSD/shockley.gluster.private:_enginedomain/1d60fd45-507d-4a78-8294-d642b3178ea3/images/22a172de-698e-4cc5-bff0-082882fb3347/8738287c-8a25-4a2a-a53a-65c366a972a1 > > > > > Dec 9 15:27:47 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config:Found > > > > > an OVF for HE VM, trying to convert > > > > > Dec 9 15:27:47 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config:Got > > > > > vm.conf from OVF_STORE > > > > > Dec 9 15:27:47 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Current > > > > > state > > > > > EngineUp (score: 3400) > > > > > Dec 9 15:27:47 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Best > > > > > remote > > > > > host read.mgmt.private (id: 2, score: 3400) > > > > > Dec 9 15:27:48 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > established > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > closed > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > established > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > closed > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > established > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > closed > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > established > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > closed > > > > > Dec 9 15:27:48 shockley ovirt-ha-broker: > > > > > INFO:mem_free.MemFree:memFree: > > > > > 7392 > > > > > Dec 9 15:27:50 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > Dec 9 15:27:52 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > Dec 9 15:27:54 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > Dec 9 15:27:55 shockley ovirt-ha-broker: > > > > > INFO:cpu_load_no_engine.EngineHealth:System load total=0.1234, > > > > > engine=0.0364, non-engine=0.0869 > > > > > Dec 9 15:27:57 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Initializing > > > > > VDSM > > > > > Dec 9 15:27:57 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Connecting > > > > > the storage > > > > > Dec 9 15:27:58 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > Dec 9 15:27:58 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting > > > > > storage server > > > > > Dec 9 15:27:58 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting > > > > > storage server > > > > > Dec 9 15:27:59 shockley ovirt-ha-agent: > > > > > INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Refreshing > > > > > the storage domain > > > > > Dec 9 15:27:59 shockley ovirt-ha-broker: > > > > > INFO:ovirt_hosted_engine_ha.broker.listener.ConnectionHandler:Connection > > > > > established > > > > > Dec 9 15:27:59 shockley journal: vdsm jsonrpc.JsonRpcServer ERROR > > > > > Internal > > > > > server error#012Traceback (most recent call last):#012 File > > > > > "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 533, in > > > > > _serveRequest#012 res = method(**params)#012 File > > > > > "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod#012 > > > > > result > > > > > = fn(*methodArgs)#012 File "/usr/share/vdsm/gluster/apiwrapper.py", > > > > > line > > > > > 117, in status#012 return self._gluster.volumeStatus(volumeName, > > > > > brick, > > > > > statusOption)#012 File "/usr/share/vdsm/gluster/api.py", line 86, in > > > > > wrapper#012 rv = func(*args, **kwargs)#012 File > > > > > "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus#012 > > > > > statusOption)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in > > > > > __call__#012 return callMethod()#012 File > > > > > "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 > > > > > **kwargs)#012 > > > > > File "<string>", line 2, in glusterVolumeStatus#012 File > > > > > "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _ca > > > > > llmethod#012 raise convert_to_error(kind, result)#012KeyError: > > > > > 'device' > > > > > > > > > > From /var/log/vdsm/vdsm.log: > > > > > > > > > > jsonrpc.Executor/1::ERROR::2016-12-09 > > > > > 15:27:46,870::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > jsonrpc.Executor/5::ERROR::2016-12-09 > > > > > 15:27:48,627::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > jsonrpc.Executor/7::ERROR::2016-12-09 > > > > > 15:27:50,164::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > jsonrpc.Executor/0::ERROR::2016-12-09 > > > > > 15:27:52,804::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > jsonrpc.Executor/5::ERROR::2016-12-09 > > > > > 15:27:54,679::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > jsonrpc.Executor/2::ERROR::2016-12-09 > > > > > 15:27:58,349::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > jsonrpc.Executor/4::ERROR::2016-12-09 > > > > > 15:27:59,169::__init__::538::jsonrpc.JsonRpcServer::(_serveRequest) > > > > > Internal server error > > > > > Traceback (most recent call last): > > > > > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > > > > > 533, > > > > > in _serveRequest > > > > > res = method(**params) > > > > > File "/usr/share/vdsm/rpc/Bridge.py", line 275, in _dynamicMethod > > > > > result = fn(*methodArgs) > > > > > File "/usr/share/vdsm/gluster/apiwrapper.py", line 117, in status > > > > > return self._gluster.volumeStatus(volumeName, brick, statusOption) > > > > > File "/usr/share/vdsm/gluster/api.py", line 86, in wrapper > > > > > rv = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/api.py", line 407, in volumeStatus > > > > > statusOption) > > > > > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ > > > > > return callMethod() > > > > > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> > > > > > **kwargs) > > > > > File "<string>", line 2, in glusterVolumeStatus > > > > > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, > > > > > in > > > > > _callmethod > > > > > raise convert_to_error(kind, result) > > > > > KeyError: 'device' > > > > > > > > > > From /var/log/vdsm/supervdsm.log: > > > > > > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > MainProcess|jsonrpc.Executor/5::ERROR::2016-12-09 > > > > > 15:27:48,625::supervdsmServer::120::SuperVdsm.ServerCallback::(wrapper) > > > > > Error in wrapper > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > MainProcess|jsonrpc.Executor/7::ERROR::2016-12-09 > > > > > 15:27:50,163::supervdsmServer::120::SuperVdsm.ServerCallback::(wrapper) > > > > > Error in wrapper > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > MainProcess|jsonrpc.Executor/0::ERROR::2016-12-09 > > > > > 15:27:52,803::supervdsmServer::120::SuperVdsm.ServerCallback::(wrapper) > > > > > Error in wrapper > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > MainProcess|jsonrpc.Executor/5::ERROR::2016-12-09 > > > > > 15:27:54,677::supervdsmServer::120::SuperVdsm.ServerCallback::(wrapper) > > > > > Error in wrapper > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > MainProcess|jsonrpc.Executor/2::ERROR::2016-12-09 > > > > > 15:27:58,348::supervdsmServer::120::SuperVdsm.ServerCallback::(wrapper) > > > > > Error in wrapper > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > MainProcess|jsonrpc.Executor/4::ERROR::2016-12-09 > > > > > 15:27:59,168::supervdsmServer::120::SuperVdsm.ServerCallback::(wrapper) > > > > > Error in wrapper > > > > > Traceback (most recent call last): > > > > > File "/usr/share/vdsm/supervdsmServer", line 118, in wrapper > > > > > res = func(*args, **kwargs) > > > > > File "/usr/share/vdsm/supervdsmServer", line 534, in wrapper > > > > > return func(*args, **kwargs) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 352, in volumeStatus > > > > > return _parseVolumeStatusDetail(xmltree) > > > > > File "/usr/share/vdsm/gluster/cli.py", line 216, in > > > > > _parseVolumeStatusDetail > > > > > 'device': value['device'], > > > > > KeyError: 'device' > > > > > > > > > > Please note that the whole oVirt cluster is working (apparently) as it > > > > > should, but due to a known limitation with split-GlusterFS-network > > > > > setup > > > > > (http://lists.ovirt.org/pipermail/users/2016-August/042119.html solved > > > > > in > > > > > https://gerrit.ovirt.org/#/c/60083/ but maybe not backported to 3.6.x > > > > > or > > > > > present only in nightly later than 3.6.7, right?) GlusterFS volumes are > > > > > being managed from the hosts commandline only, while the oVirt Engine > > > > > webui is used only to monitor them. > > > > > > > > > > The GlusterFS part is currently experiencing some recurring NFS crashes > > > > > (using internal GlusterFS NFS support, not NFS-Ganesha) as reported in > > > > > Gluster users mailing list and in Bugzilla > > > > > (http://www.gluster.org/pipermail/gluster-users/2016-December/029357.html > > > > > and https://bugzilla.redhat.com/show_bug.cgi?id=1381970 without any > > > > > feedback insofar...) but only on not-oVirt-related volumes. > > > > > > > > > > Finally, I can confirm that checking all oVirt-related and > > > > > not-oVirt-related GlusterFS volumes from the hosts commandline with: > > > > > > > > > > vdsClient -s localhost glusterVolumeStatus volumeName=nomevolume > > > > > > > > Can you post the output of 'gluster volume status <vol-name> detail > > > > --xml'. > > > > > > > > Regards, > > > > Ramesh > > > > > > > > Hi Ramesh, > > > > > > > > Please find attached all the output produced with the following command: > > > > > > > > for vol in $(gluster volume list); do gluster volume status ${vol} detail > > > > --xml > ${vol}.xml; res=$?; echo "Exit ${res} for volume ${vol}"; done > > > > > > > > Please note that the exit code was always zero. > > > > > > > > > > +gluster-users > > > > > > This seems to be a bug in Glusterfs 3.7.17. Output of 'gluster volume > > > status <vol-name> details --xml ' should have a <device> element for all > > > the bricks in the volume. But it missing for the arbiter brick. This issue > > > is not re-producible in Gulsterfs-3.8. > > > > Do I need to open a GlusterFS bug for this on 3.7? > > Looking at the changelog, it does not seem to have been fixed in 3.7.18 nor > > to be among the already known issues. > > > > Please open a bug against Glusterfs 3.7.17. Done: https://bugzilla.redhat.com/show_bug.cgi?id=1406569 > > On the oVirt side: is GlusterFS 3.8 compatible with oVirt 3.6.x (maybe with x > > > 7 ie using nightly snapshots)? > > > > You can upgrade to GlusterFS 3.8. It is compatible with oVirt 3.6. > > Note: You may have to add the GlusterFS 3.8 repo manually from https://download.gluster.org/pub/gluster/glusterfs/3.8/LATEST/. Many thanks for your advice and for your help. Do you happen to know whether the split-GlusterFS-network limitation in oVirt 3.6.7 has been fixed (backporting https://gerrit.ovirt.org/#/c/60083/ ) in latest oVirt 3.6.x (unsupported, I know...) nightly snapshot releases? Many thanks again. Regards, Giuseppe > Regards, > Ramesh > > > Many thanks. > > > > Regards, > > Giuseppe > > > > > Regards, > > > Ramesh > > > > > > > > > > Many thanks for you help. > > > > > > > > Best regards, > > > > Giuseppe > > > > > > > > > > > > > > > > > > always succeeds without errors. > > > > > > > > > > Many thanks in advance for any advice (please note that I'm planning to > > > > > upgrade from 3.6.7 to latest nightly 3.6.10.x as soon as the > > > > > corresponding > > > > > RHEV gets announced, then later on all the way up to 4.1.0 as soon as > > > > > it > > > > > stabilizes; on GlusterFS-side I'd like to upgrade asap to 3.8.x but I > > > > > cannot find any hint on oVirt 3.6.x compatibility...). > > > > > > > > > > Best regards, > > > > > Giuseppe > > > > > > > > > > PS: please keep my address in to/copy since I still have problems > > > > > receiving > > > > > oVirt mailing list messages on Hotmail. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Users mailing list > > > > > Users(a)ovirt.org > > > > > http://lists.phx.ovirt.org/mailman/listinfo/users > > > > > > > > > > > > > >

1 0

Adding Disk stuck?
by Pat Riehecky 20 Dec '16

20 Dec '16

Last Friday I started a job to add 1 new disk to each of 4 VMs - total of 4 disks each 100G. It seems to still be running, but no host shows an obvious IO load. State is Adding Disk (hour glass) -> Validating (green check mark) -> Executing (hour glass) ->-> Creating Volume (green check mark) I checked in with: /usr/share/ovirt-engine/setup/dbutils/taskcleaner.sh and it didn't show anything interesting. The VMs themselves show the disks are there, but the VMs are still locked by the disk processes. Ideas? Pat -- Pat Riehecky Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

2 3

Iso Upload
by Koen Vanoppen 20 Dec '16

20 Dec '16

Dear All, I thougt it was possible to upload an iso to ovirt 4 now. But for some reason I didn't manage to do it. If I try to upload a iso in the disk section ov the gui, I'm always getting the following message: Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registred as a vailid ca in the browser. ovirt-image-io-proxy is installed. Already rerun engine-setup... But still the image get's paused when I try to upload it... Any ideas?

6 8

Failed to import Hosted Engine VM
by knarra 20 Dec '16

20 Dec '16

Hi, I have latest master installed and i see that Hosted Engine VM fails to import. Below are the logs i see in the engine log. Can some one help me understand why does this happen? 2016-12-20 06:46:02,291Z INFO [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] START, GetImageInfoVDSComman d( GetImageInfoVDSCommandParameters:{runAsync='true', storagePoolId='00000001-0001-0001-0001-000000000311', ignoreFailoverLimit='false', storageDomainId='4830f5b2-5a7d-4a89- 8fc9-8911134035e4', imageGroupId='0dec26c2-59c8-4d7f-adc0-6e4c878028ee', imageId='e1133334-9f08-4e71-9b3a-d6a93273fbd3'}), log id: 78f8a633 2016-12-20 06:46:02,291Z INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] START, GetVolumeInfoVDSComm and(HostName = hosted_engine1, GetVolumeInfoVDSCommandParameters:{runAsync='true', hostId='4c4a3633-2c2a-49c9-be06-78a21a4a2584', storagePoolId='00000001-0001-0001-0001-0000 00000311', storageDomainId='4830f5b2-5a7d-4a89-8fc9-8911134035e4', imageGroupId='0dec26c2-59c8-4d7f-adc0-6e4c878028ee', imageId='e1133334-9f08-4e71-9b3a-d6a93273fbd3'}), log id: 62a0b308 2016-12-20 06:46:02,434Z ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] Failed building DiskImage: No enum const org.ovirt.engine.core.common.businessentities.LeaseState.{owners=[Ljava.lang.Object;@28beccfa, version=2} 2016-12-20 06:46:02,434Z INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] Command 'org.ovirt.engine.c ore.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand' return value ' VolumeInfoReturn:{status='Status [code=0, message=Done]'} status = OK domain = 4830f5b2-5a7d-4a89-8fc9-8911134035e4 voltype = LEAF description = Hosted Engine Image parent = 00000000-0000-0000-0000-000000000000 format = RAW generation = 0 image = 0dec26c2-59c8-4d7f-adc0-6e4c878028ee ctime = 1482153085 disktype = 2 legality = LEGAL mtime = 0 apparentsize = 53687091200 children: [] pool = capacity = 53687091200 uuid = e1133334-9f08-4e71-9b3a-d6a93273fbd3 truesize = 2761210368 type = SPARSE lease: owners: [1] version = 2 ' 2016-12-20 06:46:02,434Z INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] HostName = hosted_engine1 2016-12-20 06:46:02,434Z INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] FINISH, GetVolumeInfoVDSCommand, log id: 62a0b308 2016-12-20 06:46:02,434Z ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] Failed to get the volume information, marking as FAILED 2016-12-20 06:46:02,434Z INFO [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] FINISH, GetImageInfoVDSCommand, log id: 78f8a633 2016-12-20 06:46:02,434Z WARN [org.ovirt.engine.core.bll.exportimport.ImportVmCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] Validation of action 'ImportVm' failed for user SYSTEM. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,ACTION_TYPE_FAILED_VM_IMAGE_DOES_NOT_EXIST 2016-12-20 06:46:02,435Z INFO [org.ovirt.engine.core.bll.exportimport.ImportVmCommand] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] Lock freed to object 'EngineLock:{exclusiveLocks='[89681893-94fe-4366-be6d-15141ff2b365=<VM, ACTION_TYPE_FAILED_VM_IS_BEING_IMPORTED$VmName HostedEngine>, HostedEngine=<VM_NAME, ACTION_TYPE_FAILED_NAME_ALREADY_USED>]', sharedLocks='[89681893-94fe-4366-be6d-15141ff2b365=<REMOTE_VM, ACTION_TYPE_FAILED_VM_IS_BEING_IMPORTED$VmName HostedEngine>]'}' 2016-12-20 06:46:02,435Z ERROR [org.ovirt.engine.core.bll.HostedEngineImporter] (org.ovirt.thread.pool-6-thread-48) [77f83e0f] Failed importing the Hosted Engine VM 2016-12-20 06:46:04,436Z INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (DefaultQuartzScheduler4) [2d8b8a56] FINISH, GlusterServersListVDSCommand, return: [10.70.36.79/23:CONNECTED, 10.70.36.80:CONNECTED, 10.70.36.81:CONNECTED], log id: 617781b7 Thanks kasturi.

2 2