- Users - oVirt List Archives

listing domains fails
by Fabrice Bacchella 31 May '16

31 May '16

--Apple-Mail=_943A44EE-DB36-4E2B-A9A5-F7AE7F010E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm trying to list domains using the api, and I'm getting a strange = message : > GET /api/storagedomains;case_sensitive=3DTrue HTTP/1.1 ... > Version: 3 > Content-Type: application/xml > Accept: application/xml > Filter: False > Prefer: persistent-auth > Content-Length: 0 < HTTP/1.1 404 Not Found < <?xml version=3D"1.0" encoding=3D"UTF-8" standalone=3D"yes"?> < <fault> < <reason>Operation Failed</reason> < <detail>Entity not found: Storage server connection: = id=3D6860d96f-557e-4d82-a209-401d72bd6e16</detail> < </fault> And in engine.log, I got: Before: 2016-05-30 13:07:31,017 INFO = [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSComma= nd] (default task-25) [4c2e1822] START, = DisconnectStorageServerVDSCommand(HostName =3D ng320, = StorageServerConnectionManagementVDSParameters:{runAsync=3D'true', = hostId=3D'4426ed42-0805-43b1-92d9-3e5a680eaf38', = storagePoolId=3D'00000000-0000-0000-0000-000000000000', = storageType=3D'LOCALFS', = connectionList=3D'[StorageServerConnections:{id=3D'6860d96f-557e-4d82-a209= -401d72bd6e16', connection=3D'/data/ovirt/data', iqn=3D'null', = vfsType=3D'null', mountOptions=3D'null', nfsVersion=3D'null', = nfsRetrans=3D'null', nfsTimeo=3D'null', iface=3D'null', = netIfaceName=3D'null'}]'}), log id: 63f890 ... 2016-05-30 13:07:32,312 INFO = [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSComma= nd] (default task-25) [4c2e1822] FINISH, = DisconnectStorageServerVDSCommand, return: = {6860d96f-557e-4d82-a209-401d72bd6e16=3D0}, log id: 63f890 When I run the command: 2016-05-31 15:34:11,259 ERROR = [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default = task-13) [] Operation Failed: Entity not found: Storage server = connection: id=3D6860d96f-557e-4d82-a209-401d72bd6e16 What's wrong ?= --Apple-Mail=_943A44EE-DB36-4E2B-A9A5-F7AE7F010E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I'm trying to list domains using the api, and I'm getting a = strange message :<div class=3D""><br class=3D""></div><div class=3D""><div= style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">> GET = /api/storagedomains;case_sensitive=3DTrue = HTTP/1.1</font></div></div><div class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">...</font></div><div class=3D""><div= style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">> Version: 3</font></div><div = style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">> Content-Type: application/xml</font></div><div = style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">> Accept: application/xml</font></div><div = style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">> Filter: False</font></div><div style=3D"margin: = 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" = class=3D"">> Prefer: persistent-auth</font></div><div style=3D"margin: = 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" = class=3D"">> Content-Length: 0</font></div></div><div class=3D""><font = face=3D"Menlo" style=3D"font-size: 11px;" class=3D""><br = class=3D""></font></div><div class=3D""><div style=3D"margin: 0px;" = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D""><= HTTP/1.1 404 Not Found</font></div></div><div class=3D""><div = style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">< <?xml version=3D"1.0" encoding=3D"UTF-8" = standalone=3D"yes"?></font></div><div style=3D"margin: 0px;" = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D""><= <fault></font></div><div style=3D"margin: 0px;" class=3D""><font = face=3D"Menlo" style=3D"font-size: 11px;" class=3D""><     = <reason>Operation Failed</reason></font></div><div = style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D""><     <detail>Entity not found: = Storage server connection: = id=3D6860d96f-557e-4d82-a209-401d72bd6e16</detail></font></div><div = style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">< </fault></font></div></div><div = class=3D""><br class=3D""></div><div class=3D"">And in engine.log, I = got:</div><div class=3D"">Before:</div><div class=3D""><font = face=3D"Menlo" class=3D""><span style=3D"font-size: 11px;" = class=3D"">2016-05-30 13:07:31,017 = INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStora= geServerVDSCommand] (default task-25) [4c2e1822] START, = DisconnectStorageServerVDSCommand(HostName =3D ng320, = StorageServerConnectionManagementVDSParameters:{runAsync=3D'true', ho= stId=3D'4426ed42-0805-43b1-92d9-3e5a680eaf38', = storagePoolId=3D'00000000-0000-0000-0000-000000000000', = storageType=3D'LOCALFS', connectionList=3D'[StorageServerConnections:= {id=3D'6860d96f-557e-4d82-a209-401d72bd6e16', = connection=3D'/data/ovirt/data', iqn=3D'null', vfsType=3D'null', = mountOptions=3D'null', nfsVersion=3D'null', nfsRetrans=3D'null', = nfsTimeo=3D'null', iface=3D'null', netIfaceName=3D'null'}]'}), = log id: 63f890<br class=3D"">...</span></font></div><div = class=3D""><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">2016-05-30 13:07:32,312 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSComma= nd] (default task-25) [4c2e1822] FINISH, = DisconnectStorageServerVDSCommand, return: = {6860d96f-557e-4d82-a209-401d72bd6e16=3D0}, log id: 63f890</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D""><br= class=3D""></div><div style=3D"margin: 0px;" class=3D"">When I run the = command:</div><div style=3D"margin: 0px;" class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">2016-05-31 15:34:11,259 ERROR = [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default = task-13) [] Operation Failed: Entity not found: Storage server = connection: = id=3D6860d96f-557e-4d82-a209-401d72bd6e16</font></div></div><div = style=3D"margin: 0px;" class=3D""><br class=3D""></div><div = style=3D"margin: 0px;" class=3D"">What's wrong ?</div></body></html>= --Apple-Mail=_943A44EE-DB36-4E2B-A9A5-F7AE7F010E4A--

1 0

VMs using hugepages
by Ralf Schenk 31 May '16

31 May '16

