June 2016 - Users - oVirt List Archives

ovirt-engine-4.0 storage ISO Domain Unattached
by 转圈圈 29 Jun '16

29 Jun '16

This is a multi-part message in MIME format. ------=_NextPart_57722C31_099CAE98_75F77AF5 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 UHJvYmxlbTpJbnN0YWxsIHRoZSBvdmlydC1lbmdpbmUtNC4wICxJIGNob3NlIHRoZSBJU08g RG9tYWluIHBhdGggIi92YXIvbGliL2V4cG9ydHMvaXNvIiBhbmQgaW5zdGFsbCBzdWNjZXNz ZnVsIDtidXQgYWNjZXNzIHRocm91Z2ggYnJvd3NlciwgdGhlIElTTyBEb21haW4gc3RhdGUg aXMgIlVuYXR0YWNoZWQiOw== ------=_NextPart_57722C31_099CAE98_75F77AF5 Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 PGRpdj5Qcm9ibGVtOkluc3RhbGwgdGhlIG92aXJ0LWVuZ2luZS00LjAgLEkgY2hvc2UgdGhl IElTTyBEb21haW4gcGF0aCAiL3Zhci9saWIvZXhwb3J0cy9pc28iIGFuZCBpbnN0YWxsIHN1 Y2Nlc3NmdWwgO2J1dCBhY2Nlc3MgdGhyb3VnaCBicm93c2VyLCA8c3BhbiBzdHlsZT0ibGlu ZS1oZWlnaHQ6IDEuNTsiPnRoZSBJU08gRG9tYWluIHN0YXRlIGlzICJVbmF0dGFjaGVkPC9z cGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS41OyI+Ijs8L3NwYW4+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+ ------=_NextPart_57722C31_099CAE98_75F77AF5--

2 1

Unable to Access Engine UI after Upgrade to OVirt 4.0
by Ralf Schenk 29 Jun '16

29 Jun '16

This is a multi-part message in MIME format. --------------E85BCCB0E0B26128FAA9BFD9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, i upgraded hosted engine 3.6.6 to 4.0. Now I can't access the Web-UI: If I access the UI via https://engine-mciii.rxmgmt.databay.de I get the Error-Page "The client is not authorized to request an authorization. It's required to access the system using FQDN." I used the same FQDN during setup and even in the Upgrade Process this was used according to "Configuration Preview" below: What can I do to get UI working ? Do I have a problem with case sensistivity ? (The triple-"I" in the FQDN) ? --== CONFIGURATION PREVIEW ==-- Default SAN wipe after delete : False Firewall manager : firewalld Update Firewall : False Host FQDN : engine-mcIII.rxmgmt.databay.de Require packages rollback : False Upgrade packages : True Engine database secured connection : False Engine database host : localhost Engine database user name : engine Engine database name : engine Engine database port : 5432 Engine database host name validation : False DWH database secured connection : False DWH database host : localhost DWH database user name : ovirt_engine_history DWH database name : ovirt_engine_history DWH database port : 5432 DWH database host name validation : False Engine installation : True PKI organization : rxmgmt.databay.de DWH installation : True Configure local DWH database : True Engine Host FQDN : engine-mcIII.rxmgmt.databay.de Configure VMConsole Proxy : True Configure WebSocket Proxy : True bye -- *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: Wilhelm Dohmen ------------------------------------------------------------------------ --------------E85BCCB0E0B26128FAA9BFD9 Content-Type: multipart/related; boundary="------------BB8924563898A8AE76EBE5AC" --------------BB8924563898A8AE76EBE5AC 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 upgraded hosted engine 3.6.6 to 4.0. Now I can't access the Web-UI:</p> <p>If I access the UI via <a class="moz-txt-link-freetext" href="https://engine-mciii.rxmgmt.databay.de">https://engine-mciii.rxmgmt.databay.de</a> I get the Error-Page "The client is not authorized to request an authorization. It's required to access the system using FQDN."</p> <p>I used the same FQDN during setup and even in the Upgrade Process this was used according to "Configuration Preview" below:</p> <p>What can I do to get UI working ? Do I have a problem with case sensistivity ? (The triple-"I" in the FQDN) ?<br> </p> <p><br> </p> <p> --== CONFIGURATION PREVIEW ==--<br> <br> Default SAN wipe after delete : False<br> Firewall manager : firewalld<br> Update Firewall : False<br> Host FQDN : engine-mcIII.rxmgmt.databay.de<br> Require packages rollback : False<br> Upgrade packages : True<br> Engine database secured connection : False<br> Engine database host : localhost<br> Engine database user name : engine<br> Engine database name : engine<br> Engine database port : 5432<br> Engine database host name validation : False<br> DWH database secured connection : False<br> DWH database host : localhost<br> DWH database user name : ovirt_engine_history<br> DWH database name : ovirt_engine_history<br> DWH database port : 5432<br> DWH database host name validation : False<br> Engine installation : True<br> PKI organization : rxmgmt.databay.de<br> DWH installation : True<br> Configure local DWH database : True<br> Engine Host FQDN : engine-mcIII.rxmgmt.databay.de<br> Configure VMConsole Proxy : True<br> Configure WebSocket Proxy : True<br> <br> </p> bye<br> <div class="moz-signature">-- <br> <p> </p> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.C57F84B5.3EF7173E@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: Wilhelm Dohmen </font> </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------BB8924563898A8AE76EBE5AC Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.C57F84B5.3EF7173E(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= --------------BB8924563898A8AE76EBE5AC-- --------------E85BCCB0E0B26128FAA9BFD9--

2 7

Failed to start self hosted engine after upgrading oVirt to 4.0
by Stefano Danzi 29 Jun '16

29 Jun '16

Hi! I've just upgrade oVirt from 3.6 to 4.0 and I'm not able to start the self hosted engine. first thing is that the host network lose the degaut gateway configuration. But this is not the problem. Logs: ==> /var/log/ovirt-hosted-engine-ha/agent.log <== MainThread::INFO::2016-06-23 18:28:40,833::hosted_engine::669::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Reloading vm.conf from the shared storage domain MainThread::INFO::2016-06-23 18:28:40,833::config::206::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Trying to get a fresher copy of vm configuration from the OVF_STORE MainThread::INFO::2016-06-23 18:28:44,535::ovf_store::102::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) Found OVF_STORE: imgUUID:8d07965c-a5c4-4057-912d-901f80cf246c, volUUID:ce3aa63e-e1c4-498e-bdca-9d2e9f47f0f9 MainThread::INFO::2016-06-23 18:28:44,582::ovf_store::102::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) Found OVF_STORE: imgUUID:bd9aaf0b-8435-4d78-9871-8c7a7f7fa02a, volUUID:3c477b06-063e-4f01-bd05-84c7d467742b MainThread::INFO::2016-06-23 18:28:44,674::ovf_store::111::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) Extracting Engine VM OVF from the OVF_STORE MainThread::INFO::2016-06-23 18:28:44,675::ovf_store::118::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) OVF_STORE volume path: /rhev/data-center/mnt/ovirt01.hawai.lan:_engine/46f55a31-f35f-465c-b3e2-df45c05e06a7/images/bd9aaf0b-8435-4d78-9871-8c7a7f7fa02a/3c477b06-063e-4f01-bd05-84c7d467742b MainThread::INFO::2016-06-23 18:28:44,682::config::226::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Found an OVF for HE VM, trying to convert MainThread::INFO::2016-06-23 18:28:44,684::config::231::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Got vm.conf from OVF_STORE MainThread::INFO::2016-06-23 18:28:44,684::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_broker) Initializing ha-broker connection MainThread::INFO::2016-06-23 18:28:44,685::brokerlink::129::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(start_monitor) Starting monitor ping, options {'addr': '192.168.1.254'} ==> /var/log/ovirt-hosted-engine-ha/broker.log <== Thread-25::ERROR::2016-06-23 18:28:44,697::listener::182::ovirt_hosted_engine_ha.broker.listener.ConnectionHandler::(handle) Error while serving connection Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py", line 166, in handle data) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py", line 299, in _dispatch .set_storage_domain(client, sd_type, **options) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py", line 66, in set_storage_domain self._backends[client].connect() File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 400, in connect volUUID=volume.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 ==> /var/log/ovirt-hosted-engine-ha/agent.log <== MainThread::INFO::2016-06-23 18:28:44,697::hosted_engine::602::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_broker) Failed set the storage domain: 'Failed to set storage domain VdsmBackend, options {'hosted-engine.lockspace': '7B22696D6167655F75756964223A202265663131373139322D623564662D346534362D383939622D626666333362663862663135222C202270617468223A206E756C6C2C2022766F6C756D655F75756964223A202230613363393433652D633032392D343134372D623364342D396366353364663161356262227D', 'sp_uuid': '00000000-0000-0000-0000-000000000000', 'dom_type': 'nfs3', 'hosted-engine.metadata': '7B22696D6167655F75756964223A202233353066396361302D363933302D346336342D626438632D613262656631656336383934222C202270617468223A206E756C6C2C2022766F6C756D655F75756964223A202235393335373437392D656664612D343563312D386363392D656131653739633231646561227D', 'sd_uuid': '46f55a31-f35f-465c-b3e2-df45c05e06a7'}: Request failed: <class 'socket.error'>'. Waiting '5's before the next attempt ==> /var/log/vdsm/vdsm.log <== periodic/3::WARNING::2016-06-23 18:34:41,731::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/2::WARNING::2016-06-23 18:34:43,657::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.BlockjobMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/0::WARNING::2016-06-23 18:34:43,732::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/3::WARNING::2016-06-23 18:34:45,732::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/2::WARNING::2016-06-23 18:34:47,723::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/1::WARNING::2016-06-23 18:34:49,724::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/0::WARNING::2016-06-23 18:34:51,725::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/3::WARNING::2016-06-23 18:34:53,726::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/2::WARNING::2016-06-23 18:34:55,727::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] ==> /var/log/vdsm/mom.log <== 2016-06-23 18:34:56,376 - mom.vdsmInterface - ERROR - Cannot connect to VDSM! [Errno 101] Network is unreachable ==> /var/log/vdsm/vdsm.log <== periodic/1::WARNING::2016-06-23 18:34:57,727::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/2::WARNING::2016-06-23 18:34:58,652::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.BlockjobMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] periodic/2::WARNING::2016-06-23 18:34:59,728::periodic::269::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['b66ae2c5-de0f-4361-953b-f10226da7eb8'] Reactor thread::INFO::2016-06-23 18:35:00,048::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept) Accepting connection from ::ffff:192.168.1.50:60604 Reactor thread::DEBUG::2016-06-23 18:35:00,057::protocoldetector::85::ProtocolDetector.Detector::(__init__) Using required_size=11 Reactor thread::INFO::2016-06-23 18:35:00,058::protocoldetector::121::ProtocolDetector.Detector::(handle_read) Detected protocol stomp from ::ffff:192.168.1.50:60604 Reactor thread::INFO::2016-06-23 18:35:00,058::stompreactor::101::Broker.StompAdapter::(_cmd_connect) Processing CONNECT request Reactor thread::DEBUG::2016-06-23 18:35:00,059::stompreactor::483::protocoldetector.StompDetector::(handle_socket) Stomp detected from ('::ffff:192.168.1.50', 60604) JsonRpc (StompReactor)::INFO::2016-06-23 18:35:00,059::stompreactor::128::Broker.StompAdapter::(_cmd_subscribe) Subscribe command received jsonrpc.Executor/2::DEBUG::2016-06-23 18:35:01,688::__init__::522::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'Host.getHardwareInfo' in bridge with {} [root@ovirt01 ~]# netstat -lnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 985/rpcbind tcp 0 0 0.0.0.0:882 0.0.0.0:* LISTEN 1970/glusterfs tcp 0 0 0.0.0.0:54322 0.0.0.0:* LISTEN 925/python tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1600/sshd tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 1978/glusterfsd tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN 1970/glusterfs tcp 0 0 0.0.0.0:38465 0.0.0.0:* LISTEN 1970/glusterfs tcp 0 0 0.0.0.0:49153 0.0.0.0:* LISTEN 1963/glusterfsd tcp 0 0 0.0.0.0:32802 0.0.0.0:* LISTEN 2193/rpc.statd tcp 0 0 0.0.0.0:38466 0.0.0.0:* LISTEN 1970/glusterfs tcp 0 0 0.0.0.0:16514 0.0.0.0:* LISTEN 1633/libvirtd tcp 0 0 0.0.0.0:38468 0.0.0.0:* LISTEN 1970/glusterfs tcp 0 0 0.0.0.0:38469 0.0.0.0:* LISTEN 1970/glusterfs tcp 0 0 0.0.0.0:24007 0.0.0.0:* LISTEN 1652/glusterd tcp6 0 0 :::54321 :::* LISTEN 1921/python tcp6 0 0 :::22 :::* LISTEN 1600/sshd tcp6 0 0 :::16514 :::* LISTEN 1633/libvirtd udp 0 0 0.0.0.0:40503 0.0.0.0:* 937/avahi-daemon: r udp 0 0 0.0.0.0:40873 0.0.0.0:* 2193/rpc.statd udp 0 0 0.0.0.0:111 0.0.0.0:* 985/rpcbind udp 0 0 127.0.0.1:323 0.0.0.0:* 952/chronyd udp 0 0 0.0.0.0:694 0.0.0.0:* 985/rpcbind udp 0 0 127.0.0.1:703 0.0.0.0:* 2193/rpc.statd udp 0 0 0.0.0.0:879 0.0.0.0:* 1970/glusterfs udp 0 0 0.0.0.0:5353 0.0.0.0:* 937/avahi-daemon: r udp6 0 0 ::1:323 :::* 952/chronyd Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 19455 1633/libvirtd /var/run/libvirt/libvirt-sock unix 2 [ ACC ] STREAM LISTENING 22529 1633/libvirtd /var/run/libvirt/libvirt-sock-ro unix 2 [ ACC ] STREAM LISTENING 16902 1/systemd /var/run/rpcbind.sock unix 2 [ ACC ] STREAM LISTENING 24077 1978/glusterfsd /var/run/gluster/changelog-36d1d6bf77f0ad218a0db9ada4237737.sock unix 2 [ ACC ] STREAM LISTENING 20494 992/gssproxy /run/gssproxy.sock unix 2 [ ACC ] STREAM LISTENING 14641 682/multipathd @/org/kernel/linux/storage/multipathd unix 2 [ ACC ] STREAM LISTENING 16914 1/systemd /var/run/avahi-daemon/socket unix 2 [ ACC ] STREAM LISTENING 19484 993/sanlock /var/run/sanlock/sanlock.sock unix 2 [ ACC ] STREAM LISTENING 24095 1963/glusterfsd /var/run/gluster/changelog-c54f38f29c5c1e84d2766564ea967b8d.sock unix 2 [ ACC ] STREAM LISTENING 16929 1/systemd /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 12093 1/systemd /run/systemd/private unix 2 [ ACC ] STREAM LISTENING 16924 1/systemd @ISCSID_UIP_ABSTRACT_NAMESPACE unix 2 [ ACC ] STREAM LISTENING 18255 925/python /var/run/vdsm/ovirt-imageio-daemon.sock unix 2 [ ACC ] STREAM LISTENING 23905 1963/glusterfsd /var/run/gluster/b3162364606c81381a4c768484c6f091.socket unix 2 [ ACC ] SEQPACKET LISTENING 13409 1/systemd /run/udev/control unix 2 [ ACC ] STREAM LISTENING 90477 1970/glusterfs /var/run/gluster/b6606e2cc1634ac3c57dae961f6a6cc3.socket unix 2 [ ACC ] STREAM LISTENING 13428 1/systemd /run/lvm/lvmetad.socket unix 2 [ ACC ] STREAM LISTENING 18302 920/python /var/run/ovirt-hosted-engine-ha/broker.socket unix 2 [ ACC ] STREAM LISTENING 23947 1978/glusterfsd /var/run/gluster/65f923a8c0294836aec3ffce760511cb.socket unix 2 [ ACC ] STREAM LISTENING 20112 1652/glusterd /var/run/glusterd.socket unix 2 [ ACC ] STREAM LISTENING 18321 939/python /var/run/vdsm/svdsm.sock unix 2 [ ACC ] STREAM LISTENING 20493 992/gssproxy /var/lib/gssproxy/default.sock unix 2 [ ACC ] STREAM LISTENING 13470 1/systemd /run/lvm/lvmpolld.socket unix 2 [ ACC ] STREAM LISTENING 16909 1/systemd @ISCSIADM_ABSTRACT_NAMESPACE unix 2 [ ACC ] STREAM LISTENING 18160 990/wdmd /var/run/wdmd/wdmd.sock unix 2 [ ACC ] STREAM LISTENING 2291 1/systemd /run/systemd/journal/stdout unix 2 [ ACC ] STREAM LISTENING 90622 1923/python /var/run/vdsm/mom-vdsm.sock

