- Users - oVirt List Archives

Re: [ovirt-users] documentation change suggestion / question
by Karli Sjöberg 09 Oct '16

09 Oct '16

--_000_9cff90f6acfe44c2ab30837610301bceexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gOCBva3QuIDIwMTYgMTk6MTUgc2tyZXYgQ2hhcmxlcyBLb3psZXIgPGNrb3psZXJpaWlA Z21haWwuY29tPjoNCj4NCj4gR29vZ2xpbmcgIm92aXJ0IHdpbmRvd3MgYWdlbnQiIHRoaXMgaXMg dGhlIGZpcnN0IGxpbmsgdGhhdCBwb3BzIHVwOiBodHRwOi8vd3d3Lm92aXJ0Lm9yZy9kb2N1bWVu dGF0aW9uL2ludGVybmFsL2d1ZXN0LWFnZW50L2d1ZXN0LWFnZW50LWZvci13aW5kb3dzLw0KPg0K PiBUaGlzIGRvYyBzZWVtcyBub24taW50dWl0aXZlIGFuZCBvdmVyIGNvbXBsaWNhdGVkDQo+DQo+ IFNwZWNpZmljYWxseSwgdGhlIFJlZEhhdCBkb2N1bWVudGF0aW9uIHRoYXQgaXMgNCBsaW5rcyBi ZWxvdyBpcyBzaW1wbGUgYXMgImluc3RhbGwgdGhpcyBwYWNrYWdlIGFuZCBtb3VudCB0aGUgaXNv IjogaHR0cHM6Ly9jb21tdW5pdHkucmVkaGF0LmNvbS9ibG9nLzIwMTUvMDUvaG93LXRvLWluc3Rh bGwtYW5kLXVzZS1vdmlydHMtd2luZG93cy1ndWVzdC10b29scy8NCj4NCj4gVGhlIGZvcm1lciB3 YXMgdXBkYXRlZCBhcyBlYXJseSBhcyBKdW5lIG9mIHRoaXMgeWVhcg0KPg0KPiAxLikgVGhlIFJl ZEhhdCBkb2N1bWVudCB3b3JrZWQgZm9yIG1lIHNvIEkgZG9udCB0aGluayBvVmlydCA0LnggY2Fu dCB1c2UgdGhlIHNhbWUNCj4gMi4pIFdoeSBoYXZlIHNlcGFyYXRlIGFyZWFzIG9mIGRvY3VtZW50 YXRpb24gdGhhdCBhcmUgc28gZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlcj8gVGhpcyBoYXMgY2F1 c2VkIG1lIGlzc3VlcyBpbiB0aGUgcGFzdCB3aGVyZWJ5IEkgZm91bmQgUkggZG9jcyB0aGF0IHdl cmUgbXVjaCBtb3JlIGNsZWFyIGFuZCBjb25jaXNlDQoNClRoYXQncyBiZWNhdXNlIGFsbCBvVmly dCBkb2N1bWVudGF0aW9uIGlzIGNvbW11bml0eSBkcml2ZW4uIFRoaXMgc3BlY2lmaWMgcGFnZSB3 YXMgd3JpdHRlbiBieSBhIGd1eSBJIGhhcHBlbiB0byBrbm93IHF1aXRlIHdlbGwgKEkgd3JvdGUg aXQpOikNCg0KVGhpcyB3YXMgd3JpdHRlbiBiYWNrIHdoZW4gdGhlcmUgd2FzIG5vIGVhc3kgdG8g aW5zdGFsbCBwYWNrYWdlLCB3aGVyZSB5b3UgaGFkIHRvIGRvIHRoYXQgYnkgaGFuZCwgYW5kIGlm IHlvdSB3YW50IHRvLCB5b3Ugc3RpbGwgY2FuLCB0aGUgbWV0aG9kIHN0aWxsIHdvcmtzLiBCdXQg SSBhZ3JlZSB0aGF0IGlmIHRoZXJlJ3MgYW4gZWFzaWVyIHdheSB0b2RheSwgSSB0aGluayB3ZSBz aG91bGQgZ28gd2l0aCB0aGF0IGZpcnN0IGFuZCBrZWVwIHRoaXMgY29tcGlsaW5nIG1ldGhvZCBh cyB0aGUgZmFsbGJhY2suDQoNCj4gMy4pIElzIHRoZXJlIGFueW9uZSB3aG8gbWlnaHQgd2FudCB0 byBtZXJnZSBSSCBkb2NzIHdpdGggb1ZpcnQgZG9jcyB3aGVyZSB0aGUgUkggZG9jcyBhcmUgYmV0 dGVyIHRoYW4gb1ZpcnQ/DQoNCkhvcGluZyBzb21lb25lIEBSSCBjYW4gYW5zd2VyIHRoaXMsIGJl Y2F1c2UgSSBkb24ndCBrbm93IGlmIEknbSBhbGxvd2VkIHRvIGRvIHRoYXQ/DQoNCi9LDQoNCj4N Cj4gVGhhbmtzIHNvIG11Y2ggZm9yIHByb3ZpZGluZyBzdWNoIGEgZ3JlYXQgcHJvZHVjdCEgSSBq dXN0IGZlZWwgc29tZXRpbWVzIHRoZSBkb2NzIGFyZSBhIGxpdHRsZSBtb3JlIGRldmVsb3Blci1j ZW50cmljIHdoZXJlYXMgdGhlIFJlZEhhdCBkb2NzIGFyZSBtb3JlIGVhc2lseSByZWFkYWJsZQ0K --_000_9cff90f6acfe44c2ab30837610301bceexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <7C7FB8E8E6F9084D92C4FF0EBE6AE5CC(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiA4IG9rdC4gMjAxNiAxOToxNSBza3JldiBDaGFybGVzIEtvemxlciAmbHQ7Y2tv emxlcmlpaUBnbWFpbC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IEdvb2dsaW5nICZxdW90 O292aXJ0IHdpbmRvd3MgYWdlbnQmcXVvdDsgdGhpcyBpcyB0aGUgZmlyc3QgbGluayB0aGF0IHBv cHMgdXA6Jm5ic3A7aHR0cDovL3d3dy5vdmlydC5vcmcvZG9jdW1lbnRhdGlvbi9pbnRlcm5hbC9n dWVzdC1hZ2VudC9ndWVzdC1hZ2VudC1mb3Itd2luZG93cy88YnI+DQomZ3Q7PGJyPg0KJmd0OyBU aGlzIGRvYyBzZWVtcyBub24taW50dWl0aXZlIGFuZCBvdmVyIGNvbXBsaWNhdGVkPGJyPg0KJmd0 Ozxicj4NCiZndDsgU3BlY2lmaWNhbGx5LCB0aGUgUmVkSGF0IGRvY3VtZW50YXRpb24gdGhhdCBp cyA0IGxpbmtzIGJlbG93IGlzIHNpbXBsZSBhcyAmcXVvdDtpbnN0YWxsIHRoaXMgcGFja2FnZSBh bmQgbW91bnQgdGhlIGlzbyZxdW90OzombmJzcDtodHRwczovL2NvbW11bml0eS5yZWRoYXQuY29t L2Jsb2cvMjAxNS8wNS9ob3ctdG8taW5zdGFsbC1hbmQtdXNlLW92aXJ0cy13aW5kb3dzLWd1ZXN0 LXRvb2xzLzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBmb3JtZXIgd2FzIHVwZGF0ZWQgYXMgZWFy bHkgYXMgSnVuZSBvZiB0aGlzIHllYXImbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLikgVGhl IFJlZEhhdCBkb2N1bWVudCB3b3JrZWQgZm9yIG1lIHNvIEkgZG9udCB0aGluayBvVmlydCA0Lngg Y2FudCB1c2UgdGhlIHNhbWU8YnI+DQomZ3Q7IDIuKSBXaHkgaGF2ZSBzZXBhcmF0ZSBhcmVhcyBv ZiBkb2N1bWVudGF0aW9uIHRoYXQgYXJlIHNvIGRpZmZlcmVudCBmcm9tIGVhY2ggb3RoZXI/IFRo aXMgaGFzIGNhdXNlZCBtZSBpc3N1ZXMgaW4gdGhlIHBhc3Qgd2hlcmVieSBJIGZvdW5kIFJIIGRv Y3MgdGhhdCB3ZXJlIG11Y2ggbW9yZSBjbGVhciBhbmQgY29uY2lzZSZuYnNwOzwvcD4NCjxwIGRp cj0ibHRyIj5UaGF0J3MgYmVjYXVzZSBhbGwgb1ZpcnQgZG9jdW1lbnRhdGlvbiBpcyBjb21tdW5p dHkgZHJpdmVuLiBUaGlzIHNwZWNpZmljIHBhZ2Ugd2FzIHdyaXR0ZW4gYnkgYSBndXkgSSBoYXBw ZW4gdG8ga25vdyBxdWl0ZSB3ZWxsIChJIHdyb3RlIGl0KTopPC9wPg0KPHAgZGlyPSJsdHIiPlRo aXMgd2FzIHdyaXR0ZW4gYmFjayB3aGVuIHRoZXJlIHdhcyBubyBlYXN5IHRvIGluc3RhbGwgcGFj a2FnZSwgd2hlcmUgeW91IGhhZCB0byBkbyB0aGF0IGJ5IGhhbmQsIGFuZCBpZiB5b3Ugd2FudCB0 bywgeW91IHN0aWxsIGNhbiwgdGhlIG1ldGhvZCBzdGlsbCB3b3Jrcy4gQnV0IEkgYWdyZWUgdGhh dCBpZiB0aGVyZSdzIGFuIGVhc2llciB3YXkgdG9kYXksIEkgdGhpbmsgd2Ugc2hvdWxkIGdvIHdp dGggdGhhdCBmaXJzdA0KIGFuZCBrZWVwIHRoaXMgY29tcGlsaW5nIG1ldGhvZCBhcyB0aGUgZmFs bGJhY2suPC9wPg0KPHAgZGlyPSJsdHIiPiZndDsgMy4pIElzIHRoZXJlIGFueW9uZSB3aG8gbWln aHQgd2FudCB0byBtZXJnZSBSSCBkb2NzIHdpdGggb1ZpcnQgZG9jcyB3aGVyZSB0aGUgUkggZG9j cyBhcmUgYmV0dGVyIHRoYW4gb1ZpcnQ/PC9wPg0KPHAgZGlyPSJsdHIiPkhvcGluZyBzb21lb25l IEBSSCBjYW4gYW5zd2VyIHRoaXMsIGJlY2F1c2UgSSBkb24ndCBrbm93IGlmIEknbSBhbGxvd2Vk IHRvIGRvIHRoYXQ/PC9wPg0KPHAgZGlyPSJsdHIiPi9LPC9wPg0KPHAgZGlyPSJsdHIiPiZndDs8 YnI+DQomZ3Q7IFRoYW5rcyBzbyBtdWNoIGZvciBwcm92aWRpbmcgc3VjaCBhIGdyZWF0IHByb2R1 Y3QhIEkganVzdCBmZWVsIHNvbWV0aW1lcyB0aGUgZG9jcyBhcmUgYSBsaXR0bGUgbW9yZSBkZXZl bG9wZXItY2VudHJpYyB3aGVyZWFzIHRoZSBSZWRIYXQgZG9jcyBhcmUgbW9yZSBlYXNpbHkgcmVh ZGFibGUmbmJzcDs8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9cff90f6acfe44c2ab30837610301bceexch24sluse_--

2 1

documentation change suggestion / question
by Charles Kozler 08 Oct '16

08 Oct '16

Googling "ovirt windows agent" this is the first link that pops up: http://www.ovirt.org/documentation/internal/guest-agent/guest-agent-for-win… This doc seems non-intuitive and over complicated Specifically, the RedHat documentation that is 4 links below is simple as "install this package and mount the iso": https://community.redhat.com/blog/2015/05/how-to-install-and-use-ovirts-win… The former was updated as early as June of this year 1.) The RedHat document worked for me so I dont think oVirt 4.x cant use the same 2.) Why have separate areas of documentation that are so different from each other? This has caused me issues in the past whereby I found RH docs that were much more clear and concise 3.) Is there anyone who might want to merge RH docs with oVirt docs where the RH docs are better than oVirt? Thanks so much for providing such a great product! I just feel sometimes the docs are a little more developer-centric whereas the RedHat docs are more easily readable

1 0

How to add a tcp type serial to a vm in ovirt 4.0?
by lifuqiong 08 Oct '16

08 Oct '16

This is a multipart message in MIME format. ------=_NextPart_000_04AE_01D221B2.B69E7920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We can easily add a Serial Hardware in virt-manager, when adding the serial, the vm's xml add these lines as follows: . <serial type='tcp'> <source mode='bind' host='127.0.0.1' service='4555' /> <protocol type='telnet' /> </serial> ... But I can't add a tcp serial in ovirt 4.0 when I create a VM, even after I reading http://www.ovirt.org/documentation/admin-guide/serial-console-setup/ Hope someone can help me. Thank you Mark ------=_NextPart_000_04AE_01D221B2.B69E7920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DZH-CN link=3Dblue = vlink=3Dpurple style=3D'text-justify-trim:punctuation'><div = class=3DWordSection1>Hi, = <o:p></o:p>         We can = easily add a Serial Hardware in virt-manager, when adding the serial, = the vm’s xml add these lines as follows:<o:p></o:p>…<o:p></o:p><serial = type=3D’tcp’><o:p></o:p>         <source = mode=3D’bind’ host=3D’127.0.0.1’ = service=3D’4555’ /><o:p></o:p>         = <protocol type=3D’telnet’ /><o:p></o:p></serial><o:p></o:p>…..<o:p></o:p>         = <o:p></o:p>         But I = can’t add a tcp serial in ovirt 4.0 when I create a VM, even after = I reading <a = href=3D"http://www.ovirt.org/documentation/admin-guide/serial-console-set= up/">http://www.ovirt.org/documentation/admin-guide/serial-console-setup/= </a><o:p></o:p><o:p> </o:p>Hope someone can help me. <o:p></o:p>Thank you<o:p></o:p>Mark<o:p></o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_04AE_01D221B2.B69E7920--

1 0

RE > Multiple export domains limit?
by aleksey.maksimov＠it-kb.ru 07 Oct '16

07 Oct '16

Hello oVirt guru`s! http://lists.ovirt.org/pipermail/users/2015-November/036056.html Is there a progress on this issue?

2 1

Can't add host - Failed to read hardware information
by David Pinkerton 07 Oct '16

07 Oct '16

I'm trying to add a host to a freshly built cluster. yum install finishes, then the message " Failed to read hardware information" is displayed - host has installation failed. If I try to re-install I get the same message and the host goes non-responsive. engine log: 2016-10-07 21:13:46,525 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [2854e702] Connecting to /192.168.21.71 2016-10-07 21:13:46,526 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler4) [3fa97b73] Command 'GetCapabilitiesVDSCommand(HostName = rhv1, VdsIdAndVdsVDSCommandParametersBase:{runAsync='true', hostId='96358424-a14e-4d29-957f-3d7ddac99c12', vds='Host[rhv1,96358424-a14e-4d29-957f-3d7ddac99c12]'})' execution failed: org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed 2016-10-07 21:13:46,526 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (DefaultQuartzScheduler4) [3fa97b73] Failure to refresh Vds runtime info: org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed 2016-10-07 21:13:46,526 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (DefaultQuartzScheduler4) [3fa97b73] Exception: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:157) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:120) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:451) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:653) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:121) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refresh(HostMonitoring.java:85) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:238) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:77) [scheduler.jar:] at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:51) [scheduler.jar:] at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_102] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102] Caused by: org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed at org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient.connect(ReactorClient.java:165) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.getClient(JsonRpcClient.java:134) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:81) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.FutureMap.<init>(FutureMap.java:70) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer.getCapabilities(JsonRpcVdsServer.java:258) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:15) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:110) [vdsbroker.jar:] ... 18 more 2016-10-07 21:13:49,531 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [2854e702] Connecting to /192.168.21.71 vdsm.log jsonrpc.Executor/3::INFO::2016-10-07 20:45:31,554::__init__::513::jsonrpc.JsonRpcServer::(_serveRequest) RPC call Host.getCapabilities succeeded in 0.06 seconds jsonrpc.Executor/4::DEBUG::2016-10-07 20:45:32,566::__init__::530::jsonrpc.JsonRpcServer::(_handle_request) Calling 'Host.getHardwareInfo' in bridge with {} jsonrpc.Executor/4::ERROR::2016-10-07 20:45:32,673::API::1340::vds::(getHardwareInfo) failed to retrieve hardware info Traceback (most recent call last): File "/usr/share/vdsm/API.py", line 1337, in getHardwareInfo hw = supervdsm.getProxy().getHardwareInfo() File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 53, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 51, in <lambda> **kwargs) File "<string>", line 2, in getHardwareInfo File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in _callmethod kind, result = conn.recv() EOFError jsonrpc.Executor/4::INFO::2016-10-07 20:45:32,680::__init__::513::jsonrpc.JsonRpcServer::(_serveRequest) RPC call Host.getHardwareInfo failed (error 57) in 0.11 seconds jsonrpc.Executor/6::DEBUG::2016-10-07 20:45:33,783::__init__::530::jsonrpc.JsonRpcServer::(_handle_request) Calling 'Host.getCapabilities' in bridge with {} MainThread::DEBUG::2016-10-07 20:45:36,211::vdsm::73::vds::(sigtermHandler) Received signal 15 I'm also seeing segfaults in supervdsm on the host's console. -- David Pinkerton +61-488-904-232 <http://apac.redhat.com/>

2 1

change broker.conf configuration on shared storage
by emanuel.santosvarina＠mahle.com 07 Oct '16

07 Oct '16

This is a multipart message in MIME format. --=_alternative 004F9B75C1258043_= Content-Type: text/plain; charset="US-ASCII" hi all, hmm, broker.conf is now on the shared storage and not replicated on each host local file system. how to make changes to the conf, e.g. the notify key? thanks, emanuel --=_alternative 004F9B75C1258043_= Content-Type: text/html; charset="US-ASCII" hi all, hmm, broker.conf is now on the shared storage and not replicated on each host local file system. how to make changes to the conf, e.g.  the notify key? thanks, emanuel --=_alternative 004F9B75C1258043_=--

3 5

VMs paused due to IO issues - Dell Equallogic controller failover
by Gary Lloyd 07 Oct '16

07 Oct '16

Hi We have Ovirt 3.65 with a Dell Equallogic SAN and we use Direct Luns for all our VMs. At the weekend during early hours an Equallogic controller failed over to its standby on one of our arrays and this caused about 20 of our VMs to be paused due to IO problems. I have also noticed that this happens during Equallogic firmware upgrades since we moved onto Ovirt 3.65. As recommended by Dell disk timeouts within the VMs are set to 60 seconds when they are hosted on an EqualLogic SAN. Is there any other timeout value that we can configure in vdsm.conf to stop VMs from getting paused when a controller fails over ? Also is there anything that we can tweak to automatically unpause the VMs once connectivity with the arrays is re-established ? At the moment we are running a customized version of storageServer.py, as Ovirt has yet to include iscsi multipath support for Direct Luns out of the box. Many Thanks *Gary Lloyd* ________________________________________________ I.T. Systems:Keele University Finance & IT Directorate Keele:Staffs:IC1 Building:ST5 5NB:UK +44 1782 733063 <%2B44%201782%20733073> ________________________________________________

4 7

VM SSO
by Maxence Sartiaux 07 Oct '16

07 Oct '16

Hello, I try to use the VM SSO but no login, still on the logon screen ... I'm on ovirt 4.0.3, connected to an AD (Samba 4.5) + VMs Windows 7/10 stateless sysprep-ed to integrate to the domain and obviously the guest-agent is installed. My AD user can connect to the user panel, take a vm and connect to the console but no sign on on the windows. (the "Connect Automatically" option is ticked) Also, i don't know why but my username on ovirt panel has a double domain "u1@labo.lan@labo.lan" <- is this my problem ? The AD configuration is the configuration from the extension setup wizard, no custom config, no mapping Any ideas ? Thank you

2 1

VDSM Network Interface configuration
by Maton, Brett 07 Oct '16

07 Oct '16

Where is the configuration that VDSM uses to generate ifcfg files? My nameservers have moved and it seems to regenerate the ifcfg (ovirtmgmt) file overwriting the changes with the correct name servers in when the server is rebooted and s putting in the wrong (old) nameserver addresses. Where can I fix this ? Thanks

2 1

Cleanup illegal snapshot
by Markus Stockhausen 06 Oct '16

06 Oct '16

This is a multi-part message in MIME format. ------=_NextPartTM-000-fc1f7529-5cad-4353-95c5-d05ce067665d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=0A= =0A= if a OVirt snapshot is illegal we might have 2 situations.=0A= =0A= 1) qemu is still using it - lsof shows qemu access to the base raw and the = =0A= delta qcow2 file. -> E.g. a previous live merge failed. In the past we =0A= successfully solved that situation by setting the status of the delta image= =0A= in the database to OK. =0A= =0A= 2) qemu is no longer using it. lsof shows qemu access only to the the base= =0A= raw file -> E.g. a previous live merge succeded in qemu but Ovirt did not= =0A= recognize. =0A= =0A= How to clean up the 2nd situation?=0A= =0A= Best regards.=0A= =0A= Markus=0A= ------=_NextPartTM-000-fc1f7529-5cad-4353-95c5-d05ce067665d Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-fc1f7529-5cad-4353-95c5-d05ce067665d--

3 4

Ovirt setup
by Bryan Sockel 06 Oct '16

06 Oct '16

Hi, I am getting an error attempting to install ovirt on a pair of bonded nics. The error that we are getting is Cannot acquire nic/bridge address. We typically run all our servers with an active/backup setup.

2 1

unable to upgrade from ovirt 3.6 to 4.0.4
by Alon Dotan 06 Oct '16

06 Oct '16

Hey all, Im trying to upgrade my ovirt installation, CentOS 7.2 fully updated engine version: oVirt Engine Version: 3.6.7.5-1.el7.centos hosts version: OS Version: RHEL - 7 - 2.1511.el7.centos.2.10 Kernel Version: 3.10.0 - 327.36.1.el7.x86_64 KVM Version: 2.3.0 - 31.el7_2.10.1 LIBVIRT Version: libvirt-1.2.17-13.el7_2.5 VDSM Version: vdsm-4.17.32-1.el7 SPICE Version: 0.12.4 - 15.el7_2.2 GlusterFS Version: [N/A] CEPH Version: got the following error after deploying the backup tar (following this guide http://www.ovirt.org/documentation/migration-engine-3.6-to-4.0/) Failed to execute stage 'Setup validation': Trying to upgrade from unsupported versions: 3.5 attaching the engine-setup answer and log Thanks,

4 3

Correct recovery procedure of the oVirt Hosted Engine 4.0
by aleksey.maksimov＠it-kb.ru 06 Oct '16

06 Oct '16

Hello oVirt guru`s! My Hosted Engine VM located on a dedicated LUN FC Storage. I do daily data backups (on NFS share) with the command: /usr/bin/engine-backup --mode=backup --scope=all --file=$BcpFileName.xz --log=$BcpFileName.log --archive-compressor=xz --files-compressor=None However, I don't know what would be the correct procedure to recover, because in different manuals outline the various steps. For example, there is information that I have to do configure postgresql (with password from file files/etc/ovirt-engine/engine.conf.d/10-setup-database.conf) before restoring (engine-backup --mode=restore): https://www.ovirt.org/documentation/admin-guide/hosted-engine-backup-and-re… And at the same time, in another document, there are no such steps: https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/singl… What should be the correct procedure for the recovery of Hosted Engine 4.0 ?

2 10

basic setup with SLES 11
by Lentes, Bernd 06 Oct '16

06 Oct '16

Hi, i'd like to create this basic setup: Two hosts with SLES 11 SP4, 10-15 guests (Windows 7, SLES, Ubuntu). SAN with several TB, attached via FC, formatted with OCFS2. VM's will run with kvm and libvirt. I'd like to have live migration. Would ovirt be possible in this setup, would i have a benefit ? Easy administration, s.th. like that ? Thanks. Bernd -- Bernd Lentes Systemadministration institute of developmental genetics Gebäude 35.34 - Raum 208 HelmholtzZentrum München bernd.lentes(a)helmholtz-muenchen.de phone: +49 (0)89 3187 1241 fax: +49 (0)89 3187 2294 Erst wenn man sich auf etwas festlegt kann man Unrecht haben Scott Adams Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

2 1

Add extra dnsname for certificate on engine
by Matt . 05 Oct '16

05 Oct '16

Hi guys, When the engine lives under engine.sub.sub.sub.domain.tld is it possible to add an extra alt hostname to it so we can add a certificate for engine.domain.tld ? I hope someone can point this out. Cheers, Matt

2 2

ETL Service fails
by Andy 05 Oct '16

05 Oct '16

------=_Part_3758020_756145403.1475295841164 Content-Type: multipart/alternative; boundary="----=_Part_3758019_2012389424.1475295841163" ------=_Part_3758019_2012389424.1475295841163 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I just upgraded to OVIRT 4.04 on the hosted appliance and for some reason I no longer see the DHW metrics on the dashboard. I receive a lot of errors, obviously, stating "ETL Service has encountered an error, Please consult the service log. The research that I have been able to come up with appears to be with a FK or a user that no longer exists in the database, however the attached logs have zero reference to these errors. Any help would be appreciated. Thanks Andy ------=_Part_3758019_2012389424.1475295841163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div style=3D"color:#000; background-color:#fff; f= ont-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, = sans-serif;font-size:10px"><div id=3D"yui_3_16_0_ym19_1_1475295566829_6832"= dir=3D"ltr">Hello, I just u= pgraded to OVIRT 4.04 on the hosted appliance and for some reason I no long= er see the DHW metrics on the dashboard. I receive a lot of errors, obvious= ly, stating "ETL Service has encountered an error, Please consult the servi= ce log. The research that I have been able to come up with appears to be wi= th a FK or a user that no longer exists in the database, however the attach= ed logs have zero reference to these errors. Any help w= ould be appreciated. </div><= div dir=3D"ltr"> </div><div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_14752955= 66829_7031">Thanks Andy</div></div></body></html> ------=_Part_3758019_2012389424.1475295841163-- ------=_Part_3758020_756145403.1475295841164 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=logs Content-ID: <d1e00938-2621-e516-6bd5-7329b95cfe8c(a)yahoo.com> W3Jvb3RAZXhjb3ZtZyBvdmlydC1lbmdpbmUtZHdoXSMgbW9yZSBvdmlydC1lbmdpbmUtZHdoZC5s b2cgCjIwMTYtMTAtMDEgMDI6Mzg6Mzl8RVRMIFNlcnZpY2UgU3RhcnRlZApvdmlydEVuZ2luZURi RHJpdmVyQ2xhc3N8b3JnLnBvc3RncmVzcWwuRHJpdmVyCm92aXJ0RW5naW5lSGlzdG9yeURiSmRi Y0Nvbm5lY3Rpb258amRiYzpwb3N0Z3Jlc3FsOi8vbG9jYWxob3N0OjU0MzIvb3ZpcnRfZW5naW5l X2hpc3Rvcnk/c3NsZmFjdG9yeT1vcmcucG9zdGdyZXNxbC5zc2wuTm9uVmFsaWRhdGluZ0ZhY3Rv cnkKaG91cnNUb0tlZXBEYWlseXwwCmhvdXJzVG9LZWVwSG91cmx5fDcyMApvdmlydEVuZ2luZURi UGFzc3dvcmR8KioqKioqKioqKioqKioqKioqKioqKgpydW5EZWxldGVUaW1lfDMKb3ZpcnRFbmdp bmVEYkpkYmNDb25uZWN0aW9ufGpkYmM6cG9zdGdyZXNxbDovL2xvY2FsaG9zdDo1NDMyL2VuZ2lu ZT9zc2xmYWN0b3J5PW9yZy5wb3N0Z3Jlc3FsLnNzbC5Ob25WYWxpZGF0aW5nRmFjdG9yeQpydW5J bnRlcmxlYXZlfDIwCmxpbWl0Um93c3xsaW1pdCAxMDAwCm92aXJ0RW5naW5lSGlzdG9yeURiVXNl cnxvdmlydF9lbmdpbmVfaGlzdG9yeQpvdmlydEVuZ2luZURiVXNlcnxlbmdpbmUKZGVsZXRlSW5j cmVtZW50fDEwCnRpbWVCZXR3ZWVuRXJyb3JFdmVudHN8MzAwMDAwCmhvdXJzVG9LZWVwU2FtcGxl c3wyNApkZWxldGVNdWx0aXBsaWVyfDEwMDAKbGFzdEVycm9yU2VudHwyMDExLTA3LTAzIDEyOjQ2 OjQ3LjAwMDAwMApldGxWZXJzaW9ufDQuMC4yCmR3aEFnZ3JlZ2F0aW9uRGVidWd8ZmFsc2UKZHdo VXVpZHw3NmQ1NTg4Ny1hMDgxLTQ5YTAtODllNy1kOGIxMmQxYWYyYzMKb3ZpcnRFbmdpbmVIaXN0 b3J5RGJEcml2ZXJDbGFzc3xvcmcucG9zdGdyZXNxbC5Ecml2ZXIKb3ZpcnRFbmdpbmVIaXN0b3J5 RGJQYXNzd29yZHwqKioqKioqKioqKioqKioqKioqKioqCkV4Y2VwdGlvbiBpbiBjb21wb25lbnQg dEpEQkNPdXRwdXRfNQpFeGNlcHRpb24gaW4gY29tcG9uZW50IHRKREJDT3V0cHV0XzYKRXhjZXB0 aW9uIGluIGNvbXBvbmVudCB0SkRCQ091dHB1dF8yCm9yZy5wb3N0Z3Jlc3FsLnV0aWwuUFNRTEV4 Y2VwdGlvbjogRVJST1I6IGluZGV4ICJpZHhfdm1fY29uZmlndXJhdGlvbl92ZXJzaW9uX3NhbXBs ZXMiIGNvbnRhaW5zIHVuZXhwZWN0ZWQgemVybyBwYWdlIGF0IGJsb2NrIDI0MjMKICBIaW50OiBQ bGVhc2UgUkVJTkRFWCBpdC4KCWF0IG9yZy5wb3N0Z3Jlc3FsLmNvcmUudjMuUXVlcnlFeGVjdXRv ckltcGwucmVjZWl2ZUVycm9yUmVzcG9uc2UoUXVlcnlFeGVjdXRvckltcGwuamF2YToyMTU3KQoJ YXQgb3JnLnBvc3RncmVzcWwuY29yZS52My5RdWVyeUV4ZWN1dG9ySW1wbC5wcm9jZXNzUmVzdWx0 cyhRdWVyeUV4ZWN1dG9ySW1wbC5qYXZhOjE4ODYpCglhdCBvcmcucG9zdGdyZXNxbC5jb3JlLnYz LlF1ZXJ5RXhlY3V0b3JJbXBsLmV4ZWN1dGUoUXVlcnlFeGVjdXRvckltcGwuamF2YToyNTUpCglh dCBvcmcucG9zdGdyZXNxbC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGUoQWJz dHJhY3RKZGJjMlN0YXRlbWVudC5qYXZhOjU1NSkKCWF0IG9yZy5wb3N0Z3Jlc3FsLmpkYmMyLkFi c3RyYWN0SmRiYzJTdGF0ZW1lbnQuZXhlY3V0ZVdpdGhGbGFncyhBYnN0cmFjdEpkYmMyU3RhdGVt ZW50LmphdmE6NDE3KQoJYXQgb3JnLnBvc3RncmVzcWwuamRiYzIuQWJzdHJhY3RKZGJjMlN0YXRl bWVudC5leGVjdXRlVXBkYXRlKEFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuamF2YTozNjMpCglhdCBv dmlydF9lbmdpbmVfZHdoLnN0YXRpc3RpY3NzeW5jXzRfMC5TdGF0aXN0aWNzU3luYy50SkRCQ0lu cHV0XzEwUHJvY2VzcyhTdGF0aXN0aWNzU3luYy5qYXZhOjkwMzApCglhdCBvdmlydF9lbmdpbmVf ZHdoLnN0YXRpc3RpY3NzeW5jXzRfMC5TdGF0aXN0aWNzU3luYyQ1LnJ1bihTdGF0aXN0aWNzU3lu Yy5qYXZhOjE2MDcxKQpFeGNlcHRpb24gaW4gY29tcG9uZW50IHRKREJDT3V0cHV0XzQKb3JnLnBv c3RncmVzcWwudXRpbC5QU1FMRXhjZXB0aW9uOiBFUlJPUjogY3VycmVudCB0cmFuc2FjdGlvbiBp cyBhYm9ydGVkLCBjb21tYW5kcyBpZ25vcmVkIHVudGlsIGVuZCBvZiB0cmFuc2FjdGlvbiBibG9j awoJYXQgb3JnLnBvc3RncmVzcWwuY29yZS52My5RdWVyeUV4ZWN1dG9ySW1wbC5yZWNlaXZlRXJy b3JSZXNwb25zZShRdWVyeUV4ZWN1dG9ySW1wbC5qYXZhOjIxNTcpCglhdCBvcmcucG9zdGdyZXNx bC5jb3JlLnYzLlF1ZXJ5RXhlY3V0b3JJbXBsLnByb2Nlc3NSZXN1bHRzKFF1ZXJ5RXhlY3V0b3JJ bXBsLmphdmE6MTg4NikKCWF0IG9yZy5wb3N0Z3Jlc3FsLmNvcmUudjMuUXVlcnlFeGVjdXRvcklt cGwuZXhlY3V0ZShRdWVyeUV4ZWN1dG9ySW1wbC5qYXZhOjI1NSkKCWF0IG9yZy5wb3N0Z3Jlc3Fs LmpkYmMyLkFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuZXhlY3V0ZShBYnN0cmFjdEpkYmMyU3RhdGVt ZW50LmphdmE6NTU1KQoJYXQgb3JnLnBvc3RncmVzcWwuamRiYzIuQWJzdHJhY3RKZGJjMlN0YXRl bWVudC5leGVjdXRlV2l0aEZsYWdzKEFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuamF2YTo0MTcpCglh dCBvcmcucG9zdGdyZXNxbC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGVVcGRh dGUoQWJzdHJhY3RKZGJjMlN0YXRlbWVudC5qYXZhOjM2MykKCWF0IG92aXJ0X2VuZ2luZV9kd2gu c3RhdGlzdGljc3N5bmNfNF8wLlN0YXRpc3RpY3NTeW5jLnRKREJDSW5wdXRfOFByb2Nlc3MoU3Rh dGlzdGljc1N5bmMuamF2YTo2MjU4KQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zdGF0aXN0aWNzc3lu Y180XzAuU3RhdGlzdGljc1N5bmMkNC5ydW4oU3RhdGlzdGljc1N5bmMuamF2YToxNjAyNSkKb3Jn LnBvc3RncmVzcWwudXRpbC5QU1FMRXhjZXB0aW9uOiBFUlJPUjogY3VycmVudCB0cmFuc2FjdGlv biBpcyBhYm9ydGVkLCBjb21tYW5kcyBpZ25vcmVkIHVudGlsIGVuZCBvZiB0cmFuc2FjdGlvbiBi bG9jawoJYXQgb3JnLnBvc3RncmVzcWwuY29yZS52My5RdWVyeUV4ZWN1dG9ySW1wbC5yZWNlaXZl RXJyb3JSZXNwb25zZShRdWVyeUV4ZWN1dG9ySW1wbC5qYXZhOjIxNTcpCglhdCBvcmcucG9zdGdy ZXNxbC5jb3JlLnYzLlF1ZXJ5RXhlY3V0b3JJbXBsLnByb2Nlc3NSZXN1bHRzKFF1ZXJ5RXhlY3V0 b3JJbXBsLmphdmE6MTg4NikKCWF0IG9yZy5wb3N0Z3Jlc3FsLmNvcmUudjMuUXVlcnlFeGVjdXRv ckltcGwuZXhlY3V0ZShRdWVyeUV4ZWN1dG9ySW1wbC5qYXZhOjI1NSkKCWF0IG9yZy5wb3N0Z3Jl c3FsLmpkYmMyLkFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuZXhlY3V0ZShBYnN0cmFjdEpkYmMyU3Rh dGVtZW50LmphdmE6NTU1KQoyMDE2LTEwLTAxIDAyOjM5OjAxfFVwMjZxOXxEazNRUVN8UHB2aVEw fE9WSVJUX0VOR0lORV9EV0h8U3RhdGlzdGljc1N5bmN8RGVmYXVsdHw2fEphdmEgRXhjZXB0aW9u fHRKREJDT3V0cHV0XzV8b3JnLnBvc3RncmVzcWwudXRpbC5QU1FMRXhjZXB0aW9uCjpFUlJPUjog aW5kZXggImlkeF92bV9jb25maWd1cmF0aW9uX3ZlcnNpb25fc2FtcGxlcyIgY29udGFpbnMgdW5l eHBlY3RlZCB6ZXJvIHBhZ2UgYXQgYmxvY2sgMjQyMwogIEhpbnQ6IFBsZWFzZSBSRUlOREVYIGl0 LnwxCglhdCBvcmcucG9zdGdyZXNxbC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1 dGVXaXRoRmxhZ3MoQWJzdHJhY3RKZGJjMlN0YXRlbWVudC5qYXZhOjQxNykKCWF0IG9yZy5wb3N0 Z3Jlc3FsLmpkYmMyLkFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuZXhlY3V0ZVVwZGF0ZShBYnN0cmFj dEpkYmMyU3RhdGVtZW50LmphdmE6MzYzKQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zdGF0aXN0aWNz c3luY180XzAuU3RhdGlzdGljc1N5bmMudEpEQkNJbnB1dF80UHJvY2VzcyhTdGF0aXN0aWNzU3lu Yy5qYXZhOjIwNTUpCglhdCBvdmlydF9lbmdpbmVfZHdoLnN0YXRpc3RpY3NzeW5jXzRfMC5TdGF0 aXN0aWNzU3luYyQyLnJ1bihTdGF0aXN0aWNzU3luYy5qYXZhOjE1OTMzKQpFeGNlcHRpb24gaW4g Y29tcG9uZW50IHRKREJDT3V0cHV0XzcKb3JnLnBvc3RncmVzcWwudXRpbC5QU1FMRXhjZXB0aW9u OiBFUlJPUjogY3VycmVudCB0cmFuc2FjdGlvbiBpcyBhYm9ydGVkLCBjb21tYW5kcyBpZ25vcmVk IHVudGlsIGVuZCBvZiB0cmFuc2FjdGlvbiBibG9jawoJYXQgb3JnLnBvc3RncmVzcWwuY29yZS52 My5RdWVyeUV4ZWN1dG9ySW1wbC5yZWNlaXZlRXJyb3JSZXNwb25zZShRdWVyeUV4ZWN1dG9ySW1w bC5qYXZhOjIxNTcpCglhdCBvcmcucG9zdGdyZXNxbC5jb3JlLnYzLlF1ZXJ5RXhlY3V0b3JJbXBs LnByb2Nlc3NSZXN1bHRzKFF1ZXJ5RXhlY3V0b3JJbXBsLmphdmE6MTg4NikKCWF0IG9yZy5wb3N0 Z3Jlc3FsLmNvcmUudjMuUXVlcnlFeGVjdXRvckltcGwuZXhlY3V0ZShRdWVyeUV4ZWN1dG9ySW1w bC5qYXZhOjI1NSkKCWF0IG9yZy5wb3N0Z3Jlc3FsLmpkYmMyLkFic3RyYWN0SmRiYzJTdGF0ZW1l bnQuZXhlY3V0ZShBYnN0cmFjdEpkYmMyU3RhdGVtZW50LmphdmE6NTU1KQoJYXQgb3JnLnBvc3Rn cmVzcWwuamRiYzIuQWJzdHJhY3RKZGJjMlN0YXRlbWVudC5leGVjdXRlV2l0aEZsYWdzKEFic3Ry YWN0SmRiYzJTdGF0ZW1lbnQuamF2YTo0MTcpCglhdCBvcmcucG9zdGdyZXNxbC5qZGJjMi5BYnN0 cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGVVcGRhdGUoQWJzdHJhY3RKZGJjMlN0YXRlbWVudC5q YXZhOjM2MykKCWF0IG92aXJ0X2VuZ2luZV9kd2guc3RhdGlzdGljc3N5bmNfNF8wLlN0YXRpc3Rp Y3NTeW5jLnRKREJDSW5wdXRfMThQcm9jZXNzKFN0YXRpc3RpY3NTeW5jLmphdmE6MTM0MjkpCglh dCBvdmlydF9lbmdpbmVfZHdoLnN0YXRpc3RpY3NzeW5jXzRfMC5TdGF0aXN0aWNzU3luYyQ3LnJ1 bihTdGF0aXN0aWNzU3luYy5qYXZhOjE2MTYzKQpvcmcucG9zdGdyZXNxbC51dGlsLlBTUUxFeGNl cHRpb246IEVSUk9SOiBjdXJyZW50IHRyYW5zYWN0aW9uIGlzIGFib3J0ZWQsIGNvbW1hbmRzIGln bm9yZWQgdW50aWwgZW5kIG9mIHRyYW5zYWN0aW9uIGJsb2NrCglhdCBvcmcucG9zdGdyZXNxbC5j b3JlLnYzLlF1ZXJ5RXhlY3V0b3JJbXBsLnJlY2VpdmVFcnJvclJlc3BvbnNlKFF1ZXJ5RXhlY3V0 b3JJbXBsLmphdmE6MjE1NykKCWF0IG9yZy5wb3N0Z3Jlc3FsLmNvcmUudjMuUXVlcnlFeGVjdXRv ckltcGwucHJvY2Vzc1Jlc3VsdHMoUXVlcnlFeGVjdXRvckltcGwuamF2YToxODg2KQoJYXQgb3Jn LnBvc3RncmVzcWwuY29yZS52My5RdWVyeUV4ZWN1dG9ySW1wbC5leGVjdXRlKFF1ZXJ5RXhlY3V0 b3JJbXBsLmphdmE6MjU1KQoJYXQgb3JnLnBvc3RncmVzcWwuamRiYzIuQWJzdHJhY3RKZGJjMlN0 YXRlbWVudC5leGVjdXRlKEFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuamF2YTo1NTUpCglhdCBvcmcu cG9zdGdyZXNxbC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGVXaXRoRmxhZ3Mo QWJzdHJhY3RKZGJjMlN0YXRlbWVudC5qYXZhOjQxNykKCWF0IG9yZy5wb3N0Z3Jlc3FsLmpkYmMy LkFic3RyYWN0SmRiYzJTdGF0ZW1lbnQuZXhlY3V0ZVVwZGF0ZShBYnN0cmFjdEpkYmMyU3RhdGVt ZW50LmphdmE6MzYzKQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zdGF0aXN0aWNzc3luY180XzAuU3Rh dGlzdGljc1N5bmMudEpEQkNJbnB1dF8xMlByb2Nlc3MoU3RhdGlzdGljc1N5bmMuamF2YToxMTM3 OCkyMDE2LTEwLTAxIDAyOjM5OjAxfFVwMjZxOXxEazNRUVN8UHAKdmlRMHxPVklSVF9FTkdJTkVf RFdIfFN0YXRpc3RpY3NTeW5jfERlZmF1bHR8NnxKYXZhIEV4Y2VwdGlvbnx0SkRCQ091dHB1dF80 fG9yZy5wb3N0Z3Jlc3FsLnV0aWwuUFNRTEV4Y2VwdGlvbjpFUlJPUjogY3VycmVudCB0cmFuc2Fj dGlvbiBpcyBhYm9ydAplZCwgY29tbWFuZHMgaWdub3JlZCB1bnRpbCBlbmQgb2YgdHJhbnNhY3Rp b24gYmxvY2t8MQoKCWF0IG92aXJ0X2VuZ2luZV9kd2guc3RhdGlzdGljc3N5bmNfNF8wLlN0YXRp c3RpY3NTeW5jJDYucnVuKFN0YXRpc3RpY3NTeW5jLmphdmE6MTYxMTcpCjIwMTYtMTAtMDEgMDI6 Mzk6MDF8VXAyNnE5fERrM1FRU3xQcHZpUTB8T1ZJUlRfRU5HSU5FX0RXSHxTdGF0aXN0aWNzU3lu Y3xEZWZhdWx0fDZ8SmF2YSBFeGNlcHRpb258dEpEQkNPdXRwdXRfN3xvcmcucG9zdGdyZXNxbC51 dGlsLlBTUUxFeGNlcHRpb24KOkVSUk9SOiBjdXJyZW50IHRyYW5zYWN0aW9uIGlzIGFib3J0ZWQs IGNvbW1hbmRzIGlnbm9yZWQgdW50aWwgZW5kIG9mIHRyYW5zYWN0aW9uIGJsb2NrfDEKMjAxNi0x MC0wMSAwMjozOTowMXxVcDI2cTl8RGszUVFTfFBwdmlRMHxPVklSVF9FTkdJTkVfRFdIfFN0YXRp c3RpY3NTeW5jfERlZmF1bHR8NnxKYXZhIEV4Y2VwdGlvbnx0SkRCQ091dHB1dF8yfG9yZy5wb3N0 Z3Jlc3FsLnV0aWwuUFNRTEV4Y2VwdGlvbgo6RVJST1I6IGN1cnJlbnQgdHJhbnNhY3Rpb24gaXMg YWJvcnRlZCwgY29tbWFuZHMgaWdub3JlZCB1bnRpbCBlbmQgb2YgdHJhbnNhY3Rpb24gYmxvY2t8 MQoyMDE2LTEwLTAxIDAyOjM5OjAxfFVwMjZxOXxEazNRUVN8UHB2aVEwfE9WSVJUX0VOR0lORV9E V0h8U3RhdGlzdGljc1N5bmN8RGVmYXVsdHw2fEphdmEgRXhjZXB0aW9ufHRKREJDT3V0cHV0XzZ8 b3JnLnBvc3RncmVzcWwudXRpbC5QU1FMRXhjZXB0aW9uCjpFUlJPUjogY3VycmVudCB0cmFuc2Fj dGlvbiBpcyBhYm9ydGVkLCBjb21tYW5kcyBpZ25vcmVkIHVudGlsIGVuZCBvZiB0cmFuc2FjdGlv biBibG9ja3wxCkV4Y2VwdGlvbiBpbiBjb21wb25lbnQgdFJ1bkpvYl81CmphdmEubGFuZy5SdW50 aW1lRXhjZXB0aW9uOiBDaGlsZCBqb2IgcnVubmluZyBmYWlsZWQKCWF0IG92aXJ0X2VuZ2luZV9k d2guc2FtcGxlcnVuam9ic180XzAuU2FtcGxlUnVuSm9icy50UnVuSm9iXzVQcm9jZXNzKFNhbXBs ZVJ1bkpvYnMuamF2YToxNjU0KQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zYW1wbGVydW5qb2JzXzRf MC5TYW1wbGVSdW5Kb2JzLnRSdW5Kb2JfNlByb2Nlc3MoU2FtcGxlUnVuSm9icy5qYXZhOjE0NTYp CglhdCBvdmlydF9lbmdpbmVfZHdoLnNhbXBsZXJ1bmpvYnNfNF8wLlNhbXBsZVJ1bkpvYnMudFJ1 bkpvYl8xUHJvY2VzcyhTYW1wbGVSdW5Kb2JzLmphdmE6MTIyOCkKCWF0IG92aXJ0X2VuZ2luZV9k d2guc2FtcGxlcnVuam9ic180XzAuU2FtcGxlUnVuSm9icy50UnVuSm9iXzRQcm9jZXNzKFNhbXBs ZVJ1bkpvYnMuamF2YToxMDAwKQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zYW1wbGVydW5qb2JzXzRf MC5TYW1wbGVSdW5Kb2JzLnRKREJDQ29ubmVjdGlvbl8yUHJvY2VzcyhTYW1wbGVSdW5Kb2JzLmph dmE6NzY3KQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zYW1wbGVydW5qb2JzXzRfMC5TYW1wbGVSdW5K b2JzLnRKREJDQ29ubmVjdGlvbl8xUHJvY2VzcyhTYW1wbGVSdW5Kb2JzLmphdmE6NjQyKQoJYXQg b3ZpcnRfZW5naW5lX2R3aC5zYW1wbGVydW5qb2JzXzRfMC5TYW1wbGVSdW5Kb2JzJDIucnVuKFNh bXBsZVJ1bkpvYnMuamF2YToyNjgzKQoyMDE2LTEwLTAxIDAyOjM5OjAxfFBwdmlRMHxEazNRUVN8 VjNURjBWfE9WSVJUX0VOR0lORV9EV0h8U2FtcGxlUnVuSm9ic3xEZWZhdWx0fDZ8SmF2YSBFeGNl cHRpb258dFJ1bkpvYl81fGphdmEubGFuZy5SdW50aW1lRXhjZXB0aW9uOkNoaWxkIGpvYiByCnVu bmluZyBmYWlsZWR8MQpFeGNlcHRpb24gaW4gY29tcG9uZW50IHRSdW5Kb2JfMQpqYXZhLmxhbmcu UnVudGltZUV4Y2VwdGlvbjogQ2hpbGQgam9iIHJ1bm5pbmcgZmFpbGVkCglhdCBvdmlydF9lbmdp bmVfZHdoLnNhbXBsZXRpbWVrZWVwaW5nam9iXzRfMC5TYW1wbGVUaW1lS2VlcGluZ0pvYi50UnVu Sm9iXzFQcm9jZXNzKFNhbXBsZVRpbWVLZWVwaW5nSm9iLmphdmE6NjA2NykKCWF0IG92aXJ0X2Vu Z2luZV9kd2guc2FtcGxldGltZWtlZXBpbmdqb2JfNF8wLlNhbXBsZVRpbWVLZWVwaW5nSm9iLnRK REJDSW5wdXRfMlByb2Nlc3MoU2FtcGxlVGltZUtlZXBpbmdKb2IuamF2YTo1ODA5KQoJYXQgb3Zp cnRfZW5naW5lX2R3aC5zYW1wbGV0aW1la2VlcGluZ2pvYl80XzAuU2FtcGxlVGltZUtlZXBpbmdK b2IudEpEQkNDb25uZWN0aW9uXzFQcm9jZXNzKFNhbXBsZVRpbWVLZWVwaW5nSm9iLmphdmE6NDQ0 NCkKCWF0IG92aXJ0X2VuZ2luZV9kd2guc2FtcGxldGltZWtlZXBpbmdqb2JfNF8wLlNhbXBsZVRp bWVLZWVwaW5nSm9iLnRKREJDQ29ubmVjdGlvbl8yUHJvY2VzcyhTYW1wbGVUaW1lS2VlcGluZ0pv Yi5qYXZhOjQzMTkpCglhdCBvdmlydF9lbmdpbmVfZHdoLnNhbXBsZXRpbWVrZWVwaW5nam9iXzRf MC5TYW1wbGVUaW1lS2VlcGluZ0pvYi50Um93R2VuZXJhdG9yXzJQcm9jZXNzKFNhbXBsZVRpbWVL ZWVwaW5nSm9iLmphdmE6NDE4OCkKCWF0IG92aXJ0X2VuZ2luZV9kd2guc2FtcGxldGltZWtlZXBp bmdqb2JfNF8wLlNhbXBsZVRpbWVLZWVwaW5nSm9iLnRKREJDSW5wdXRfM1Byb2Nlc3MoU2FtcGxl VGltZUtlZXBpbmdKb2IuamF2YTozNTkzKQoJYXQgb3ZpcnRfZW5naW5lX2R3aC5zYW1wbGV0aW1l a2VlcGluZ2pvYl80XzAuU2FtcGxlVGltZUtlZXBpbmdKb2IudEpEQkNJbnB1dF81UHJvY2VzcyhT YW1wbGVUaW1lS2VlcGluZ0pvYi5qYXZhOjI5NzcpCglhdCBvdmlydF9lbmdpbmVfZHdoLnNhbXBs ZXRpbWVrZWVwaW5nam9iXzRfMC5TYW1wbGVUaW1lS2VlcGluZ0pvYi50SkRCQ0lucHV0XzRQcm9j ZXNzKFNhbXBsZVRpbWVLZWVwaW5nSm9iLmphdmE6MjI5NSkKCWF0IG92aXJ0X2VuZ2luZV9kd2gu c2FtcGxldGltZWtlZXBpbmdqb2JfNF8wLlNhbXBsZVRpbWVLZWVwaW5nSm9iLnRKREJDQ29ubmVj dGlvbl8zUHJvY2VzcyhTYW1wbGVUaW1lS2VlcGluZ0pvYi5qYXZhOjE2NDkpCglhdCBvdmlydF9l bmdpbmVfZHdoLnNhbXBsZXRpbWVrZWVwaW5nam9iXzRfMC5TYW1wbGVUaW1lS2VlcGluZ0pvYiQy LnJ1bihTYW1wbGVUaW1lS2VlcGluZ0pvYi5qYXZhOjExMzYxKQo= ------=_Part_3758020_756145403.1475295841164--

3 3

hosted-engine and GlusterFS on Vlan help
by Hanson 05 Oct '16

05 Oct '16

Hi Guys, I've converted my lab from using 802.3ad with bonding>bridged vlans to one link with two vlan bridges and am now having traffic jumping to the gateway when moving VM's/ISO/etc. 802.3ad = node1>switch1>node2 801.1q = node1>switch1>gateway>switch1>node2 I assume I've setup the same vlan style, though this time I used the gui on the initial host install... setting up the vlans with their parent being eth0. Hosted-engine on deploy then creates ovirtmgmt on top of eth0.11 ... Switch is tagged for vlans 10 & 11. Including a PVID of 11 for good measure. (Gluster is vlan 11) I'd expect the traffic from node to node to be going from port to port like it did in 802.3ad, what have I done wrong or is it using the gui initially? This is how the current setup looks: /var/lib/vdsm/Persistent/netconf/nets/ovirtmgmt: { "ipv6autoconf": false, "nameservers": [], "nic": "eth0", "vlan": 11, "ipaddr": "10.0.3.11", "switch": "legacy", "mtu": 1500, "netmask": "255.255.255.0", "dhcpv6": false, "stp": false, "bridged": true, "gateway": "10.0.3.1", "defaultRoute": true } /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt: # Generated by VDSM version 4.18.13-1.el7.centos DEVICE=ovirtmgmt TYPE=Bridge DELAY=0 STP=off ONBOOT=yes IPADDR=10.0.3.11 NETMASK=255.255.255.0 GATEWAY=10.0.3.1 BOOTPROTO=none DEFROUTE=yes NM_CONTROLLED=no IPV6INIT=no VLAN_ID=11 MTU=1500 Thanks!!

2 2

4.0 - 2nd node fails on deploy
by Jason Jeffrey 05 Oct '16

05 Oct '16

This is a multipart message in MIME format. ------=_NextPart_000_07BF_01D21D07.1029FF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am trying to build a x3 HC cluster, with a self hosted engine using gluster. I have successful built the 1st node, however when I attempt to run hosted-engine -deploy on node 2, I get the following error [WARNING] A configuration file must be supplied to deploy Hosted Engine on an additional host. [ ERROR ] 'version' is not stored in the HE configuration image [ ERROR ] Unable to get the answer file from the shared storage [ ERROR ] Failed to execute stage 'Environment customization': Unable to get the answer file from the shared storage [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20161002232505.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Hosted Engine deployment failed Looking at the failure in the log file.. 2016-10-02 23:25:05 WARNING otopi.plugins.gr_he_common.core.remote_answerfile remote_answerfile._customization:151 A configuration file must be supplied to deploy Hosted Engine on an additional host. 2016-10-02 23:25:05 DEBUG otopi.plugins.gr_he_common.core.remote_answerfile remote_answerfile._fetch_answer_file:61 _fetch_answer_f ile 2016-10-02 23:25:05 DEBUG otopi.plugins.gr_he_common.core.remote_answerfile remote_answerfile._fetch_answer_file:69 fetching from: /rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91b5-4f49-9c6b-fff 45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b/7 8cb2527-a2e2-489a-9fad-465a72221b37 2016-10-02 23:25:05 DEBUG otopi.plugins.gr_he_common.core.remote_answerfile heconflib._dd_pipe_tar:69 executing: 'sudo -u vdsm dd i f=/rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91b5-4f49-9c6b-f ff45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b /78cb2527-a2e2-489a-9fad-465a72221b37 bs=4k' 2016-10-02 23:25:05 DEBUG otopi.plugins.gr_he_common.core.remote_answerfile heconflib._dd_pipe_tar:70 executing: 'tar -tvf -' 2016-10-02 23:25:05 DEBUG otopi.plugins.gr_he_common.core.remote_answerfile heconflib._dd_pipe_tar:88 stdout: 2016-10-02 23:25:05 DEBUG otopi.plugins.gr_he_common.core.remote_answerfile heconflib._dd_pipe_tar:89 stderr: 2016-10-02 23:25:05 ERROR otopi.plugins.gr_he_common.core.remote_answerfile heconflib.validateConfImage:111 'version' is not stored in the HE configuration image 2016-10-02 23:25:05 ERROR otopi.plugins.gr_he_common.core.remote_answerfile remote_answerfile._fetch_answer_file:73 Unable to get t he answer file from the shared storage Looking at the detected gluster path - /rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91b5-4f49-9c6b-fff 45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b/ [root@dcasrv02 ~]# ls -al /rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91b5-4f49-9c6b-fff 45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b/ total 1049609 drwxr-xr-x. 2 vdsm kvm 4096 Oct 2 04:46 . drwxr-xr-x. 6 vdsm kvm 4096 Oct 2 04:46 .. -rw-rw----. 1 vdsm kvm 1073741824 Oct 2 04:46 78cb2527-a2e2-489a-9fad-465a72221b37 -rw-rw----. 1 vdsm kvm 1048576 Oct 2 04:46 78cb2527-a2e2-489a-9fad-465a72221b37.lease -rw-r--r--. 1 vdsm kvm 294 Oct 2 04:46 78cb2527-a2e2-489a-9fad-465a72221b37.meta 78cb2527-a2e2-489a-9fad-465a72221b37 is a 1 GB file, is this the engine VM ? Copying the answers file form primary (/etc/ovirt-hosted-engine/answers.conf ) to node 2 and rerunning produces the same error : ( (hosted-engine --deploy --config-append=/root/answers.conf ) Also tried on node 3, same issues Happy to provide logs and other debugs Thanks Jason ------=_NextPart_000_07BF_01D21D07.1029FF10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DEN-GB = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>Hi,<o:p></o:p><o:p> </o:p>I am trying to build a x3 HC = cluster, with a self hosted engine using = gluster.<o:p></o:p><o:p> </o:p>I have successful built the 1st node,  = however when I attempt to run hosted-engine –deploy on node 2, I = get the following error<o:p></o:p><o:p> </o:p>[WARNING] A configuration file must be supplied to deploy = Hosted Engine on an additional host.<o:p></o:p>[ ERROR ] 'version' is not stored = in the HE configuration image<o:p></o:p>[ ERROR ] Unable to get the answer = file from the shared storage<o:p></o:p>[ ERROR ] Failed to execute stage = 'Environment customization': Unable to get the answer file from the = shared storage<o:p></o:p>[ INFO  ] Stage: Clean up<o:p></o:p>[ INFO  ] Generating answer = file = '/var/lib/ovirt-hosted-engine-setup/answers/answers-20161002232505.conf'<= o:p></o:p>[ = INFO  ] Stage: Pre-termination<o:p></o:p>[ INFO  ] Stage: = Termination<o:p></o:p>[ ERROR ] Hosted Engine deployment failed    = <o:p></o:p><o:p> </o:p>Looking at the failure in the log = file..<o:p></o:p><o:p> </o:p>2016-10-02 23:25:05 WARNING = otopi.plugins.gr_he_common.core.remote_answerfile = remote_answerfile._customization:151 A = configuration<o:p></o:p>file must be supplied to deploy Hosted Engine on an = additional host.<o:p></o:p>2016-10-02 23:25:05 DEBUG = otopi.plugins.gr_he_common.core.remote_answerfile = remote_answerfile._fetch_answer_file:61 = _fetch_answer_f<o:p></o:p>ile<o:p></o:p>2016-10-02 23:25:05 DEBUG = otopi.plugins.gr_he_common.core.remote_answerfile = remote_answerfile._fetch_answer_file:69 fetching = from:<o:p></o:p>/rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91= b5-4f49-9c6b-fff45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b/7<o= :p></o:p>8cb2527-a2e2-489a-9fad-465a72221b37<o:p></o:p>2016-10-02 23:25:05 DEBUG = otopi.plugins.gr_he_common.core.remote_answerfile = heconflib._dd_pipe_tar:69 executing: 'sudo -u vdsm dd = i<o:p></o:p>f=3D/rhev/data-center/mnt/glusterSD/dcastor02:engine/0a02156= 3-91b5-4f49-9c6b-fff45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b= <o:p></o:p>/78cb2527-a2e2-489a-9fad-465a72221b37 = bs=3D4k'<o:p></o:p>2016-10-02 23:25:05 DEBUG = otopi.plugins.gr_he_common.core.remote_answerfile = heconflib._dd_pipe_tar:70 executing: 'tar -tvf = -'<o:p></o:p>2016-10-02 23:25:05 DEBUG = otopi.plugins.gr_he_common.core.remote_answerfile = heconflib._dd_pipe_tar:88 stdout:<o:p></o:p>2016-10-02 23:25:05 DEBUG = otopi.plugins.gr_he_common.core.remote_answerfile = heconflib._dd_pipe_tar:89 stderr:<o:p></o:p>2016-10-02 23:25:05 ERROR = otopi.plugins.gr_he_common.core.remote_answerfile = heconflib.validateConfImage:111 'version' is not = stored<o:p></o:p> in = the HE configuration image<o:p></o:p>2016-10-02 23:25:05 ERROR = otopi.plugins.gr_he_common.core.remote_answerfile = remote_answerfile._fetch_answer_file:73 Unable to get = t<o:p></o:p>he answer = file from the shared storage<o:p></o:p><o:p> </o:p>Looking at the detected gluster = path - = /rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91b5-4f49-9c6b-= fff45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b/<o:p></o:p></spa= n><o:p> </o:p>[root@dcasrv02 ~]# ls -al = /rhev/data-center/mnt/glusterSD/dcastor02:engine/0a021563-91b5-4f49-9c6b-= fff45e85a025/images/f055216c-02f9-4cd1-a22c-d6b56a0a8e9b/<o:p></o:p></spa= n>total = 1049609<o:p></o:p>drwxr-xr-x. 2 vdsm kvm       = 4096 Oct  2 04:46 .<o:p></o:p>drwxr-xr-x. 6 vdsm kvm       = 4096 Oct  2 04:46 ..<o:p></o:p>-rw-rw----. 1 vdsm kvm 1073741824 = Oct  2 04:46 = 78cb2527-a2e2-489a-9fad-465a72221b37<o:p></o:p>-rw-rw----. 1 vdsm = kvm    1048576 Oct  2 04:46 = 78cb2527-a2e2-489a-9fad-465a72221b37.lease<o:p></o:p>-rw-r--r--. 1 vdsm = kvm        294 Oct  2 04:46 = 78cb2527-a2e2-489a-9fad-465a72221b37.meta  <o:p></o:p><o:p> </o:p>78cb2527-a2e2-489a-9fad-465a72221b37 is  a 1 GB file, = is this the engine VM ?<o:p></o:p><o:p> </o:p>Copying the answers file form primary = (/etc/ovirt-hosted-engine/answers.conf ) to  node 2 and rerunning = produces the same error : (<o:p></o:p>(hosted-engine --deploy  = --config-append=3D/root/answers.conf )<o:p></o:p><o:p> </o:p>Also tried on node 3, same issues = <o:p></o:p><o:p> </o:p>Happy to provide logs and other = debugs<o:p></o:p><o:p> </o:p>Thanks <o:p></o:p><o:p> </o:p>Jason <o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_07BF_01D21D07.1029FF10--

4 13

libvirt-v2v error
by Saman Bandara 05 Oct '16

05 Oct '16

Dear sir, I'm getting following error while trying to convert a VMWare RHEL6 server to kvm. Please give any suggestion to resolve this. [root@kvm16 ~]# virt-v2v ic esx://10.16.32.12/?no_verify=1 -o rhev -os 10.16.32.16:/vm-images/export_domain --network rhevm "10.16.32.36-db-slcloudcontrol" virt-v2v: Failed to connect to qemu:///system: libvirt error code: 45, message: authentication failed: Failed to step SASL negotiation: -7 (SASL(-7): invalid parameter supplied: Unexpectedly missing a prompt result) -- *Saman K. Bandara,** Database Administrator* *ShipXpres Technologies (Pvt) Ltd.* 2300 Marsh Point Road, Suite 101 || Neptune Beach, FL 32266 Phone: +94 71 8135485 <%2B94%20718135485> | +94 <%2B94%20777522730>76 6014001 *Company Website <http://www.shipxpress.com/>* || *LinkedIn <http://www.linkedin.com/company/shipxpress> *|| *Facebook <https://www.facebook.com/ShipXpressInc>* || *Twitter <https://twitter.com/ShipXpressInc>*

2 1

oVirt 3.6.4 / PXE guest boot issues
by Alan Griffiths 05 Oct '16

05 Oct '16

A explanation/work-around for this issue raised back in April. It seems that if, in UCS, you configure a vNIC with a single native VLAN it will still add an 802.1q header with tag 0 - possibly to do with QoS. And this extra header prevents iPXE from parsing the DHCP response. The solution for me was to present all VLANs on a single trunked vNIC to the blade and configure VLAN tagging as per normal. The result is the tags are stripped off the packets before being passed to the VM and DHCP now works. The same issue applies to VM-FEX as packets coming off the VF will have the 802.1q header. The only solution I can see here is to configure a bridged interface for initial build of the VM and then switch to VM-FEX afterwards. I found a discussion on the iPXE mailing list about addressing the vlan 0 issue, but I could see no agreed solution. http://lists.ipxe.org/pipermail/ipxe-devel/2016-April/004901.html Alan

1 0

Re: [ovirt-users] DISCARD support?
by Nicolas Ecarnot 04 Oct '16

04 Oct '16

This is a multi-part message in MIME format. --------------DFD541D40E712C15A95C6FB1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Sending this here to share knowledge. Here is what I learned from many BZ and mailing list posts readings. I'm not working at Redhat, so please correct me if I'm wrong. We are using thin-provisioned block storage LUNs (Equallogic), on which oVirt is creating numerous Logical Volumes, and we're very happy with it. When oVirt is removing a virtual disk, the SAN is not informed, because the LVM layer is not sending the "issue_discard" flag. /etc/lvm/lvm.conf is not the natural place to try to change this parameter, as VDSM is not using it. Efforts are presently made to include issue_discard setting support directly into vdsm.conf, first on a datacenter scope (4.0.x), then per storage domain (4.1.x) and maybe via a web GUI check-box. Part of the effort is to make sure every bit of a planned to be removed LV get wiped out. Part is to inform the block storage side about the deletion, in case of thin provisioned LUNs. https://bugzilla.redhat.com/show_bug.cgi?id=1342919 https://bugzilla.redhat.com/show_bug.cgi?id=981626 -- Nicolas ECARNOT On Mon, Oct 3, 2016 at 2:24 PM, Nicolas Ecarnot <nicolas(a)ecarnot.net <mailto:nicolas@ecarnot.net>> wrote: Yaniv, As a pure random way of web surfing, I found that you posted on twitter an information about DISCARD support. (https://twitter.com/YanivKaul/status/773513216664174592 <https://twitter.com/YanivKaul/status/773513216664174592>) I did not dig any further, but has it any relation with the fact that so far, oVirt did not reclaim lost storage space amongst its logical volumes of its storage domains? A BZ exist about this, but one was told no work would be done about it until 4.x.y, so now we're there, I was wondering if you knew more? Feel free to send such questions on the mailing list (ovirt users or devel), so other will be able to both chime in and see the response. We've supported a custom hook for enabling discard per disk (which is only relevant for virtio-SCSI and IDE) for some versions now (3.5 I believe). We are planning to add this via a UI and API in 4.1. In addition, we are looking into discard (instead of wipe after delete, when discard is also zero'ing content) as well as discard when removing LVs. See: http://www.ovirt.org/develop/release-management/features/storage/pass-disca… http://www.ovirt.org/develop/release-management/features/storage/wipe-volum… http://www.ovirt.org/develop/release-management/features/storage/discard-af… Y. Best, -- Nicolas ECARNOT --------------DFD541D40E712C15A95C6FB1 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"> <div dir="ltr">Hello, Sending this here to share knowledge. Here is what I learned from many BZ and mailing list posts readings. I'm not working at Redhat, so please correct me if I'm wrong. We are using thin-provisioned block storage LUNs (Equallogic), on which oVirt is creating numerous Logical Volumes, and we're very happy with it. When oVirt is removing a virtual disk, the SAN is not informed, because the LVM layer is not sending the "issue_discard" flag. /etc/lvm/lvm.conf is not the natural place to try to change this parameter, as VDSM is not using it. Efforts are presently made to include issue_discard setting support directly into vdsm.conf, first on a datacenter scope (4.0.x), then per storage domain (4.1.x) and maybe via a web GUI check-box. Part of the effort is to make sure every bit of a planned to be removed LV get wiped out. Part is to inform the block storage side about the deletion, in case of thin provisioned LUNs. <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1342919">https://bugzilla.redhat.com/show_bug.cgi?id=1342919</a> <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=981626">https://bugzilla.redhat.com/show_bug.cgi?id=981626</a> -- Nicolas ECARNOT <div class="gmail_extra"> <div class="gmail_quote">On Mon, Oct 3, 2016 at 2:24 PM, Nicolas Ecarnot <<a href="mailto:nicolas@ecarnot.net" target="_blank">nicolas(a)ecarnot.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yaniv, As a pure random way of web surfing, I found that you posted on twitter an information about DISCARD support. (<a href="https://twitter.com/YanivKaul/status/773513216664174592" rel="noreferrer" target="_blank">https://twitter.com/YanivKaul/status/773513216664174592</a>) I did not dig any further, but has it any relation with the fact that so far, oVirt did not reclaim lost storage space amongst its logical volumes of its storage domains? A BZ exist about this, but one was told no work would be done about it until 4.x.y, so now we're there, I was wondering if you knew more? </blockquote> <div> </div> <div>Feel free to send such questions on the mailing list (ovirt users or devel), so other will be able to both chime in and see the response.</div> <div>We've supported a custom hook for enabling discard per disk (which is only relevant for virtio-SCSI and IDE) for some versions now (3.5 I believe).</div> <div>We are planning to add this via a UI and API in 4.1.</div> <div>In addition, we are looking into discard (instead of wipe after delete, when discard is also zero'ing content) as well as discard when removing LVs.</div> <div>See:</div> <div><a href="http://www.ovirt.org/develop/release-management/features/storage/pass-disca…">http://www.ovirt.org/develop/release-management/features/storage/pass-disca…</a></div> <div><a href="http://www.ovirt.org/develop/release-management/features/storage/wipe-volum…">http://www.ovirt.org/develop/release-management/features/storage/wipe-volum…</a></div> <div><a href="http://www.ovirt.org/develop/release-management/features/storage/discard-af…">http://www.ovirt.org/develop/release-management/features/storage/discard-af…</a></div> <div> </div> <div>Y.</div> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Best, -- Nicolas ECARNOT </blockquote> </div> </div> </div> </body> </html> --------------DFD541D40E712C15A95C6FB1--

3 2

Re: [ovirt-users] Migrate machines in unknown state?
by Ekin Meroğlu 04 Oct '16

04 Oct '16

Hi Yaniv, On Sun, Aug 7, 2016 at 9:37 PM, Ekin Meroğlu <ekin.meroglu(a)linuxera.com> > wrote: > >> Hi, >> >> Just a reminder, if you have power management configured, first turn that >> off for the host - when you restart vdsmd with the power management >> configured, engine finds it not responding and tries to fence (e.g. reboot) >> the host. >> > > That's not true - if it's a graceful restart, it should not happen. > Can you explain this a little more? Is there a mechanism to prevent fencing on this scenario? In two of our customers' production systems we've experienced this exact behavior (i.e. engine fencing the host while restarting vdsm service manually) for a number of times, and we were specifically advised by Red Hat Support to turn off PM before restarting service. I'd like to to know if we have a better / easier way to restart vdsm. btw, b oth of the environments were RHEV-H based RHEV 3.5 clusters, and both we were busy systems, so restarting vdsm service took quite a long time. I'm guessing this might be a factor. Regards, > > > >> >> Other than that, restarting vdsmd has been safe in my experience... >> >> Regards, >> >> On Thu, Aug 4, 2016 at 6:10 PM, Nicolás <nicolas(a)devels.es> wrote: >> >>> >>> >>> El 04/08/16 a las 15:25, Arik Hadas escribió: >>> >>>> >>>> ----- Original Message ----- >>>> >>>>> El 2016-08-04 08:24, Arik Hadas escribió: >>>>> >>>>>> ----- Original Message ----- >>>>>> >>>>>>> >>>>>>> El 04/08/16 a las 07:18, Arik Hadas escribió: >>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We're running oVirt 4.0.1 and today I found out that one of our >>>>>>>>> hosts >>>>>>>>> has all its VMs in an unknown state. I actually don't know how (and >>>>>>>>> when) did this happen, but I'd like to restore service possibly >>>>>>>>> without >>>>>>>>> turning off these machines. The host is up, the VMs are up, 'qemu' >>>>>>>>> process exists, no errors, it's just the VMs running on it that >>>>>>>>> have a >>>>>>>>> '?' where status is defined. >>>>>>>>> >>>>>>>>> Is it safe in this case to simply modify database and set those >>>>>>>>> VM's >>>>>>>>> status to 'up'? I remember having to do this a time ago when we >>>>>>>>> faced >>>>>>>>> storage issues, it didn't break anything back then. If not, is >>>>>>>>> there a >>>>>>>>> "safe" way to migrate those VMs to a different host and restart the >>>>>>>>> host >>>>>>>>> that marked them as unknown? >>>>>>>>> >>>>>>>> Hi Nicolás, >>>>>>>> >>>>>>>> I assume that the host these VMs are running on is empty in the >>>>>>>> webadmin, >>>>>>>> right? if that is the case then you've probably hit [1]. Changing >>>>>>>> their >>>>>>>> status to up is not the way to go since these VMs will not be >>>>>>>> monitored. >>>>>>>> >>>>>>> Hi Arik, >>>>>>> >>>>>>> By "empty" you mean the webadmin reports the host being running 0 >>>>>>> VMs? >>>>>>> If so, that's not the case, actually the VM count seems to be correct >>>>>>> in >>>>>>> relation to "qemu-*" processes (about 32 VMs), I can even see the >>>>>>> machines in the "Virtual machines" tab of the host, it's just they >>>>>>> are >>>>>>> all marked with the '?' mark. >>>>>>> >>>>>> No, I meant the 'Host' column in the Virtual Machines tab but if you >>>>>> see >>>>>> the VMs in the "Virtual machines" sub-tab of the host then run_on_vds >>>>>> points to the right host.. >>>>>> >>>>>> The host is up in the webadmin as well? >>>>>> Can you share the engine log? >>>>>> >>>>>> Yes, the host is up in the webadmin, there are no issues with it, just >>>>> the VMs running on it have the '?' mark. I've made 3 tests: >>>>> >>>>> 1) Restart engine: did not help >>>>> 2) Check firewall, seems to be ok. >>>>> 2) PostgreSQL: UPDATE vm_dynamic SET status = 1 WHERE status = 8; : >>>>> After a while, I see lots of entries like this: >>>>> >>>>> 2016-08-04 09:23:10,910 WARN >>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >>>>> (DefaultQuartzScheduler4) [6ad135b8] Correlation ID: null, Call Stack: >>>>> null, Custom Event ID: -1, Message: VM xxx is not responding. >>>>> >>>>> I'm attaching the engine log, but I don't know when did this happen for >>>>> the first time, though. If there's a manual way/command to migrate VMs >>>>> to a different host I'd appreciate a hint about it. >>>>> >>>>> Is it safe to restart vdsmd on this host? >>>>> >>>> The engine log looks fine - the VMs are reported as not-responding for >>>> some reason. I would restart libvirtd and vdsmd then >>>> >>> >>> Is restarting those two daemons safe? I mean, will that stop all qemu-* >>> processes, so the VMs marked as unknown will stop? >>> >>> >>> Thanks. >>>>> >>>>> Thanks. >>>>>>> >>>>>>> Yes, there is no other way to resolve it other than changing the DB >>>>>>>> but >>>>>>>> the change should be to update run_on_vds field of these VMs to the >>>>>>>> host >>>>>>>> you know they are running on. Their status will then be updates in >>>>>>>> 15 >>>>>>>> sec. >>>>>>>> >>>>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1354494 >>>>>>>> >>>>>>>> Arik. >>>>>>>> >>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Nicolás >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users(a)ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>>> >>>>>>>>> >>>>>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> >> >> -- >> *Ekin Meroğlu** Red Hat Certified Architect* >> >> linuxera Özgür Yazılım Çözüm ve Hizmetleri >> *T* +90 (850) 22 LINUX | *GSM* +90 (532) 137 77 04 >> www.linuxera.com | bilgi(a)linuxera.com >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > -- *Ekin Meroğlu** Red Hat Certified Architect* linuxera Özgür Yazılım Çözüm ve Hizmetleri *T* +90 (850) 22 LINUX | *GSM* +90 (532) 137 77 04 www.linuxera.com | bilgi(a)linuxera.com