This is a multi-part message in MIME format. --------------1F41AA982CD26EC47BC0B407 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, I try to get VM's to use hugepages by default. We use them on our manual VM's set up for libvirt and experience performance advantages. I installed vdsm-hook-hugepages, but according to http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/ I have to set hugepages=SIZE. Engine Web-Fronted doesn't show an option anywhere to specify this. I want the VMs to have: <memoryBacking> <hugepages/> </memoryBacking> Any hint ? Versions: vdsm.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-cli.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-gluster.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-hook-hugepages.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-hook-vmfex-dev.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-infra.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-jsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-python.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-xmlrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-yajsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 Engine: ovirt-engine.noarch 3.6.6.2-1.el7.centos @ovirt-3.6 -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------1F41AA982CD26EC47BC0B407 Content-Type: multipart/related; boundary="------------42116FB0C46FABA6A6982AF7" --------------42116FB0C46FABA6A6982AF7 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"> <p>Hello,</p> <p>I try to get VM's to use hugepages by default. We use them on our manual VM's set up for libvirt and experience performance advantages. I installed vdsm-hook-hugepages, but according to <a class="moz-txt-link-freetext" href="http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/">http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/</a> I have to set hugepages=SIZE. Engine Web-Fronted doesn't show an option anywhere to specify this. <br> </p> <p>I want the VMs to have:</p> <p><tt> <memoryBacking><br> <hugepages/><br> </memoryBacking><br> </tt><br> </p> <p>Any hint ?<br> </p> <p>Versions:</p> <p><tt>vdsm.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-cli.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-gluster.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-hook-hugepages.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-hook-vmfex-dev.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-infra.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-jsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-python.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-xmlrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-yajsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><br> </p> Engine:<br> ovirt-engine.noarch 3.6.6.2-1.el7.centos @ovirt-3.6<br> <br> <div class="moz-signature">-- <br> <p> </p> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.FD451D75.B4E6C315@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Ralf Schenk</b><br> fon +49 (0) 24 05 / 40 83 70<br> fax +49 (0) 24 05 / 40 83 759<br> mail <a href="mailto:rs@databay.de"><font color="#FF0000"><b>rs(a)databay.de</b></font></a><br> </font> </td> <td width="30"> </td> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Databay AG</b><br> Jens-Otto-Krag-Straße 11<br> D-52146 Würselen<br> <a href="http://www.databay.de"><font color="#FF0000"><b>www.databay.de</b></font></a> </font> </td> </tr> <tr> <td colspan="3" valign="top"> <font face="Verdana, Arial, sans-serif" size="1"><br> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202<br> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns<br> Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </font> </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------42116FB0C46FABA6A6982AF7 Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.FD451D75.B4E6C315(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------42116FB0C46FABA6A6982AF7-- --------------1F41AA982CD26EC47BC0B407--

2 1

Clone, template, pools : how does it uses disk space ?
by Alexis HAUSER 31 May '16

31 May '16

Hi, I would like to know what happens to storage when using the different method of cloning or generating VMs using templates / pools. I'd like to know also in what case VM and virtual disks are totally independent and in what case they are not. Sadly the RHEV documentation doesn't really provide these informations and I don't find any explicit informations about it. For example, when making a VM from template, using pre-allocated disk option, for a 50GB Virtual disk, it only uses 3GB on the physical disk. Another example, when making a pool of 10 VMs, based on a VM with a 50 GB virtual disk, only 2GB more space is used on the physical disk. What is exactly done when this happens ? Here are the case I would like to have informations about (physical storage, and independence of VMs) : - using simple "clone function" - making VM from template with "clone" mode - making VM from template with "thin" mode - making VM in pools Is there modes calculating only the difference from the original VM, and other modes copying totally the informations from the virtual disk from the original VM ?

3 3

Re: [ovirt-users] oVirt 4.0 hosted-engine deploy exits without messages or logs
by Gianluca Cecchi 31 May '16

31 May '16

On Fri, May 13, 2016 at 10:43 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > wrote: > On Thu, May 12, 2016 at 3:32 PM, Sandro Bonazzola wrote: > >> >> >> >> I strongly suggest to use master. In particular, I strongly suggest to us >> oVirt Node Next ISO for hosts and the engine appliance for the deployment. >> Installing Hosted Engine using Cockpit Web UI has been a nice experience >> yesterday. >> https://twitter.com/SandroBonazzola/status/730426730515673092 >> >> Be sure to install also the new dashboard package once your Hosted Engine >> is up, that's another nice thing to see in action. >> >> > It seems master from yesterday, attempting self hosted engine on nfs3 with > hypervisor on CentOS 7.2 gives: > > [ INFO ] Stage: Transaction setup > [ INFO ] Stage: Misc configuration > [ INFO ] Stage: Package installation > [ INFO ] Stage: Misc configuration > [ INFO ] Configuring libvirt > [ INFO ] Configuring VDSM > [ INFO ] Starting vdsmd > [ INFO ] Creating Storage Domain > [ INFO ] Creating Storage Pool > [ INFO ] Connecting Storage Pool > [ INFO ] Verifying sanlock lockspace initialization > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] > Network is unreachable > [ INFO ] Stage: Clean up > > It seems I get the same problem with 4.0 beta too... At least basic sh engine install should work in a beta, I think.... [ INFO ] Creating Storage Domain [ INFO ] Creating Storage Pool [ INFO ] Connecting Storage Pool [ INFO ] Verifying sanlock lockspace initialization [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20160531110857.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Hosted Engine deployment failed: this system is not reliable, please check the issue, fix and redeploy Inside ovirt-hosted-engine-setup initially I see an error about SSL and vdsmd May 31 11:03:58 ovirtita.localdomain.local vdsm[8571]: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected eof 2016-05-31 11:04:36 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'status', 'vdsmd.service') stderr: I see it also inside messages And then 2016-05-31 11:08:51 DEBUG otopi.plugins.gr_he_setup.sanlock.lockspace storage_backends.create_volume :270 Connecting to VDSM 2016-05-31 11:08:51 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-setup/sanlock/lockspace.py", l ine 143, in _misc lockspace + '.metadata': md_size, File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 369, in create service_size=size) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 279, in create_volume volUUID=volume_uuid File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 245, in _get_volume_path volUUID File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1301, in single_request self.send_content(h, request_body) File "/usr/lib64/python2.7/xmlrpclib.py", line 1448, in send_content connection.endheaders(request_body) File "/usr/lib64/python2.7/httplib.py", line 975, in endheaders self._send_output(message_body) File "/usr/lib64/python2.7/httplib.py", line 835, in _send_output self.send(msg) File "/usr/lib64/python2.7/httplib.py", line 797, in send self.connect() File "/usr/lib/python2.7/site-packages/vdsm/m2cutils.py", line 203, in connect sock = socket.create_connection((self.host, self.port), self.timeout) File "/usr/lib64/python2.7/socket.py", line 571, in create_connection raise err error: [Errno 101] Network is unreachable 2016-05-31 11:08:51 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable 2016-05-31 11:08:51 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/etc/ovirt-hosted-engine/firewalld/hosted-console.xml'' 2016-05-31 11:08:51 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/etc/ovirt-hosted-engine/iptables.example'' 2016-05-31 11:08:51 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/etc/sysconfig/iptables'' The NFS file system is indeed mounted together with a loop device /dev/loop1 2.0G 3.1M 1.9G 1% /rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ ovirtita.localdomain.local:/SHE_DOMAIN 25G 34M 25G 1% /rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN And getting this in messages: May 31 11:03:51 ovirtita rpc.mountd[937]: authenticated mount request from 192.168.122.51:668 for /S HE_DOMAIN (/SHE_DOMAIN) May 31 11:03:51 ovirtita rpc.mountd[937]: authenticated unmount request from 192.168.122.51:927 for /SHE_DOMAIN (/SHE_DOMAIN) May 31 11:03:51 ovirtita journal: vdsm SchemaCache WARNING Provided value "1" not defined in Storage DomainType enum for StoragePool.connectStorageServer May 31 11:03:51 ovirtita journal: vdsm SchemaCache WARNING Provided parameters {u'protocol_version': 3, u'connection': u'ovirtita.localdomain.local:/SHE_DOMAIN', u'user': u'kvm', u'id': u'd8094512-9c9 e-4138-abbb-20715ea7fb96'} do not match any of union ConnectionRefParameters values May 31 11:03:51 ovirtita rpc.mountd[937]: authenticated mount request from 192.168.122.51:899 for /S HE_DOMAIN (/SHE_DOMAIN) sanlock.log contains the lines below. It seems strange the truncate of hostname from "ovirtita.localdomain.local" to "ovirtita.l" in many lines 2016-05-31 11:07:42+0200 6143 [8341]: s1 lockspace 9501187c-41a3-4e80-aa97-772bacae4c84:250:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/dom_ md/ids:0 2016-05-31 11:08:03+0200 6164 [8342]: s1:r1 resource 9501187c-41a3-4e80-aa97-772bacae4c84:SDM:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/do m_md/leases:1048576 for 3,11,9192 2016-05-31 11:08:03+0200 6164 [8342]: s2 lockspace cd9f23e2-1b3b-46fb-bf56-8687958c4ff8:250:/rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN/cd9f23e2-1b3b-46fb-bf56-8687958c4ff8/dom_md/ids:0 2016-05-31 11:08:03+0200 6164 [8327]: s1 host 250 1 6143 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:24+0200 6185 [8341]: s2:r2 resource cd9f23e2-1b3b-46fb-bf56-8687958c4ff8:SDM:/rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN/cd9f23e2-1b3b-46fb-bf56-8687958c4ff8/dom_md/ leases:1048576 for 3,11,9192 2016-05-31 11:08:24+0200 6185 [8327]: s2 host 250 1 6164 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:30+0200 6191 [8342]: s3 lockspace 9501187c-41a3-4e80-aa97-772bacae4c84:1:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/dom_md /ids:0 2016-05-31 11:08:30+0200 6191 [8341]: s4 lockspace cd9f23e2-1b3b-46fb-bf56-8687958c4ff8:1:/rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN/cd9f23e2-1b3b-46fb-bf56-8687958c4ff8/dom_md/ids:0 2016-05-31 11:08:51+0200 6212 [8327]: s4 host 1 1 6191 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [8327]: s4 host 250 1 0 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [8327]: s3 host 1 1 6191 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [8327]: s3 host 250 1 0 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [9662]: s3:r3 resource 9501187c-41a3-4e80-aa97-772bacae4c84:SDM:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/dom_md/leases:1048576 for 3,11,9192 2016-05-31 11:11:31+0200 6372 [8342]: s5 lockspace d260b12c-3bf2-405a-9537-2949064e58b5:250:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpugQ9c3/d260b12c-3bf2-405a-9537-2949064e58b5/dom_md/ids:0 Any way to understand why the "create_connect" fails and why it decodes it as "Network unreachable"? BTW: during setup I see this message [WARNING] Cannot locate gluster packages, Hyper Converged setup support will be disabled. Does it mean hyper converged setup could be supported in 4.0? Thanks, Gianluca

1 0

Re: [ovirt-users] On 3.6.6, tried doing a live VM storage migration... didn't work
by Markus Stockhausen 31 May '16

31 May '16

------=_NextPartTM-000-7fc17005-f5d8-4745-92f6-4a4dc02fab36 Content-Type: multipart/alternative; boundary="_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_" --_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IG9mIGF0IGxlYXN0IG9uZSBsaXZlIERpc2sgTWlncmF0aW9uIGlzc3VlIHdpdGggTXVs dGkgRGlzayBWTXMuDQoNCmh0dHBzOi8vYnVnemlsbGEucmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/ aWQ9MTMxOTQwMA0KDQpNaWdodCBiZSB0b3RhbGx5IGRpZmZlcmVudCBidXQgSSBtdXN0IGFkbWl0 IHRoYXQgdGhpcyBmZWF0dXJlIGhhZCBzZXZlcmFsIHVwcyBhbmQgZG93bnMgdGhlIGxhc3QgeWVh cnMuDQoNCk1hcmt1cw0KDQpBbSAyNi4wNS4yMDE2IDM6NTAgdm9ybS4gc2NocmllYiBDaHJpc3Rv cGhlciBDb3ggPGNjb3hAZW5kbGVzc25vdy5jb20+Og0KSW4gb3VyIG9sZCAzLjQgb3ZpcnQsIEkg a25vdyBJJ3ZlIG1pZ3JhdGVkIHN0b3JhZ2Ugb24gbGl2ZSBWTXMgYW5kIGV2ZXJ5dGhpbmcNCnNl ZW1lZCB0byB3b3JrLg0KDQpIb3dldmVyIG9uIDMuNi42LCBJIHRyaWVkIHRoaXMgYW5kIEkgc2F3 IHRoZSB3YXJuaW5nIGFib3V0IG1vdmluZyBzdG9yYWdlIG9uIGENCmxpdmUgVk0gKGl0IHdhc24n dCBkb2luZyBtdWNoIG9mIGFueXRoaW5nKSBhbmQgSSB3ZW50IGFoZWFkIGFuZCBtaWdyYXRlZCB0 aGUNCnN0b3JhZ2UgZnJvbSBvbmUgc3RvcmFnZSBkb21haW4gdG8gYW5vdGhlci4gICBCdXQgd2hl biBpdCB3YXMgdGhyb3VnaCwgZXZlbg0KdGhvdWdoIHRoZSBWTSB3YXMgc3RpbGwgYWxpdmUsIHdo ZW4gSSB0cmllZCB0byB3cml0ZSB0byBhIHZpcnR1YWwgZGlzayB0aGF0IHdhcw0KcGFydCBvZiB0 aGUgbW92ZSwgaXQgcGF1c2VkIHRoZSBWTSBzYXlpbmcgdGhlcmUgd2Fzbid0IGVub3VnaCBzdG9y YWdlLg0KDQpJIGNvdWxkIHVucGF1c2UgdGhlIFZNLCBidXQgaW4gYSBmZXcgc2Vjb25kcywgd2l0 aCB0aGluZ3Mgd3JpdGluZyB0byB0aGUgdmlydHVhbA0KZGlzaywgYWdhaW4gaXQgd2FzIHBhdXNl ZCB3aXRoIHRoZSBzYW1lIG91dCBvZiBzcGFjZSBtZXNzYWdlLiAgVmRzbSBsb2dzIHNob3dlZA0K dGhlIGVub3NwYyByZXR1cm4gY29kZS4uLiBzbyBpdCBtYWRlIHNlbnNlLCBpdCdzIGp1c3QgdGhh dCB0aGUgVk0gc2hvd3MgcGxlbnR5DQpvZiBzdG9yYWdlIHRoZXJlLiAgT25jZSBJIHJlYm9vdGVk IHRoZSBWTSwgZXZlcnl0aGluZyB3ZW50IGJhY2sgdG8gbm9ybWFsLg0KDQpTbyBpcyBtb3Zpbmcg c3RvcmFnZSBmb3IgYSBsaXZlIFZNIG5vdCBzdXBwb3J0ZWQ/ICBJIGd1ZXNzIHdlIGdvdCBsdWNr eSBpbiBvdXINCjMuNCBzeXN0ZW0gKD8pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpVc2VycyBtYWlsaW5nIGxpc3QNClVzZXJzQG92aXJ0Lm9yZw0K aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo= --_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <CB7FDCFAC1461E4489DDC562BF4BDB5A(a)collogia.de> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pkkga25vdyBvZiBhdCBsZWFzdCBvbmUgbGl2ZSBEaXNrIE1pZ3JhdGlvbiBpc3N1ZSB3aXRoIE11 bHRpIERpc2sgVk1zLjwvcD4NCjxwIGRpcj0ibHRyIj5odHRwczovL2J1Z3ppbGxhLnJlZGhhdC5j b20vc2hvd19idWcuY2dpP2lkPTEzMTk0MDA8L3A+DQo8cCBkaXI9Imx0ciI+TWlnaHQgYmUgdG90 YWxseSBkaWZmZXJlbnQgYnV0IEkgbXVzdCBhZG1pdCB0aGF0IHRoaXMgZmVhdHVyZSBoYWQgc2V2 ZXJhbCB1cHMgYW5kIGRvd25zIHRoZSBsYXN0IHllYXJzLjwvcD4NCjxwIGRpcj0ibHRyIj5NYXJr dXM8L3A+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+QW0gMjYuMDUuMjAxNiAzOjUwIHZvcm0u IHNjaHJpZWIgQ2hyaXN0b3BoZXIgQ294ICZsdDtjY294QGVuZGxlc3Nub3cuY29tJmd0Ozo8YnIg dHlwZT0iYXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdCI+PC9z cGFuPjwvZm9udD4NCjxkaXY+SW4gb3VyIG9sZCAzLjQgb3ZpcnQsIEkga25vdyBJJ3ZlIG1pZ3Jh dGVkIHN0b3JhZ2Ugb24gbGl2ZSBWTXMgYW5kIGV2ZXJ5dGhpbmcNCjxicj4NCnNlZW1lZCB0byB3 b3JrLjxicj4NCjxicj4NCkhvd2V2ZXIgb24gMy42LjYsIEkgdHJpZWQgdGhpcyBhbmQgSSBzYXcg dGhlIHdhcm5pbmcgYWJvdXQgbW92aW5nIHN0b3JhZ2Ugb24gYSA8YnI+DQpsaXZlIFZNIChpdCB3 YXNuJ3QgZG9pbmcgbXVjaCBvZiBhbnl0aGluZykgYW5kIEkgd2VudCBhaGVhZCBhbmQgbWlncmF0 ZWQgdGhlIDxicj4NCnN0b3JhZ2UgZnJvbSBvbmUgc3RvcmFnZSBkb21haW4gdG8gYW5vdGhlci4m bmJzcDsmbmJzcDsgQnV0IHdoZW4gaXQgd2FzIHRocm91Z2gsIGV2ZW4gPGJyPg0KdGhvdWdoIHRo ZSBWTSB3YXMgc3RpbGwgYWxpdmUsIHdoZW4gSSB0cmllZCB0byB3cml0ZSB0byBhIHZpcnR1YWwg ZGlzayB0aGF0IHdhcyA8YnI+DQpwYXJ0IG9mIHRoZSBtb3ZlLCBpdCBwYXVzZWQgdGhlIFZNIHNh eWluZyB0aGVyZSB3YXNuJ3QgZW5vdWdoIHN0b3JhZ2UuPGJyPg0KPGJyPg0KSSBjb3VsZCB1bnBh dXNlIHRoZSBWTSwgYnV0IGluIGEgZmV3IHNlY29uZHMsIHdpdGggdGhpbmdzIHdyaXRpbmcgdG8g dGhlIHZpcnR1YWwgPGJyPg0KZGlzaywgYWdhaW4gaXQgd2FzIHBhdXNlZCB3aXRoIHRoZSBzYW1l IG91dCBvZiBzcGFjZSBtZXNzYWdlLiZuYnNwOyBWZHNtIGxvZ3Mgc2hvd2VkIDxicj4NCnRoZSBl bm9zcGMgcmV0dXJuIGNvZGUuLi4gc28gaXQgbWFkZSBzZW5zZSwgaXQncyBqdXN0IHRoYXQgdGhl IFZNIHNob3dzIHBsZW50eSA8YnI+DQpvZiBzdG9yYWdlIHRoZXJlLiZuYnNwOyBPbmNlIEkgcmVi b290ZWQgdGhlIFZNLCBldmVyeXRoaW5nIHdlbnQgYmFjayB0byBub3JtYWwuPGJyPg0KPGJyPg0K U28gaXMgbW92aW5nIHN0b3JhZ2UgZm9yIGEgbGl2ZSBWTSBub3Qgc3VwcG9ydGVkPyZuYnNwOyBJ IGd1ZXNzIHdlIGdvdCBsdWNreSBpbiBvdXIgPGJyPg0KMy40IHN5c3RlbSAoPyk8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVz ZXJzIG1haWxpbmcgbGlzdDxicj4NClVzZXJzQG92aXJ0Lm9yZzxicj4NCjxhIGhyZWY9Imh0dHA6 Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycyI+aHR0cDovL2xpc3RzLm92 aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_-- ------=_NextPartTM-000-7fc17005-f5d8-4745-92f6-4a4dc02fab36 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-7fc17005-f5d8-4745-92f6-4a4dc02fab36--

2 1

Ovirt 3.6.6 on Centos 7.2 not using native gluster (gfapi)
by Ralf Schenk 31 May '16

31 May '16

This is a multi-part message in MIME format. --------------AF66DE8F49B7941B791B002E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, I set up 8 Hosts and self-hosted-engine running HA on 3 of them from gluster replica 3 Volume. HA is working, I can set one host of the 3 configured for hosted-engine to maintenance and engine migrates to other host. I did the hosted-engine --deploy with type gluster and my gluster hosted storage is accessed as glusterfs.mydomain.de:/engine I set up another gluster volume (distributed replicated 4x2=8) as Data storage for my virtual machines which is accessible as glusterfs.mydomain.de:/gv0. ISO and Export Volume are defined from NFS Server. When I set up a VM on the gluster storage I expected it to run with native gluster support. However if I dumpxml the libvirt machine definition I've something like that in it's config: [...] <disk type='file' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='threads'/> <source file='/rhev/data-center/00000001-0001-0001-0001-0000000000b9/5d99af76-33b5-47d8-99da-1f32413c7bb0/images/011ab08e-71af-4d5b-a6a8-9b843a10329e/3f71d6c7-9b6d-4872-abc6-01a2b3329656'/> <backingStore/> <target dev='vda' bus='virtio'/> <serial>011ab08e-71af-4d5b-a6a8-9b843a10329e</serial> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> I expected to have something like this: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='threads'/> <source protocol='gluster' name='gv0/5d99af76-33b5-47d8-99da-1f32413c7bb0/images/011ab08e-71af-4d5b-a6a8-9b843a10329e/3f71d6c7-9b6d-4872-abc6-01a2b3329656'> <host name='glusterfs.mydomain.de'/> </source> [...] All hosts have vdsm-gluster gluster installed: [root@microcloud21 libvirt]# yum list installed | grep vdsm-* vdsm.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-cli.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-gluster.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-hook-hugepages.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-hook-vmfex-dev.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-infra.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-jsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-python.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-xmlrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-yajsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 How do I get my most wanted feature native gluster support running ? -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------AF66DE8F49B7941B791B002E Content-Type: multipart/related; boundary="------------0AF6A7E1F21AB119CC361D8D" --------------0AF6A7E1F21AB119CC361D8D 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"> <p>Hello,<br> </p> <p>I set up 8 Hosts and self-hosted-engine running HA on 3 of them from gluster replica 3 Volume. HA is working, I can set one host of the 3 configured for hosted-engine to maintenance and engine migrates to other host. I did the hosted-engine --deploy with type gluster and my gluster hosted storage is accessed as glusterfs.mydomain.de:/engine<br> </p> <p>I set up another gluster volume (distributed replicated 4x2=8) as Data storage for my virtual machines which is accessible as glusterfs.mydomain.de:/gv0. ISO and Export Volume are defined from NFS Server.</p> <p>When I set up a VM on the gluster storage I expected it to run with native gluster support. However if I dumpxml the libvirt machine definition I've something like that in it's config:</p> <p>[...]<br> </p> <p><tt> <disk type='file' device='disk' snapshot='no'></tt><tt><br> </tt><tt> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='threads'/></tt><tt><br> </tt><tt> <source file='/rhev/data-center/00000001-0001-0001-0001-0000000000b9/5d99af76-33b5-47d8-99da-1f32413c7bb0/images/011ab08e-71af-4d5b-a6a8-9b843a10329e/3f71d6c7-9b6d-4872-abc6-01a2b3329656'/></tt><tt><br> </tt><tt> <backingStore/></tt><tt><br> </tt><tt> <target dev='vda' bus='virtio'/></tt><tt><br> </tt><tt> <serial>011ab08e-71af-4d5b-a6a8-9b843a10329e</serial></tt><tt><br> </tt><tt> <boot order='1'/></tt><tt><br> </tt><tt> <alias name='virtio-disk0'/></tt><tt><br> </tt><tt> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/></tt><tt><br> </tt><tt> </disk></tt><br> <br> </p> I expected to have something like this:<br> <tt><disk type='network' device='disk'></tt><tt><br> </tt><tt> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='threads'/></tt><tt><br> </tt><tt> <source protocol='gluster' name='gv0/5d99af76-33b5-47d8-99da-1f32413c7bb0/images/011ab08e-71af-4d5b-a6a8-9b843a10329e/3f71d6c7-9b6d-4872-abc6-01a2b3329656'></tt><tt><br> </tt><tt> <host name='glusterfs.mydomain.de'/></tt><tt><br> </tt><tt> </source></tt><tt><br> </tt><tt> [...]</tt><tt><br> </tt><br> All hosts have vdsm-gluster gluster installed:<br> <tt>[root@microcloud21 libvirt]# yum list installed | grep vdsm-*</tt><tt><br> </tt><tt>vdsm.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-cli.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-gluster.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-hook-hugepages.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-hook-vmfex-dev.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-infra.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-jsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-python.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-xmlrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><tt>vdsm-yajsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt><br> </tt><br> How do I get my most wanted feature native gluster support running ?<br> <br> <div class="moz-signature">-- <br> <p> </p> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.B7BA9679.E32DEC3A@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Ralf Schenk</b><br> fon +49 (0) 24 05 / 40 83 70<br> fax +49 (0) 24 05 / 40 83 759<br> mail <a href="mailto:rs@databay.de"><font color="#FF0000"><b>rs(a)databay.de</b></font></a><br> </font> </td> <td width="30"> </td> <td valign="top"> <font face="Verdana, Arial, sans-serif" size="-1"><br> <b>Databay AG</b><br> Jens-Otto-Krag-Straße 11<br> D-52146 Würselen<br> <a href="http://www.databay.de"><font color="#FF0000"><b>www.databay.de</b></font></a> </font> </td> </tr> <tr> <td colspan="3" valign="top"> <font face="Verdana, Arial, sans-serif" size="1"><br> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202<br> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns<br> Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </font> </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------0AF6A7E1F21AB119CC361D8D Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.B7BA9679.E32DEC3A(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------0AF6A7E1F21AB119CC361D8D-- --------------AF66DE8F49B7941B791B002E--

2 3

Problem using xenial cloud images with ovirt
by Claude Durocher 30 May '16

30 May '16

------=_=-_OpenGroupware_org_NGMime-4367-1464365638.750478-0------ content-type: text/plain; charset=utf-8 content-length: 413 content-transfer-encoding: quoted-printable Hi. I'm trying to run a Ubuntu cloud image on oVirt 3.6. It works fine with= the 14.04 image or Centos 7 image but I have trouble with the 16.04 im= age : I have no network and cloud-init dont receive any data from oVirt= . Also, the VM takes about 5 minutes to boot (then I cant login as clou= d-init dont seem to work). I've validated the 16.04 image : I can boot it fine on my workstation r= unning kvm. ------=_=-_OpenGroupware_org_NGMime-4367-1464365638.750478-0------ content-type: text/html; charset=utf-8 content-length: 446 content-transfer-encoding: quoted-printable <html>Hi.<br />I'm trying to run a Ubuntu cloud image on oVirt 3.6.= It works fine with the 14.04 image or Centos 7 image but I have troubl= e with the 16.04 image : I have no network and cloud-init dont receive = any data from oVirt. Also, the VM takes about 5 minutes to boot (then I= cant login as cloud-init dont seem to work).<br />I've validated t= he 16.04 image : I can boot it fine on my workstation running kvm.</htm= l> ------=_=-_OpenGroupware_org_NGMime-4367-1464365638.750478-0--------

1 1

Using ceph volumes with ovirt
by Alessandro De Salvo 30 May '16

30 May '16

This is a multi-part message in MIME format. --------------C7D3C76DD1E6339049812313 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm happily using our research cluster in Italy via gluster, and now I'm trying to hotplug a ceph disk on a VM of my cluster, without success. The ceph cluster is managed via openstack cinder and I can create correctly the disk via ovirt (3.6.6.2-1 on CentOS 7.2). The problem comes when trying to hotplug, or start a machine with the given disk attached. In the vdsm log of the host where the VM is running or starting I see the following error: jsonrpc.Executor/5::INFO::2016-05-30 10:35:29,197::vm::2729::virt.vm::(hotplugDisk) vmId=`c189472e-25d2-4df1-b089-590009856dd3`::Hotplug disk xml: <disk address="" device="disk" snapshot="no" type="network"> <source name="images/volume-9134b639-c23c-4ff1-91ca-0462c80026d2" protocol="rbd"> <host name="141.108.X.Y1" port="6789" transport="tcp"/> <host name="141.108.X.Y2" port="6789" transport="tcp"/> </source> <auth username="cinder"> <secret type="ceph" uuid="<base 64 ceph secret>"/> </auth> <target bus="virtio" dev="vdb"/> <driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/> </disk> jsonrpc.Executor/5::ERROR::2016-05-30 10:35:29,198::vm::2737::virt.vm::(hotplugDisk) vmId=`c189472e-25d2-4df1-b089-590009856dd3`::Hotplug failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2735, in hotplugDisk self._dom.attachDevice(driveXml) File "/usr/share/vdsm/virt/virdomain.py", line 68, in f ret = attr(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 124, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 1313, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 530, in attachDevice if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) libvirtError: XML error: invalid auth secret uuid In fact the uuid of the secret used by ovirt to hotplug seems to be the ceph secret (masked here as <base 64 ceph secret>), while libvirt expects the uuid of the libvirt secret, by looking at the instructions http://docs.ceph.com/docs/jewel/rbd/libvirt/. Anyone got it working? Thanks, Alessandro --------------C7D3C76DD1E6339049812313 Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-15"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p> </p> <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">Hi, <br> I'm happily using our research cluster in Italy via gluster, and now I'm trying to hotplug a ceph disk on a VM of my cluster, without success. <br> The ceph cluster is managed via openstack cinder and I can create correctly the disk via ovirt (3.6.6.2-1 on CentOS 7.2). <br> The problem comes when trying to hotplug, or start a machine with the given disk attached. <br> In the vdsm log of the host where the VM is running or starting I see the following error: <br> <br> <br> jsonrpc.Executor/5::INFO::2016-05-30 10:35:29,197::vm::2729::virt.vm::(hotplugDisk) vmId=`c189472e-25d2-4df1-b089-590009856dd3`::Hotplug disk xml: <disk address="" device="disk" snapshot="no" type="network"> <br> <source name="images/volume-9134b639-c23c-4ff1-91ca-0462c80026d2" protocol="rbd"> <br> <host name="141.108.X.Y1" port="6789" transport="tcp"/> <br> <host name="141.108.X.Y2" port="6789" transport="tcp"/> <br> </source> <br> <auth username="cinder"> <br> <secret type="ceph" uuid="<base 64 ceph secret>"/> <br> </auth> <br> <target bus="virtio" dev="vdb"/> <br> <driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/> <br> </disk> <br> <br> jsonrpc.Executor/5::ERROR::2016-05-30 10:35:29,198::vm::2737::virt.vm::(hotplugDisk) vmId=`c189472e-25d2-4df1-b089-590009856dd3`::Hotplug failed <br> Traceback (most recent call last): <br> File "/usr/share/vdsm/virt/vm.py", line 2735, in hotplugDisk <br> self._dom.attachDevice(driveXml) <br> File "/usr/share/vdsm/virt/virdomain.py", line 68, in f <br> ret = attr(*args, **kwargs) <br> File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 124, in wrapper <br> ret = f(*args, **kwargs) <br> File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 1313, in wrapper <br> return func(inst, *args, **kwargs) <br> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 530, in attachDevice <br> if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) <br> libvirtError: XML error: invalid auth secret uuid <br> <br> <br> <br> In fact the uuid of the secret used by ovirt to hotplug seems to be the ceph secret (masked here as <base 64 ceph secret>), while libvirt expects the uuid of the libvirt secret, by looking at the instructions <a class="moz-txt-link-freetext" href="http://docs.ceph.com/docs/jewel/rbd/libvirt/">http://docs.ceph.com/docs/jewel/rbd/libvirt/</a>. <br> Anyone got it working? <br> Thanks, <br> <br> Alessandro <br> </div> </body> </html> --------------C7D3C76DD1E6339049812313--

2 2

failing update ovirt-engine on centos 7
by Fabrice Bacchella 30 May '16

30 May '16

--Apple-Mail=_9190D383-816A-4168-8F45-9E5CFD2D7429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have an dedicated machin to run ovirt-engine (not hosted). It's an up = to date centos 7.2.1511 I installed ovirt 3.6.6 a few weeks ago (May 10 17:56:44 tells me = yum.log) Now, I'm trying a full yum update and getting : # yum update .... Error: Package: ovirt-engine-tools-3.6.5.3-1.el7.centos.noarch = (@ovirt-3.6) Requires: ovirt-engine-tools-backup =3D 3.6.5.3-1.el7.centos Removing: = ovirt-engine-tools-backup-3.6.5.3-1.el7.centos.noarch (@ovirt-3.6) ovirt-engine-tools-backup =3D 3.6.5.3-1.el7.centos Updated By: = ovirt-engine-tools-backup-3.6.6.2-1.el7.centos.noarch (ovirt-3.6) ovirt-engine-tools-backup =3D 3.6.6.2-1.el7.centos rpm -qi ovirt-engine-tools says : Version : 3.6.5.3 Release : 1.el7.centos ... Build Date : Mon Apr 11 23:45:30 2016 Build Host : el7-vm02.phx.ovirt.org and : rpm -qi ovirt-engine-tools-backup says: Name : ovirt-engine-tools-backup Version : 3.6.5.3 Release : 1.el7.centos ... Build Date : Mon Apr 11 23:45:30 2016 Build Host : el7-vm02.phx.ovirt.org yum update ovirt-engine-tools-backup ovirt-engine-tools fails in the = same way. but: yum list ovirt-engine-tools-backup ovirt-engine-tools Loaded plugins: etckeeper, fastestmirror, versionlock Loading mirror speeds from cached hostfile Installed Packages ovirt-engine-tools.noarch = 3.6.5.3-1.el7.centos = @ovirt-3.6 ovirt-engine-tools-backup.noarch = 3.6.5.3-1.el7.centos = @ovirt-3.6 Available Packages ovirt-engine-tools-backup.noarch = 3.6.6.2-1.el7.centos = ovirt-3.6=20 So no ovirt-engine-tools to update. and indeed : yum update ovirt-engine-tools Loaded plugins: etckeeper, fastestmirror, versionlock Loading mirror speeds from cached hostfile No packages marked for update I have disable ovirt-3.6-epel, because I already use epel, is it the = problem ? What should I do ? I don't think removing ovirt-engine-tools is a = option. --Apple-Mail=_9190D383-816A-4168-8F45-9E5CFD2D7429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D"">I have an dedicated = machin to run ovirt-engine (not hosted). It's an up to date centos = 7.2.1511<br class=3D""><br class=3D"">I installed ovirt 3.6.6 a few = weeks ago (May 10 17:56:44 tells me yum.log)<br class=3D""><br = class=3D"">Now, I'm trying a full yum update and getting :<div = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D""># = yum update</font></div><div class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">....</font></div><div = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D""><br = class=3D""></font></div><div class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">Error: Package: = ovirt-engine-tools-3.6.5.3-1.el7.centos.noarch (@ovirt-3.6)<br = class=3D"">           Requires: = ovirt-engine-tools-backup =3D 3.6.5.3-1.el7.centos<br class=3D"">  =          Removing: = ovirt-engine-tools-backup-3.6.5.3-1.el7.centos.noarch (@ovirt-3.6)<br = class=3D"">              =  ovirt-engine-tools-backup =3D 3.6.5.3-1.el7.centos<br = class=3D"">           Updated By: = ovirt-engine-tools-backup-3.6.6.2-1.el7.centos.noarch (ovirt-3.6)<br = class=3D"">              =  ovirt-engine-tools-backup =3D 3.6.6.2-1.el7.centos<br class=3D""><br= class=3D""></font></div><div class=3D""><br class=3D""></div><div = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D"">rpm = -qi ovirt-engine-tools says :</font></div><div class=3D""><font = face=3D"Menlo" style=3D"font-size: 11px;" class=3D"">Version   =   : 3.6.5.3<br class=3D"">Release     : 1.el7.centos<br = class=3D"">...</font></div><font face=3D"Menlo" style=3D"font-size: = 11px;" class=3D"">Build Date  : Mon Apr 11 23:45:30 2016<br = class=3D""></font><div class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">Build Host  : <a = href=3D"http://el7-vm02.phx.ovirt.org" = class=3D"">el7-vm02.phx.ovirt.org</a><br class=3D""><br = class=3D""></font></div><div class=3D""><br class=3D""></div><div = class=3D"">and :</div><div class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">rpm -qi ovirt-engine-tools-backup = says:</font></div><div class=3D""><font face=3D"Menlo" style=3D"font-size:= 11px;" class=3D"">Name        : = ovirt-engine-tools-backup<br class=3D"">Version     : = 3.6.5.3<br class=3D"">Release     : = 1.el7.centos</font></div><div class=3D""><font face=3D"Menlo" = style=3D"font-size: 11px;" class=3D"">...<br class=3D"">Build Date =  : Mon Apr 11 23:45:30 2016<br class=3D"">Build Host  : <a = href=3D"http://el7-vm02.phx.ovirt.org" = class=3D"">el7-vm02.phx.ovirt.org</a><br class=3D""><br = class=3D""></font></div><div class=3D"">yum update = ovirt-engine-tools-backup ovirt-engine-tools fails in the same way.<br = class=3D""></div><div class=3D""><br class=3D""></div><div = class=3D"">but:</div><div class=3D""><br class=3D""></div><div = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D"">yum = list ovirt-engine-tools-backup ovirt-engine-tools<br class=3D"">Loaded = plugins: etckeeper, fastestmirror, versionlock<br class=3D"">Loading = mirror speeds from cached hostfile<br class=3D"">Installed Packages<br = class=3D"">ovirt-engine-tools.noarch           =                     =                     =       3.6.5.3-1.el7.centos         =                     =                     =  (a)ovirt-3.6<br class=3D"">ovirt-engine-tools-backup.noarch   =                     =                     =        3.6.5.3-1.el7.centos       =                     =                     =    (a)ovirt-3.6<br class=3D"">Available Packages<br = class=3D"">ovirt-engine-tools-backup.noarch         =                     =                     =  3.6.6.2-1.el7.centos             =                     =                 =  ovirt-3.6 <br class=3D""></font><br class=3D""></div><div = class=3D"">So no ovirt-engine-tools to update.</div><div = class=3D""><br class=3D""></div><div class=3D"">and indeed :</div><div = class=3D""><font face=3D"Menlo" style=3D"font-size: 11px;" class=3D"">yum = update ovirt-engine-tools<br class=3D"">Loaded plugins: etckeeper, = fastestmirror, versionlock<br class=3D"">Loading mirror speeds from = cached hostfile<br class=3D"">No packages marked for update<br = class=3D""><br class=3D""></font></div><div class=3D"">I have = disable ovirt-3.6-epel, because I already use epel, is it the = problem ?</div><div class=3D""><br class=3D""></div><div class=3D"">What = should I do ? I don't think removing ovirt-engine-tools  is a = option.</div><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div></body></html>= --Apple-Mail=_9190D383-816A-4168-8F45-9E5CFD2D7429--

7 15

One RHEV Virtual Machine does not Automatically Resume following Compellent SAN Controller Failover
by Duckworth, Douglas C 30 May '16

30 May '16

Hello -- Not sure if y'all can help with this issue we've been seeing with RHEV... On 11/13/2015, during Code Upgrade of Compellent SAN at our Disaster Recovery Site, we Failed Over to Secondary SAN Controller. Most Virtual Machines in our DR Cluster Resumed automatically after Pausing except VM "BADVM" on Host "BADHOST." In Engine.log you can see that BADVM was sent into "VM_PAUSED_EIO" state at 10:47:57: "VM BADVM has paused due to storage I/O problem." On this Red Hat Enterprise Virtualization Hypervisor 6.6 (20150512.0.el6ev) Host, two other VMs paused but then automatically resumed without System Administrator intervention... In our DR Cluster, 22 VMs also resumed automatically... None of these Guest VMs are engaged in high I/O as these are DR site VMs not currently doing anything. We sent this information to Dell. Their response: "The root cause may reside within your virtualization solution, not the parent OS (RHEV-Hypervisor disc) or Storage (Dell Compellent.)" We are doing this Failover again on Sunday November 29th so we would like to know how to mitigate this issue, given we have to manually resume paused VMs that don't resume automatically. Before we initiated SAN Controller Failover, all iSCSI paths to Targets were present on Host tulhv2p03. VM logs on Host show in /var/log/libvirt/qemu/badhost.log that Storage error was reported: block I/O error in device 'drive-virtio-disk0': Input/output error (5) block I/O error in device 'drive-virtio-disk0': Input/output error (5) block I/O error in device 'drive-virtio-disk0': Input/output error (5) block I/O error in device 'drive-virtio-disk0': Input/output error (5) All disks used by this Guest VM are provided by single Storage Domain COM_3TB4_DR with serial "270." In syslog we do see that all paths for that Storage Domain Failed: Nov 13 16:47:40 multipathd: 36000d310005caf000000000000000270: remaining active paths: 0 Though these recovered later: Nov 13 16:59:17 multipathd: 36000d310005caf000000000000000270: sdbg - tur checker reports path is up Nov 13 16:59:17 multipathd: 36000d310005caf000000000000000270: remaining active paths: 8 Does anyone have an idea of why the VM would fail to automatically resume if the iSCSI paths used by its Storage Domain recovered? Thanks Doug -- Thanks Douglas Charles Duckworth Unix Administrator Tulane University Technology Services 1555 Poydras Ave NOLA -- 70112 E: duckd(a)tulane.edu O: 504-988-9341 F: 504-988-8505

5 5