5 16

restore of backup fail when Migrating to ovirt-engine 4.0
by Ricky Schneberger 29 Jun '16

29 Jun '16

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JapCK5PgIhrI8oHqAqwsEWsRJPfAwenGn Content-Type: multipart/mixed; boundary="l95MFGKDaMAbLFS8wD8PlqiDFIL5ddENQ" From: Ricky Schneberger <ricky(a)schneberger.se> Reply-To: ricky(a)schneberger.se To: users <users(a)ovirt.org> Message-ID: <577140AA.1030104(a)schneberger.se> Subject: restore of backup fail when Migrating to ovirt-engine 4.0 --l95MFGKDaMAbLFS8wD8PlqiDFIL5ddENQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I ran my oVirt 3.6 on Centos6 and because of that I had to do a manual migration when trying to move to oVirt 4.0. http://www.ovirt.org/documentation/migration-engine-3.6-to-4.0/ Everything went OK until I did the restore, ## engine-backup --mode=3Drestore --no-restore-permissions --provision-db --file=3Dengine-backup.tar.gz --log=3Dengine-backup-restore.log Preparing to restore: - Unpacking file 'engine-backup.tar.gz' FATAL: Backup was created by version '3.6' and can not be restored using the installed version 4.1 and then I got stucked. Is there something I need to do when I do the backup? My old oVirt-engine was version ovirt-engine-3.6.3.4-1.el6.noarch regards --=20 Ricky Schneberger ------------------------------------ Use PGP to protect your own privacy! Key fingerprint =3D 59E1 2B00 C28B 6E0D C8D1 D85B 39AA 7CD5 B88C 0B63 Key-ID: 0xB88C0B63 --l95MFGKDaMAbLFS8wD8PlqiDFIL5ddENQ-- --JapCK5PgIhrI8oHqAqwsEWsRJPfAwenGn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldxQKoACgkQOap81biMC2Mc0gCePkUfEw4SBu2UM2i5/eE3Wmwc gS0AnRVM8n3LdQf7Ca0GK9hYRqY+GPkO =HEj+ -----END PGP SIGNATURE----- --JapCK5PgIhrI8oHqAqwsEWsRJPfAwenGn-- -- IMPORTANT! This message has been scanned for viruses and phishing links. However, it is your responsibility to evaluate the links and attachments you choose to click. If you are uncertain, we always try to help. Greetings helpdesk(a)actnet.se

6 18

ovirt-engine-4.0 storage ISO Domain Unattached
by 转圈圈 29 Jun '16

29 Jun '16

This is a multi-part message in MIME format. ------=_NextPart_57737DBD_0A5F5BD0_4F0318D1 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 UHJvYmxlbTpJbnN0YWxsIHRoZSBvdmlydC1lbmdpbmUtNC4wICxJIGNob3NlIHRoZSBJU08g RG9tYWluIHBhdGggIi92YXIvbGliL2V4cG9ydHMvaXNvIiBhbmQgaW5zdGFsbCBzdWNjZXNz ZnVsIDtidXQgYWNjZXNzIHRocm91Z2ggYnJvd3NlciwgdGhlIElTTyBEb21haW4gc3RhdGUg aXMgIlVuYXR0YWNoZWQiOw== ------=_NextPart_57737DBD_0A5F5BD0_4F0318D1 Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 PGRpdj5Qcm9ibGVtOkluc3RhbGwgdGhlIG92aXJ0LWVuZ2luZS00LjAgLEkgY2hvc2UgdGhl IElTTyBEb21haW4gcGF0aCAiL3Zhci9saWIvZXhwb3J0cy9pc28iIGFuZCBpbnN0YWxsIHN1 Y2Nlc3NmdWwgO2J1dCBhY2Nlc3MgdGhyb3VnaCBicm93c2VyLCA8c3BhbiBzdHlsZT0ibGlu ZS1oZWlnaHQ6IDEuNTsiPnRoZSBJU08gRG9tYWluIHN0YXRlIGlzICJVbmF0dGFjaGVkPC9z cGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS41OyI+Ijs8L3NwYW4+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+ ------=_NextPart_57737DBD_0A5F5BD0_4F0318D1--

2 1

Create a Virtual Disk failed
by Dewey Du 28 Jun '16

28 Jun '16

I use glusterfs as storage. When I tried to create a virtual disk for a vm, I got the following error in UI logs. ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-48) [] Permutation name: B003B5EDCB6FC4308644D5D001F65B4C ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-48) [] Uncaught exception: : com.google.gwt.core.client.JavaScriptException: (TypeError) __gwt$exception: <skipped>: a is undefined at Unknown._kj(Unknown Source) at Unknown.JUq(Unknown Source) at Unknown.Fbr(Unknown Source) at Unknown.Hno(Unknown Source) at Unknown.t0n(Unknown Source) at Unknown.w0n(Unknown Source) at Unknown.q3n(Unknown Source) at Unknown.t3n(Unknown Source) at Unknown.S2n(Unknown Source) at Unknown.V2n(Unknown Source) at Unknown.bMe(Unknown Source) at Unknown.V7(Unknown Source) at Unknown.k8(Unknown Source) at Unknown.czf/c.onreadystatechange<(Unknown Source) at Unknown.Ux(Unknown Source) at Unknown.Yx(Unknown Source) at Unknown.Xx/<(Unknown Source) at Unknown.anonymous(Unknown Source)

4 5

VDI experience to share?
by Giorgio Bersano 28 Jun '16

28 Jun '16

Hi everyone, I've been asked to deploy a VDI solution based on our oVirt infrastructure. What we have in production is a 3.6 manager (standalone, not HE) with a 3.5 cluster (CentOS 6) and a 3.6 cluster (CentOS 7), iSCSI storage, fully redundant networking. What is not clear to me is the client side, especially because we have been asked to implement a thin client solution but I've been almost unable to find suitable devices. Is there anyone in this list willing to share his/her experience on this topic? Probably my search skill is low but I've only seen references to IGEL. Other brands? There is another strong requirement: our network infrastructure makes use of 802.1x to authenticate client devices and it would be highly advisable to respect that constraint. TIA, Giorgio.

9 17

Re: [ovirt-users] 3.6 to 4.0 upgrade cert issue
by Matt Haught 28 Jun '16

28 Jun '16

So I switched back to the original self-signed certs that I had luckily saved and was able to get in without error. Is there a new process for using non-self-signed certs with ovirt 4.0? Thanks, -- Matt Haught On Fri, Jun 24, 2016 at 11:19 AM, Matt Haught <dmhaught(a)ncsu.edu> wrote: > I just attempted an upgrade from 3.6 to 4.0 hosted engine and ran into an > problem. The hosted engine vm updated without issue, but when I go to login > to the web interface to continue the process I get: > > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > > at every page load and I can't login. I have a feeling that the issue > comes from where I replaced the self-signed certs with trusted ca signed > certs a year ago. Is there a work around? > > CentOS 7.2 > > Thanks, > > -- > Matt Haught >

3 5

Security Groups
by Pavel Gashev 28 Jun '16

28 Jun '16

Hello, Currently oVirt supports network security groups for OpenStack network provider only. Are there plans to implement Security Groups for native networks? Technically, I can configure a vNic profile with some Security Groups UUID, and apply it in before_device_create and before_update_device VDSM hooks as filterref to some custom nwfilter. The only issue is that I have to manually edit and distribute nwfilter xml among hardware nodes. If I want isolate set of VMs, I have to manually maintain MAC addresses of VMs in that xml. It would be great if oVirt web interface had a nwfilter editor. Are there plans for it? Thanks

2 1

ovirt-engine-4.0 storage ISO Domain Unattached
by 转圈圈 28 Jun '16

28 Jun '16

This is a multi-part message in MIME format. ------=_NextPart_57722BB7_09080C70_033D1CB6 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 UHJvYmxlbTpJbnN0YWxsIHRoZSBvdmlydC1lbmdpbmUtNC4wICxJIGNob3NlIHRoZSBJU08g RG9tYWluIHBhdGggIi92YXIvbGliL2V4cG9ydHMvaXNvIiBhbmQgaW5zdGFsbCBzdWNjZXNz ZnVsIDtidXQgYWNjZXNzIHRocm91Z2ggYnJvd3NlciwgdGhlIElTTyBEb21haW4gc3RhdGUg aXMgIlVuYXR0YWNoZWQiOw== ------=_NextPart_57722BB7_09080C70_033D1CB6 Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 PGRpdj5Qcm9ibGVtOkluc3RhbGwgdGhlIG92aXJ0LWVuZ2luZS00LjAgLEkgY2hvc2UgdGhl IElTTyBEb21haW4gcGF0aCAiL3Zhci9saWIvZXhwb3J0cy9pc28iIGFuZCBpbnN0YWxsIHN1 Y2Nlc3NmdWwgO2J1dCBhY2Nlc3MgdGhyb3VnaCBicm93c2VyLCZuYnNwOzxzcGFuIHN0eWxl PSJsaW5lLWhlaWdodDogMS41OyI+dGhlIElTTyBEb21haW4gc3RhdGUgaXMgIlVuYXR0YWNo ZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjU7Ij4iOzwvc3Bhbj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj4= ------=_NextPart_57722BB7_09080C70_033D1CB6--

1 0

migrating a vm from a down node
by Bill James 28 Jun '16

28 Jun '16

I am doing some fault tolerance type testing with ovirt before we put it in production. One thing I noticed is if I unplug the power from a hardware node, including iLo (fence), that the VMs that were on that host go to unknown state. I have found no way in the GUI to migrate the hosts, even they they are marked HA. The only way I've found so far is to modify the database directly. Is that the only recovery from a host failure of this type? engine=> update vm_dynamic set status = 0 where vm_guid =(select engine(> vm_guid from vm_static where vm_name = 'myvm'); ovirt-engine-3.6.4.1-1.el7.centos.noarch centos 7.2 Also is 3.6.4 a OK version to use or should I upgrade first? (looks like 3.6.6.2-1.el7.centos is current latest)

2 1

Accessing VM over WAN
by RK RK 28 Jun '16

28 Jun '16

Hi, I am planning to deploy oVirt 4.0.0 in a production environment where initially it will host 150 VDIs and will expand by 20 to 25 in subsequent years with Windows 7, 8.1 and 10. Users will be accessing these VDIs from their android tab or any tiny thin client devices which will have only very small footprint OS with HTML5 supported browser. I wish to give users to access the VDIs over WAN(from their home or on travel). Is it possible to access the VDIs via spice-html5 over the WAN. Any special configurations to be made to enable it? How should I make spice-html5 as the default protocol to access the VDIs? -- With Regards, RK, +91 9840483044

4 3

VMs halt on Storage Error
by David Gerner 27 Jun '16

27 Jun '16

Hi, I'm running into a strange issue that I've been trying to solve unsuccessfully for a few days now, and I was hoping someone could offer some insight. A few days ago I needed to reboot the the server that hosts the management engine and is also a node in the system. Following proper procedure I selected a new host to be the SPM, migrated VMs off the Host, and put it into maintenance mode. After the host came back up (and the management engine was back online) I noticed that one of my VMs had halted on a storage error, to rule out the SPM being the issue I asked oVirt to select a new SPM and it was stuck in a contending loop where each host tries to contend for SPM status but ultimately fails (every other VM also halted by this point). The error was "BlockSD master file system FSCK error", after researching the error I found a post on this list that was the same error and the author said that a simple FSCK on the offending file system fixed his issue. I had to force shutdown every VM from the halted state and put all but one host into maintenance mode. On that host I ran a FSCK on the offending volume which found a lot of short read errors which it fixed and afterwards the contending loop was broke and hosts could now successfully be an SPM. Now every VM halts on start or resume, even ones that were offline at the time of the earlier incident, with a Storage Error "abnormal vm stop device virtio-disk0 error eio". I can't even create new disks because it fails with an error. I've attached what I think is the relevant VDSM log portion of a VM trying to resume, if more is needed please just let me know. I'm worried FSCK and I mangled the file system, and have no idea how to repair it. Any insight is greatly appreciated. Thank you, Dave oVirt Engine Version: 3.6.2.6-1.el7.centos Storage Tech: iSCSI 4 Servers each with: OS: RHEL - 7 - 2.1511.el7.centos.2.10 Kernel: 3.10.0 - 327.4.5.el7.x86_64 KVM Version: 2.3.0 - 31.el7_2.7.1 libVirt Version: libvirt-1.2.17-13.el7_2.5 VDSM Version: vdsm-4.17.28-0.el7.centos

2 1

direct mounting of vm disks?
by Robert Story 27 Jun '16

27 Jun '16

--Sig_/.lLlEVeLgvPZAtF/dI+yD0s Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I'm using oVirt 3.5.x w/nfs for vm file storage. I'm trying to restore a vm from backup, which entails: - scp backup.tar to vm - untar backup on vm this means all the data makes 3 trips over the network, each of which causes a load spike on my nfs server. That nfs load, of course, affects all other vms. what I'd like to be able to do is - scp backup.tar to nfs server - stop vm - mount vm disks on nfs server - untar backup on nfs server (using ionice to minimze load impact) - unmount vm disks - start vm I remember that I used to use kpartx to mount regular KVM disks, so I'm hoping that it can also be done here. Anyone else tried to make this work? Robert --=20 Senior Software Engineer @ Parsons --Sig_/.lLlEVeLgvPZAtF/dI+yD0s Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldvXM8ACgkQ7/fVLLY1mni4KwCdFDpmX8f3BumEgulWCmcUiiNz m6wAnReCZ1roZh10nXVW0iIYKtl+M9gE =KDOJ -----END PGP SIGNATURE----- --Sig_/.lLlEVeLgvPZAtF/dI+yD0s--

2 2

Unofficial projects
by James Michels 27 Jun '16

27 Jun '16

Greetings, Is there some official oVirt section where you list unofficial oVirt-related projects? If so, what is the process for a new unofficial project to get listed there? If not, I think it might be a good idea to provide a minimal support by listing them. Thank you. James

3 3

no katello 3.0 errata available anymore into ovirt
by Nathanaël Blanchet 27 Jun '16

27 Jun '16

Hi, I upgraded to the latest katello 3.0, and errata are not available anymore for hosts or vms. There is no error, it always displays 0 errata. The name of the host/vm is the same as into foreman. Though, list of provisionned hosts is still available, so I suppose the issue comes from katello API and not foreman API. Thank you. -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

2 1

Migrations Guide in order to migrate to Enterprise Linux 7
by Ricky Schneberger 27 Jun '16