2 3

oVirt 4.0.4 and Active Directory Kerberos SSO for Administration/User Portal. Troubleshooting
by aleksey.maksimov＠it-kb.ru 04 Oct '16

04 Oct '16

Hello oVirt guru`s! I set up oVirt integration with Active Directory LDAP according to the manual: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualiza… I created a profile integration with my domain. All is working well. Now I'm trying to configure single sign-on for portals based on Kerberos. All settings are performed according to the manual: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualiza… Kerberos client tested and working. However, SSO is not working. Please tell me how to find the cause of the problem. What are the steps to troubleshooting to do?

3 15

Ovirt 4.04 unable to umount LUNs on hosts
by Andrea Ghelardi 04 Oct '16

04 Oct '16

--_004_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_ Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_" --_000_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello ovirt gurus, I'd like to bother you with a long lasting issue I face. My (new) test setup (not production one) is running ovirt 4.04 hosted engin= e on a Dell R510 server connected to SAN Compellent SC040 via iscsi. All systems installed from scratch following guidelines. Ovirt hosted engine installed using ovirt-appliance. Everything is working "fine". BUT We are unable to perform a clear LUN removal. We can perform all actions from web interface (storage add, maintenance, de= tach, delete) with no error. However, underlying device remains mapped to server. As a result, we are un= able to unmap the LUN otherwise multipath fails, server fails, ovirt fails = etc. Steps to reproduce: 1) Create LUN on SAN, map it to server -> OK 2) Log in ovirt web interface, add a new storage targeting LUN -> OK 3) Create disk, create VM setup VM, (optional) -> OK 4) Shutdown VM -> OK 5) Ovirt: Put storage in maintenance -> OK 6) Ovirt: Detach storage -> OK 7) Ovirt: Delete storage -> OK Expected result: Ovirt unmaps and remove device from multipath so that it can be destroyed a= t SAN storage level. It should be possible to perform this action even when host is not in maint= enance. Current result: volume remain locked in multipath (map in use). Trying vgchange -a n <DEVICE> and then multipath -f <DEVICE> removes device= , but then it is automatically re-added after a while (???) Please note: this is the same behavior we always faced also with our ovirt = production environment. Details attached. Volume to be removed: LUN 000064 Any ideas? Thanks AG --_000_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_ 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"> Hello ovirt gurus,<o:p></o:p> I’d like to bother you with a long lasting iss= ue I face.<o:p></o:p> My (new) test setup (not production one) is running = ovirt 4.04 hosted engine on a Dell R510 server connected to SAN Compellent = SC040 via iscsi.<o:p></o:p> All systems installed from scratch following guideli= nes.<o:p></o:p> Ovirt hosted engine installed using ovirt-appliance.= <o:p></o:p> Everything is working “fine”.<o:p></o:p>= BUT<o:p></o:p> We are unable to perform a clear LUN removal.<o:p></= o:p> We can perform all actions from web interface (stora= ge add, maintenance, detach, delete) with no error.<o:p></o:p> However, underlying device remains mapped to server.= As a result, we are unable to unmap the LUN otherwise multipath fails, ser= ver fails, ovirt fails etc.<o:p></o:p> <o:p> </o:p> Steps to reproduce:<o:p></o:p> <![if !supportLists]>1)      <![endif]>Create LUN on SAN, map it to server -> OK<o:p></= o:p> <![if !supportLists]>2)      <![endif]>Log in ovirt web interface, add a new storage targe= ting LUN -> OK<o:p></o:p> <![if !supportLists]>3)      <![endif]>Create disk, create VM setup VM, (optional) -> O= K<o:p></o:p> <![if !supportLists]>4)      <![endif]>Shutdown VM -> OK<o:p></o:p> <![if !supportLists]>5)      <![endif]>Ovirt: Put storage in maintenance -> OK<o:p></o:= p> <![if !supportLists]>6)      <![endif]>Ovirt: Detach storage -> OK<o:p></o:p> <![if !supportLists]>7)      <![endif]>Ovirt: Delete storage -> OK<o:p></o:p> <o:p> </o:p> Expected result:<o:p></o:p> Ovirt unmaps and remove device from multipath so tha= t it can be destroyed at SAN storage level.<o:p></o:p> It should be possible to perform this action even wh= en host is not in maintenance.<o:p></o:p> <o:p> </o:p> Current result: volume remain locked in multipath (m= ap in use).<o:p></o:p> Trying vgchange -a n <DEVICE> and then multipa= th -f <DEVICE> removes device, but then it is automatically re-added = after a while (???)<o:p></o:p> <o:p> </o:p> Please note: this is the same behavior we always fac= ed also with our ovirt production environment.<o:p></o:p> Details attached. Volume to be removed: LUN 000064<o= :p></o:p> <o:p> </o:p> Any ideas?<o:p></o:p> Thanks<o:p></o:p> AG<o:p></o:p> </div> </body> </html> --_000_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_-- --_004_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_ Content-Type: text/plain; name="ovirt-multipath.txt" Content-Description: ovirt-multipath.txt Content-Disposition: attachment; filename="ovirt-multipath.txt"; size=17919; creation-date="Tue, 04 Oct 2016 13:16:00 GMT"; modification-date="Tue, 04 Oct 2016 13:16:00 GMT" Content-Transfer-Encoding: base64 W3Jvb3RAYmFyYmVyYSBsb2ddIyBtdWx0aXBhdGggLWxsDQozNjAwMGQzMTAwMDRlZGMwMDAwMDAw MDAwMDAwMDAwNjQgZG0tMCBDT01QRUxOVCxDb21wZWxsZW50IFZvbA0Kc2l6ZT0xMDBHIGZlYXR1 cmVzPScwJyBod2hhbmRsZXI9JzAnIHdwPXJ3DQpgLSstIHBvbGljeT0nc2VydmljZS10aW1lIDAn IHByaW89MSBzdGF0dXM9YWN0aXZlDQogIHwtIDE4OjA6MDoyIHNkayAgODoxNjAgIGFjdGl2ZSBy ZWFkeSBydW5uaW5nDQogIHwtIDE5OjA6MDoyIHNkbSAgODoxOTIgIGFjdGl2ZSByZWFkeSBydW5u aW5nDQogIHwtIDIyOjA6MDoyIHNkcSAgNjU6MCAgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwt IDIzOjA6MDoyIHNkcyAgNjU6MzIgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDI0OjA6MDoy IHNkdSAgNjU6NjQgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDI4OjA6MDoyIHNkYWEgNjU6 MTYwIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDI5OjA6MDoyIHNkYWIgNjU6MTc2IGFjdGl2 ZSByZWFkeSBydW5uaW5nDQogIHwtIDU6MDowOjIgIHNkYyAgODozMiAgIGFjdGl2ZSByZWFkeSBy dW5uaW5nDQogIGAtIDY6MDowOjIgIHNkZyAgODo5NiAgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQoz NjAwMGQzMTAwMDRlZGMwMDAwMDAwMDAwMDAwMDAwNjIgZG0tMSBDT01QRUxOVCxDb21wZWxsZW50 IFZvbA0Kc2l6ZT0xLjBUIGZlYXR1cmVzPScwJyBod2hhbmRsZXI9JzAnIHdwPXJ3DQpgLSstIHBv bGljeT0nc2VydmljZS10aW1lIDAnIHByaW89MSBzdGF0dXM9YWN0aXZlDQogIHwtIDU6MDowOjEg IHNkYiAgODoxNiAgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDY6MDowOjEgIHNkZCAgODo0 OCAgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDE5OjA6MDoxIHNkbCAgODoxNzYgIGFjdGl2 ZSByZWFkeSBydW5uaW5nDQogIHwtIDE4OjA6MDoxIHNkaiAgODoxNDQgIGFjdGl2ZSByZWFkeSBy dW5uaW5nDQogIHwtIDIyOjA6MDoxIHNkcCAgODoyNDAgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQog IHwtIDIzOjA6MDoxIHNkciAgNjU6MTYgIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDI0OjA6 MDoxIHNkdCAgNjU6NDggIGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIHwtIDI5OjA6MDoxIHNkeiAg NjU6MTQ0IGFjdGl2ZSByZWFkeSBydW5uaW5nDQogIGAtIDI4OjA6MDoxIHNkeSAgNjU6MTI4IGFj dGl2ZSByZWFkeSBydW5uaW5nDQozNjAwMGQzMTAwMDRlZGMwMDAwMDAwMDAwMDAwMDAwNjEgZG0t MTkgQ09NUEVMTlQsQ29tcGVsbGVudCBWb2wNCnNpemU9MTIwRyBmZWF0dXJlcz0nMCcgaHdoYW5k bGVyPScwJyB3cD1ydw0KYC0rLSBwb2xpY3k9J3NlcnZpY2UtdGltZSAwJyBwcmlvPTEgc3RhdHVz PWFjdGl2ZQ0KICB8LSA4OjA6MDoxICBzZGYgIDg6ODAgICBhY3RpdmUgcmVhZHkgcnVubmluZw0K ICB8LSA3OjA6MDoxICBzZGUgIDg6NjQgICBhY3RpdmUgcmVhZHkgcnVubmluZw0KICB8LSAxMTow OjA6MSBzZGggIDg6MTEyICBhY3RpdmUgcmVhZHkgcnVubmluZw0KICB8LSAxMjowOjA6MSBzZGkg IDg6MTI4ICBhY3RpdmUgcmVhZHkgcnVubmluZw0KICB8LSAyMDowOjA6MSBzZG4gIDg6MjA4ICBh Y3RpdmUgcmVhZHkgcnVubmluZw0KICB8LSAyMTowOjA6MSBzZG8gIDg6MjI0ICBhY3RpdmUgcmVh ZHkgcnVubmluZw0KICB8LSAyNTowOjA6MSBzZHYgIDY1OjgwICBhY3RpdmUgcmVhZHkgcnVubmlu Zw0KICB8LSAyNjowOjA6MSBzZHcgIDY1Ojk2ICBhY3RpdmUgcmVhZHkgcnVubmluZw0KICBgLSAy NzowOjA6MSBzZHggIDY1OjExMiBhY3RpdmUgcmVhZHkgcnVubmluZw0KW3Jvb3RAYmFyYmVyYSBs b2ddIw0KW3Jvb3RAYmFyYmVyYSBsb2ddIyBsc3Njc2kNClswOjA6MDowXSAgICBkaXNrICAgIFNF QUdBVEUgIFNUMzMwMDY1N1NTICAgICAgRVM2NiAgLQ0KWzA6MDoxOjBdICAgIGRpc2sgICAgU0VB R0FURSAgU1QzMzAwNjU3U1MgICAgICBFUzY2ICAtDQpbMDoxOjA6MF0gICAgZGlzayAgICBEZWxs ICAgICBWaXJ0dWFsIERpc2sgICAgIDEwMjggIC9kZXYvc2RhDQpbMzowOjA6MF0gICAgY2QvZHZk ICBQTERTICAgICBEVkQrLVJXIERTLThBOFNIIEtENTEgIC9kZXYvc3IwDQpbNTowOjA6MV0gICAg ZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RiDQpbNTowOjA6 Ml0gICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RjDQpb NjowOjA6MV0gICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYv c2RkDQpbNjowOjA6Ml0gICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYg IC9kZXYvc2RnDQpbNzowOjA6MV0gICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAg IDA2MDYgIC9kZXYvc2RlDQpbODowOjA6MV0gICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50 IFZvbCAgIDA2MDYgIC9kZXYvc2RmDQpbMTE6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21w ZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RoDQpbMTI6MDowOjFdICAgZGlzayAgICBDT01QRUxO VCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RpDQpbMTg6MDowOjFdICAgZGlzayAgICBD T01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RqDQpbMTg6MDowOjJdICAgZGlz ayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RrDQpbMTk6MDowOjFd ICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RsDQpbMTk6 MDowOjJdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2Rt DQpbMjA6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9k ZXYvc2RuDQpbMjE6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2 MDYgIC9kZXYvc2RvDQpbMjI6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZv bCAgIDA2MDYgIC9kZXYvc2RwDQpbMjI6MDowOjJdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxs ZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RxDQpbMjM6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBD b21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RyDQpbMjM6MDowOjJdICAgZGlzayAgICBDT01Q RUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2RzDQpbMjQ6MDowOjFdICAgZGlzayAg ICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2R0DQpbMjQ6MDowOjJdICAg ZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2R1DQpbMjU6MDow OjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYvc2R2DQpb MjY6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYgIC9kZXYv c2R3DQpbMjc6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAgIDA2MDYg IC9kZXYvc2R4DQpbMjg6MDowOjFdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50IFZvbCAg IDA2MDYgIC9kZXYvc2R5DQpbMjg6MDowOjJdICAgZGlzayAgICBDT01QRUxOVCBDb21wZWxsZW50 IFZvbCAgIDA2MDYgIC9kZXYvc2RhYQ0KWzI5OjA6MDoxXSAgIGRpc2sgICAgQ09NUEVMTlQgQ29t cGVsbGVudCBWb2wgICAwNjA2ICAvZGV2L3Nkeg0KWzI5OjA6MDoyXSAgIGRpc2sgICAgQ09NUEVM TlQgQ29tcGVsbGVudCBWb2wgICAwNjA2ICAvZGV2L3NkYWINCltyb290QGJhcmJlcmEgbG9nXSMN Cltyb290QGJhcmJlcmEgbG9nXSMgdmdzDQogIFZHICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAjUFYgI0xWICNTTiBBdHRyICAgVlNpemUgICAgVkZyZWUNCiAgNDA5MDc0NjItNWI1 OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5ICAgMSAgIDkgICAwIHd6LS1uLSAgIDk5LjYyZyAgIDM1 LjUwZw0KICA0ZTRhZmIyZi0yYzg2LTQ0ZWUtOTBlZC01ODIyMDY2NGM4YzQgICAxICAxMiAgIDAg d3otLW4tICAxMTkuNjJnICAxMDQuMjVnDQogIDYyZDhjZmRkLWVlODAtNDE1Yi1iMmMzLWE3ZTZi ZGEwZGQ5NyAgIDEgICA4ICAgMCB3ei0tbi0gMTAyMy42MmcgMTAxOS41MGcNCltyb290QGJhcmJl cmEgbG9nXSMgbHZzDQogIExWICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWRyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXR0ciAgICAgICBMU2l6ZSAgIFBvb2wg T3JpZ2luIERhdGElICBNZXRhJSAgTW92ZSBMb2cgQ3B5JVN5bmMgQ29udmVydA0KICAzOTdjMGY0 MC1lZDcwLTQ2NzAtYWY4OS01NWMzNWRlOTI5ZDYgNDA5MDc0NjItNWI1OC00MGMyLWFkZTctMzAz MWM4YTAxOTQ5IC13aS1hLS0tLS0gMTI4LjAwbQ0KICBhYWMzMmNmOS1hZjBkLTQyYzQtODRmNy02 YzYyZmE2MmYyM2MgNDA5MDc0NjItNWI1OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5IC13aS1hLS0t LS0gIDYwLjAwZw0KICBkNTA2NWNjZC1jNTZhLTQyYmItYWNjZC02ZTA5YzhhNDRlYmUgNDA5MDc0 NjItNWI1OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5IC13aS1hLS0tLS0gMTI4LjAwbQ0KICBpZHMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDA5MDc0NjItNWI1OC00MGMyLWFkZTct MzAzMWM4YTAxOTQ5IC13aS1hLS0tLS0gMTI4LjAwbQ0KICBpbmJveCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgNDA5MDc0NjItNWI1OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5IC13aS1h LS0tLS0gMTI4LjAwbQ0KICBsZWFzZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDA5 MDc0NjItNWI1OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5IC13aS1hLS0tLS0gICAyLjAwZw0KICBt YXN0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNDA5MDc0NjItNWI1OC00MGMyLWFk ZTctMzAzMWM4YTAxOTQ5IC13aS1hLS0tLS0gICAxLjAwZw0KICBtZXRhZGF0YSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgNDA5MDc0NjItNWI1OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5IC13 aS1hLS0tLS0gNTEyLjAwbQ0KICBvdXRib3ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg NDA5MDc0NjItNWI1OC00MGMyLWFkZTctMzAzMWM4YTAxOTQ5IC13aS1hLS0tLS0gMTI4LjAwbQ0K ICAxMmI2YjJmMC0xMTFjLTQ0MWYtYmE4NS0yMDk5NmEwNDkzNzggNGU0YWZiMmYtMmM4Ni00NGVl LTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0tLS0gICAxLjAwZw0KICAzMjQwZTFmNC1mMTZiLTQ3 NmEtODBlYS1lYzRmMTRiZGFiODUgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0 IC13aS1hby0tLS0gMTI4LjAwbQ0KICA3YTY1ZTBlMi0wNWY1LTQwYmYtOWE0MC0wOWFjNTBhYjA2 NzMgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0tLS0gMTI4LjAw bQ0KICA5ZDFlZDNmZC1kNmVmLTRiYmMtYjIyMi03Njg3MTM0YjhmYzMgNGU0YWZiMmYtMmM4Ni00 NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0tLS0gMTI4LjAwbQ0KICBiODUxMDc3Yi0yZjJk LTQ5NzAtYjQzMy00MjdjYWQ3OTZkNDYgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRj OGM0IC13aS1hby0tLS0gIDEwLjAwZw0KICBlY2M0N2U3OC1iMDUyLTQwZmYtOGVhZi00MTQ1YjQx ZGY4NTEgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0tLS0gMTI4 LjAwbQ0KICBpZHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNGU0YWZiMmYtMmM4 Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hby0tLS0gMTI4LjAwbQ0KICBpbmJveCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2 NjRjOGM0IC13aS1hLS0tLS0gMTI4LjAwbQ0KICBsZWFzZXMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0tLS0g ICAyLjAwZw0KICBtYXN0ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNGU0YWZiMmYt MmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0tLS0gICAxLjAwZw0KICBtZXRhZGF0 YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgy MjA2NjRjOGM0IC13aS1hLS0tLS0gNTEyLjAwbQ0KICBvdXRib3ggICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgNGU0YWZiMmYtMmM4Ni00NGVlLTkwZWQtNTgyMjA2NjRjOGM0IC13aS1hLS0t LS0gMTI4LjAwbQ0KICA0Mjg3ZjRhYy1jNmM0LTQ0NDUtYWU0ZC0xOGI5ZTg3OTFkYjYgNjJkOGNm ZGQtZWU4MC00MTViLWIyYzMtYTdlNmJkYTBkZDk3IC13aS0tLS0tLS0gMTI4LjAwbQ0KICA4ZjVi OTBlNy1mMWIzLTQ3OWEtODNhZS04Y2JhMDM4NDlmOGUgNjJkOGNmZGQtZWU4MC00MTViLWIyYzMt YTdlNmJkYTBkZDk3IC13aS0tLS0tLS0gMTI4LjAwbQ0KICBpZHMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgNjJkOGNmZGQtZWU4MC00MTViLWIyYzMtYTdlNmJkYTBkZDk3IC13aS1h by0tLS0gMTI4LjAwbQ0KICBpbmJveCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNjJk OGNmZGQtZWU4MC00MTViLWIyYzMtYTdlNmJkYTBkZDk3IC13aS1hLS0tLS0gMTI4LjAwbQ0KICBs ZWFzZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNjJkOGNmZGQtZWU4MC00MTViLWIy YzMtYTdlNmJkYTBkZDk3IC13aS1hLS0tLS0gICAyLjAwZw0KICBtYXN0ZXIgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgNjJkOGNmZGQtZWU4MC00MTViLWIyYzMtYTdlNmJkYTBkZDk3IC13 aS1hby0tLS0gICAxLjAwZw0KICBtZXRhZGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg NjJkOGNmZGQtZWU4MC00MTViLWIyYzMtYTdlNmJkYTBkZDk3IC13aS1hLS0tLS0gNTEyLjAwbQ0K ICBvdXRib3ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNjJkOGNmZGQtZWU4MC00MTVi LWIyYzMtYTdlNmJkYTBkZDk3IC13aS1hLS0tLS0gMTI4LjAwbQ0KW3Jvb3RAYmFyYmVyYSBsb2dd Iw0KW3Jvb3RAYmFyYmVyYSBsb2ddIyBkbXNldHVwIGluZm8NCk5hbWU6ICAgICAgICAgICAgICA0 ZTRhZmIyZi0tMmM4Ni0tNDRlZS0tOTBlZC0tNTgyMjA2NjRjOGM0LTMyNDBlMWY0LS1mMTZiLS00 NzZhLS04MGVhLS1lYzRmMTRiZGFiODUNClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQg QWhlYWQ6ICAgICAgICA4MTkyDQpUYWJsZXMgcHJlc2VudDogICAgTElWRQ0KT3BlbiBjb3VudDog ICAgICAgIDENCkV2ZW50IG51bWJlcjogICAgICAwDQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAy Ng0KTnVtYmVyIG9mIHRhcmdldHM6IDENClVVSUQ6IExWTS1raEJNdTIxUjFwdDRLZFVIY1RJUVFq S0FJWFZFcTNWeEdMYThNeFhMakdacmlWekl3WmloOG5WRzN3YnlmMGpuDQoNCk5hbWU6ICAgICAg ICAgICAgICA2MmQ4Y2ZkZC0tZWU4MC0tNDE1Yi0tYjJjMy0tYTdlNmJkYTBkZDk3LWxlYXNlcw0K U3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDogICAgICAgIDgxOTINClRhYmxl cyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMA0KRXZlbnQgbnVtYmVyOiAg ICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDEzDQpOdW1iZXIgb2YgdGFyZ2V0czogMQ0K VVVJRDogTFZNLWN6aUw4aFI2UEpjdVZJbkRuUHhFbzBlQlpJaFdCUkwyN2cyR0c2N1AwTmZZOUUw OWhoajFoWHVLZkJxUWpJYjMNCg0KTmFtZTogICAgICAgICAgICAgIDRlNGFmYjJmLS0yYzg2LS00 NGVlLS05MGVkLS01ODIyMDY2NGM4YzQtYjg1MTA3N2ItLTJmMmQtLTQ5NzAtLWI0MzMtLTQyN2Nh ZDc5NmQ0Ng0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDogICAgICAgIDgx OTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMQ0KRXZlbnQg bnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDE4DQpOdW1iZXIgb2YgdGFy Z2V0czogMQ0KVVVJRDogTFZNLWtoQk11MjFSMXB0NEtkVUhjVElRUWpLQUlYVkVxM1Z4RzhEUkg1 NjZwUGx6MExhcjZVdUxTem9UYU5vTUpBSXoNCg0KTmFtZTogICAgICAgICAgICAgIDRlNGFmYjJm LS0yYzg2LS00NGVlLS05MGVkLS01ODIyMDY2NGM4YzQtZWNjNDdlNzgtLWIwNTItLTQwZmYtLThl YWYtLTQxNDViNDFkZjg1MQ0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDog ICAgICAgIDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAg MA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDkNCk51bWJl ciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0ta2hCTXUyMVIxcHQ0S2RVSGNUSVFRaktBSVhWRXEz VnhxdVdWM0RPdHRNMkQwbGd5WGdZZUhORzhiY0NlT29UTw0KDQpOYW1lOiAgICAgICAgICAgICAg NDA5MDc0NjItLTViNTgtLTQwYzItLWFkZTctLTMwMzFjOGEwMTk0OS1tZXRhZGF0YQ0KU3RhdGU6 ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDogICAgICAgIDI1Ng0KVGFibGVzIHByZXNl bnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAwDQpFdmVudCBudW1iZXI6ICAgICAgMA0K TWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMg0KTnVtYmVyIG9mIHRhcmdldHM6IDENClVVSUQ6IExW TS1OalJIVnNRd0hOcmxyUE1wc0FleXBoU2xHdUpEWjc2TFd2WHlKaWpPMTRCcVpwUDE5Vloya20w UmZHVVZKcUtMDQoNCk5hbWU6ICAgICAgICAgICAgICA0ZTRhZmIyZi0tMmM4Ni0tNDRlZS0tOTBl ZC0tNTgyMjA2NjRjOGM0LTEyYjZiMmYwLS0xMTFjLS00NDFmLS1iYTg1LS0yMDk5NmEwNDkzNzgN ClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAgICAgICA4MTkyDQpUYWJs ZXMgcHJlc2VudDogICAgTElWRQ0KT3BlbiBjb3VudDogICAgICAgIDANCkV2ZW50IG51bWJlcjog ICAgICAwDQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAxNw0KTnVtYmVyIG9mIHRhcmdldHM6IDEN ClVVSUQ6IExWTS1raEJNdTIxUjFwdDRLZFVIY1RJUVFqS0FJWFZFcTNWeEx3cTNmMnNFbmdXeTMx b1R4ajJyZjlCMWFYbWhCSzhoDQoNCk5hbWU6ICAgICAgICAgICAgICA0MDkwNzQ2Mi0tNWI1OC0t NDBjMi0tYWRlNy0tMzAzMWM4YTAxOTQ5LWxlYXNlcw0KU3RhdGU6ICAgICAgICAgICAgIEFDVElW RQ0KUmVhZCBBaGVhZDogICAgICAgIDI1Ng0KVGFibGVzIHByZXNlbnQ6ICAgIExJVkUNCk9wZW4g Y291bnQ6ICAgICAgICAwDQpFdmVudCBudW1iZXI6ICAgICAgMA0KTWFqb3IsIG1pbm9yOiAgICAg IDI1MywgNA0KTnVtYmVyIG9mIHRhcmdldHM6IDENClVVSUQ6IExWTS1OalJIVnNRd0hOcmxyUE1w c0FleXBoU2xHdUpEWjc2TERGWmgzZHRNWUwyVk1STFFtN0hNd0FsNDNrOE9tTUZvDQoNCk5hbWU6 ICAgICAgICAgICAgICA2MmQ4Y2ZkZC0tZWU4MC0tNDE1Yi0tYjJjMy0tYTdlNmJkYTBkZDk3LW1l dGFkYXRhDQpTdGF0ZTogICAgICAgICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAgICAgICAgODE5 Mg0KVGFibGVzIHByZXNlbnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAwDQpFdmVudCBu dW1iZXI6ICAgICAgMA0KTWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMTENCk51bWJlciBvZiB0YXJn ZXRzOiAxDQpVVUlEOiBMVk0tY3ppTDhoUjZQSmN1VkluRG5QeEVvMGVCWkloV0JSTDJRVGhHcHRR T0VTR2Fmdm1ybGozOXl5WlhTdFlFTzBSbQ0KDQpOYW1lOiAgICAgICAgICAgICAgNGU0YWZiMmYt LTJjODYtLTQ0ZWUtLTkwZWQtLTU4MjIwNjY0YzhjNC03YTY1ZTBlMi0tMDVmNS0tNDBiZi0tOWE0 MC0tMDlhYzUwYWIwNjczDQpTdGF0ZTogICAgICAgICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAg ICAgICAgODE5Mg0KVGFibGVzIHByZXNlbnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAw DQpFdmVudCBudW1iZXI6ICAgICAgMA0KTWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMTANCk51bWJl ciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0ta2hCTXUyMVIxcHQ0S2RVSGNUSVFRaktBSVhWRXEz VnhTM0dzYXY2YXBPeW1FRFNZa0xwUUVrQlFYM3g4VDExVg0KDQpOYW1lOiAgICAgICAgICAgICAg MzYwMDBkMzEwMDA0ZWRjMDAwMDAwMDAwMDAwMDAwMDY0DQpTdGF0ZTogICAgICAgICAgICAgQUNU SVZFDQpSZWFkIEFoZWFkOiAgICAgICAgMjU2DQpUYWJsZXMgcHJlc2VudDogICAgTElWRQ0KT3Bl biBjb3VudDogICAgICAgIDkNCkV2ZW50IG51bWJlcjogICAgICAxDQpNYWpvciwgbWlub3I6ICAg ICAgMjUzLCAwDQpOdW1iZXIgb2YgdGFyZ2V0czogMQ0KVVVJRDogbXBhdGgtMzYwMDBkMzEwMDA0 ZWRjMDAwMDAwMDAwMDAwMDAwMDY0DQoNCk5hbWU6ICAgICAgICAgICAgICA0MDkwNzQ2Mi0tNWI1 OC0tNDBjMi0tYWRlNy0tMzAzMWM4YTAxOTQ5LWQ1MDY1Y2NkLS1jNTZhLS00MmJiLS1hY2NkLS02 ZTA5YzhhNDRlYmUNClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAgICAg ICAyNTYNClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMA0KRXZl bnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDI5DQpOdW1iZXIgb2Yg dGFyZ2V0czogMQ0KVVVJRDogTFZNLU5qUkhWc1F3SE5ybHJQTXBzQWV5cGhTbEd1SkRaNzZMaUIy QlNmRFh4RmdUa1Y3bDNocU1zb0xLeGpUMll2WEkNCg0KTmFtZTogICAgICAgICAgICAgIDYyZDhj ZmRkLS1lZTgwLS00MTViLS1iMmMzLS1hN2U2YmRhMGRkOTctbWFzdGVyDQpTdGF0ZTogICAgICAg ICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAgICAgICAgODE5Mg0KVGFibGVzIHByZXNlbnQ6ICAg IExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAxDQpFdmVudCBudW1iZXI6ICAgICAgMA0KTWFqb3Is IG1pbm9yOiAgICAgIDI1MywgMTYNCk51bWJlciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0tY3pp TDhoUjZQSmN1VkluRG5QeEVvMGVCWkloV0JSTDJ2eWJHU1dGY1pJOTVaMjY4VVVGMTVBMGp4Y2dO VzZMUg0KDQpOYW1lOiAgICAgICAgICAgICAgNjJkOGNmZGQtLWVlODAtLTQxNWItLWIyYzMtLWE3 ZTZiZGEwZGQ5Ny1pZHMNClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAg ICAgICA4MTkyDQpUYWJsZXMgcHJlc2VudDogICAgTElWRQ0KT3BlbiBjb3VudDogICAgICAgIDEN CkV2ZW50IG51bWJlcjogICAgICAwDQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAxNA0KTnVtYmVy IG9mIHRhcmdldHM6IDENClVVSUQ6IExWTS1jemlMOGhSNlBKY3VWSW5EblB4RW8wZUJaSWhXQlJM MmwzSTlOOFFyYW81cnkyTUdHM0xoVU9XRmYxM2s3VnFMDQoNCk5hbWU6ICAgICAgICAgICAgICA0 ZTRhZmIyZi0tMmM4Ni0tNDRlZS0tOTBlZC0tNTgyMjA2NjRjOGM0LW1ldGFkYXRhDQpTdGF0ZTog ICAgICAgICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAgICAgICAgODE5Mg0KVGFibGVzIHByZXNl bnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAwDQpFdmVudCBudW1iZXI6ICAgICAgMA0K TWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMjANCk51bWJlciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBM Vk0ta2hCTXUyMVIxcHQ0S2RVSGNUSVFRaktBSVhWRXEzVnh0Q2RnQ2Y2c1hNVWtWQTAxYTNHTEVT QVYzMjNqR2xHdA0KDQpOYW1lOiAgICAgICAgICAgICAgNDA5MDc0NjItLTViNTgtLTQwYzItLWFk ZTctLTMwMzFjOGEwMTk0OS1tYXN0ZXINClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQg QWhlYWQ6ICAgICAgICAyNTYNClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAg ICAgICAgMA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDcN Ck51bWJlciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0tTmpSSFZzUXdITnJsclBNcHNBZXlwaFNs R3VKRFo3Nkw1QjlDbmFjck1oOWZONzNNTzBtV0ZBV25mWm5NZnJJdg0KDQpOYW1lOiAgICAgICAg ICAgICAgNjJkOGNmZGQtLWVlODAtLTQxNWItLWIyYzMtLWE3ZTZiZGEwZGQ5Ny1vdXRib3gNClN0 YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAgICAgICA4MTkyDQpUYWJsZXMg cHJlc2VudDogICAgTElWRQ0KT3BlbiBjb3VudDogICAgICAgIDANCkV2ZW50IG51bWJlcjogICAg ICAwDQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAxMg0KTnVtYmVyIG9mIHRhcmdldHM6IDENClVV SUQ6IExWTS1jemlMOGhSNlBKY3VWSW5EblB4RW8wZUJaSWhXQlJMMllUZ2RDNzljdjhuRWdEVGpn bDQyRW9JcXpuUEIwemxtDQoNCk5hbWU6ICAgICAgICAgICAgICAzNjAwMGQzMTAwMDRlZGMwMDAw MDAwMDAwMDAwMDAwNjINClN0YXRlOiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAg ICAgICA4MTkyDQpUYWJsZXMgcHJlc2VudDogICAgTElWRQ0KT3BlbiBjb3VudDogICAgICAgIDYN CkV2ZW50IG51bWJlcjogICAgICAwDQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAxDQpOdW1iZXIg b2YgdGFyZ2V0czogMQ0KVVVJRDogbXBhdGgtMzYwMDBkMzEwMDA0ZWRjMDAwMDAwMDAwMDAwMDAw MDYyDQoNCk5hbWU6ICAgICAgICAgICAgICA0ZTRhZmIyZi0tMmM4Ni0tNDRlZS0tOTBlZC0tNTgy MjA2NjRjOGM0LWxlYXNlcw0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDog ICAgICAgIDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAg MA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDIyDQpOdW1i ZXIgb2YgdGFyZ2V0czogMQ0KVVVJRDogTFZNLWtoQk11MjFSMXB0NEtkVUhjVElRUWpLQUlYVkVx M1Z4SDN5ZUxsMmZmMnE1c2FPRTVaaDUwVnhMSjF4dktqbngNCg0KTmFtZTogICAgICAgICAgICAg IDQwOTA3NDYyLS01YjU4LS00MGMyLS1hZGU3LS0zMDMxYzhhMDE5NDktaW5ib3gNClN0YXRlOiAg ICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAgICAgICAyNTYNClRhYmxlcyBwcmVzZW50 OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1h am9yLCBtaW5vcjogICAgICAyNTMsIDYNCk51bWJlciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0t TmpSSFZzUXdITnJsclBNcHNBZXlwaFNsR3VKRFo3NkxkZndWaG53T24zakt1endQekZ6M1lEODlJ VGlMZkVTUA0KDQpOYW1lOiAgICAgICAgICAgICAgNjJkOGNmZGQtLWVlODAtLTQxNWItLWIyYzMt LWE3ZTZiZGEwZGQ5Ny1pbmJveA0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVh ZDogICAgICAgIDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAg ICAgMA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDE1DQpO dW1iZXIgb2YgdGFyZ2V0czogMQ0KVVVJRDogTFZNLWN6aUw4aFI2UEpjdVZJbkRuUHhFbzBlQlpJ aFdCUkwyZGNCOWFWWlVJWUVGZFRFeWNEWjZkekZVS0FaT0lMcjANCg0KTmFtZTogICAgICAgICAg ICAgIDQwOTA3NDYyLS01YjU4LS00MGMyLS1hZGU3LS0zMDMxYzhhMDE5NDktb3V0Ym94DQpTdGF0 ZTogICAgICAgICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAgICAgICAgMjU2DQpUYWJsZXMgcHJl c2VudDogICAgTElWRQ0KT3BlbiBjb3VudDogICAgICAgIDANCkV2ZW50IG51bWJlcjogICAgICAw DQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAzDQpOdW1iZXIgb2YgdGFyZ2V0czogMQ0KVVVJRDog TFZNLU5qUkhWc1F3SE5ybHJQTXBzQWV5cGhTbEd1SkRaNzZMeTdCOWhZNUN2MVIzT1pNQnZ2ZE9l SlltamZWcVRPWUENCg0KTmFtZTogICAgICAgICAgICAgIDM2MDAwZDMxMDAwNGVkYzAwMDAwMDAw MDAwMDAwMDA2MQ0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDogICAgICAg IDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMTINCkV2 ZW50IG51bWJlcjogICAgICAwDQpNYWpvciwgbWlub3I6ICAgICAgMjUzLCAxOQ0KTnVtYmVyIG9m IHRhcmdldHM6IDENClVVSUQ6IG1wYXRoLTM2MDAwZDMxMDAwNGVkYzAwMDAwMDAwMDAwMDAwMDA2 MQ0KDQpOYW1lOiAgICAgICAgICAgICAgNGU0YWZiMmYtLTJjODYtLTQ0ZWUtLTkwZWQtLTU4MjIw NjY0YzhjNC1pbmJveA0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBBaGVhZDogICAg ICAgIDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMA0K RXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAgICAyNTMsIDI0DQpOdW1iZXIg b2YgdGFyZ2V0czogMQ0KVVVJRDogTFZNLWtoQk11MjFSMXB0NEtkVUhjVElRUWpLQUlYVkVxM1Z4 RFh3NklvMEoza2VHUjNVWDA1eXZNWFJ2VzB1WGVxVmoNCg0KTmFtZTogICAgICAgICAgICAgIDQw OTA3NDYyLS01YjU4LS00MGMyLS1hZGU3LS0zMDMxYzhhMDE5NDktMzk3YzBmNDAtLWVkNzAtLTQ2 NzAtLWFmODktLTU1YzM1ZGU5MjlkNg0KU3RhdGU6ICAgICAgICAgICAgIEFDVElWRQ0KUmVhZCBB aGVhZDogICAgICAgIDI1Ng0KVGFibGVzIHByZXNlbnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAg ICAgICAwDQpFdmVudCBudW1iZXI6ICAgICAgMA0KTWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMjgN Ck51bWJlciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0tTmpSSFZzUXdITnJsclBNcHNBZXlwaFNs R3VKRFo3NkwxcW5iSVpaSzVoSTRyaWZyakY2N0EwaldWNDBBYkRwRA0KDQpOYW1lOiAgICAgICAg ICAgICAgNDA5MDc0NjItLTViNTgtLTQwYzItLWFkZTctLTMwMzFjOGEwMTk0OS1pZHMNClN0YXRl OiAgICAgICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAgICAgICAyNTYNClRhYmxlcyBwcmVz ZW50OiAgICBMSVZFDQpPcGVuIGNvdW50OiAgICAgICAgMA0KRXZlbnQgbnVtYmVyOiAgICAgIDAN Ck1ham9yLCBtaW5vcjogICAgICAyNTMsIDUNCk51bWJlciBvZiB0YXJnZXRzOiAxDQpVVUlEOiBM Vk0tTmpSSFZzUXdITnJsclBNcHNBZXlwaFNsR3VKRFo3NkxuWGNRaEVaWEhUQzhCQkRjWEVTWHBP c2VnMTBkbG9TTA0KDQpOYW1lOiAgICAgICAgICAgICAgNGU0YWZiMmYtLTJjODYtLTQ0ZWUtLTkw ZWQtLTU4MjIwNjY0YzhjNC05ZDFlZDNmZC0tZDZlZi0tNGJiYy0tYjIyMi0tNzY4NzEzNGI4ZmMz DQpTdGF0ZTogICAgICAgICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAgICAgICAgODE5Mg0KVGFi bGVzIHByZXNlbnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAwDQpFdmVudCBudW1iZXI6 ICAgICAgMA0KTWFqb3IsIG1pbm9yOiAgICAgIDI1MywgOA0KTnVtYmVyIG9mIHRhcmdldHM6IDEN ClVVSUQ6IExWTS1raEJNdTIxUjFwdDRLZFVIY1RJUVFqS0FJWFZFcTNWeGlOQjVjdFJheGRXY29N S2tlaENnRDYzcGpkQW15QVZZDQoNCk5hbWU6ICAgICAgICAgICAgICA0ZTRhZmIyZi0tMmM4Ni0t NDRlZS0tOTBlZC0tNTgyMjA2NjRjOGM0LW1hc3Rlcg0KU3RhdGU6ICAgICAgICAgICAgIEFDVElW RQ0KUmVhZCBBaGVhZDogICAgICAgIDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBMSVZFDQpPcGVu IGNvdW50OiAgICAgICAgMA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBtaW5vcjogICAg ICAyNTMsIDI1DQpOdW1iZXIgb2YgdGFyZ2V0czogMQ0KVVVJRDogTFZNLWtoQk11MjFSMXB0NEtk VUhjVElRUWpLQUlYVkVxM1Z4NUdJZjNaejg3YzZRQ3dYUWF2RFc4b0NBcmVOT1Nrc2oNCg0KTmFt ZTogICAgICAgICAgICAgIDQwOTA3NDYyLS01YjU4LS00MGMyLS1hZGU3LS0zMDMxYzhhMDE5NDkt YWFjMzJjZjktLWFmMGQtLTQyYzQtLTg0ZjctLTZjNjJmYTYyZjIzYw0KU3RhdGU6ICAgICAgICAg ICAgIEFDVElWRQ0KUmVhZCBBaGVhZDogICAgICAgIDgxOTINClRhYmxlcyBwcmVzZW50OiAgICBM SVZFDQpPcGVuIGNvdW50OiAgICAgICAgMA0KRXZlbnQgbnVtYmVyOiAgICAgIDANCk1ham9yLCBt aW5vcjogICAgICAyNTMsIDI3DQpOdW1iZXIgb2YgdGFyZ2V0czogMQ0KVVVJRDogTFZNLU5qUkhW c1F3SE5ybHJQTXBzQWV5cGhTbEd1SkRaNzZMN1pCejB2QTBkYkpCcWhWbnpWYWp6OTE3QnhwaWxV YmMNCg0KTmFtZTogICAgICAgICAgICAgIDRlNGFmYjJmLS0yYzg2LS00NGVlLS05MGVkLS01ODIy MDY2NGM4YzQtaWRzDQpTdGF0ZTogICAgICAgICAgICAgQUNUSVZFDQpSZWFkIEFoZWFkOiAgICAg ICAgODE5Mg0KVGFibGVzIHByZXNlbnQ6ICAgIExJVkUNCk9wZW4gY291bnQ6ICAgICAgICAxDQpF dmVudCBudW1iZXI6ICAgICAgMA0KTWFqb3IsIG1pbm9yOiAgICAgIDI1MywgMjMNCk51bWJlciBv ZiB0YXJnZXRzOiAxDQpVVUlEOiBMVk0ta2hCTXUyMVIxcHQ0S2RVSGNUSVFRaktBSVhWRXEzVngx Q1d5T3dRYkttMjZ2UzlZQnJEb1MxUjdDTG9tbGVyOA0KDQpOYW1lOiAgICAgICAgICAgICAgNGU0 YWZiMmYtLTJjODYtLTQ0ZWUtLTkwZWQtLTU4MjIwNjY0YzhjNC1vdXRib3gNClN0YXRlOiAgICAg ICAgICAgICBBQ1RJVkUNClJlYWQgQWhlYWQ6ICAgICAgICA4MTkyDQpUYWJsZXMgcHJlc2VudDog ICAgTElWRQ0KT3BlbiBjb3VudDogICAgICAgIDANCkV2ZW50IG51bWJlcjogICAgICAwDQpNYWpv ciwgbWlub3I6ICAgICAgMjUzLCAyMQ0KTnVtYmVyIG9mIHRhcmdldHM6IDENClVVSUQ6IExWTS1r aEJNdTIxUjFwdDRLZFVIY1RJUVFqS0FJWFZFcTNWeE0zblFnZmRaMlVYUlRaR3BacnZPZ3dQQUZP UkJJZDM4DQoNCltyb290QGJhcmJlcmEgbG9nXSMgY2F0IC9ldGMvbXVsdGlwYXRoLmNvbmYNCiMg VkRTTSBSRVZJU0lPTiAxLjMNCg0KZGVmYXVsdHMgew0KICAgIHBvbGxpbmdfaW50ZXJ2YWwgICAg ICAgICAgICA1DQogICAgbm9fcGF0aF9yZXRyeSAgICAgICAgICAgICAgIGZhaWwNCiAgICB1c2Vy X2ZyaWVuZGx5X25hbWVzICAgICAgICAgbm8NCiAgICBmbHVzaF9vbl9sYXN0X2RlbCAgICAgICAg ICAgeWVzDQogICAgZmFzdF9pb19mYWlsX3RtbyAgICAgICAgICAgIDUNCiAgICBkZXZfbG9zc190 bW8gICAgICAgICAgICAgICAgMzANCiAgICBtYXhfZmRzICAgICAgICAgICAgICAgICAgICAgNDA5 Ng0KfQ0KDQojIFJlbW92ZSBkZXZpY2VzIGVudHJpZXMgd2hlbiBvdmVycmlkZXMgc2VjdGlvbiBp cyBhdmFpbGFibGUuDQpkZXZpY2VzIHsNCiAgICBkZXZpY2Ugew0KICAgICAgICAjIFRoZXNlIHNl dHRpbmdzIG92ZXJyaWRlcyBidWlsdC1pbiBkZXZpY2VzIHNldHRpbmdzLiBJdCBkb2VzIG5vdCBh cHBseQ0KICAgICAgICAjIHRvIGRldmljZXMgd2l0aG91dCBidWlsdC1pbiBzZXR0aW5ncyAodGhl c2UgdXNlIHRoZSBzZXR0aW5ncyBpbiB0aGUNCiAgICAgICAgIyAiZGVmYXVsdHMiIHNlY3Rpb24p LCBvciB0byBkZXZpY2VzIGRlZmluZWQgaW4gdGhlICJkZXZpY2VzIiBzZWN0aW9uLg0KICAgICAg ICAjIE5vdGU6IFRoaXMgaXMgbm90IGF2YWlsYWJsZSB5ZXQgb24gRmVkb3JhIDIxLiBGb3IgbW9y ZSBpbmZvIHNlZQ0KICAgICAgICAjIGh0dHBzOi8vYnVnemlsbGEucmVkaGF0LmNvbS8xMjUzNzk5 DQogICAgICAgIGFsbF9kZXZzICAgICAgICAgICAgICAgIHllcw0KICAgICAgICBub19wYXRoX3Jl dHJ5ICAgICAgICAgICBmYWlsDQogICAgfQ0KfQ0KDQojIEVuYWJsZSB3aGVuIHRoaXMgc2VjdGlv biBpcyBhdmFpbGFibGUgb24gYWxsIHN1cHBvcnRlZCBwbGF0Zm9ybXMuDQojIE9wdGlvbnMgZGVm aW5lZCBoZXJlIG92ZXJyaWRlIGRldmljZSBzcGVjaWZpYyBvcHRpb25zIGVtYmVkZGVkIGludG8N CiMgbXVsdGlwYXRoZC4NCiMNCiMgb3ZlcnJpZGVzIHsNCiMgICAgICBub19wYXRoX3JldHJ5ICAg ICAgICAgICBmYWlsDQojIH0NCg0K --_004_CY4PR14MB1687A42BA552152A8D40EE5FE9C50CY4PR14MB1687namp_--

1 0

Can't boot VM: "At least one numa node has to be configured when enabling memory hotplug"
by gregor 04 Oct '16

04 Oct '16

Hi, yesterday I exported all my VM's and reinstalled the host fresh as hosted-engine installation. After importing one VM and starting this, it gaves me the error message (engine.log) see below. After researching what "numa" means I don't have a clue what this should mean or what was configured wrong. It's only one Server followed this [1] instruction. ... 2016-10-04 06:34:30,719 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler4) [66e4bd80] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM webserver is down with error. Exit message: unsupported configuration: At least one numa node has to be configured when enabling memory hotplug. 2016-10-04 06:34:30,731 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] (DefaultQuartzScheduler4) [66e4bd80] Rerun VM 'b5947250-77d3-46d2-a8c6-cdd9072bb558'. Called from VDS 'host' 2016-10-04 06:34:30,933 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-49) [66e4bd80] Correlation ID: 7e9dded6, Job ID: 63c37b21-c3f4-40da-9eb2-fe98e824827c, Call Stack: null, Custom Event ID: -1, Message: Failed to run VM webserver (User: admin@internal-authz). ... cheers gregor [1] https://www.ovirt.org/documentation/how-to/hosted-engine/

1 0