27 Jun '16

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lqvbPKPnHTdwtMCUjfMuxijuAKhJRnANe Content-Type: multipart/mixed; boundary="mVCwoxH39T20LMeN7dVTaPAj3lpWdCIge" From: Ricky Schneberger <ricky(a)schneberger.se> Reply-To: ricky(a)schneberger.se To: users <users(a)ovirt.org> Message-ID: <57711C2E.5020500(a)schneberger.se> Subject: Migrations Guide in order to migrate to Enterprise Linux 7 --mVCwoxH39T20LMeN7dVTaPAj3lpWdCIge Content-Type: multipart/alternative; boundary="------------030708040908010902070501" This is a multi-part message in MIME format. --------------030708040908010902070501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I found out that an upgrade of oVirt 3.6 to 4.0 is not supported on Enterprise Linux 6. The information was that I should follow an Migration Guide - https://www.ovirt.org/release/4.0.0/documentation/migration-engine-3.6-to-4= .0. "Upgrade on Fedora 22 and Enterprise Linux 6 is not supported and you should follow our Migration Guide <https://www.ovirt.org/release/4.0.0/documentation/migration-engine-3.6-to-= 4.0/> in order to migrate to Enterprise Linux 7 or Fedora 23." The link only gives an 404. Regards --=20 Ricky Schneberger ------------------------------------ Use PGP to protect your own privacy! Key fingerprint =3D 59E1 2B00 C28B 6E0D C8D1 D85B 39AA 7CD5 B88C 0B63 Key-ID: 0xB88C0B63 --------------030708040908010902070501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8= "> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> Hi,<br> I found out that an upgrade of oVirt 3.6 to 4.0 is not supported on Enterprise Linux 6.<br> The information was that I should follow an Migration Guide - <a class=3D"moz-txt-link-freetext" href=3D"https://www.ovirt.org/release/4.= 0.0/documentation/migration-engine-3.6-to-4.0">https://www.ovirt.org/releas= e/4.0.0/documentation/migration-engine-3.6-to-4.0</a>.<br> <br> "Upgrade on Fedora 22 and Enterprise Linux 6 is not supported and you should follow our <a href=3D"https://www.ovirt.org/release/4.0.0/documentation/migration-engine-= 3.6-to-4.0/">Migration Guide</a> in order to migrate to Enterprise Linux 7 or Fedora 23."<br> <br> The link only gives an 404.<br> <br> Regards<br> <pre class=3D"moz-signature" cols=3D"72">--=20 Ricky Schneberger ------------------------------------ Use PGP to protect your own privacy! Key fingerprint =3D 59E1 2B00 C28B 6E0D C8D1 D85B 39AA 7CD5 B88C 0B63 Key-ID: 0xB88C0B63 </pre> </body> </html> --------------030708040908010902070501-- --mVCwoxH39T20LMeN7dVTaPAj3lpWdCIge-- --lqvbPKPnHTdwtMCUjfMuxijuAKhJRnANe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldxHC4ACgkQOap81biMC2PXVgCgjJxrcy15uBP4XhnZmhKho2FB SYUAnRojHvqX5++WAFVwB69maUq3Loqn =ZQtv -----END PGP SIGNATURE----- --lqvbPKPnHTdwtMCUjfMuxijuAKhJRnANe-- -- IMPORTANT! This message has been scanned for viruses and phishing links. However, it is your responsibility to evaluate the links and attachments you choose to click. If you are uncertain, we always try to help. Greetings helpdesk(a)actnet.se

2 2

Network redundancy with Manual balancing per VLAN
by Fernando Frediani 27 Jun '16

27 Jun '16

Hello, In VMware it is possible to bond two network interfaces and for each Portgroup (equivalent to a VLAN) is possible to tell which of the physical interfaces underneath it you wish the traffic to flow primarily and which stays as secondary(bond mode=1 equivalent). So for certain VLANs (Management, Live Migration, etc) is possible to force traffic flow via one physical NIC of the bond and for other VLANs (Virtual Machine's traffic) outs via the other NIC with failover to each other should a cable or switch fails. This is specially good for better utilize the fewer NICs available and still have redundancy. In oVirt it is also possible to have bonds, but would it still be possible to do that same and favor the traffic per VLAN basis ? I guess it is something related to Linux Bond module but perhaps someone has done this already. Thanks Fernando

4 5

oVirt and Ceph
by Charles Gomes 27 Jun '16

27 Jun '16

--_000_307E608C4BFFA145A1496A5FD1ACC3BC1D7FDD46exchange2010dim_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I've been reading lots of material about implementing oVirt with Ceph, howe= ver all talk about using Cinder. Is there a way to get oVirt with Ceph without having to implement entire Op= enstack ? I'm already currently using Foreman to deploy Ceph and KVM nodes, trying to= minimize the amount of moving parts. I heard something about oVirt providi= ng a managed Cinder appliance, have any seen this ? --_000_307E608C4BFFA145A1496A5FD1ACC3BC1D7FDD46exchange2010dim_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hello<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I’ve been reading lots of material about imple= menting oVirt with Ceph, however all talk about using Cinder. <o:p></o:p></p> <p class=3D"MsoNormal">Is there a way to get oVirt with Ceph without having= to implement entire Openstack ? <o:p></o:p></p> <p class=3D"MsoNormal">I’m already currently using Foreman to deploy = Ceph and KVM nodes, trying to minimize the amount of moving parts. I heard = something about oVirt providing a managed Cinder appliance, have any seen t= his ?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_307E608C4BFFA145A1496A5FD1ACC3BC1D7FDD46exchange2010dim_--

9 12

latest CentOS libvirt updates safe?
by Robert Story 27 Jun '16

27 Jun '16

--Sig_/2+FpI4Cvur605E8SRHVCwXB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have oVirt 3.5.x on CentOS 7 hosts. These hosts have updates which include livbirt: libvirt-client x86_64 1.2.17-13.el7_2.5 updates 4= .3 M libvirt-daemon x86_64 1.2.17-13.el7_2.5 updates 5= 85 k libvirt-daemon-config-nwfilter x86_64 1.2.17-13.el7_2.5 updates 1= 22 k libvirt-daemon-driver-interface x86_64 1.2.17-13.el7_2.5 updates 1= 62 k libvirt-daemon-driver-network x86_64 1.2.17-13.el7_2.5 updates 3= 02 k libvirt-daemon-driver-nodedev x86_64 1.2.17-13.el7_2.5 updates 1= 61 k libvirt-daemon-driver-nwfilter x86_64 1.2.17-13.el7_2.5 updates 1= 85 k libvirt-daemon-driver-qemu x86_64 1.2.17-13.el7_2.5 updates 5= 71 k libvirt-daemon-driver-secret x86_64 1.2.17-13.el7_2.5 updates 1= 55 k libvirt-daemon-driver-storage x86_64 1.2.17-13.el7_2.5 updates 3= 28 k libvirt-daemon-kvm x86_64 1.2.17-13.el7_2.5 updates 1= 18 k libvirt-lock-sanlock Is it safe to let yum update these packages while the host has running VMs? in maintenance mode? or not at all? Robert --=20 Senior Software Engineer @ Parsons --Sig_/2+FpI4Cvur605E8SRHVCwXB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldum/EACgkQ7/fVLLY1mnj6KQCfWUsVS/OU/98ynUgin2QwEw46 ANsAnjElWFKIhCURI95jsBsCmewxDTgq =Oi3o -----END PGP SIGNATURE----- --Sig_/2+FpI4Cvur605E8SRHVCwXB--

6 7

Network Interface order changed after reboot
by ovirt＠timmi.org 27 Jun '16

27 Jun '16

Hi List, I have two nodes (running CentOS 7) and the network interface order changed for some interfaces after every reboot. The configurations are done through the oVirt GUI. So the ifcfg-ethX scripts are configured automatically by VDSM. Is there any option to get this configured to be stable? Best regards and thank you Christoph

5 11

InClusterUpgrade Scheduling Policy
by Scott 27 Jun '16

27 Jun '16

Hello list, I'm trying to upgrade a self-hosted engine RHEV environment running 3.5/el6 to 3.6/el7. I'm following the process outlined in these two documents: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualiza… https://access.redhat.com/solutions/2300331 The problem I'm having is I don't seem to be able to apply the "InClusterUpgrade" policy (procedure 5.5, step 4). I get the following error: Can not start cluster upgrade mode, see below for details: VM HostedEngine with id 5ca9cb38-82e5-4eea-8ff6-e2bc33598211 is configured to be not migratable. But the HostedEngine VM is not one I can edit due to being mid-upgrade. And even if I could, the setting its complaining about can't be managed by the engine (I tried in another RHEV instance). Is this a bug? What am I missing to be able to move on? As it seems now, the InClusterUpgrade scheduling policy is useless and can't actually be used. Thanks for any suggestions/help, Scott

3 7

vm pauses with "vm has paused due to unknown storage error
by Bill Bill 27 Jun '16

27 Jun '16

--_000_CO2PR0801MB0743180FC142ED11D7D5D3E0A62E0CO2PR0801MB0743_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhhdmUgMyBub2RlcyBydW5uaW5nIGJvdGggb1ZpcnQgYW5kIEdsdXN0ZXIgb24g NCBTU0TigJlzIGVhY2guIEF0IHRoZSBtb21lbnQsIHRoZXJlIGFyZSB0d28gcGh5c2ljYWwgbmlj cywgb25lIGhhcyBwdWJsaWMgaW50ZXJuZXQgYWNjZXNzIGFuZCB0aGUgb3RoZXIgaXMgYSBub24t cm91dGFibGUgbmV0d29yayB1c2VkIGZvciBvdmlydG1nbXQgJiBnbHVzdGVyLg0KDQpJbiB0aGUg bG9naWNhbCBuZXR3b3JrcywgSSBoYXZlIHNlbGVjdGVkIGdsdXN0ZXIgZm9yIHRoZSBub25yb3V0 YWJsZSBuZXR3b3JrIHJ1bm5pbmcgb3ZpcnRtZ210IGFuZCBnbHVzdGVyIGhvd2V2ZXIsIHR3byBW TeKAmXMgcmFuZG9tbHkgcGF1c2UgZm9yIHdoYXQgc2VlbXMgbGlrZSBubyByZWFzb24uIFRoZXkg Y2FuIGJvdGggYmUgcmVzdW1lZCB3aXRob3V0IGlzc3VlLg0KDQpPbmUgdGVzdCBWTSBoYXMgNEdC IG9mIG1lbW9yeSBhbmQgYSBzbWFsbCBkaXNrIOKAkyBubyBwcm9ibGVtcyB3aXRoIHRoaXMgb25l LiBUd28gb3RoZXJzIGhhdmUgODAwR0IgZGlza3MgYW5kIDMyR0Igb2YgUkFNIOKAkyBib3RoIHZt 4oCZcyBleGhpYml0IHRoZSBzYW1lIGlzc3VlLg0KDQpJIGFsc28gc2VlIHRoZXNlIGluIHRoZSBv VmlydCBkYXNoYm9hcmQ6DQoNCg0KRmFpbGVkIHRvIHVwZGF0ZSBPVkYgZGlza3MgOWU2MDMyOGQt MjlhZi00NTMzLTg0ZjktNjMzZDg3ZjU0OGE3LCBPVkYgZGF0YSBpc24ndCB1cGRhdGVkIG9uIHRo b3NlIE9WRiBzdG9yZXMgKERhdGEgQ2VudGVyIHh4eHh4LCBTdG9yYWdlIERvbWFpbiBzci12b2x1 bWUwMSkuDQoNCkp1biAyMywgMjAxNiA5OjU0OjAzIFBNDQoNClZEU00gY29tbWFuZCBmYWlsZWQ6 IENvdWxkIG5vdCBhY3F1aXJlIHJlc291cmNlLiBQcm9iYWJseSByZXNvdXJjZSBmYWN0b3J5IHRo cmV3IGFuIGV4Y2VwdGlvbi46ICgpDQoNCi8vLy8vLy8vLy8vLy8vLw0KDQpWTSB4eHh4eCBoYXMg YmVlbiBwYXVzZWQgZHVlIHRvIHVua25vd24gc3RvcmFnZSBlcnJvci4NCg0KLy8vLy8vLy8vLy8v Ly8vDQoNCkluIHRoZSBlcnJvciBsb2cgb24gdGhlIGVuZ2luZSwgSSBzZWUgdGhlc2U6DQoNCkVS Uk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0bG9naGFuZGxpbmcu QXVkaXRMb2dEaXJlY3Rvcl0gKEZvcmtKb2luUG9vbC0xLXdvcmtlci03KSBbMTBjYWY5M2VdIENv cnJlbGF0aW9uIElEOiBudWxsLCBDYWxsIFN0YWNrOiBudWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0x LCBNZXNzYWdlOiBWTSB4eHh4eHggaGFzIGJlZW4gcGF1c2VkIGR1ZSB0byB1bmtub3duIHN0b3Jh Z2UgZXJyb3IuDQoNCklORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1 ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKEZvcmtKb2luUG9vbC0xLXdvcmtlci0x MSkgWzEwY2FmOTNlXSBDb3JyZWxhdGlvbiBJRDogbnVsbCwgQ2FsbCBTdGFjazogbnVsbCwgQ3Vz dG9tIEV2ZW50IElEOiAtMSwgTWVzc2FnZTogVk0geHh4eHh4IGhhcyByZWNvdmVyZWQgZnJvbSBw YXVzZWQgYmFjayB0byB1cC4NCg0KLy8vLy8vLy8vLy8vLy8vDQoNCkhvc3RuYW1lcyBhcmUgYWxs IGxvY2FsIHRvIC9ldGMvaG9zdHMgb24gYWxsIHNlcnZlcnMg4oCTIHRoZXkgYWxzbyByZXNvbHZl IHdpdGhvdXQgaXNzdWUgZnJvbSBlYWNoIGhvc3QuDQoNCi8vLy8vLy8vLy8vLy8vDQoNCjIwMTYt MDYtMjMgMjI6MDg6NTksNjExIFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2Vy LmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0 elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNr ICdvdmlydDM0MzU6L21udC9kYXRhL3NyLXZvbHVtZTAxJyBvZiB2b2x1bWUgJzkzZTM2Y2RjLWFi MWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OScgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1 c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2 M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjE0IFdBUk4gIFtvcmcub3ZpcnQuZW5n aW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1s UnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBu b3QgYXNzb2NpYXRlIGJyaWNrICdvdmlydDM2Mzc6L21udC9kYXRhL3NyLXZvbHVtZTAxJyBvZiB2 b2x1bWUgJzkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OScgd2l0aCBjb3JyZWN0 IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRl LTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjE2IFdB Uk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVt ZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYp IFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdvdmlydDM4Mzk6L21udC9kYXRh L3NyLXZvbHVtZTAxJyBvZiB2b2x1bWUgJzkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1 NmI1OScgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGlu IGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYt MjMgMjI6MDg6NTksNjE4IFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmds dXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNj aGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdv dmlydDM0MzU6L21udC9kYXRhL2Rpc3RyaWJ1dGVkJyBvZiB2b2x1bWUgJ2I4ODdiMDVlLTJlYTYt NDk2ZS05NTUyLTE1NWQ2NThlZWFhNicgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3Rl ciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5 MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjIwIFdBUk4gIFtvcmcub3ZpcnQuZW5naW5l LmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBj XSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3Qg YXNzb2NpYXRlIGJyaWNrICdvdmlydDM2Mzc6L21udC9kYXRhL2Rpc3RyaWJ1dGVkJyBvZiB2b2x1 bWUgJ2I4ODdiMDVlLTJlYTYtNDk2ZS05NTUyLTE1NWQ2NThlZWFhNicgd2l0aCBjb3JyZWN0IG5l dHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0 YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjIyIFdBUk4g IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNM aXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsx YzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdvdmlydDM4Mzk6L21udC9kYXRhL2Rp c3RyaWJ1dGVkJyBvZiB2b2x1bWUgJ2I4ODdiMDVlLTJlYTYtNDk2ZS05NTUyLTE1NWQ2NThlZWFh Nicgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNs dXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMg MjI6MDg6NTksNjI0IFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0 ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVk dWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdvdmly dDM0MzU6L21udC9kYXRhL2lzbycgb2Ygdm9sdW1lICc4OWYzMjQ1Ny1jOGMzLTQ5MGUtYjQ5MS0x NmRkMjdkZTAwNzMnIHdpdGggY29ycmVjdCBuZXR3b3JrIGFzIG5vIGdsdXN0ZXIgbmV0d29yayBm b3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIyLTRhOTktOWNkMC1iNjNlOTE5YjlhY2EnDQoy MDE2LTA2LTIzIDIyOjA4OjU5LDYyNiBXQVJOICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jy b2tlci5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJwY10gKERlZmF1bHRR dWFydHpTY2hlZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90IGFzc29jaWF0ZSBi cmljayAnb3ZpcnQzNjM3Oi9tbnQvZGF0YS9pc28nIG9mIHZvbHVtZSAnODlmMzI0NTctYzhjMy00 OTBlLWI0OTEtMTZkZDI3ZGUwMDczJyB3aXRoIGNvcnJlY3QgbmV0d29yayBhcyBubyBnbHVzdGVy IG5ldHdvcmsgZm91bmQgaW4gY2x1c3RlciAnNzViZDY0ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkx OWI5YWNhJw0KMjAxNi0wNi0yMyAyMjowODo1OSw2MjggV0FSTiAgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RSZXR1cm5Gb3JYbWxScGNd IChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03NikgWzFjMWNmNGZdIENvdWxkIG5vdCBh c3NvY2lhdGUgYnJpY2sgJ292aXJ0MzgzOTovbW50L2RhdGEvaXNvJyBvZiB2b2x1bWUgJzg5ZjMy NDU3LWM4YzMtNDkwZS1iNDkxLTE2ZGQyN2RlMDA3Mycgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMg bm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05 Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjI5IElORk8gIFtvcmcub3Zp cnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0VkRTQ29t bWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gRklOSVNI LCBHbHVzdGVyVm9sdW1lc0xpc3RWRFNDb21tYW5kLCByZXR1cm46IHtiODg3YjA1ZS0yZWE2LTQ5 NmUtOTU1Mi0xNTVkNjU4ZWVhYTY9b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmNvbW1vbi5idXNpbmVz c2VudGl0aWVzLmdsdXN0ZXIuR2x1c3RlclZvbHVtZUVudGl0eUBkOGM5MDM5YiwgOTNlMzZjZGMt YWIxYi00MWVjLWFjN2YtOTY2Y2YzODU2YjU5PW9yZy5vdmlydC5lbmdpbmUuY29yZS5jb21tb24u YnVzaW5lc3NlbnRpdGllcy5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVFbnRpdHlAZmU1YWIwMTksIDg5 ZjMyNDU3LWM4YzMtNDkwZS1iNDkxLTE2ZGQyN2RlMDA3Mz1vcmcub3ZpcnQuZW5naW5lLmNvcmUu Y29tbW9uLmJ1c2luZXNzZW50aXRpZXMuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lRW50aXR5QDlhNTZk NjMzfSwgbG9nIGlkOiA0ODVhMDYxMQ0KMjAxNi0wNi0yMyAyMjowOTowNCw2NDUgSU5GTyAgW29y Zy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RW RFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItODkpIFtdIFNUQVJULCBH bHVzdGVyVm9sdW1lc0xpc3RWRFNDb21tYW5kKEhvc3ROYW1lID0gb3ZpcnQzODM5LCBHbHVzdGVy Vm9sdW1lc0xpc3RWRFNQYXJhbWV0ZXJzOntydW5Bc3luYz0ndHJ1ZScsIGhvc3RJZD0nMzJjNTAw ZTUtMjY4ZC00MjZhLTlhNGEtMTA4NTM1ZTY3NzIyJ30pLCBsb2cgaWQ6IDQxYjY0NzlkDQo= --_000_CO2PR0801MB0743180FC142ED11D7D5D3E0A62E0CO2PR0801MB0743_ Content-Type: text/html; charset="utf-8" Content-ID: <D0C4FA3A5B1EE240A396E58D5F57A2E7(a)sct-15-1-485-2-msonline-outlook-1173a.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 bGFzcz0iTXNvTm9ybWFsIj5IYXZlIDMgbm9kZXMgcnVubmluZyBib3RoIG9WaXJ0IGFuZCBHbHVz dGVyIG9uIDQgU1NE4oCZcyBlYWNoLiBBdCB0aGUgbW9tZW50LCB0aGVyZSBhcmUgdHdvIHBoeXNp Y2FsIG5pY3MsIG9uZSBoYXMgcHVibGljIGludGVybmV0IGFjY2VzcyBhbmQgdGhlIG90aGVyIGlz IGEgbm9uLXJvdXRhYmxlIG5ldHdvcmsgdXNlZCBmb3Igb3ZpcnRtZ210ICZhbXA7IGdsdXN0ZXIu PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiB0aGUgbG9naWNhbCBuZXR3b3JrcywgSSBoYXZlIHNlbGVjdGVkIGds dXN0ZXIgZm9yIHRoZSBub25yb3V0YWJsZSBuZXR3b3JrIHJ1bm5pbmcgb3ZpcnRtZ210IGFuZCBn bHVzdGVyIGhvd2V2ZXIsIHR3byBWTeKAmXMgcmFuZG9tbHkgcGF1c2UgZm9yIHdoYXQgc2VlbXMg bGlrZSBubyByZWFzb24uIFRoZXkgY2FuIGJvdGggYmUgcmVzdW1lZCB3aXRob3V0IGlzc3VlLjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T25lIHRlc3QgVk0gaGFzIDRHQiBvZiBtZW1vcnkgYW5kIGEgc21hbGwgZGlz ayDigJMgbm8gcHJvYmxlbXMgd2l0aCB0aGlzIG9uZS4gVHdvIG90aGVycyBoYXZlIDgwMEdCIGRp c2tzIGFuZCAzMkdCIG9mIFJBTSDigJMgYm90aCB2beKAmXMgZXhoaWJpdCB0aGUgc2FtZSBpc3N1 ZS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+SSBhbHNvIHNlZSB0aGVzZSBpbiB0aGUgb1ZpcnQgZGFzaGJvYXJkOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+RmFpbGVkIHRvIHVwZGF0ZSBPVkYgZGlza3Mg OWU2MDMyOGQtMjlhZi00NTMzLTg0ZjktNjMzZDg3ZjU0OGE3LCBPVkYgZGF0YSBpc24ndCB1cGRh dGVkIG9uIHRob3NlIE9WRiBzdG9yZXMgKERhdGEgQ2VudGVyIHh4eHh4LCBTdG9yYWdlIERvbWFp biBzci12b2x1bWUwMSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkp1biAyMywgMjAxNiA5OjU0OjAz IFBNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlZEU00gY29tbWFuZCBmYWlsZWQ6IENvdWxkIG5vdCBh Y3F1aXJlIHJlc291cmNlLiBQcm9iYWJseSByZXNvdXJjZSBmYWN0b3J5IHRocmV3IGFuIGV4Y2Vw dGlvbi46ICgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi8vLy8vLy8vLy8vLy8vLzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5WTSB4eHh4eCBoYXMgYmVlbiBwYXVzZWQgZHVlIHRvIHVua25vd24gc3RvcmFn ZSBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Ly8vLy8vLy8vLy8vLy8vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkluIHRoZSBlcnJvciBsb2cgb24gdGhlIGVuZ2luZSwgSSBzZWUgdGhlc2U6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPkVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJv a2VyLmF1ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKEZvcmtKb2luUG9vbC0xLXdv cmtlci03KSBbMTBjYWY5M2VdIENvcnJlbGF0aW9uIElEOiBudWxsLCBDYWxsIFN0YWNrOiBudWxs LCBDdXN0b20gRXZlbnQgSUQ6DQogLTEsIE1lc3NhZ2U6IFZNIHh4eHh4eCBoYXMgYmVlbiBwYXVz ZWQgZHVlIHRvIHVua25vd24gc3RvcmFnZSBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SU5G TyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5hdWRpdGxvZ2hhbmRs aW5nLkF1ZGl0TG9nRGlyZWN0b3JdIChGb3JrSm9pblBvb2wtMS13b3JrZXItMTEpIFsxMGNhZjkz ZV0gQ29ycmVsYXRpb24gSUQ6IG51bGwsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJ RDoNCiAtMSwgTWVzc2FnZTogVk0geHh4eHh4IGhhcyByZWNvdmVyZWQgZnJvbSBwYXVzZWQgYmFj ayB0byB1cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Ly8vLy8vLy8vLy8vLy8vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkhvc3RuYW1lcyBhcmUgYWxsIGxvY2FsIHRvIC9ldGMvaG9zdHMgb24gYWxsIHNl cnZlcnMg4oCTIHRoZXkgYWxzbyByZXNvbHZlIHdpdGhvdXQgaXNzdWUgZnJvbSBlYWNoIGhvc3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPi8vLy8vLy8vLy8vLy8vPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PjIwMTYtMDYtMjMgMjI6MDg6NTksNjExIFdBUk4mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RSZXR1cm5Gb3JYbWxScGNdIChE ZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03NikgWzFjMWNmNGZdIENvdWxkIG5vdCBhc3Nv Y2lhdGUNCiBicmljayAnb3ZpcnQzNDM1Oi9tbnQvZGF0YS9zci12b2x1bWUwMScgb2Ygdm9sdW1l ICc5M2UzNmNkYy1hYjFiLTQxZWMtYWM3Zi05NjZjZjM4NTZiNTknIHdpdGggY29ycmVjdCBuZXR3 b3JrIGFzIG5vIGdsdXN0ZXIgbmV0d29yayBmb3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIy LTRhOTktOWNkMC1iNjNlOTE5YjlhY2EnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4yMDE2LTA2LTIzIDIyOjA4OjU5LDYxNCBX QVJOJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3Rl clZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3Jr ZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlDQogYnJpY2sgJ292aXJ0MzYzNzov bW50L2RhdGEvc3Itdm9sdW1lMDEnIG9mIHZvbHVtZSAnOTNlMzZjZGMtYWIxYi00MWVjLWFjN2Yt OTY2Y2YzODU2YjU5JyB3aXRoIGNvcnJlY3QgbmV0d29yayBhcyBubyBnbHVzdGVyIG5ldHdvcmsg Zm91bmQgaW4gY2x1c3RlciAnNzViZDY0ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkxOWI5YWNhJzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+MjAxNi0wNi0yMyAyMjowODo1OSw2MTYgV0FSTiZuYnNwOyBbb3JnLm92aXJ0LmVuZ2lu ZS5jb3JlLnZkc2Jyb2tlci5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJw Y10gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90 IGFzc29jaWF0ZQ0KIGJyaWNrICdvdmlydDM4Mzk6L21udC9kYXRhL3NyLXZvbHVtZTAxJyBvZiB2 b2x1bWUgJzkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OScgd2l0aCBjb3JyZWN0 IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRl LTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjIwMTYtMDYtMjMgMjI6MDg6NTks NjE4IFdBUk4mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5H bHVzdGVyVm9sdW1lc0xpc3RSZXR1cm5Gb3JYbWxScGNdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVy X1dvcmtlci03NikgWzFjMWNmNGZdIENvdWxkIG5vdCBhc3NvY2lhdGUNCiBicmljayAnb3ZpcnQz NDM1Oi9tbnQvZGF0YS9kaXN0cmlidXRlZCcgb2Ygdm9sdW1lICdiODg3YjA1ZS0yZWE2LTQ5NmUt OTU1Mi0xNTVkNjU4ZWVhYTYnIHdpdGggY29ycmVjdCBuZXR3b3JrIGFzIG5vIGdsdXN0ZXIgbmV0 d29yayBmb3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIyLTRhOTktOWNkMC1iNjNlOTE5Yjlh Y2EnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4yMDE2LTA2LTIzIDIyOjA4OjU5LDYyMCBXQVJOJm5ic3A7IFtvcmcub3ZpcnQu ZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9y WG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3Vs ZCBub3QgYXNzb2NpYXRlDQogYnJpY2sgJ292aXJ0MzYzNzovbW50L2RhdGEvZGlzdHJpYnV0ZWQn IG9mIHZvbHVtZSAnYjg4N2IwNWUtMmVhNi00OTZlLTk1NTItMTU1ZDY1OGVlYWE2JyB3aXRoIGNv cnJlY3QgbmV0d29yayBhcyBubyBnbHVzdGVyIG5ldHdvcmsgZm91bmQgaW4gY2x1c3RlciAnNzVi ZDY0ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkxOWI5YWNhJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+MjAxNi0wNi0yMyAyMjow ODo1OSw2MjIgV0FSTiZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5nbHVz dGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJwY10gKERlZmF1bHRRdWFydHpTY2hl ZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90IGFzc29jaWF0ZQ0KIGJyaWNrICdv dmlydDM4Mzk6L21udC9kYXRhL2Rpc3RyaWJ1dGVkJyBvZiB2b2x1bWUgJ2I4ODdiMDVlLTJlYTYt NDk2ZS05NTUyLTE1NWQ2NThlZWFhNicgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3Rl ciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5 MTliOWFjYSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjIwMTYtMDYtMjMgMjI6MDg6NTksNjI0IFdBUk4mbmJzcDsgW29yZy5v dmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RSZXR1 cm5Gb3JYbWxScGNdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03NikgWzFjMWNmNGZd IENvdWxkIG5vdCBhc3NvY2lhdGUNCiBicmljayAnb3ZpcnQzNDM1Oi9tbnQvZGF0YS9pc28nIG9m IHZvbHVtZSAnODlmMzI0NTctYzhjMy00OTBlLWI0OTEtMTZkZDI3ZGUwMDczJyB3aXRoIGNvcnJl Y3QgbmV0d29yayBhcyBubyBnbHVzdGVyIG5ldHdvcmsgZm91bmQgaW4gY2x1c3RlciAnNzViZDY0 ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkxOWI5YWNhJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+MjAxNi0wNi0yMyAyMjowODo1 OSw2MjYgV0FSTiZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5nbHVzdGVy LkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJwY10gKERlZmF1bHRRdWFydHpTY2hlZHVs ZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90IGFzc29jaWF0ZQ0KIGJyaWNrICdvdmly dDM2Mzc6L21udC9kYXRhL2lzbycgb2Ygdm9sdW1lICc4OWYzMjQ1Ny1jOGMzLTQ5MGUtYjQ5MS0x NmRkMjdkZTAwNzMnIHdpdGggY29ycmVjdCBuZXR3b3JrIGFzIG5vIGdsdXN0ZXIgbmV0d29yayBm b3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIyLTRhOTktOWNkMC1iNjNlOTE5YjlhY2EnPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4yMDE2LTA2LTIzIDIyOjA4OjU5LDYyOCBXQVJOJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5l LmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBj XSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3Qg YXNzb2NpYXRlDQogYnJpY2sgJ292aXJ0MzgzOTovbW50L2RhdGEvaXNvJyBvZiB2b2x1bWUgJzg5 ZjMyNDU3LWM4YzMtNDkwZS1iNDkxLTE2ZGQyN2RlMDA3Mycgd2l0aCBjb3JyZWN0IG5ldHdvcmsg YXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5 OS05Y2QwLWI2M2U5MTliOWFjYSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjIwMTYtMDYtMjMgMjI6MDg6NTksNjI5IElORk8m bmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9s dW1lc0xpc3RWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsx YzFjZjRmXSBGSU5JU0gsIEdsdXN0ZXJWb2x1bWVzTGlzdFZEU0NvbW1hbmQsDQogcmV0dXJuOiB7 Yjg4N2IwNWUtMmVhNi00OTZlLTk1NTItMTU1ZDY1OGVlYWE2PW9yZy5vdmlydC5lbmdpbmUuY29y ZS5jb21tb24uYnVzaW5lc3NlbnRpdGllcy5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVFbnRpdHlAZDhj OTAzOWIsIDkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OT1vcmcub3ZpcnQuZW5n aW5lLmNvcmUuY29tbW9uLmJ1c2luZXNzZW50aXRpZXMuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lRW50 aXR5QGZlNWFiMDE5LCA4OWYzMjQ1Ny1jOGMzLTQ5MGUtYjQ5MS0xNmRkMjdkZTAwNzM9b3JnLm92 aXJ0LmVuZ2luZS5jb3JlLmNvbW1vbi5idXNpbmVzc2VudGl0aWVzLmdsdXN0ZXIuR2x1c3RlclZv bHVtZUVudGl0eUA5YTU2ZDYzM30sDQogbG9nIGlkOiA0ODVhMDYxMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+MjAxNi0wNi0y MyAyMjowOTowNCw2NDUgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tl ci5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2No ZWR1bGVyX1dvcmtlci04OSkgW10gU1RBUlQsIEdsdXN0ZXJWb2x1bWVzTGlzdFZEU0NvbW1hbmQo SG9zdE5hbWUNCiA9IG92aXJ0MzgzOSwgR2x1c3RlclZvbHVtZXNMaXN0VkRTUGFyYW1ldGVyczp7 cnVuQXN5bmM9J3RydWUnLCBob3N0SWQ9JzMyYzUwMGU1LTI2OGQtNDI2YS05YTRhLTEwODUzNWU2 NzcyMid9KSwgbG9nIGlkOiA0MWI2NDc5ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CO2PR0801MB0743180FC142ED11D7D5D3E0A62E0CO2PR0801MB0743_--

3 2

oVirt 3.6 to 4.0 Upgrade
by Brett I. Holcomb 27 Jun '16

27 Jun '16

In order to not hijack another thread I wanted to separate this from the "latest CentOS libvirt updates safe?" thread since this is different than what the OP on that thread wants to do. I've been digging through the 4.0 documentation since I'd like to upgrade in the not to distant future so I'm doing research and I'm confused. I'm running 3.6.6 in a hosted Engine environment. My engine runs in a vm on the host. The host is a physical box and the VMs are stored on a NAS accessed by an iSCSI LUN, I have no other hosts running so I can not migrate. According to this link, https://www.ovirt.org/release/4.0.0/, I'm told to simply run yum update ovirt-engine-setup and then engine-setup but I assume that's for a non hosted-engine environment. I then go to the link for Hosted_Engine_HOwto#Upgrade_Hosted_Engine guide and am told to do this. Set hosted-engine maintenance mode to global and other stuff that is written assuming I have some place to migrate my VMs to. I do not have another host. So how do I properly move to oVirt 4.0 from 3.6.6 on a single physical host running a hosted Engine VM? Thanks.

3 4

Maintenance and hosted engine issue with Ovirt 4.0
by Bertrand Caplet 26 Jun '16

26 Jun '16

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3h4m2hcgdjFHtq8mNeaCD5hu0pIJG26iX Content-Type: multipart/mixed; boundary="GFM2vDbBGUeA0wNJT7d6kjCp8ADn59Dsq" From: Bertrand Caplet <bertrand.caplet(a)chunkz.net> To: users <users(a)ovirt.org> Message-ID: <4e5a6b1b-4360-2582-190f-d9d96fac3b2c(a)chunkz.net> Subject: Maintenance and hosted engine issue with Ovirt 4.0 --GFM2vDbBGUeA0wNJT7d6kjCp8ADn59Dsq Content-Type: multipart/alternative; boundary="------------C3B1797A5CA6C32E68FD0BE3" This is a multi-part message in MIME format. --------------C3B1797A5CA6C32E68FD0BE3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, I have hosted engine configured in my infrastructure and I just upgraded from Ovirt 3.6 to Ovirt 4.0 yesterday. Upgrade of hosted engine and my 2 nodes did ok. But now when I put one node in maintenance, it prepares for maintenance ; unset SPM if it was then migrate all the VMs to the another node. All of this steps are ok but VM stays locked and in migration mode like this : =2E Btw for the hosted engine I did migrate it manually. So all the others VMs are stuck locked and in migration mode. I did noticed every 10 minutes or so (pretty random), the ovirt-hosted-engine HA is sending mail in this order : 1. EngineUnexpectedlyDown 2. (StartState-ReinitializeFSM sometimes) 3. EngineDown-EngineStart 4. EngineStart-EngineStarting 5. EngineStarting-EngineUnexpectedlyDown 6. Repeat The hosted engine is pingable all this long, the web UI is reacheable all this long too. Anyone having this type of issues ? Do I open a bug on BugZilla ? Thanks in advance, Regards, --=20 CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: 6E494EB9 GPG FP: CB1B 664A 9165 98F8 459F 0807 CA35 B76F 6E49 4EB9 --------------C3B1797A5CA6C32E68FD0BE3 Content-Type: multipart/related; boundary="------------DF0929E39F7F44B41DB6C2AC" --------------DF0929E39F7F44B41DB6C2AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf= -8"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <p>Hi there,<br> I have hosted engine configured in my infrastructure and I just upgraded from Ovirt 3.6 to Ovirt 4.0 yesterday.</p> <p>Upgrade of hosted engine and my 2 nodes did ok. But now when I put one node in maintenance, it prepares for maintenance ; unset SPM if it was then migrate all the VMs to the another node. All of this steps are ok but VM stays locked and in migration mode like this :<br> <img src=3D"cid:part1.10023D7D.B57AAA47@chunkz.net" alt=3D"">. Btw = for the hosted engine I did migrate it manually.</p> <p>So all the others VMs are stuck locked and in migration mode. <br>= I did noticed every 10 minutes or so (pretty random), the ovirt-hosted-engine HA is sending mail in this order :</p> <ol> <li>EngineUnexpectedlyDown</li> <li>(StartState-ReinitializeFSM sometimes)<br> </li> <li>EngineDown-EngineStart</li> <li>EngineStart-EngineStarting</li> <li>EngineStarting-EngineUnexpectedlyDown</li> <li>Repeat</li> </ol> <p>The hosted engine is pingable all this long, the web UI is reacheable all this long too.</p> <p>Anyone having this type of issues ? Do I open a bug on BugZilla ?<= br> Thanks in advance,<br> Regards,</p> <pre class=3D"moz-signature" cols=3D"72">--=20 CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: 6E494EB9 GPG FP: CB1B 664A 9165 98F8 459F 0807 CA35 B76F 6E49 4EB9</pre> </body> </html> --------------DF0929E39F7F44B41DB6C2AC Content-Type: image/png; name="fommfmefonkedboc.png" Content-Transfer-Encoding: base64 Content-ID: <part1.10023D7D.B57AAA47(a)chunkz.net> Content-Disposition: inline; filename="fommfmefonkedboc.png" iVBORw0KGgoAAAANSUhEUgAAABYAAAAUCAIAAAAGHlpnAAAC20lEQVQ4jbWUz08TQRTH38mb JzXeTLz4JxiTRhOKeIda4tXLHk16QDhZAnJgS0sCCmmUAgYVEgXa0FJrQ+svaLu0lN8trFBK +SFCpd0tszO73fFQKEJq1BBf3mFmvpnPe3kz74GA5DM6/C/EQjwV4GJchI/zW6ek5EY6wMVC 4djC0vpvEYvLqckoj7Aq5NSp6cT0/EpR2vwmcBH+AKvZnBqdXYnO8iUQiaQQisxjQrGMMrJM ZfreFS5I8cT6eHgDE4rzNCchkqejnokSiBCXQjKVCM1kcxlJJRh//jRpt3vbW2wD/S4xT7BC 0xkxeyAhon74MlMCEQitZw/yRKEYqyJSM1nVPRZpsfSpkmq2tA47AzlJzSEVK3Q/q7g9oRKI 8eDq4tJ2OLKKiTo85Gsyd9SbX5jaXyH5AMu0ucX2euAdJnRzW/y68mPMP30CYevptfX0mi2d 27uYm1xJpXZaLc+kfF5WqYiwolBCiCJTk7krufF9PSXE4mmvL3qMaGhoZI6s8fHj9L6SFeT+ t05zc3cn221hn0uUYklpY1++sfszIl7mdyNTG24Pd4iw9fQWLnu8vsLiyVMrJnSO3xn3J1xD wfqO3oF496O2Lsegb35pD+fpMr/n88Wc7qMXqa2tYximkI53bI5hmIe1dZgoM/GMw8Etb21V tOvAdON63Z3tXXFfUBAhc/ObTtcUv7p3iChELhalsEWE2p0LybXERbcGpGpAVecl3f2+B4Ho qqTIg66PS2u7x7+TKWXDjkByLXHBowGkA3QXUDWgqkuivmnCNOKYSibXTvQIwzA1NTUsy1qt VqvVyrJsIakroxqQ7oGoA6ESkB5QNSAdCPprI5rTbVZEMAxTRFy1awBVAdJBTg85HSAdiJWH J0h/zn/rzwiIlENQC5FyCJcDpwVOC0EtBMsgWAHBMgjdvjx68wTCYDAYjUaDwcCyrNFo/LW6 fzUvSpbzrCPnn/wniysT9kzcu9gAAAAASUVORK5CYII= --------------DF0929E39F7F44B41DB6C2AC-- --------------C3B1797A5CA6C32E68FD0BE3-- --GFM2vDbBGUeA0wNJT7d6kjCp8ADn59Dsq-- --3h4m2hcgdjFHtq8mNeaCD5hu0pIJG26iX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXb/IoAAoJEMo1t29uSU65+RAIAL8pHJrSmvNoYJfJ1LRZ3um1 frq6pP+9ChcSE+eBl+Cvb2T1wB1cJiuxrmKqrVnh1wN9CSwc8mVJe77aPhyY8exg 5pqRXmzh0t8A+hQ0KvARZso++CkcgXx24EiZysM8KLQWfILkV22Sf/0XystdMFZd eTet81/9WA7IQNcGYR4Lp/Tz8b9QiBm0Z9zoRVRQN4GTzUm9MWm7utubDkDYtiJf oIKKAP0c8ll7YJ27KhUfQ/XiNH988TPx1V4P8SzADMnq31T9wXS8/YrmNV5o3roJ p6sDOtpmtSEas2rj8JT+4dbSxMQb5puYTGL17wxKNwbGnxaS2CGI9V7c9vu+WyU= =1BC8 -----END PGP SIGNATURE----- --3h4m2hcgdjFHtq8mNeaCD5hu0pIJG26iX--

2 1

oVirt 4.0 Host install fail cause of dnf api
by Pilař Vojtěch 26 Jun '16

26 Jun '16

--_000_c9bbad56edaa4f53be9de7805b8be891EX13nconzolocal_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi all, iam trying to install host from oVirt Engine Web Admin, but with no success= so far. Everything dies on sigCheckPkg bug from dnf (https://bugzilla.redh= at.com/show_bug.cgi?id=3D1344270) 2016-06-25 19:36:22 INFO otopi.plugins.otopi.packagers.dnfpackager dnfpacka= ger.info:79 DNF Downloaded libselinux-python-2.4-4.fc23.x86_64.rpm The 'sigCheckPkg' function is not a part of DNF API and will be removed in = the upcoming DNF release. Please use only officially supported API function= s. DNF API documentation is available at https://dnf.readthedocs.org/en/lat= est/api.html. 2016-06-25 19:36:22 ERROR otopi.plugins.otopi.packagers.dnfpackager dnfpack= ager.error:84 DNF 'NoneType' object is not iterable 2016-06-25 19:36:22 DEBUG otopi.plugins.otopi.packagers.dnfpackager dnfpack= ager.verbose:75 DNF Closing transaction with rollback Is there any workaround? I see no way to deploy hosts. (Fedora 23, oVirt 4.0) Thank you for help --_000_c9bbad56edaa4f53be9de7805b8be891EX13nconzolocal_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> <style type=3D"text/css" style=3D"display:none"></style> </head> <body> <div style=3D"font-size:12pt;color:#000000;background-color:#FFFFFF;font-fa= mily:Calibri,Arial,Helvetica,sans-serif;"> <p><br> </p> <p>Hi all,<br> <br> iam trying to install host from oVirt Engine Web Admin, but with no success= so far. Everything dies on sigCheckPkg bug from dnf (https://bugzilla.redh= at.com/show_bug.cgi?id=3D1344270)<br> <br> <span style=3D"font-size: 10pt;">2016-06-25 19:36:22 INFO otopi.plugins.oto= pi.packagers.dnfpackager dnfpackager.info:79 DNF Downloaded libselinux-pyth= on-2.4-4.fc23.x86_64.rpm</span><br style=3D"font-size: 10pt;"> <span style=3D"font-size: 10pt;">The 'sigCheckPkg' function is not a part o= f DNF API and will be removed in the upcoming DNF release. Please use only = officially supported API functions. DNF API documentation is available at h= ttps://dnf.readthedocs.org/en/latest/api.html.</span><br style=3D"font-size= : 10pt;"> <span style=3D"font-size: 10pt;">2016-06-25 19:36:22 ERROR otopi.plugins.ot= opi.packagers.dnfpackager dnfpackager.error:84 DNF 'NoneType' object is not= iterable</span><br style=3D"font-size: 10pt;"> <span style=3D"font-size: 10pt;">2016-06-25 19:36:22 DEBUG otopi.plugins.ot= opi.packagers.dnfpackager dnfpackager.verbose:75 DNF Closing transaction wi= th rollback</span><br> <br> Is there any workaround? I see no way to deploy hosts.<br> <br> (Fedora 23, oVirt 4.0)<br> <br> Thank you for help<br> </p> </div> </body> </html> --_000_c9bbad56edaa4f53be9de7805b8be891EX13nconzolocal_--

2 3

oVirt/RHEV and HP Blades and HP iSCSI SAN
by Colin Coe 26 Jun '16

26 Jun '16

Hi all We run four RHEV datacenters, two PROD, one DEV and one TEST/Training. They are all working OK but I'd like a definitive answer on how I should be configuring the networking side as I'm pretty sure we're getting sub-optimal networking performance. All datacenters are housed in HP C7000 Blade enclosures. The PROD datacenters use HP 4730 iSCSI SAN clusters, each datacenter has a cluster of two 4730s. These are configured RAID5 internally with NRAID1. The DEV and TEST datacenters are using P4500 iSCSI SANs and each datacenter has a cluster of three P4500s configured with RAID10 internally and NRAID5. The HP C7000 each have two Flex10/10D interconnect modules configured in a redundant ring so that we can upgrade the interconnects without dropping network connectivity to the infrastructure. We use fat RHEL-H 7.2 hypervisors (HP BL460) and these are all configured with six network interfaces: - eno1 and eno2 are bond0 which is the rhevm interface - eno3 and eno4 are bond1 and all the VM VLANs are trunked over this bond using 802.1q - eno5 and eno6 are bond2 and dedicated to iSCSI traffic Is this the "correct" way to do this? If not, what should I be doing instead? Thanks CC

3 6

Ovirt 4.0 Engine Setup Failure
by Melissa Mesler 25 Jun '16

25 Jun '16

I am doing a clean install of Ovirt 4.0. Upon executing engine-setup with all default values, it fails. This is the error during setup: [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/bin/ovirt-aaa-jdbc-tool' failed to execute Any ideas?

3 6

Error mounting hosted engine Volume (Glusterfs) via VDSM
by Ralf Schenk 25 Jun '16

25 Jun '16

This is a multi-part message in MIME format. --------------490BE4DF07D0809CD094F385 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I think options for mounting the hosted-engine Volume changed in latest vdsm to support mounting from backup-volfile-servers. [root@microcloud28 ~]# rpm -qi vdsm Name : vdsm Version : 4.17.28 Release : 1.el7 Architecture: noarch Install Date: Fri 10 Jun 2016 11:17:37 AM CEST Group : Applications/System Size : 3828639 License : GPLv2+ Signature : RSA/SHA1, Fri 03 Jun 2016 12:53:20 AM CEST, Key ID 7aebbe8261e8806c Source RPM : vdsm-4.17.28-1.el7.src.rpm Now my hosts have problems to mount the Volume. On hosted-engine setup I configured the (Replica 3) volume to be "glusterfs.rxmgmt.databay.de:/engine" which ist a Round-Robin DNS to my gluster hosts and _not_ the DNS-Name of any gluster-brick. Now VDSM logs: jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::fileUtils::143::Storage.fileUtils::(createdir) Cre ating directory: /rhev/data-center/mnt/glusterSD/glusterfs.rxmgmt.databay.de:_engine mode: None jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::storageServer::364::Storage.StorageServer.MountCon nection::(_get_backup_servers_option) Using bricks: ['microcloud21.rxmgmt.databay.de', 'microcloud24.r xmgmt.databay.de', 'microcloud27.rxmgmt.databay.de'] jsonrpc.Executor/3::WARNING::2016-06-25 19:40:02,520::storageServer::370::Storage.StorageServer.MountC onnection::(_get_backup_servers_option) gluster server u'glusterfs.rxmgmt.databay.de' is not in bricks ['microcloud21.rxmgmt.databay.de', 'microcloud24.rxmgmt.databay.de', 'microcloud27.rxmgmt.databay.de' ], possibly mounting duplicate servers jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bi n/taskset --cpu-list 0-7 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=3Dvdsm-glusterfs /usr/bin /mount -o backup-volfile-servers=3Dmicrocloud21.rxmgmt.databay.de:microcloud24.rxmg= mt.databay.de:microcl oud27.rxmgmt.databay.de glusterfs.rxmgmt.databay.de:/engine /rhev/data-center/mnt/glusterSD/glusterfs. rxmgmt.databay.de:_engine (cwd None) jsonrpc.Executor/3::ERROR::2016-06-25 19:40:02,540::hsm::2473::Storage.HSM::(connectStorageServer) Cou ld not connect to storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServ= er conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 237, in connect six.reraise(t, v, tb) File "/usr/share/vdsm/storage/storageServer.py", line 229, in connect self._mount.mount(self.options, self._vfsType, cgroup=3Dself.CGROUP) File "/usr/share/vdsm/storage/mount.py", line 225, in mount return self._runcmd(cmd, timeout) File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';Running scope as unit run-13461.scope.\nmount.nfs: an incorrect mount option was specified\n') So the mount is tried as NFS which hasn't the option "-o backup-volfile-servers=3D...". As a consequence the host is disabled in engine. The only way to get it up is mounting the volume manually to /rhev/data-center/mnt/glusterSD/glusterfs. rxmgmt.databay.de:_engine and activate it manually in Management-GUI. Should and can I change the hosted_storage entry-point globally to i.e. "microcloud21.rxmgmt.databay.de" or wouldn't it be better globally that VDSM uses "-t glusterfs" to try to mount the gluster-Volume regardless which DNS Name for the gluster-service is used ? Ovirt is: ovirt-release36.noarch 1:3.6.6-1 Bye --=20 *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> =09 *Databay AG* Jens-Otto-Krag-Stra=C3=9Fe 11 D-52146 W=C3=BCrselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen =E2=80=A2 HRB:8437 =E2=80=A2 USt-IdNr.: DE 210844= 202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------490BE4DF07D0809CD094F385 Content-Type: multipart/related; boundary="------------9EB1620A3DC18A1D6499F226" --------------9EB1620A3DC18A1D6499F226 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 think options for mounting the hosted-engine Volume changed in latest vdsm to support mounting from backup-volfile-servers.</p> <p><tt>[root@microcloud28 ~]# rpm -qi vdsm</tt><tt><br> </tt><tt>Name : vdsm</tt><tt><br> </tt><tt>Version : 4.17.28</tt><tt><br> </tt><tt>Release : 1.el7</tt><tt><br> </tt><tt>Architecture: noarch</tt><tt><br> </tt><tt>Install Date: Fri 10 Jun 2016 11:17:37 AM CEST</tt><tt><br> </tt><tt>Group : Applications/System</tt><tt><br> </tt><tt>Size : 3828639</tt><tt><br> </tt><tt>License : GPLv2+</tt><tt><br> </tt><tt>Signature : RSA/SHA1, Fri 03 Jun 2016 12:53:20 AM CEST, Key ID 7aebbe8261e8806c</tt><tt><br> </tt><tt>Source RPM : vdsm-4.17.28-1.el7.src.rpm</tt><tt><br> </tt></p> <p>Now my hosts have problems to mount the Volume. On hosted-engine setup I configured the (Replica 3) volume to be "glusterfs.rxmgmt.databay.de:/engine" which ist a Round-Robin DNS to my gluster hosts and _not_ the DNS-Name of any gluster-brick.<br> </p> <p>Now VDSM logs:</p> <p><tt>jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::fileUtils::143::Storage.fileUtils::(createdir) Cre</tt><tt><br> </tt><tt>ating directory: /rhev/data-center/mnt/glusterSD/glusterfs.rxmgmt.databay.de:_engine mode: None</tt><tt><br> </tt><tt>jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::storageServer::364::Storage.StorageServer.MountCon</tt><tt><br> </tt><tt>nection::(_get_backup_servers_option) Using bricks: ['microcloud21.rxmgmt.databay.de', 'microcloud24.r</tt><tt><br> </tt><tt>xmgmt.databay.de', 'microcloud27.rxmgmt.databay.de']</tt><tt><br> </tt><tt>jsonrpc.Executor/3::WARNING::2016-06-25 19:40:02,520::storageServer::370::Storage.StorageServer.MountC</tt><tt><br> </tt><tt>onnection::(_get_backup_servers_option) gluster server u'glusterfs.rxmgmt.databay.de' is not in bricks</tt><tt><br> </tt><tt> ['microcloud21.rxmgmt.databay.de', 'microcloud24.rxmgmt.databay.de', 'microcloud27.rxmgmt.databay.de'</tt><tt><br> </tt><tt>], possibly mounting duplicate servers</tt><tt><br> </tt><tt>jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bi</tt><tt><br> </tt><tt>n/taskset --cpu-list 0-7 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin</tt><tt><br> </tt><tt>/mount -o backup-volfile-servers=microcloud21.rxmgmt.databay.de:microcloud24.rxmgmt.databay.de:microcl</tt><tt><br> </tt><tt>oud27.rxmgmt.databay.de glusterfs.rxmgmt.databay.de:/engine /rhev/data-center/mnt/glusterSD/glusterfs.</tt><tt><br> </tt><tt>rxmgmt.databay.de:_engine (cwd None)</tt><tt><br> </tt><tt>jsonrpc.Executor/3::ERROR::2016-06-25 19:40:02,540::hsm::2473::Storage.HSM::(connectStorageServer) Cou</tt><tt><br> </tt><tt>ld not connect to storageServer</tt><tt><br> </tt><tt>Traceback (most recent call last):</tt><tt><br> </tt><tt> File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServer</tt><tt><br> </tt><tt> conObj.connect()</tt><tt><br> </tt><tt> File "/usr/share/vdsm/storage/storageServer.py", line 237, in connect</tt><tt><br> </tt><tt> six.reraise(t, v, tb)</tt><tt><br> </tt><tt> File "/usr/share/vdsm/storage/storageServer.py", line 229, in connect</tt><tt><br> </tt><tt> self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP)</tt><tt><br> </tt><tt> File "/usr/share/vdsm/storage/mount.py", line 225, in mount</tt><tt><br> </tt><tt> return self._runcmd(cmd, timeout)</tt><tt><br> </tt><tt> File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd</tt><tt><br> </tt><tt> raise MountError(rc, ";".join((out, err)))</tt><tt><br> </tt><tt>MountError: (32, ';Running scope as unit run-13461.scope.\nmount.nfs: an incorrect mount option was specified\n')</tt><tt><br> </tt></p> <p>So the mount is tried as NFS which hasn't the option "-o backup-volfile-servers=...".</p> <p>As a consequence the host is disabled in engine. The only way to get it up is mounting the volume manually to /rhev/data-center/mnt/glusterSD/glusterfs.<br> rxmgmt.databay.de:_engine and activate it manually in Management-GUI.<br> </p> <p>Should and can I change the hosted_storage entry-point globally to i.e. "microcloud21.rxmgmt.databay.de" or wouldn't it be better globally that VDSM uses "-t glusterfs" to try to mount the gluster-Volume regardless which DNS Name for the gluster-service is used ?</p> <p>Ovirt is:</p> <p><tt>ovirt-release36.noarch 1:3.6.6-1</tt><br> </p> Bye<br> <div class="moz-signature">-- <br> <p> </p> <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.2FE99626.D833EF80@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> --------------9EB1620A3DC18A1D6499F226 Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.2FE99626.D833EF80(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= --------------9EB1620A3DC18A1D6499F226-- --------------490BE4DF07D0809CD094F385--

1 1

Setup new enviroment
by Andy Michielsen 25 Jun '16

25 Jun '16

Hello all, I was just wondering what your opinions would be in setting up a new oVirt enviroment. I have 4 old servers, 3 with 64 Gigs of ram and 2 tera's of disk space an one with 32 Gigs of ram and 1,2 Gb. Each has 2 hexcore cpu's. Each server has at least 2 nic's. I would like to use each server in a seperate cluster with there own local storage as this would all only be used as a test enviroment but still would like to manage them from one interface. Deploy new vm's from templates etc. Can I still use the all in one installation for engine and node ? Or can I install the engine on a seperate host, physical or virtual. What would be a good way to use the network ? Any advice would be greatly appriciated. Thanks in advance.

3 5

3.6 to 4.0 upgrade cert issue
by Matt Haught 24 Jun '16

24 Jun '16

I just attempted an upgrade from 3.6 to 4.0 hosted engine and ran into an problem. The hosted engine vm updated without issue, but when I go to login to the web interface to continue the process I get: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at every page load and I can't login. I have a feeling that the issue comes from where I replaced the self-signed certs with trusted ca signed certs a year ago. Is there a work around? CentOS 7.2 Thanks, -- Matt Haught

1 0

Is oVirt 3.6 with GlusterFS 3.7 recommended for production usage?
by Dewey Du 24 Jun '16

24 Jun '16

I want to deploy oVirt 3.6 with GlusterFS 3.7 to my online servers. Is it recommended for production usage? Thx.

2 5

Hosted Engine Spamming Transition E-Mails
by Charles Tassell 24 Jun '16

24 Jun '16

Hi Folks, I'm having a strange issue with my 3.6 setup. For the past few days the system has been spamming me with "The state machine changed state" E-Mails. First I get the "EngineUnexpectedlyDown-EngineDown", then "EngineDown-EngineStart" then "EngineStart-EngineStarting" I checked the hosted engine VM and it's been up for 16 days and the system looks to be running fine, so I'm wondering what's going on. And when I say spamming, I mean I'm getting 200+ E-Mails a day. It seems to trigger every 20 minutes or so with about 2 minutes between each of the 3 messages in the set.

2 4

vds.dispatcher ERROR SSL in ovirt 4.0
by Claude Durocher 23 Jun '16

23 Jun '16

------=_=-_OpenGroupware_org_NGMime-8376-1465422592.973792-0------ content-type: text/plain; charset=utf-8 content-length: 257 content-transfer-encoding: quoted-printable I'm testing ovirt 4.0 rc1 on centos 7 (hosted engine on nfs). Every 15 = seconds or so, I receive the following error: journal: vdsm vds.dispatcher ERROR SSL error during reading data: (104,= 'Connection reset by peer') Any ideas on how to debug this? ------=_=-_OpenGroupware_org_NGMime-8376-1465422592.973792-0------ content-type: text/html; charset=utf-8 content-length: 307 content-transfer-encoding: quoted-printable <html>I'm testing ovirt 4.0 rc1 on centos 7 (hosted engine on nfs).= Every 15 seconds or so, I receive the following error:<br /><br />jour= nal: vdsm vds.dispatcher ERROR SSL error during reading data: (104, &#3= 9;Connection reset by peer')<br /><br />Any ideas on how to debug t= his?</html> ------=_=-_OpenGroupware_org_NGMime-8376-1465422592.973792-0--------

2 5

New oVirt-Live (3.6.6 rc1) is available for download
by Lev Veyde 23 Jun '16

23 Jun '16

Hi, The new oVirt-Live 3.6.6 rc1 is available for download. You can download it from: http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ovirt-live/ovirt-live-el7-… Thanks in advance, Lev Veyde.

1 1

[ANN] oVirt 4.0.0 Final Release is now available
by Sandro Bonazzola 23 Jun '16

23 Jun '16

The oVirt Project is pleased to announce today the general availability of oVirt 4.0.0. This release is available now for: * Fedora 23 (tech preview) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 (tech preview) * oVirt Next Generation Node 4.0 Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO will be available soon. [4] * A new oVirt Next Generation Node will be available soon [4]. * A new oVirt Engine Appliance will be available soon. * A new oVirt Guest Tools ISO is already available [4]. * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.0 release highlights: http://www.ovirt.org/release/4.0.0/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.0/ [4] http://resources.ovirt.org/pub/ovirt-4.0/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Image format after Live Storage Migration
by Raz Tamir 23 Jun '16

23 Jun '16

Hi all, Before 4.0, when we performed a Live Storage Migration on a vm disk we expected from the disk format to become a qcow because of the auto generated snapshot as part of the live storage migration process. >From 4.0 this process got changed and after the disk migration finishes, the auto generated snapshot is removed (Live Merge), so the expectation also changed and the format should be the original format of the disk -- Thanks, Raz Tamir Red Hat Israel

1 0

Network redundancy with Manual balancing
by Fernando Frediani 23 Jun '16

23 Jun '16

Hello, In VMware it is possible to bound two network interfaces and for each Portgroup (equivalent to a VLAN) is possible to tell which of the physical interfaces you wish the traffic to flow primarily and which stays as secondary(bond mode=1 equivalent). So for certain VLANs (Management, Live Migration, etc) is possible to force traffic flow via one physical NIC of the bond and for other VLANs (Virtual Machine's traffic) outs via the other NIC with failover to each other should a cable or switch fails. In oVirt it is also possible to have bonds, but would it still be possible to do that same and favor the traffic per VLAN basis ? Thanks Fernando

1 0

oVirt 3.6.7 Fifth Release Candidate is now available for testing
by Rafael Martins 23 Jun '16

23 Jun '16

The oVirt Project is pleased to announce the availability of the Fifth Release Candidate of oVirt 3.6.7 for testing, as of June 21th, 2016 This release is available now for: * Fedora 22 * Red Hat Enterprise Linux 6.7 or later * CentOS Linux (or similar) 6.7 or later * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 22 This release candidate includes the following updated packages: * ovirt-engine * vdsm See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is available [2]. * A new oVirt Appliance is available. * Mirrors[3] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 3.6.7 release highlights: http://www.ovirt.org/release/3.6.7/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/3.6.7/ [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ovirt-live/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Rafael Martins

4 3

Will not communicate with VCenter
by JC Clark 23 Jun '16

23 Jun '16

This is a multi-part message in MIME format. --------------070803030608000402070203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I am trying to establish a VCenter as an External Provider. The when I try to "Test" the connection, the ovirt error message says that I have "failed to communicate". The Vcenter logs clearly shows the logging in and logging out of the ovirt administrator to the vCenter instance. And the final error message says: Jun 22, 2016 9:49:06 AM Provider VMWare was updated. (User: admin@internal) Jun 22, 2016 9:47:01 AM Failed to retrieve VMs information from external server vpx://vcenter.mcsaipan.net/MCS1/vmware.mcsaipan.net?no_verify=1 I am using oVirt 3.6.6 Vcenter Server Appliance no Cluster Uncaught exception occurred. Please tryreloading <javascript:window.location.reload(true)>the page. Details: Exception caught: Exception caught: (TypeError) __gwt$exception: <skipped>: Cannot read property 'f' of null Please have your administrator check the UI logs This guy pops up when I try to connect. Anyway just looking for a clue. Any suggestions are welcome. Thanks --------------070803030608000402070203 Content-Type: multipart/related; boundary="------------060607090100070206030207" --------------060607090100070206030207 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 alink="#EE0000" bgcolor="#ffffff" link="#0B6CDA" text="#000000" vlink="#551A8B"> I am trying to establish a VCenter as an External Provider. The when I try to "Test" the connection, the ovirt error message says that I have "failed to communicate". <br> <br> The Vcenter logs clearly shows the logging in and logging out of the ovirt administrator to the vCenter instance.<br> <br> And the final error message says: <meta http-equiv="content-type" content="text/html; charset=utf-8"> <table __gwtcellbasedwidgetimpldispatchingfocus="true" __gwtcellbasedwidgetimpldispatchingblur="true" class="GDOL3HYCJYB" style="box-sizing: border-box; border-collapse: collapse; border-spacing: 0px; color: white; font-family: "Arial Unicode MS",Arial,sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; table-layout: fixed; background-color: rgb(102, 102, 102);" cellspacing="0" height="55" width="990"> <colgroup style="box-sizing: border-box;"><col style="box-sizing: border-box; width: 30px;"><col style="box-sizing: border-box; width: 160px;"><col style="box-sizing: border-box; width: 30px;"><col style="box-sizing: border-box;"></colgroup><thead style="box-sizing: border-box;"><tr __gwt_header_row="0" style="box-sizing: border-box;"> </tr> </thead><tbody style="box-sizing: border-box;"> <tr __gwt_row="0" __gwt_subrow="0" class="GDOL3HYCCXB" style="box-sizing: border-box; background: rgb(102, 102, 102);"> <td class="GDOL3HYCBXB GDOL3HYCDXB GDOL3HYCEXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 30px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33021" style="box-sizing: border-box; outline-style: none;"> <div id="gwt-uid-746_col0_row0" class="" style="box-sizing: border-box; line-height: 13px; text-align: center; vertical-align: middle;"><img onload='this.__gwtLastUnhandledEvent="load";' src="cid:part1.06010603.03050308@mcsaipan.net" style="box-sizing: border-box; border: 0px; vertical-align: middle; width: 14px; height: 12px; background: url("data:image/gif;base64,R0lGODlhDgAMAKIHAE3SEhlQAGHwKiYmJje5BqL/olXgG////yH5BAEAAAcALAAAAAAOAAwAAAM0eLp8ES2GAmBUUxArizDbMQxMBkIDUZCOdypDIY8eEMKAIMiGzeG63q0xABiHkRTyMvgxEgA7") 0px 0px no-repeat;" border="0"></div> </div> </td> <td class="GDOL3HYCBXB GDOL3HYCDXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 160px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33022" style="box-sizing: border-box; outline-style: none;"> <div class="" id="gwt-uid-746_col1_row0" style="box-sizing: border-box; overflow: hidden; text-overflow: ellipsis; white-space: nowrap;">Jun 22, 2016 9:49:06 AM</div> </div> </td> <td class="GDOL3HYCBXB GDOL3HYCDXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 30px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33023" style="box-sizing: border-box; outline-style: none;"><span id="gwt-uid-746_col2_row0" class="" style="box-sizing: border-box;"><img onload='this.__gwtLastUnhandledEvent="load";' src="cid:part1.06010603.03050308@mcsaipan.net" style="box-sizing: border-box; border: 0px; vertical-align: middle; width: 16px; height: 16px; background: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAwElEQVR42q2TwQ3DIAxFGaXTZAUkcmaEMEV6TuBIR2CIXjJMpA5A86K0IpScXKQvWfb/hm9AqWp577sQwn2e5+cWr4CYHDV1taZpum2EccNrGIZsrc193+8gJkcNDtyW+OGcy8aYrLVughocuKcmdKVwJaxxNBm/njlauXOM8UdU5uAedjrFcPBXElNKJ0ErhwatYsIMqd7tI2iJARq0WFiZdOvIy7LsaFlCg1beQGxBPETxNYof0l+esvgzSb7zGzLdBMtBu0HJAAAAAElFTkSuQmCC") 0px 0px no-repeat;" border="0"></span></div> </td> <td class="GDOL3HYCBXB GDOL3HYCDXB GDOL3HYCOXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 1685px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33024" style="box-sizing: border-box; outline-style: none;"> <div class="" id="gwt-uid-746_col3_row0" style="box-sizing: border-box; overflow: hidden; text-overflow: ellipsis; white-space: nowrap;">Provider VMWare was updated. (User: admin@internal)</div> </div> </td> </tr> <tr __gwt_row="1" __gwt_subrow="0" class="GDOL3HYCCYB GDOL3HYCEYB GDOL3HYCJXB" style="box-sizing: border-box; color: white; height: auto; overflow: auto; background: rgb(102, 102, 102);"> <td class="GDOL3HYCBXB GDOL3HYCDYB GDOL3HYCEXB GDOL3HYCFYB GDOL3HYCKXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 30px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33021" style="box-sizing: border-box; outline-style: none;"> <div id="gwt-uid-746_col0_row1" class="" style="box-sizing: border-box; line-height: 13px; text-align: center; vertical-align: middle;"><img onload='this.__gwtLastUnhandledEvent="load";' src="cid:part1.06010603.03050308@mcsaipan.net" style="box-sizing: border-box; border: 0px; vertical-align: middle; width: 14px; height: 12px; background: url("data:image/gif;base64,R0lGODlhDgAMAJEDAMwzAP8zAGYAAP///yH5BAEAAAMALAAAAAAOAAwAAAIs3GA5ogeYQGBGyADlo+u+gHHVBQJiYpVnBJaN4XmNJ6QYG45uZypWX1nVEgUAOw==") 0px 0px no-repeat;" border="0"></div> </div> </td> <td class="GDOL3HYCBXB GDOL3HYCDYB GDOL3HYCFYB GDOL3HYCKXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 160px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33022" style="box-sizing: border-box; outline-style: none;"> <div class="" id="gwt-uid-746_col1_row1" style="box-sizing: border-box; overflow: hidden; text-overflow: ellipsis; white-space: nowrap;">Jun 22, 2016 9:47:01 AM</div> </div> </td> <td class="GDOL3HYCBXB GDOL3HYCDYB GDOL3HYCFYB GDOL3HYCKXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 30px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33023" style="box-sizing: border-box; outline-style: none;"><span id="gwt-uid-746_col2_row1" class="" style="box-sizing: border-box;"><img onload='this.__gwtLastUnhandledEvent="load";' src="cid:part1.06010603.03050308@mcsaipan.net" style="box-sizing: border-box; border: 0px; vertical-align: middle; width: 16px; height: 16px; background: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAwElEQVR42q2TwQ3DIAxFGaXTZAUkcmaEMEV6TuBIR2CIXjJMpA5A86K0IpScXKQvWfb/hm9AqWp577sQwn2e5+cWr4CYHDV1taZpum2EccNrGIZsrc193+8gJkcNDtyW+OGcy8aYrLVughocuKcmdKVwJaxxNBm/njlauXOM8UdU5uAedjrFcPBXElNKJ0ErhwatYsIMqd7tI2iJARq0WFiZdOvIy7LsaFlCg1beQGxBPETxNYof0l+esvgzSb7zGzLdBMtBu0HJAAAAAElFTkSuQmCC") 0px 0px no-repeat;" border="0"></span></div> </td> <td class="GDOL3HYCBXB GDOL3HYCDYB GDOL3HYCFYB GDOL3HYCOXB GDOL3HYCKXB" style="box-sizing: border-box; padding: 0px 0px 0px 5px; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; overflow: hidden; border-width: 0px 0px 1px; border-bottom-style: solid; border-bottom-color: rgb(141, 141, 141); vertical-align: middle; white-space: nowrap; width: 1685px; height: 26px !important; line-height: 26px !important;"> <div __gwt_cell="cell-gwt-uid-33024" tabindex="0" style="box-sizing: border-box; outline-style: none;"> <div class="" id="gwt-uid-746_col3_row1" style="box-sizing: border-box; overflow: hidden; text-overflow: ellipsis; white-space: nowrap;">Failed to retrieve VMs information from external server vpx://vcenter.mcsaipan.net/MCS1/vmware.mcsaipan.net?no_verify=1 <br> </div> </div> </td> </tr> </tbody> </table> <pre class="moz-signature" cols="72"> </pre> I am using oVirt 3.6.6 <br> Vcenter Server Appliance<br> no Cluster<br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <br class="Apple-interchange-newline"> <span style="color: rgb(169, 68, 66); font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: nowrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: rgb(242, 222, 222);">Uncaught exception occurred. Please try<span class="Apple-converted-space"> </span></span><a href="javascript:window.location.reload(true)" style="box-sizing: border-box; color: rgb(0, 0, 170); text-decoration: none; font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: nowrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(242, 222, 222);">reloading</a><span style="color: rgb(169, 68, 66); font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: nowrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: rgb(242, 222, 222);"><span class="Apple-converted-space"> </span>the page. Details: Exception caught: Exception caught: (TypeError) __gwt$exception: <skipped>: Cannot read property 'f' of null</span><br style="box-sizing: border-box; color: rgb(169, 68, 66); font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: nowrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(242, 222, 222);"> <span style="color: rgb(169, 68, 66); font-family: 'Arial Unicode MS', Arial, sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: nowrap; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: rgb(242, 222, 222);">Please have your administrator check the UI logs<br> <br> </span><span style="color: rgb(169, 68, 66); font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21.6667px; text-align: start; text-indent: 0px; text-transform: none; white-space: nowrap; widows: 1; word-spacing: 0px; display: inline ! important; float: none; background-color: rgb(242, 222, 222);"><font color="#000000">This guy pops up when I try to connect.</font></span><br> <br> Anyway just looking for a clue. Any suggestions are welcome.<br> <br> Thanks<br> </body> </html> --------------060607090100070206030207-- --------------070803030608000402070203--

3 2

new version of qemu
by qinglong.dong＠horebdata.cn 23 Jun '16

23 Jun '16

This is a multi-part message in MIME format. ------=_001_NextPart212181354545_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGFsbA0KICAgICAgICBJIGhhdmUgZm91bmQgdGhhdCB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg cWVtdSBoYXMgYmVlbiB1cGRhdGVkIHRvIDIuNi4gSW4gdGhlIGxhdGVzdCB2ZXJzaW9uIGl0IHN1 cHBvcnRzIGEgbmV3IHZpcnRpby1ncHUgZGV2aWNlIHdoaWNoIHN1cHBydHMgYWNjZWxlcmF0ZWQg MkQgYW5kIDNELiBRZW11IDIuMyBpcyB1c2VkIGluIG92aXJ0IDMuNiBmb3Igbm93LiBTbyBJIHdv bmRlciB3aGVuIHRoZSB2ZXJzaW9uIG9mIHFlbXUgd2lsbCBiZSB1cGRhdGVkIGluIG92aXJ0IG9y IGlmIEkgY2FuIHVwZGF0ZSB0aGUgdmVyc2lvbiBvZiBxZW11IGluIG92aXJ0IG15c2VsZi4NCkFu eW9uZSBjYW4gaGVscKO/IFRoYW5rcyENCg0KDQoNCg== ------=_001_NextPart212181354545_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DGB2312"><style>body { line-height: 1.5; }body { font-size: 10.5pt; fon= t-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5;= }</style></head><body>=0A<div><span></span>Hi, all</div>=0A<div>  &n= bsp; <span style=3D"font-size: 10.5pt; line-height: 1.5; background-c= olor: window;">    I have found that the </span>latest&nbsp= ;version<span style=3D"font-size: 10.5pt; line-height: 1.5; background-col= or: window;"> of qemu has been updated to 2.6. In the latest version = it supports </span><span style=3D"font-size: 10.5pt; line-height: 1.5= ; background-color: window;">a new virtio-gpu device which suppr= ts </span><span style=3D"font-size: 10.5pt; line-height: 1.5; backgro= und-color: window;">accelerated 2D and 3D. Qemu 2.3 is used in ovirt = 3.6 for now. So I wonder when the version of qemu will be updated in ovirt= or if I can update the version of qemu in ovirt myself.</span></div><div>= Anyone can help=A3=BF Thanks!</div><hr style=3D"width: 210px; height: 1px;= " color=3D"#b5c4df" size=3D"1" align=3D"left">=0A<div><br></div>=0A</body>= </html> ------=_001_NextPart212181354545_=------

2 1

User admin@internal can't login in oVirt 3.6
by Julián Tete 22 Jun '16

22 Jun '16

oVirt: 3.6.2 Trying to use: https://github.com/machacekondra/ovirt-engine-kerbldap-migration First use: engine-manage-domains add --domain=udistritaloas.edu.co --provider=ipa --user=admin --ldap-servers=freeipa.udistritaloas.edu.co The domain was added, but a I can't access to the webadmin portal :/ I get the message: "User is not authorized to perform this action." In ovirt-cli [401] - Unauthorized tail -n 5000 /var/log/ovirt-engine/engine.log | grep admin@internal 2016-06-20 10:52:22,835 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-32) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal failed to log in. 2016-06-20 10:52:22,836 WARN [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand] (default task-32) [] CanDoAction of action 'LoginAdminUser' failed for user admin@internal. Reasons: USER_NOT_AUTHORIZED_TO_PERFORM_ACTION 2016-06-20 11:00:37,679 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-3) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal failed to log in. 2016-06-20 11:00:37,679 WARN [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (default task-3) [] CanDoAction of action 'LoginUser' failed for user admin@internal. Reasons: USER_NOT_AUTHORIZED_TO_PERFORM_ACTION 2016-06-20 11:01:04,016 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-4) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal failed to log in. 2016-06-20 11:01:04,016 WARN [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (default task-4) [] CanDoAction of action 'LoginUser' failed for user admin@internal. Reasons: USER_NOT_AUTHORIZED_TO_PERFORM_ACTION Properties of Internal domain: cat /etc/ovirt-engine/aaa/internal.properties ovirt.engine.extension.name = internal-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.jdbc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.jdbc.binding.api.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = internal ovirt.engine.aaa.authn.authz.plugin = internal-authz config.datasource.file = /etc/ovirt-engine/aaa/internal.properties cat /etc/ovirt-engine/extensions.d/internal-authn.properties ovirt.engine.extension.name = internal-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.jdbc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.jdbc.binding.api.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = internal ovirt.engine.aaa.authn.authz.plugin = internal-authz config.datasource.file = /etc/ovirt-engine/aaa/internal.properties cat /etc/ovirt-engine/extensions.d/internal-authz.properties ovirt.engine.extension.name = internal-authz ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.jdbc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.jdbc.binding.api.AuthzExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.datasource.file = /etc/ovirt-engine/aaa/internal.properties Properties of admin@internal user: ovirt-aaa-jdbc-tool user show admin -- User admin(fdfc627c-d875-11e0-90f0-83df133b58cc) -- Namespace: * Name: admin ID: fdfc627c-d875-11e0-90f0-83df133b58cc Display Name: Email: First Name: admin Last Name: Department: Title: Description: Account Disabled: false Account Unlocked At: 1970-01-01 00:00:00Z Account Valid From: 2015-10-01 00:00:00Z Account Valid To: 2100-01-01 00:00:00Z Account Without Password: false Last successful Login At: 2016-06-20 16:01:03Z Last unsuccessful Login At: 2016-06-19 16:53:07Z Password Valid To: 2100-01-01 00:00:00Z ¿ Can I assign privilegies to the user ? ¿ Any idea ?

2 10

Hosted Engine - Storage Domain registration
by Anantha Raghava 22 Jun '16

22 Jun '16

This is a multi-part message in MIME format. --------------080104060203000406070600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I was able to install Hosted Engine on CentOS 7.2 Host with NFS Storage. I faced challenge in registering the NFS Storage Domain - hosted_storage - on which the Hosted Engine VM was created. When I attempt to attach the hosted_storage to Data Center, the process fails and it could not register. Hosted_Engine_Host is registered and is up & running, but data center is down resulting in the infrastructure going down. Another question is, if this storage is not registered in domain, how would engine vm migrate in case of host failure? Can some one guide me on this? -- Thanks & Regards, Anantha Raghava --------------080104060203000406070600 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <font face="Liberation Serif">Hi,<br> <br> I was able to install Hosted Engine on CentOS 7.2 Host with NFS Storage. I faced challenge in registering the NFS Storage Domain - hosted_storage - on which the Hosted Engine VM was created. When I attempt to attach the hosted_storage to Data Center, the process fails and it could not register. Hosted_Engine_Host is registered and is up & running, but data center is down resulting in the infrastructure going down.<br> <br> Another question is, if this storage is not registered in domain, how would engine vm migrate in case of host failure?</font><br> <div class="moz-signature"><br> Can some one guide me on this?<br> -- <p style="margin-bottom: 0cm; line-height: 100%"><font face="Times New Roman, serif">Thanks & Regards,</font></p> <address style="line-height: 100%"><font face="Times New Roman, serif">Anantha Raghava</font></address> <br> </div> </body> </html> --------------080104060203000406070600--

2 2

Slow Export Domain
by Sven Achtelik 22 Jun '16

22 Jun '16

--_000_BFAB40933B3367488CE6299BAF8592D101235BFF2FF8SOCRATESasl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, I'm trying to export VMs to an Export Domain for Backup and noticed that al= l of this is running at max 100Mbit/s. Is this some limitation that comes w= ith the Export Domain ? I've checked all network connections and all of the= m report at least 1000Mbits/s. Am I missing something ? Thank you, Sven --_000_BFAB40933B3367488CE6299BAF8592D101235BFF2FF8SOCRATESasl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 15 (filtered medium)"><style></style></head><body lang=3DDE link=3D"#0563C1" v= link=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal>Hi Everyone= , <o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal><span lang=3DEN-US>I’m trying to export VMs to an Export Domain = for Backup and noticed that all of this is running at max 100Mbit/s. Is thi= s some limitation that comes with the Export Domain ? I’ve checked al= l network connections and all of them report at least 1000Mbits/s.  Am= I missing something ? <o:p></o:p></span></p><p class=3DMsoNormal><span lan= g=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span lang=3DEN-= US>Thank you, <o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US= ><o:p> </o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>Sven &= nbsp;<o:p></o:p></span></p></div></body></html>= --_000_BFAB40933B3367488CE6299BAF8592D101235BFF2FF8SOCRATESasl_--

4 9

[ANN] oVirt 4.0 reporting deprecation
by Sandro Bonazzola 22 Jun '16

22 Jun '16

As the virtualization market matures, IT organizations need to deploy virtualization features that help to deliver services faster while driving innovation and eliminating costly manual tasks. oVirt 4.0 introduces a new seamless system dashboard that is suited for large scale virtualization environments. The dashboard provides easy access monitoring information for the infrastructure including a resource global utilization overview of CPU, memory, and storage host resources. oVirt 4.0 will not include a suite of previously available JasperReports Server pre-built reports. In the interim, users accustomed to this functionality will need to use the data warehouses SQL API either directly or through an external Business Intelligence tool or remain with oVirt Reporting 3.6 on a separate server which will still work with 4.0 oVirt Data Warehouse. In upcoming releases, oVirt will continue to enhance the user experience by providing a metric store solution and a visualization tool. Together, these tools will provide better scale and a richer set of metric data. In addition, there will be enhanced advanced analytics, self-service dashboards and widget creation functionality. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 4.0.0 Fourth Release candidate is now available for testing
by Rafael Martins 21 Jun '16

21 Jun '16

The oVirt Project is pleased to announce the availability of the Fourth Release Candidate of oVirt 4.0.0 for testing, as of June 21th, 2016 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This release is available now for: * Fedora 23 * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 * oVirt Next Generation Node 4.0 See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is already available. [4] * A new oVirt Next Generation Node will be available soon. * A new oVirt Engine Appliance is already available. * A new oVirt Guest Tools ISO will be available soon. * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.0 release candidate highlights: http://www.ovirt.org/release/4.0.0/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.0/ [4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Rafael Martins

2 1

VMs running in DB, but not in VDS
by SATHEESARAN 21 Jun '16

21 Jun '16

Hello All, I was powering off lot of VMs ( around 29 vms ) in one go, by selecting them all, and 'power off' option. While doing so, I see that 2 of the VMs are stuck in powering down state. I see the following exception in engine.log <snip> 2016-06-20 05:10:57,645 ERROR [org.ovirt.engine.core.vdsbroker.VmsMonitoring] (DefaultQuartzScheduler_Worker-53) [7f967349] Failed during vms monitoring on host host1.lab.eng.blr.redhat .com error is: java.lang.ClassCastException 2016-06-20 05:10:57,645 ERROR [org.ovirt.engine.core.vdsbroker.VmsMonitoring] (DefaultQuartzScheduler_Worker-53) [7f967349] Exception:: java.lang.ClassCastException </snip> and also the following error messages <snip> 2016-06-20 05:12:01,950 INFO [org.ovirt.engine.core.vdsbroker.VmAnalyzer] (DefaultQuartzScheduler_Worker-90) [] VM '59d48f24-d6b8-4e9e-b020-b728ed239da3(appvm03) is running in db and not running in VDS 'host1.lab.eng.blr.redhat.com' 2016-06-20 05:12:01,950 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVDSCommand] (DefaultQuartzScheduler_Worker-90) [] START, FullListVDSCommand(HostName = , FullListVDSCommandParameters:{runAsync='true', hostId='f4a25596-079b-44ed-970b-2142c67b9873', vds='Host[,f4a25596-079b-44ed-970b-2142c67b9873]', vmIds='[10c5e550-4b07-4a25-9a96-ae016864f2a8]'}), log id: 28c780ea 2016-06-20 05:12:02,038 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVDSCommand] (DefaultQuartzScheduler_Worker-90) [] FINISH, FullListVDSCommand, return: [{status=Up, nicModel=rtl8139,pv, emulatedMachine=rhel6.5.0, guestDiskMapping={e5051a6c-dc96-44eb-b={name=/dev/vda}, QEMU_DVD-ROM_QM00003={name=/dev/sr0}}, vmId=10c5e550-4b07-4a25-9a96-ae016864f2a8, pid=6368, devices=[Ljava.lang.Object;@67be1679, smp=2, vmType=kvm, displayIp=0, display=vnc, displaySecurePort=-1, memSize=4096, displayPort=5900, spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir, statusTime=4726355820, vmName=HostedEngine, clientIp=, pauseCode=NOERR}], log id: 28c780ea 2016-06-20 05:12:02,040 INFO [org.ovirt.engine.core.vdsbroker.VmsMonitoring] (DefaultQuartzScheduler_Worker-90) [] Received a memballoon Device without an address when processing VM 10c5e550-4b07-4a25-9a96-ae016864f2a8 devices, skipping device: {device=memballoon, specParams={model=none}, deviceType=balloon, type=balloon, alias=balloon0} 2016-06-20 05:12:02,040 ERROR [org.ovirt.engine.core.vdsbroker.VmsMonitoring] (DefaultQuartzScheduler_Worker-90) [] Failed during vms monitoring on host host1.lab.eng.blr.redhat.com error is: java.lang.ClassCastException 2016-06-20 05:12:02,040 ERROR [org.ovirt.engine.core.vdsbroker.VmsMonitoring] (DefaultQuartzScheduler_Worker-90) [] Exception:: java.lang.ClassCastException </snip> I have also attached the engine.log Any help ? Thanks, Satheesaran S

2 3

Re: [ovirt-users] Trouble obtaining a console in SPICE with Overt 3.6 and Centos 7.1.
by Miller, Terry K 21 Jun '16

21 Jun '16

--_000_67146135468641E0B5428B48E44B401Cconocophillipscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGluc3RhbGxlZCBPdmlydCAzLjYgb24gQ2VudG9zNy4xIG1hY2hpbmUuDQoNCkkgaGF2 ZSBjcmVhdGVkIGEgZ3Vlc3QgbWFjaGluZSBjYWxsZWQgd29wYy13aW4uDQoNCldoZW4gSSBjbGlj ayBvbiB0aGUgY29uc29sZSBzeW1ib2wsIEkgZ2V0IGEgZmlsZSBkb3dubG9hZGVkIChjb25zb2xl LnZ2KSB3aGljaCBpcyBhIHNwaWNlIGNlcnRpZmljYXRlIGZpbGUuDQoNCkhvdyBkbyBJIGRlYnVn IHRoaXMgY29uc29sZSBtYXR0ZXI/ICBJIGNhbm5vdCBicmluZyB1cCBhIGNvbnNvbGUuDQoNCkVu Z2luZS5sb2c6DQoNCjAxNi0wNi0yMCAxMDowNzowOSw4MDQgSU5GTyAgW29yZy5vdmlydC5lbmdp bmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLlNldFZtVGlja2V0VkRTQ29tbWFuZF0gKGRlZmF1 bHQgdGFzay0yNSkgWzQ2YTU2YjExXSBGSU5JU0gsIFNldFZtVGlja2V0VkRTQ29tbWFuZCwgbG9n IGlkOiA1NTA4YWJhMg0KMjAxNi0wNi0yMCAxMDowNzowOSw4NTEgSU5GTyAgW29yZy5vdmlydC5l bmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExvZ0RpcmVjdG9y XSAoZGVmYXVsdCB0YXNrLTI1KSBbNDZhNTZiMTFdIENvcnJlbGF0aW9uIElEOiA0NmE1NmIxMSwg Q2FsbCBTdGFjazogbnVsbCwgQ3VzdG9tIEV2ZW50IElEOiAtMSwgTWVzc2FnZTogVXNlciBhZG1p bkBpbnRlcm5hbCBpbml0aWF0ZWQgY29uc29sZSBzZXNzaW9uIGZvciBWTSB3b3BjLXdpbg0KDQoN Cg0KDQpUZXJyeSBLLiBNaWxsZXIgICDigKIgVU5JWCBTZXJ2ZXIgT3BlcmF0aW9ucyDigKIgQ29u b2NvUGhpbGxpcHMg4oCiIDQ5MC0wOCBJbmZvcm1hdGlvbiBDZW50ZXIg4oCiICA1MTEgUy4gS2Vl bGVyIEF2ZS4g4oCiIEJhcnRsZXN2aWxsZSwgT0suICAgNzQwMDQg4oCiIFVTQQ0KVGVycnkuSy5N aWxsZXJAQ29ub2NvUGhpbGxpcHMuY29tPG1haWx0bzpUZXJyeS5LLk1pbGxlckBDb25vY29QaGls bGlwcy5jb20+ICDigKIgOTE4LTY2MS0wMzI3IG9mZmljZSDigKIgOTE4LTM5Ny01MzA0IG1vYmls ZSAg4oCiIDkxOC02NjItMTAxMiAgZmF4DQo= --_000_67146135468641E0B5428B48E44B401Cconocophillipscom_ Content-Type: text/html; charset="utf-8" Content-ID: <9B6B344CA0E61246B5C07F0E8A83F490(a)namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Iu+8re+8syDmmI7mnJ0iO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTHVjaWRhIENh bGxpZ3JhcGh5IjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5t c29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjIy LjBwdCI+SSBoYXZlIGluc3RhbGxlZCBPdmlydCAzLjYgb24gQ2VudG9zNy4xIG1hY2hpbmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToyMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MjIuMHB0Ij5JIGhhdmUgY3JlYXRlZCBh IGd1ZXN0IG1hY2hpbmUgY2FsbGVkDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4w cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+d29wYy13aW4uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MjIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjIyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToyMi4wcHQiPldoZW4gSSBjbGljayBvbiB0aGUgY29uc29sZSBzeW1ib2wsIEkgZ2V0IGEg ZmlsZSBkb3dubG9hZGVkIChjb25zb2xlLnZ2KSB3aGljaCBpcyBhIHNwaWNlIGNlcnRpZmljYXRl IGZpbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToyMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MjIuMHB0Ij5Ib3cgZG8g SSBkZWJ1ZyB0aGlzIGNvbnNvbGUgbWF0dGVyPyZuYnNwOyBJIGNhbm5vdCBicmluZyB1cCBhIGNv bnNvbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToyMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MjIuMHB0Ij5FbmdpbmUu bG9nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxOC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+MDE2LTA2 LTIwIDEwOjA3OjA5LDgwNCBJTkZPJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJv a2VyLnZkc2Jyb2tlci5TZXRWbVRpY2tldFZEU0NvbW1hbmRdIChkZWZhdWx0IHRhc2stMjUpIFs0 NmE1NmIxMV0gRklOSVNILCBTZXRWbVRpY2tldFZEU0NvbW1hbmQsDQogbG9nIGlkOiA1NTA4YWJh MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdDtmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4yMDE2LTA2LTIwIDEwOjA3OjA5LDg1MSBJTkZPJm5ic3A7 IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0bG9naGFuZGxpbmcuQXVk aXRMb2dEaXJlY3Rvcl0gKGRlZmF1bHQgdGFzay0yNSkgWzQ2YTU2YjExXSBDb3JyZWxhdGlvbiBJ RDoNCiA0NmE1NmIxMSwgQ2FsbCBTdGFjazogbnVsbCwgQ3VzdG9tIEV2ZW50IElEOiAtMSwgTWVz c2FnZTogVXNlciBhZG1pbkBpbnRlcm5hbCBpbml0aWF0ZWQgY29uc29sZSBzZXNzaW9uIGZvciBW TSB3b3BjLXdpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENhbGxpZ3JhcGh5 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiNGRjI2MDAiPlRlcnJ5IEsuIE1pbGxlciAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+4oCi IFVOSVggU2VydmVyIE9wZXJhdGlvbnMg4oCiIENvbm9jb1BoaWxsaXBzDQog4oCiIDQ5MC0wOCBJ bmZvcm1hdGlvbiBDZW50ZXIg4oCiJm5ic3A7IDUxMSBTLiBLZWVsZXIgQXZlLiDigKIgQmFydGxl c3ZpbGxlLCBPSy4gJm5ic3A7IDc0MDA0IOKAoiBVU0E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojRkYyNjAwIj48 YSBocmVmPSJtYWlsdG86VGVycnkuSy5NaWxsZXJAQ29ub2NvUGhpbGxpcHMuY29tIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5UZXJyeS5LLk1pbGxlckBDb25vY29QaGlsbGlwcy5jb208L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2Nv bG9yOiMwMDg1Q0MiPuKAojwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwODVDQyI+Jm5ic3A7 OTE4LTY2MS0wMzI3DQogb2ZmaWNlIOKAoiA5MTgtMzk3LTUzMDQgbW9iaWxlJm5ic3A7IOKAoiA5 MTgtNjYyLTEwMTIgJm5ic3A7ZmF4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_67146135468641E0B5428B48E44B401Cconocophillipscom_--

3 2

Enabling Ballooing device on templates from Python SDK
by Barak Korren 20 Jun '16

20 Jun '16

Hi there, I'm trying to create a VM pool from the Python SDK with the Ballooning device enabled. (Sorry for miss-sending earlier) My code does something like: mp = ovirtsdk.infrastructure.brokers.MemoryPolicy() mp.ballooning = true ... vm_params = ovirtsdk.infrastructure.brokers.VM() vm_params.memory_policy = mem_policy ... vmppp=ovirtsdk.infrastructure.brokers.VmPool(vm=vm_params, ...) vmpool = ovirt.vmpools.add(vmppp) The pool gets created fine, but it seems the ballooning device remains disabled for the VMs What am I doing wrong? Thanks, -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

1 0

Enabling Ballooing device on templates from Python SDK
by Barak Korren 20 Jun '16

20 Jun '16

Hi there, I'm trying to create a VM pool from the Python SDK with the Ballooning device enabled. My code does something like: mp = ovirtsdk.infrastructure.brokers.MemoryPolicy() mp.ballooning = true ... vm_params = ovirtsdk.infrastructure.brokers.VM() vm_params.memory_policy = mem_policy ... vmpool = ovirt.vmpools.add( vmpool=oVirtParams.VmPool( -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

1 0