- Users - oVirt List Archives

gentoo guest support?
by Darrell Budic 26 May '15

26 May '15

Just checking to see if anyones gotten ovirt-guest-agent to work on a gentoo based guest? -Darrell

5 4

HTTP 500 - VM START
by X.Smalbil 26 May '15

26 May '15

Hello everybody, Can anybody tell me why I’m getting a 500 error while doing: POST /api/vms/91c32fdb-5d53-4f67-91eb-4c6f23a0d81d/start HTTP/1.1 Authorization: Basic YWRt02EW50ZXJuYWw6aGFja2VyMTM= Content-Type: application/json Accept: application/json Host: 192.168.2.21 Connection: close User-Agent: Paw/2.2.1 (Macintosh; OS X/10.10.3) GCDHTTPRequest Content-Length: 248 {"vm":{"os":{"boot":[{"dev":"hd"},{"dev":"cdrom"}]},"initialization":{"host_name":"local.freak.net","cloud_init":{"network_configuration":{"nics":{"nic":[{"on_boot":"true","name":"eth0","network":{}}]}},"host":{"address":"local.devtime.dev.nl"}}}}} HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:340) org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:540) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:502) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) javax.servlet.http.HttpServlet.service(HttpServlet.java:847) org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:69) org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:39) org.ovirt.engine.core.aaa.filters.LoginFilter.doFilter(LoginFilter.java:74) org.ovirt.engine.core.aaa.filters.NegotiationFilter.doFilter(NegotiationFilter.java:113) org.ovirt.engine.core.aaa.filters.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:90) org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:73) org.ovirt.engine.core.aaa.filters.EngineSessionTokenAuthenticationFilter.doFilter(EngineSessionTokenAuthenticationFilter.java:31) org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:32) org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:110) org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:101) root cause java.lang.NullPointerException org.ovirt.engine.api.common.util.EnumValidator.validateEnum(EnumValidator.java:86) org.ovirt.engine.api.common.util.EnumValidator.validateEnum(EnumValidator.java:66) org.ovirt.engine.api.restapi.resource.validation.CloudInitValidator.validateEnums(CloudInitValidator.java:21) org.ovirt.engine.api.restapi.resource.validation.VmValidator.validateEnums(VmValidator.java:54) org.ovirt.engine.api.restapi.resource.validation.VmValidator.validateEnums(VmValidator.java:10) org.ovirt.engine.api.restapi.resource.BackendResource.validateEnums(BackendResource.java:348) org.ovirt.engine.api.restapi.resource.BackendVmResource.start(BackendVmResource.java:342) sun.reflect.GeneratedMethodAccessor1093.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:606) org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:155) org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:152) org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:525) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:502) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) javax.servlet.http.HttpServlet.service(HttpServlet.java:847) org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:69) org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:39) org.ovirt.engine.core.aaa.filters.LoginFilter.doFilter(LoginFilter.java:74) org.ovirt.engine.core.aaa.filters.NegotiationFilter.doFilter(NegotiationFilter.java:113) org.ovirt.engine.core.aaa.filters.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:90) org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:73) org.ovirt.engine.core.aaa.filters.EngineSessionTokenAuthenticationFilter.doFilter(EngineSessionTokenAuthenticationFilter.java:31) org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:32) org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:110) org.ovirt.engine.api.common.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:101) Met vriendelijke groet, With kind regards, Xander Smalbil Netbulae Virtualization Experts ---------------- Tel: 053 20 30 270 info(a)netbulae.eu Staalsteden 4-3A KvK 08198180 Fax: 053 20 30 271 www.netbulae.eu 7547 TA Enschede BTW NL821234584B01 ----------------

2 1

Postponing 3.5.3 RC2 to tomorrow
by Sandro Bonazzola 26 May '15

26 May '15

Hi, our Jenkins slaves are currently suffering DNS issues so I won't be able to build 3.5.3 RC3 today. Infra is already investigating and the issue will hopefully be fixed by tomorrow. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

About NAT in libvirt default virbr0, it cannot reach LAN of host.
by lof yer 26 May '15

26 May '15

Some users of mine are complaining about NAT in oVirt. They said that vmware's NAT can reach LAN of host like 192.168.1.0/24, but NAT(I use extnet.py in hooks, ie. 192.168.122.0/24) in oVirt cannot do that. I've tried kinds of network in virt-manager like route, nat, isolated. What's the difference between libvirt's NAT and VMWare's NAT? What should I do to make libvirt's NAT reach LAN of the host?

1 0

Regarding assigning Logical Networks to Network Interface
by knarra 25 May '15

25 May '15

Hi, I am trying to create a network called 'gluster network' and attach it to the network interfaces. After attaching the Logical Network to the network interface i see that ONBOOT in the ifcfg files is set to 'no'.Is this expected behaviour or is there any bug on this which will be fixed soon? Another question, a network interface has static ip address and assigned with logical interface. When i try detaching the Logical Network, IPADDR and NETMASK gets removed from the ifcfg file. Is this expected? Have a NIC which has dhcp address and assigned with logical network. Now i want to assign a static address to that. I went a head and modified the config files to have the static ip address and performed refresh capabilities on that host. My ip address in the UI changes, but when i go the set up Host networks tab i see that for my logical network dhcp is selected and i do see the static address in the ip address and netmask text boxes. ONBOOT is set to no, when i try creating bonds for my interfaces. My interfaces which are participating in the bond + the bond. can some one help me understand how above things work with ovirt. Thanks kasturi.

2 1

glusterfs takes a long time to syncing after host has been rebooted
by Юрий Полторацкий 25 May '15

25 May '15

Hi. I am testing oVirt 3.5.2 with 3 hosts (Dell R210). Storage type is GlusterFS (replicate 3): each host has a single 3TB HDD. When I put one host into maintence mode, then reboot it and after system has been started, the glusterfsd proccess takes a long time (more then hours with gigabyte network) to syncing. It seems to be reload all data instead of download only changes . I have several VMs, but only one VM was running (postfix relay) at that moment, so there were no lots of changes on gluster volume. I've googled for this issue without success. Is it normal situation? Or what can I do to resolve the problem? I can provide any additional info. Thanks.

3 2

VM pause when host crash/poweroff
by paf1＠email.cz 25 May '15

25 May '15

Hello, how to solve situation if VM going to "pause" mode when one of replica 2 node is stopped ( power down or crash, etc. .. ) VM is not running on stopped node and OVirt message get " VM xyz has paused due to unknown storage error" Where the error is ?? regs. Pavel

2 1

Configuring ilo2 PM; passing ssh options
by Daniel Helgenberger 25 May '15

25 May '15

Hello, to make this short - i need to pass ssh options to get the connection to ilo2 working (MACs=hmac-sha1) [1]. How can this be done? I think the 'options' field is clearly for something else? Using this option in .ssh/config works btw. Thanks! -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767

3 8

oVirt 3.6 new feature: Affinity Group Enforcement Service
by Tomer Saban 25 May '15

25 May '15

Greetings users and developers, I'm developing a new feature "Affinity Rules Enforcement Service"; In summary, =========== If an anti-affinity policy is applied to VMs that are currently running on the same hypervisor, the engine will not automatically migrate one of them off once the policy is applied. The Affinity Rules Enforcement Service will periodically check that affinity rules are being enforced and will migrate VMs if necessary in order to comply with those rules. You're welcome to review the feature page: http://www.ovirt.org/Affinity_Group_Enforcement_Service The feature page is responding to RFE https://bugzilla.redhat.com/show_bug.cgi?id=1112332 Your comments appreciated. Thanks, Tomer

2 2

REST JSON - Request syntactically incorrect
by X.Smalbil 24 May '15

24 May '15

Dear all, I’m trying loads of different request bodies to see if I can get the JSON REST to work. Adding just a name on a new vm request gives me a hint of what to do: BAD REQUEST: http://screencloud.net/v/kcp6 (also attached to this mail) So then I add the next parameter to the request body and try again: REQUEST INCORRECT: https://screencloud.net/v/hF0l ( also attached to this mail ) I’ve tried: - {"name":"local.domain.dev.nl","cluster.name":"local_cluster"} - {“vm.name":"local.domain.dev.nl”,”vm.cluster.name":"local_cluster”} - {“vm-name":"local.domain.dev.nl”,”vm-cluster-name":"local_cluster”} - {“action”: {“vm”: {[“name”:”local.domain.dev.nl”,”cluster.name”:”local_cluster”,”template.name”:”Blank”]}}} ……… and load of other combinations. And I’m really getting pretty annoyed :D So what should my JSON body actually look like? Met vriendelijke groet, With kind regards, Xander Smalbil Netbulae Virtualization Experts ---------------- Tel: 053 20 30 270 info(a)netbulae.eu Staalsteden 4-3A KvK 08198180 Fax: 053 20 30 271 www.netbulae.eu 7547 TA Enschede BTW NL821234584B01 ----------------

1 1

JSON
by X.Smalbil 24 May '15

24 May '15

Hi everybody, Where can I find some examples of using the REST api? I find it hard to find out what parameters I can send to in order to get rid of the “Request is syntactically incorrect” or “Bad request” errors so I can have a good play around. Best regards, Xander Smalbil Met vriendelijke groet, With kind regards, Xander Smalbil Netbulae Virtualization Experts ---------------- Tel: 053 20 30 270 info(a)netbulae.eu Staalsteden 4-3A KvK 08198180 Fax: 053 20 30 271 www.netbulae.eu 7547 TA Enschede BTW NL821234584B01 ----------------

1 1

Changing Hosted-Engine RAM
by Simon Hallam 24 May '15

24 May '15

--_000_8F5D1BC1709CC8409AF1935024879387812A58B6harrisnpmacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was wondering if there was any way of changing the ovirt-hosted-engine VM= 's RAM retrospectively? If I try and modify the VM in the UI, I get an error: Error while executing action: HostedEngine: Cannot edit VM. This VM is not managed by the engine. Cheers, Simon Hallam Linux Support & Development Officer Please visit our new website at www.pml.ac.uk and follow us on Twitter @Pl= ymouthMarine Winner of the Environment & Conservation category, the Charity Awards 2014. Plymouth Marine Laboratory (PML) is a company limited by guarantee register= ed in England & Wales, company number 4178503. Registered Charity No. 10912= 22. Registered Office: Prospect Place, The Hoe, Plymouth PL1 3DH, UK.=20 This message is private and confidential. If you have received this message= in error, please notify the sender and remove it from your system. You are= reminded that e-mail communications are not secure and may contain viruses= ; PML accepts no liability for any loss or damage which may be caused by vi= ruses. --_000_8F5D1BC1709CC8409AF1935024879387812A58B6harrisnpmacuk_ 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 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I was wondering if there was any way of changing the= ovirt-hosted-engine VM’s RAM retrospectively?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">If I try and modify the VM in the UI, I get an error= : <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Error while executing a= ction:<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">HostedEngine:<o:p></o:p= ></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">    Cann= ot edit VM. This VM is not managed by the engine.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> <p class=3D"MsoNormal">Cheers,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-GB">Simon Hal= lam<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-GB">Linux Sup= port & Development Officer<o:p></o:p></span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <PRE> Please visit our new website at www.pml.ac.uk and follow us on Twitter @Pl= ymouthMarine Winner of the Environment & Conservation category, the Charity Awards 2014. Plymouth Marine Laboratory (PML) is a company limited by guarantee register= ed in England & Wales, company number 4178503. Registered Charity No. 10912= 22. Registered Office: Prospect Place, The Hoe, Plymouth PL1 3DH, UK.=20 This message is private and confidential. If you have received this message= in error, please notify the sender and remove it from your system. You are= reminded that e-mail communications are not secure and may contain viruses= ; PML accepts no liability for any loss or damage which may be caused by vi= ruses. </PRE></body> </html> --_000_8F5D1BC1709CC8409AF1935024879387812A58B6harrisnpmacuk_--

2 1

Switch from Fedora 20 to CentOS 7.1
by Soeren Malchow 22 May '15

22 May '15

--_000_D565B26ABBD44294A3B34915404BCAEBmconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHN3aXRjaCBmcm9tIGZlZG9yYSAy MCB0byBjZW50b3MgNy4xIChhcyBmYXIgYXMgaSB1bmRlcnN0b29kIGl0IGhhcyBsaXZlIG1lcmdl IHN1cHBvcnQgbm93KSB3aXRoaW4gb25lIGNsdXN0ZXIsIG1lYW5pbmcNCg0KICAqICAgdGFrZSBv dXQgb25lIGNvbXB1dGUgaG9zdA0KICAqICAgUmVpbnN0YWxsIHRoYXQgY29tcHV0ZSBob3N0IHdp dGggQ2VudG9zIDcuMQ0KICAqICAgRG8gYSBob3N0ZWQtZW5naW5lIOKAlGRlcGxveQ0KICAqICAg TWlncmF0ZSBWTSB0byB0aGUgQ2VudE9TIDcuMSBob3N0DQogICogICBUYWtlIHRoZSBuZXh0IGZl ZG9yYSBob3N0IGFuZCByZWluc3RhbGwNCg0KQW55IGV4cGVyaWVuY2VzLCByZWNvbW1lbmRhdGlv bnMgb3IgcmVtYXJrcyBvbiB0aGF0ID8NCg0KUmVnYXJkcw0KU29lcmVuDQo= --_000_D565B26ABBD44294A3B34915404BCAEBmconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <9F5C9C7C4DBD2F4986A243C438FC87E3(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHN3 aXRjaCBmcm9tIGZlZG9yYSAyMCB0byBjZW50b3MgNy4xIChhcyBmYXIgYXMgaSB1bmRlcnN0b29k IGl0IGhhcyBsaXZlIG1lcmdlIHN1cHBvcnQgbm93KSB3aXRoaW4gb25lIGNsdXN0ZXIsIG1lYW5p bmcmbmJzcDs8L2Rpdj4NCjx1bD4NCjxsaT50YWtlIG91dCBvbmUgY29tcHV0ZSBob3N0PC9saT48 bGk+UmVpbnN0YWxsIHRoYXQgY29tcHV0ZSBob3N0IHdpdGggQ2VudG9zIDcuMSZuYnNwOzwvbGk+ PGxpPkRvIGEgaG9zdGVkLWVuZ2luZSDigJRkZXBsb3k8L2xpPjxsaT5NaWdyYXRlIFZNIHRvIHRo ZSBDZW50T1MgNy4xIGhvc3Q8L2xpPjxsaT5UYWtlIHRoZSBuZXh0IGZlZG9yYSBob3N0IGFuZCBy ZWluc3RhbGwmbmJzcDs8L2xpPjwvdWw+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbnkgZXhw ZXJpZW5jZXMsIHJlY29tbWVuZGF0aW9ucyBvciByZW1hcmtzIG9uIHRoYXQgPzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tb2VyZW4mbmJzcDs8L2Rp dj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D565B26ABBD44294A3B34915404BCAEBmconnet_--

5 8

Adding FCP - Request for comments
by Fábio Coelho 22 May '15

22 May '15

------=_Part_221764_1599804593.1432141777491 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvdWdodHMgYWJvdXQgQWRkaW5nIFN0b3JhZ2UgTHVucyAKCkFzIEkgYW0gbmV3IGhlcmUsIEkg d291bGQgYXBwcmVjaWF0ZSBzb21lIGFkdmljZSBhYm91dCBzb21lIGFjdGlvbnMgdGhhdCBJIGlu dGVuZCB0byBwZXJmb3JtLCBwbGVhc2UgcmVhZC4gCgpJIGhhdmUgYWRkZWQgYSBMVU4gdG8gbXkg Y2x1c3RlciBhbmQsIGZvciB0aGF0IHRhc2ssIEkgaGFkIHRvIHJlc3RhcnQgZXZlcnkgbm9kZSBv ZiBpdC4gVGhlcmUgd2FzIG5vIExVTnMgYmVmb3JlLCBtdWx0aXBhdGhkIHdhcyBzdG9wcGVkIGFu ZCBtdWx0aXBhdGguY29uZiBpbmV4aXN0ZWQuIEkgd2FzIGFibGUgdG8gbG9nIGluIGFuZCBtYW51 YWxseSBjb25maWd1cmUgbXVsdGlwYXRoLmNvbmYsIGEgc2ltcGxlIG11bHRpcGF0aGQgc3RhcnQg d2FzIG5vdCBlbm91Z2guIAoKSWYgdGhpcyB3YXNuJ3QgZW5vdWdoLCBteSBkb3VibGUgTmV0QVBQ ICggdGhyb3VnaCBhbiBIaXRhY2hpICkgcHJvdmlkZWQgbWUgd2l0aCBhIG5vdCBzbyBlbXB0eSBi cmFuZCBuZXcgTFVOLCBhbmQgdGhlIHRhc2sgdG8gYWRkIHRoZSBGQ1AgZmFpbGVkIHRvIHBvaW50 IHRoaXMuIFRydXN0aW5nIG15IGRvdWJsZSwgSSBzcGVudCBzb21lIHByZWNpb3VzIHRpbWUgc2Vh cmNoaW5nIGZvciBkaWZmZXJlbnQgcHJvYmxlbXMsIHVudGlsIHJlY2VpdmluZyBzb21lIGd1aWRh bmNlIGFuZCBkbyBhIHNpbXBsZSBkZCBpZj0vZGV2L3plcm8gdG8gdGhlIGluaXRpYWwgYmxvY2tz IG9mIHRoZSBMVU4uIAoKQ29uc3VsdGluZyB0aGUgZG9jdW1lbnRhdGlvbiAoIGh0dHA6Ly93d3cu b3ZpcnQub3JnL09WaXJ0X0FkbWluaXN0cmF0aW9uX0d1aWRlI0FkZGluZ19GQ1BfU3RvcmFnZSAp IGZvciB0aGlzIG1hdHRlcnMsIHdhcyBub3Qgb2YgYW55IGhlbHAuIAoKU28sIG15IHF1ZXN0aW9u czogCgpUaGlzIGlzIHRoZSBpbnRlbmRlZCBiZWhhdmlvcj8gU2hvdWxkIEkgb3BlbiBhIHRpY2tl dD8gCgpTaG91bGQgSSBhZGQgYSBub3RlIHRvIGRvY3VtZW50YXRpb24gdG8gcG9pbnQgc3VjaCBi ZWhhdmlvcj8gKCBpJ20gYWJvdXQgdG8gKSAKCgpDaGVlcnMsIAoKYnkgcW9lbGhlWCAKCkF2aXNv IExlZ2FsCgpBIGluZm9ybWHDp8OjbyBjb250aWRhIG5lc3RlIGUtbWFpbCBlIGVtIHNldXMgYW5l eG9zIHBvZGUgc2VyIHJlc3RyaXRhLCBzZW5kbyBvIGVtaXRlbnRlIGRlc3RlIHJlc3BvbnPDoXZl bCBwb3Igc2V1IGNvbnRlw7pkbyBlIGVuZGVyZcOnYW1lbnRvLiBTZSB2b2PDqiBuw6NvIGZvciBh IHBlc3NvYSBhdXRvcml6YWRhIGEgcmVjZWJlciBlc3RhIG1lbnNhZ2VtIGUgdGVuZG8gcmVjZWJp ZG8gYSBtZXNtYSBwb3IgZW5nYW5vLCBmYXZvciBhcGFnw6EtbGEgaW1lZGlhdGFtZW50ZS4gQSBK RlNDIGNvbnNpZGVyYSBvcGluacO1ZXMsIGNvbmNsdXPDtWVzIGUgb3V0cmFzIGluZm9ybWHDp8O1 ZXMgbsOjbyBvZmljaWFpcyBkZSByZXNwb25zYWJpbGlkYWRlIGRvIHVzdcOhcmlvIGRlc3RlIHNl cnZpw6dvLgo= ------=_Part_221764_1599804593.1432141777491 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiAjMDAwMDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+VGhvdWdodHMgYWJv dXQgQWRkaW5nIFN0b3JhZ2UgTHVucyZuYnNwOzwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAw MDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+PGJyIGRhdGEtbWNlLWJvZ3Vz PSIxIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJm b250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj b2xvcjogIzAwMDAwMDsiPkFzIEkgYW0gbmV3IGhlcmUsIEkgd291bGQgYXBwcmVjaWF0ZSBzb21l IGFkdmljZSBhYm91dCBzb21lIGFjdGlvbnMgdGhhdCBJIGludGVuZCB0byBwZXJmb3JtLCBwbGVh c2UgcmVhZC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxl PSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcjogIzAwMDAwMDsiPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJw dDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBj b25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5JIGhh dmUgYWRkZWQgYSBMVU4gdG8gbXkgY2x1c3RlciBhbmQsIGZvciB0aGF0IHRhc2ssIEkgaGFkIHRv IHJlc3RhcnQgZXZlcnkgbm9kZSBvZiBpdC4gVGhlcmUgd2FzIG5vIExVTnMgYmVmb3JlLCBtdWx0 aXBhdGhkIHdhcyBzdG9wcGVkIGFuZCZuYnNwO211bHRpcGF0aC5jb25mIGluZXhpc3RlZC4gSSB3 YXMgYWJsZSB0byBsb2cgaW4gYW5kIG1hbnVhbGx5IGNvbmZpZ3VyZSBtdWx0aXBhdGguY29uZiwg YSBzaW1wbGUgbXVsdGlwYXRoZCBzdGFydCB3YXMgbm90IGVub3VnaC48L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNv bnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiPjxiciBk YXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBj b25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRh LW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5JZiB0aGlzIHdhc24ndCBlbm91Z2gsIG15IGRv dWJsZSBOZXRBUFAgKCB0aHJvdWdoIGFuIEhpdGFjaGkgKSBwcm92aWRlZCBtZSB3aXRoIGEgbm90 IHNvIGVtcHR5IGJyYW5kIG5ldyBMVU4sIGFuZCB0aGUgdGFzayB0byBhZGQgdGhlIEZDUCBmYWls ZWQgdG8gcG9pbnQgdGhpcy4gVHJ1c3RpbmcgbXkgZG91YmxlLCBJIHNwZW50IHNvbWUgcHJlY2lv dXMgdGltZSBzZWFyY2hpbmcgZm9yIGRpZmZlcmVudCBwcm9ibGVtcywgdW50aWwgcmVjZWl2aW5n IHNvbWUgZ3VpZGFuY2UgYW5kIGRvJm5ic3A7YSBzaW1wbGUgZGQgaWY9L2Rldi96ZXJvIHRvIHRo ZSBpbml0aWFsIGJsb2NrcyBvZiB0aGUgTFVOLjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAw MDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+PGJyIGRhdGEtbWNlLWJvZ3Vz PSIxIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJm b250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj b2xvcjogIzAwMDAwMDsiPkNvbnN1bHRpbmcgdGhlIGRvY3VtZW50YXRpb24gKCZuYnNwO2h0dHA6 Ly93d3cub3ZpcnQub3JnL09WaXJ0X0FkbWluaXN0cmF0aW9uX0d1aWRlI0FkZGluZ19GQ1BfU3Rv cmFnZSApIGZvciB0aGlzIG1hdHRlcnMsIHdhcyBub3Qgb2YgYW55IGhlbHAuPC9kaXY+PGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lk YSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij48 YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNp ZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyIg ZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+U28sIG15IHF1ZXN0aW9uczo8L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTog bHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAw MDsiPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAw MDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5UaGlzIGlzIHRoZSBpbnRlbmRl ZCBiZWhhdmlvcj8gU2hvdWxkIEkgb3BlbiBhIHRpY2tldD88L2Rpdj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUs c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiPjxiciBkYXRhLW1j ZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xl LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1z dHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5TaG91bGQgSSBhZGQgYSBub3RlIHRvIGRvY3VtZW50YXRp b24gdG8gcG9pbnQgc3VjaCBiZWhhdmlvcj8gKCBpJ20gYWJvdXQgdG8gKTwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEy cHQ7IGNvbG9yOiAjMDAwMDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEg Y29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+PGJy IGRhdGEtbWNlLWJvZ3VzPSIxIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRh IGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRh dGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9k aXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1p bHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMw MDAwMDA7Ij5DaGVlcnMsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25z b2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1j ZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNp emU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBs dWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAw OyI+YnkgcW9lbGhlWDwvZGl2PjwvZGl2PjxwPjxicj4KQXZpc28gTGVnYWw8L3A+Cgo8cD5BIGlu Zm9ybWHDp8OjbyBjb250aWRhIG5lc3RlIGUtbWFpbCBlIGVtIHNldXMgYW5leG9zIHBvZGUgc2Vy IHJlc3RyaXRhLCBzZW5kbyBvIGVtaXRlbnRlIGRlc3RlIHJlc3BvbnPDoXZlbCBwb3Igc2V1IGNv bnRlw7pkbyBlIGVuZGVyZcOnYW1lbnRvLiBTZSB2b2PDqiBuw6NvIGZvciBhIHBlc3NvYSBhdXRv cml6YWRhIGEgcmVjZWJlciBlc3RhIG1lbnNhZ2VtIGUgdGVuZG8gcmVjZWJpZG8gYSBtZXNtYSBw b3IgZW5nYW5vLCBmYXZvciBhcGFnw6EtbGEgaW1lZGlhdGFtZW50ZS4gQSBKRlNDIGNvbnNpZGVy YSBvcGluacO1ZXMsIGNvbmNsdXPDtWVzIGUgb3V0cmFzIGluZm9ybWHDp8O1ZXMgbsOjbyBvZmlj aWFpcyBkZSByZXNwb25zYWJpbGlkYWRlIGRvIHVzdcOhcmlvIGRlc3RlIHNlcnZpw6dvLjwvcD48 L2JvZHk+PC9odG1sPg== ------=_Part_221764_1599804593.1432141777491--

3 7

Re: [ovirt-users] providing hosts with foreman
by Oved Ourfali 22 May '15

22 May '15

At this step, after the host installation was successful, which means iirc that all puppet classes were applied correctly, the plug in on the foreman side handles the bootstrapping of the new host. Attaching the production.log file on Foreman, and the engine.log from the ovirt engine is needed to understand what went wrong. A workaround is to remove the host, and add it back. Iirc we haven't allowed reinstall for the installing-OS status. Oved On May 22, 2015 7:57 PM, Nathanaël Blanchet <blanchet(a)abes.fr> wrote: > > Hello Yaniv, > > Okay for the DNS proxy, everything works now as expected. > I have a new question now about the install host workflow. > The host is in "installing OS" state, and on the host side it has been > successfully installed. But now how to complete the host vdms > installation and registration? > I found this on your wiki : > "For other OS - at first step won't do the registration by themselves, > but foreman will do that using a plugin (plugin will send REST-API call > to add or approve the host) " > After investigation, I found that this plugin was this one : > ruby193-rubygem-ovirt_provision_plugin (and with foreman 1.8 we can > activate it with foreman-installer now) > > But nothing happens once the OS is installed et the state is stuck on > "installing OS". Communication between foreman and engine is okay and > without firewall issue... I found nothing significative into the foreman > logs or somewhere else... > What is it supposed to happen at this step? > > > Le 17/05/2015 17:35, ybronhei a écrit : > > Hey Nathenael, > > > > On 05/13/2015 06:28 PM, Nathanaël Blanchet wrote: > >> Hi all, > >> > >> I've setup a foreman server, but when adding a new host by "discovered > >> hosts", I can't modify the address item which is default filled with a > >> built "mac-DNS". > > > > Not exactly, it set the address field to be the name you choose for > > the host dot (.) the domain that related to the picked host-group > > > >> In ovirt setup, I want to identify my future hosts by their IP and not > >> their unknown DNS name like it is described here: > >> http://www.ovirt.org/Features/ForemanIntegration. > > > > IP addresses can and should be dynamic based on your DHCP server > > configuration, but DNS name should stay the same. Adding the host that > > way to engine uses satellite to configure its DNS entry and other > > network configurations. That's why we lock the address field and fill > > it with the future FQDN. > > > >> How can I setup foreman to do such a thing? Is the setup of the DNS > >> proxy related? > > > > Yes, the DNS setup is related to it. We depend on it. Using IP address > > might brake the integration between engine and satellite when the DHCP > > service is configured with address ttl option and can give the host > > different IP address in next boot. So currently we don't support > > address modification with Discovered\Provisioned Hosts > > > >> > > > > If that answer is not clear feel free to ping me in irc (ybronhei > > @freenode #ovirt) or reply here > > > > Regards, > > > > -- > Nathanaël Blanchet > > Supervision réseau > Pôle Infrastrutures Informatiques > 227 avenue Professeur-Jean-Louis-Viala > 34193 MONTPELLIER CEDEX 5 > Tél. 33 (0)4 67 54 84 55 > Fax 33 (0)4 67 54 84 14 > blanchet(a)abes.fr >

1 0

providing hosts with foreman
by Nathanaël Blanchet 22 May '15

22 May '15

Hi all, I've setup a foreman server, but when adding a new host by "discovered hosts", I can't modify the address item which is default filled with a built "mac-DNS". In ovirt setup, I want to identify my future hosts by their IP and not their unknown DNS name like it is described here: http://www.ovirt.org/Features/ForemanIntegration. How can I setup foreman to do such a thing? Is the setup of the DNS proxy related? -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

3 3

Re: [ovirt-users] vdsm storage problem - maybe cache problem?
by ml＠ohnewald.net 22 May '15

22 May '15

Hello List, i really need some help here....could someone please give it a try? I already tried to get help on the irc channel but it seems that my problem here is too complicated or maybe i am providing not useful infos? DB & vdsClient: http://fpaste.org/223483/14320588/ (i think is part is very intresting) engine.log: http://paste.fedoraproject.org/223349/04494414 Node02 vdsm Log: http://paste.fedoraproject.org/223350/43204496 Node01 vdsm Log: http://paste.fedoraproject.org/223347/20448951 Why does my vdsm look for StorageDomain 036b5575-51fa-4f14-8b05-890d7807894c ? => This was a NFS Export which i deleted from the GUI yesterday (!!!). From the Database Log/Dump: ============================= USER_FORCE_REMOVE_STORAGE_DOMAIN 981 0 Storage Domain EXPORT2 was forcibly removed by admin@internal f b384b3da-02a6-44f3-a3f6-56751ce8c26d HP_Proliant_DL180G6 036b5575-51fa-4f14-8b05-890d7807894c EXPORT2 00000000-0000-0000-0000-000000000000 c1754ff 807321f6-2043-4a26-928c-0ce6b423c381 I already put one node into maintance, rebootet and activated it. Still the same problem. Some Screen Shots: -------------------- http://postimg.org/image/8zo4ujgjb/ http://postimg.org/image/le918grdr/ http://postimg.org/image/wnawwhrgh/ My GlusterFS fully works and is not the problem here i guess: ============================================================== 2015-05-19 04:09:06,292 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-43) [3df9132b] START, HSMClearTaskVDSCommand(HostName = ovirt-node02.stuttgart.imos.net, HostId = 6948da12-0b8a-4b6d-a9af-162e6c25dad3, taskId=2aeec039-5b95-40f0-8410-da62b44a28e8), log id: 19b18840 2015-05-19 04:09:06,337 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-43) [3df9132b] FINISH, HSMClearTaskVDSCommand, log id: 19b18840 I already had a chat with Maor Lipchuk and he told me to add another host to the datacenter and then re-initialize it. I will migrate back to ESXi for now to get those two nodes free. Then we can mess with it if anyone is interested to help me. Otherwise i will have to stay with ESXi :-( Has anyone else an idea until then? Why is my vdsm host all messed up with that zombie StorageDomain? Thanks for your time. I really, really appreciate it. Mario Am 19.05.15 um 14:57 schrieb ml(a)ohnewald.net: > Hello List, > > okay, i really need some help now. I stopped vdsmd for a little bit too > long, fencing stepped in and rebootet node01. > > I now can NOT start any vm because the storage is marked "Unknown". > > > Since node01 rebootet i am wondering why the hell it is still looking to > this StorageDomain: > > StorageDomainCache::(_findDomain) domain > 036b5575-51fa-4f14-8b05-890d7807894c not found > > Can anyone please please tell me where the id exactly it comes from? > > > Thanks, > Mario > > > > > > Am 18.05.15 um 14:21 schrieb Maor Lipchuk: >> Hi Mario, >> >> Can u try to mount this directly from the Host? >> Can u please attach the VDSM and engine logs >> >> Thanks, >> Maor >> >> >> ----- Original Message ----- >>> From: ml(a)ohnewald.net >>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>> Cc: users(a)ovirt.org >>> Sent: Monday, May 18, 2015 2:36:38 PM >>> Subject: Re: [ovirt-users] vdsm storage problem - maybe cache problem? >>> >>> Hi Maor, >>> >>> thanks for the quick reply. >>> >>> Am 18.05.15 um 13:25 schrieb Maor Lipchuk: >>> >>>>> Now my Question: Why does the vdsm node not know that i deleted the >>>>> storage? Has the vdsm cached this mount informations? Why does it >>>>> still >>>>> try to access 036b5575-51fa-4f14-8b05-890d7807894c? >>>> >>>> >>>> Yes, the vdsm use a cache for Storage Domains, you can try to >>>> restart the >>>> vdsmd service instead of rebooting the host. >>>> >>> >>> I am still getting the same error. >>> >>> >>> [root@ovirt-node01 ~]# /etc/init.d/vdsmd stop >>> Shutting down vdsm daemon: >>> vdsm watchdog stop [ OK ] >>> vdsm: Running run_final_hooks [ OK ] >>> vdsm stop [ OK ] >>> [root@ovirt-node01 ~]# >>> [root@ovirt-node01 ~]# >>> [root@ovirt-node01 ~]# >>> [root@ovirt-node01 ~]# ps aux | grep vdsmd >>> root 3198 0.0 0.0 11304 740 ? S< May07 0:00 >>> /bin/bash -e /usr/share/vdsm/respawn --minlifetime 10 --daemon >>> --masterpid /var/run/vdsm/supervdsm_respawn.pid >>> /usr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock >>> --pidfile /var/run/vdsm/supervdsmd.pid >>> root 3205 0.0 0.0 922368 26724 ? S<l May07 12:10 >>> /usr/bin/python /usr/share/vdsm/supervdsmServer --sockfile >>> /var/run/vdsm/svdsm.sock --pidfile /var/run/vdsm/supervdsmd.pid >>> root 15842 0.0 0.0 103248 900 pts/0 S+ 13:35 0:00 grep >>> vdsmd >>> >>> >>> [root@ovirt-node01 ~]# /etc/init.d/vdsmd start >>> initctl: Job is already running: libvirtd >>> vdsm: Running mkdirs >>> vdsm: Running configure_coredump >>> vdsm: Running configure_vdsm_logs >>> vdsm: Running run_init_hooks >>> vdsm: Running gencerts >>> vdsm: Running check_is_configured >>> libvirt is already configured for vdsm >>> sanlock service is already configured >>> vdsm: Running validate_configuration >>> SUCCESS: ssl configured to true. No conflicts >>> vdsm: Running prepare_transient_repository >>> vdsm: Running syslog_available >>> vdsm: Running nwfilter >>> vdsm: Running dummybr >>> vdsm: Running load_needed_modules >>> vdsm: Running tune_system >>> vdsm: Running test_space >>> vdsm: Running test_lo >>> vdsm: Running restore_nets >>> vdsm: Running unified_network_persistence_upgrade >>> vdsm: Running upgrade_300_nets >>> Starting up vdsm daemon: >>> vdsm start [ OK ] >>> [root@ovirt-node01 ~]# >>> >>> [root@ovirt-node01 ~]# grep ERROR /var/log/vdsm/vdsm.log | tail -n 20 >>> Thread-13::ERROR::2015-05-18 >>> 13:35:03,631::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-13::ERROR::2015-05-18 >>> 13:35:03,632::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,607::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,621::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,960::sdc::143::Storage.StorageDomainCache::(_findDomain) domain >>> 036b5575-51fa-4f14-8b05-890d7807894c not found >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,960::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) >>> >>> Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c >>> monitoring information >>> Thread-36::ERROR::2015-05-18 >>> 13:35:21,962::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:21,965::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:22,068::sdc::143::Storage.StorageDomainCache::(_findDomain) domain >>> 036b5575-51fa-4f14-8b05-890d7807894c not found >>> Thread-36::ERROR::2015-05-18 >>> 13:35:22,072::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) >>> >>> Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c >>> monitoring information >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,821::task::866::TaskManager.Task::(_setError) >>> Task=`54bdfc77-f63a-493b-b24e-e5a3bc4977bb`::Unexpected error >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,864::dispatcher::65::Storage.Dispatcher.Protect::(run) >>> {'status': {'message': "Unknown pool id, pool not connected: >>> ('b384b3da-02a6-44f3-a3f6-56751ce8c26d',)", 'code': 309}} >>> Thread-13::ERROR::2015-05-18 >>> 13:35:33,930::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,928::task::866::TaskManager.Task::(_setError) >>> Task=`fe9bb0fa-cf1e-4b21-af00-0698c6d1718f`::Unexpected error >>> Thread-13::ERROR::2015-05-18 >>> 13:35:33,932::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,978::dispatcher::65::Storage.Dispatcher.Protect::(run) >>> {'status': {'message': 'Not SPM: ()', 'code': 654}} >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,117::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,131::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,452::sdc::143::Storage.StorageDomainCache::(_findDomain) domain >>> 036b5575-51fa-4f14-8b05-890d7807894c not found >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,453::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) >>> >>> Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c >>> monitoring information >>> >>> >>> Thanks, >>> Mario >>> >>> >

2 3

vdsmd fails to start on boot
by Chris Jones - BookIt.com Systems Administrator 21 May '15

21 May '15

Running oVirt Node - 3.5 - 0.999.201504280931.el7.centos. On first boot, vdsmd fails to load with "Dependency failed for Virtual Desktop Server Manager." When I run "systemctl start vdsmd" it loads fine. This happens on every reboot. Looks like there is an old bug for this from 3.4. https://bugzilla.redhat.com/show_bug.cgi?id=1055153 -- This email was Virus checked by UTM 9. For issues please contact the Windows Systems Admin.

1 0

how to pause a VM from rest-api?
by Ernest Beinrohr 21 May '15

21 May '15

This is a multi-part message in MIME format. --------------070900040009080707030501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'd like to pause a VM from rest-api. But the docs are not mentioning pause, only suspend. This works: URL/api/vms/ID/suspend and pause doesn't. Pausing from vdsClient works however, but I'd like to use rest-api: vdsClient -s host1 pause ID -- Ernest Beinrohr, AXON PRO Ing <http://www.beinrohr.sk/ing.php>, RHCE <http://www.beinrohr.sk/rhce.php>, RHCVA <http://www.beinrohr.sk/rhce.php>, LPIC <http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>, +421-2-62410360 +421-903-482603 --------------070900040009080707030501 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"> I'd like to pause a VM from rest-api. But the docs are not mentioning pause, only suspend. This works: URL/api/vms/ID/suspend and pause doesn't. Pausing from vdsClient works however, but I'd like to use rest-api:<br> vdsClient -s host1 pause ID<br> <br> <br> <br> <div class="moz-signature">-- <br> <div id="oernii_footer" style="color: gray;"> <span style="font-family: Lucida Console, Luxi Mono, Courier, monospace; font-size: 90%;"> Ernest Beinrohr, AXON PRO<br> <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/ing.php">Ing</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/vca.php">VCA</a>, <br> +421-2-62410360 +421-903-482603 <br> </span> </div> <img src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk" moz-do-not-send="true" border="0" width="1" height="1"> </div> </body> </html> --------------070900040009080707030501--

3 4

[ANN] oVirt 3.6.0 First Alpha Release is now available for testing
by Sandro Bonazzola 21 May '15

21 May '15

The oVirt Project is pleased to announce the availability of the first Alpha release of oVirt 3.6 for testing, as of May 20, 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. The Alpha release is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). The Alpha release can also be deployed on Hypervisor Hosts running Fedora 21 and Fedora 22. This Alpha release of oVirt includes numerous bug fixes. See the release notes [1] for an initial list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO and Node ISO will be available soon[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

disk format hang
by paf1＠email.cz 20 May '15

20 May '15

This is a multi-part message in MIME format. --------------010600070900060906080603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, during VM instalation I needed add 300GB new disk and format as EXT3. Easy task, but .... Used striped mirror volume for that - created by: # gluster volume create 12KVM12SC4 replica 2 stripe 2 1kvm1-SAN:/p4/GFS1 1kvm2-SAN:/p4/GFS1 2kvm1-SAN /p4/GFS1 2kvm2-SAN:/p4/GFS1 force - added disk throught oVisrt GUI - VM# partprobe - VM# fdisk - make one partition, type linux - VM# mkfs.ext3 /dev/vdb1 it hangs after cca 30% of format oVirt alert: *VM has been paused due to a storage I/O error* so I tried to copy some data directly from hypervizor ( cca 80GB ) to default gluster-ovirt mountpoint ( /rhev/data-center/mnt/glusterSD/localhost:_12KVM12SC4 ) with no hangs. The same whole operation on volume distribute replica type succesfully done. Can anybody help me with it ?? Maybe continual error on /var/log/messages occure will get right view on it : May 20 15:47:00 1kvm2 virsh: All-whitespace username. May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:47:00 1kvm2 virsh: All-whitespace username. May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:48:00 1kvm2 virsh: All-whitespace username. May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:48:00 1kvm2 virsh: All-whitespace username. May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error regs to ALL !! URGENT !! Pavel --------------010600070900060906080603 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 text="#000000" bgcolor="#FFFFFF"> Hello, <br> <br> during VM instalation I needed add 300GB new disk and format as EXT3. Easy task, but ....<br> Used striped mirror volume for that - created by:<br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> # gluster volume create 12KVM12SC4 replica 2 stripe 2 1kvm1-SAN:/p4/GFS1 1kvm2-SAN:/p4/GFS1 2kvm1-SAN /p4/GFS1 2kvm2-SAN:/p4/GFS1 force<br> - added disk throught oVisrt GUI<br> - VM# partprobe<br> - VM# fdisk - make one partition, type linux<br> - VM# mkfs.ext3 /dev/vdb1<br> it hangs after cca 30% of format<br> <br> oVirt alert: <div> <div> <div style="display: inline;" class="gwt-Label"><b>VM has been paused due to a storage I/O error</b></div> </div> </div> <br> so I tried to copy some data directly from hypervizor ( cca 80GB ) to default gluster-ovirt mountpoint ( /rhev/data-center/mnt/glusterSD/localhost:_12KVM12SC4 ) with no hangs.<br> The same whole operation on volume distribute replica type succesfully done.<br> <br> Can anybody help me with it ??<br> <br> Maybe continual error on /var/log/messages occure will get right view on it :<br> <br> May 20 15:47:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:47:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:48:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:48:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error<br> <br> regs to ALL<br> <br> !! URGENT !!<br> <br> Pavel<br> </body> </html> --------------010600070900060906080603--

1 0

Re: [ovirt-users] Linux VMs get stuck after Live Migration
by Soeren Malchow 20 May '15

20 May '15

--_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCnNvbWUgYWRkaXRpb25zOg0KDQogICogICBzd2l0Y2hpbmcgb2YgbWVtb3J5 IGJhbGxvb25pZyBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbQ0KICAqICAgT25jZSB3ZSBtaWdy YXRlZCB0aGUgbWFjaGluZXMgd2UgY2FuIGJhc2ljYWxseSBub3QgdXNlIGFueXRoaW5nIGFueW1v cmUgdGhhdCBuZWVkcyBzb21lIGtpbmQgb2YgdGltaW5nIOKAkyBlLmcuIOKAnHBpbmcgMS4xLjEu MSDigJNpIDLigJ0gb3Ig4oCcd2hpbGUgdHJ1ZTsgZG8gZWNobyDigJxsYWxh4oCdOyBzbGVlcOKA nTsgZG9uZeKAnSBib3RoIGRvIHRoZSBmcmlzdCB0aGluZyAoMSBwaW5nIGFuZCBvbmUg4oCcbGFs YeKAnSBvdXRwdXQpIGJ1dCB0aGVuIHN0YWxsDQoNCkNoZWVycw0KU29lcmVuDQoNCkZyb206IDx1 c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZzxtYWlsdG86dXNlcnMtYm91bmNlc0BvdmlydC5vcmc+PiBv biBiZWhhbGYgb2YgU29lcmVuIE1hbGNob3cNCkRhdGU6IFdlZG5lc2RheSAyMCBNYXkgMjAxNSAx Mzo0Mg0KVG86ICJ1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4iDQpTdWJq ZWN0OiBbb3ZpcnQtdXNlcnNdIExpbnV4IFZNcyBnZXQgc3R1Y2sgYWZ0ZXIgTGl2ZSBNaWdyYXRp b24NCg0KRGVhciBhbGwsDQoNCldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9ibGVtIHdpdGggTGlu dXggVm1zIHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2VudE9TIDcuMSAoc28g ZmFyIGl0IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9ibGVtKSwgYWZ0ZXIg dGhlIGxpdmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0aGUgSVAgYW5kIGhv c3RuYW1lIGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vlc3QgdG9vbHMgYXJl IG5vdCBpbnN0YWxsZWQsIGJ1dCB0aGUgbWFjaGluZXMgYXJlIHN0aWxsIHJ1bm5pbmcuDQoNClRo ZW4gd2UgaGF2ZSAyIGRpZmZlcmVudCBzY2VuYXJpb3MNCg0KUmVib290L3NodXRkb3duOg0KV2hl biBpIHJlYm9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2UgVk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0 aGUgT1Mgc2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIsIHRoZSBxZW11IHByb2Nlc3MgaXMgc3Rp bGwgcnVubmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNoaW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNo dXRkb3du4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5vdCBkbyBhbnl0aGluZywgYSDigJxwb3dl ciBvZmbigJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZQ0KDQpKdXN0IHdhaXQ6DQpBZnRlciBhIHdo aWxlIHRoZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFzaWNhbGx5 IHRoZW4gc2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duDQoNClRoZSBlbnZpcm9u bWVudCBpczoNCg0KSG9zdGVkIEVuZ2luZSBvbiBDZW50T1MgNi42IHdpdGggb3ZpcnQgMy41LjIu MQ0KQ29tcHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNtIDQuMTYuMTQgYW5kIGxpYnZp cnQgMS4yLjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVwbyAoZm9yIGxpdmUgbWVyZ2Up DQpTdG9yYWdlIC0+IENlbnRPUyA3LjEgd2l0aCBnbHVzdGVyIDMuNi4zDQoNCkNhbiBhbnlvbmUg cG9pbnQgdXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uDQoNClJlZ2FyZHMNClNvZXJlbg0K --_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <E72DBA6120393545B26397A309AE61D7(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+c29tZSBhZGRpdGlv bnM6Jm5ic3A7PC9kaXY+DQo8dWw+DQo8bGk+c3dpdGNoaW5nIG9mIG1lbW9yeSBiYWxsb29uaWcg ZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW08L2xpPjxsaT5PbmNlIHdlIG1pZ3JhdGVkIHRoZSBt YWNoaW5lcyB3ZSBjYW4gYmFzaWNhbGx5IG5vdCB1c2UgYW55dGhpbmcgYW55bW9yZSB0aGF0IG5l ZWRzIHNvbWUga2luZCBvZiB0aW1pbmcg4oCTIGUuZy4g4oCccGluZyAxLjEuMS4xIOKAk2kgMuKA nSBvciDigJx3aGlsZSB0cnVlOyBkbyBlY2hvIOKAnGxhbGHigJ07IHNsZWVw4oCdOyBkb25l4oCd IGJvdGggZG8gdGhlIGZyaXN0IHRoaW5nICgxIHBpbmcgYW5kIG9uZSDigJxsYWxh4oCdIG91dHB1 dCkgYnV0IHRoZW4gc3RhbGw8L2xpPjwvdWw+DQo8ZGl2PkNoZWVyczwvZGl2Pg0KPGRpdj5Tb2Vy ZW4mbmJzcDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp OyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4m bHQ7PGEgaHJlZj0ibWFpbHRvOnVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnIj51c2Vycy1ib3VuY2Vz QG92aXJ0Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBTb2VyZW4gTWFsY2hvdzxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5IDIwIE1heSAy MDE1IDEzOjQyPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9h PiZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+W292aXJ0LXVzZXJzXSBMaW51eCBWTXMgZ2V0IHN0dWNrIGFmdGVyIExpdmUgTWlncmF0aW9u PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkRlYXIgYWxs LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgYXJlIGV4cGVyaWVuY2luZyBhIHBy b2JsZW0gd2l0aCBMaW51eCBWbXMgc3BlY2lmaWNhbGx5IHRoZSBWbXMgd2UgdGVzdGVkIGFyZSBD ZW50T1MgNy4xIChzbyBmYXIgaXQgbG9va3MgYXMgaWYgV2luZG93cyBWbXMgYXJlIG5vdCBhIHBy b2JsZW0pLCBhZnRlciB0aGUgbGl2ZSBtaWdyYXRpb24gdGhlIG1hY2hpbmVzIGRvIG5vdCBzaG93 IHRoZSBJUCBhbmQgaG9zdG5hbWUgaW4gdGhlIEdVSSwgdGhlIHNhbWUgd2F5IGFzIGlmIHRoZSBn dWVzdA0KIHRvb2xzIGFyZSBub3QgaW5zdGFsbGVkLCBidXQgdGhlIG1hY2hpbmVzIGFyZSBzdGls bCBydW5uaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlbiB3ZSBoYXZlIDIg ZGlmZmVyZW50IHNjZW5hcmlvczwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVib290 L3NodXRkb3duOjwvZGl2Pg0KPGRpdj5XaGVuIGkgcmVib290L3NodXRkb3duIG9uZSBvZiB0aGVz ZSBWTVMgZnJvbSBpbnNpZGUgdGhlIFZNIHRoZSBPUyBzZWVtcyB0byBzaHV0ZG93biwgaG93ZXZl ciwgdGhlIHFlbXUgcHJvY2VzcyBpcyBzdGlsbCBydW5uaW5nIGFuZCBmb3Igb3ZpcnQgdGhlIG1h Y2hpbmUgaXMgc3RpbGwgdXAsIGEg4oCcc2h1dGRvd27igJ0gaW4gdGhlIGZyb250ZW5kIGRvZXMg bm90IGRvIGFueXRoaW5nLCBhIOKAnHBvd2VyIG9mZuKAnSBzaHV0cyBkb3duIHRoZSBtYWNoaW5l PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KdXN0IHdhaXQ6PC9kaXY+DQo8ZGl2PkFm dGVyIGEgd2hpbGUgdGhlIG1hY2hpbmVzIGp1c3Qgc2VlbSB0byBzaHV0ZG93biBhbmQgdGhlbiBi YXNpY2FsbHkgdGhlbiBzYW1lIGhhcHBlc24gYXMgd2l0aCByZWJvb3Qvc2h1dGRvd248L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBlbnZpcm9ubWVudCBpczo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pkhvc3RlZCBFbmdpbmUgb24gQ2VudE9TIDYuNiB3aXRoIG92aXJ0 IDMuNS4yLjE8L2Rpdj4NCjxkaXY+Q29tcHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNt IDQuMTYuMTQgYW5kIGxpYnZpcnQgMS4yLjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVw byAoZm9yIGxpdmUgbWVyZ2UpPC9kaXY+DQo8ZGl2PlN0b3JhZ2UgLSZndDsgQ2VudE9TIDcuMSB3 aXRoIGdsdXN0ZXIgMy42LjM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNhbiBhbnlv bmUgcG9pbnQgdXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNvZXJlbiZuYnNwOzwvZGl2Pg0KPGRp dj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_--

1 0

NFS export domain still remain in "Preparing for maintenance"
by NUNIN Roberto 20 May '15

20 May '15

--_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all We are using oVirt engine 3.5.1-0.0 on Centos 6.6 We have two DC. One with hosts using vdsm-4.16.10-8.gitc937927.el7.x86_64, = the other vdsm-4.16.12-7.gita30da75.el6.x86_64 on Centos6.6 No hosted-engine, it run on a dedicates VM, outside oVirt. Behavior: When try to put the NFS export currently active and attached to t= he 6.6 cluster, used to move VM from one DC to the other, this remain indef= initely in "Preparing for maintenance phase". No DNS resolution issue in place. All parties involved are solved directly = and via reverse resolution. I've read about the issue on el7 and IPv6 bug, but here we have the problem= on Centos 6.6 hosts. Any idea/suggestion/further investigation ? Can we reinitialize the NFS export in some way ? Only erasing content ? Thanks in advance for any suggestion. Roberto Nunin Italy ________________________________ Questo messaggio e' indirizzato esclusivamente al destinatario indicato e p= otrebbe contenere informazioni confidenziali, riservate o proprietarie. Qua= lora la presente venisse ricevuta per errore, si prega di segnalarlo immedi= atamente al mittente, cancellando l'originale e ogni sua copia e distruggen= do eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potr= ebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibit= ed and may be unlawful. --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_ 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 14 (filtered medium)"> <style></style> </head> <body lang=3D"IT" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi all<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">We are using oVirt engine 3.5.1= -0.0 on Centos 6.6<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">We have two DC. One with hosts = using vdsm-4.16.10-8.gitc937927.el7.x86_64, the other vdsm-4.16.12-7.gita30= da75.el6.x86_64 on Centos6.6<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">No hosted-engine, it run on a d= edicates VM, outside oVirt.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Behavior: When try to put the N= FS export currently active and attached to the 6.6 cluster, used to move VM= from one DC to the other, this remain indefinitely in “Preparing for= maintenance phase”.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">No DNS resolution issue in plac= e. All parties involved are solved directly and via reverse resolution.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I’ve read about the issue= on el7 and IPv6 bug, but here we have the problem on Centos 6.6 hosts.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Any idea/suggestion/further inv= estigation ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Can we reinitialize the NFS exp= ort in some way ? Only erasing content ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks in advance for any sugge= stion.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Roberto Nunin<o:p><= /o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Italy<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <br> <hr> <font face=3D"Courier New" color=3D"Black" size=3D"2">Questo messaggio e' i= ndirizzato esclusivamente al destinatario indicato e potrebbe contenere inf= ormazioni confidenziali, riservate o proprietarie. Qualora la presente veni= sse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e dis= truggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito= e potrebbe essere fonte di violazione di legge.<br> <br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.<br> </font> </body> </html> --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_--

2 5

Linux VMs get stuck after Live Migration
by Soeren Malchow 20 May '15

20 May '15

--_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9ibGVtIHdpdGggTGludXggVm1z IHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2VudE9TIDcuMSAoc28gZmFyIGl0 IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9ibGVtKSwgYWZ0ZXIgdGhlIGxp dmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0aGUgSVAgYW5kIGhvc3RuYW1l IGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vlc3QgdG9vbHMgYXJlIG5vdCBp bnN0YWxsZWQsIGJ1dCB0aGUgbWFjaGluZXMgYXJlIHN0aWxsIHJ1bm5pbmcuDQoNClRoZW4gd2Ug aGF2ZSAyIGRpZmZlcmVudCBzY2VuYXJpb3MNCg0KUmVib290L3NodXRkb3duOg0KV2hlbiBpIHJl Ym9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2UgVk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0aGUgT1Mg c2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIsIHRoZSBxZW11IHByb2Nlc3MgaXMgc3RpbGwgcnVu bmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNoaW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNodXRkb3du 4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5vdCBkbyBhbnl0aGluZywgYSDigJxwb3dlciBvZmbi gJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZQ0KDQpKdXN0IHdhaXQ6DQpBZnRlciBhIHdoaWxlIHRo ZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFzaWNhbGx5IHRoZW4g c2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duDQoNClRoZSBlbnZpcm9ubWVudCBp czoNCg0KSG9zdGVkIEVuZ2luZSBvbiBDZW50T1MgNi42IHdpdGggb3ZpcnQgMy41LjIuMQ0KQ29t cHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNtIDQuMTYuMTQgYW5kIGxpYnZpcnQgMS4y LjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVwbyAoZm9yIGxpdmUgbWVyZ2UpDQpTdG9y YWdlIC0+IENlbnRPUyA3LjEgd2l0aCBnbHVzdGVyIDMuNi4zDQoNCkNhbiBhbnlvbmUgcG9pbnQg dXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uDQoNClJlZ2FyZHMNClNvZXJlbg0K --_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <FCD76AD0F70A3F428467305A213B2D3F(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9i bGVtIHdpdGggTGludXggVm1zIHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2Vu dE9TIDcuMSAoc28gZmFyIGl0IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9i bGVtKSwgYWZ0ZXIgdGhlIGxpdmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0 aGUgSVAgYW5kIGhvc3RuYW1lIGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vl c3QNCiB0b29scyBhcmUgbm90IGluc3RhbGxlZCwgYnV0IHRoZSBtYWNoaW5lcyBhcmUgc3RpbGwg cnVubmluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZW4gd2UgaGF2ZSAyIGRp ZmZlcmVudCBzY2VuYXJpb3M8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlYm9vdC9z aHV0ZG93bjo8L2Rpdj4NCjxkaXY+V2hlbiBpIHJlYm9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2Ug Vk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0aGUgT1Mgc2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIs IHRoZSBxZW11IHByb2Nlc3MgaXMgc3RpbGwgcnVubmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNo aW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNodXRkb3du4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5v dCBkbyBhbnl0aGluZywgYSDigJxwb3dlciBvZmbigJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZTwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SnVzdCB3YWl0OjwvZGl2Pg0KPGRpdj5BZnRl ciBhIHdoaWxlIHRoZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFz aWNhbGx5IHRoZW4gc2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZW52aXJvbm1lbnQgaXM6PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5Ib3N0ZWQgRW5naW5lIG9uIENlbnRPUyA2LjYgd2l0aCBvdmlydCAz LjUuMi4xPC9kaXY+DQo8ZGl2PkNvbXB1dGUgaG9zdHMgb24gRmVkb3JhIDIwIHdpdGggdmRzbSA0 LjE2LjE0IGFuZCBsaWJ2aXJ0IDEuMi45LjEgZnJvbSB0aGUgbGlidmlydC1wcmV2aWV3IHJlcG8g KGZvciBsaXZlIG1lcmdlKTwvZGl2Pg0KPGRpdj5TdG9yYWdlIC0mZ3Q7IENlbnRPUyA3LjEgd2l0 aCBnbHVzdGVyIDMuNi4zPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DYW4gYW55b25l IHBvaW50IHVzIHRvd2FyZHMgdGhlIHJpZ2h0IGRpcmVjdGlvbjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tb2VyZW4mbmJzcDs8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_--

1 0

Missing CPU features
by Bloemen, Jurriën 20 May '15

20 May '15

--_000_D180F3484A93jurrienbloemendmcamcnetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I try to add a new host to a new cluster but I get this message: Host <hostname> moved to Non-Operational state as host does not meet the cl= uster's minimum CPU level. Missing CPU features : model_Haswell The engine.log shows: 2015-05-19 13:54:09,843 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock [exc= lusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS , sharedLocks=3D ] 2015-05-19 13:54:09,868 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: ActivateVd= sCommand internal: false. Entities affected : ID: 1ac98a04-41ed-40b7-8f02-= e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN 2015-05-19 13:54:09,869 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock in or= der to prevent monitoring for host <hostname> from data-center DMC 2015-05-19 13:54:09,870 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from now a m= onitoring of host will be skipped for host <hostname> from data-center DMC 2015-05-19 13:54:09,885 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVdsStat= usVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-40b7-8f02-e1= b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailur= eLogged=3Dfalse), log id: 3ec2e03a 2015-05-19 13:54:09,890 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetVdsSta= tusVDSCommand, log id: 3ec2e03a 2015-05-19 13:54:09,920 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Lock rel= eased. Monitoring can run now for host <hostname> from data-center DMC 2015-05-19 13:54:09,923 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Cor= relation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Call St= ack: null, Custom Event ID: -1, Message: Host <hostname> was activated by a= dmin@internal. 2015-05-19 13:54:09,926 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object Engine= Lock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VD= S , sharedLocks=3D ] 2015-05-19 13:54:11,706 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge= tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] STAR= T, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-4= 1ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac98a04-41ed-40b7-8f02-e= 1b9cbbc5480]), log id: 32ca13a8 2015-05-19 13:54:11,712 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge= tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] FINI= SH, GetHardwareInfoVDSCommand, log id: 32ca13a8 2015-05-19 13:54:11,726 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] = (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is running wi= th disabled SELinux. 2015-05-19 13:54:11,748 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsO= rClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] Runni= ng command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entiti= es affected : ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,772 INFO [org.ovirt.engine.core.bll.SetNonOperationalV= dsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running command: S= etNonOperationalVdsCommand internal: true. Entities affected : ID: 1ac98a0= 4-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,786 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVdsStat= usVDSCommand(HostName =3D <hostname> HostId =3D 1ac98a04-41ed-40b7-8f02-e1= b9cbbc5480, status=3DNonOperational, nonOperationalReason=3DCPU_TYPE_INCOMP= ATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4 2015-05-19 13:54:11,789 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetVdsSta= tusVDSCommand, log id: 24054dd4 2015-05-19 13:54:11,796 WARN [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor= relation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message: Host= <hostname> moved to Non-Operational state as host does not meet the cluste= r's minimum CPU level. Missing CPU features : model_Haswell 2015-05-19 13:54:11,813 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor= relation ID: null, Call Stack: null, Custom Event ID: -1, Message: Status o= f host <hostname> was set to NonOperational. 2015-05-19 13:54:11,839 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCo= mmand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: Handle= VdsVersionCommand internal: true. Entities affected : ID: 1ac98a04-41ed-40= b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,841 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-41ed-4= 0b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOperational status for = reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is = skipped. It says that the host has not meet the minimum CPU level. =93lscpu" has the= following output: # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 56 On-line CPU(s) list: 0-55 Thread(s) per core: 2 Core(s) per socket: 14 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 63 Model name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz Stepping: 2 CPU MHz: 1957.007 BogoMIPS: 5206.30 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 35840K NUMA node0 CPU(s): 0-13,28-41 NUMA node1 CPU(s): 14-27,42-55 This model is a haswell: http://ark.intel.com/products/81059/Intel-Xeon-Pro= cessor-E5-2697-v3-35M-Cache-2_60-Ghz<http://ark.intel.com/products/81059/In= tel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz> and http://ark.intel.com/= products/codename/42174/Haswell#@All Is this a bug? Should I make a bug report at bugzilla for this? Or am I mis= sing something? Kind regards, Jurri=EBn Bloemen This message (including any attachments) may contain information that is pr= ivileged or confidential. If you are not the intended recipient, please not= ify the sender and delete this email immediately from your systems and dest= roy all copies of it. You may not, directly or indirectly, use, disclose, d= istribute, print or copy this email or any part of it if you are not the in= tended recipient --_000_D180F3484A93jurrienbloemendmcamcnetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <42B749253886BC48BF746A5ED0F34094(a)chellomedia.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Hi all,</div> <div><br> </div> <div>I try to add a new host to a new cluster but I get this message:</div> <div><br> </div> <div>Host <hostname> moved to Non-Operational state as host does not = meet the cluster's minimum CPU level. Missing CPU features : model_Haswell<= /div> <div><br> </div> <div>The engine.log shows:</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,843 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock= [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS</p= > <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> , sharedLocks=3D ]</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,868 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: Activ= ateVdsCommand internal: false. Entities affected :  ID: 1ac98a04-41ed-= 40b7-8f02-e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,869 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock = in order to prevent monitoring for host <hostname> from data-center D= MC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,870 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from no= w a monitoring of host will be skipped for host <hostname> = from data-center DMC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,885 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVd= sStatusVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-4= 0b7-8f02-e1b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailureLogged=3Dfalse), log id: 3ec2e03a</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,890 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetV= dsStatusVDSCommand, log id: 3ec2e03a</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,920 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Loc= k released. Monitoring can run now for host <hostname> from data-cent= er DMC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,923 INFO  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90= ] Correlation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Ca= ll Stack: null, Custom Event ID: -1, Message: Host <hostname> was activated by admin@internal.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,926 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object E= ngineLock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 valu= e: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> , sharedLocks=3D ]</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,706 INFO  [org.ovirt.engine.core.vdsbroker.vdsbrok= er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]= START, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostI= d =3D 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac= 98a04-41ed-40b7-8f02-e1b9cbbc5480]), log id: 32ca13a8</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,712 INFO  [org.ovirt.engine.core.vdsbroker.vdsbrok= er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]= FINISH, GetHardwareInfoVDSCommand, log id: 32ca13a8</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,726 WARN  [org.ovirt.engine.core.vdsbroker.VdsMana= ger] (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is= running with disabled SELinux.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,748 INFO  [org.ovirt.engine.core.bll.HandleVdsCpuF= lagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] = Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. E= ntities affected :  ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,772 INFO  [org.ovirt.engine.core.bll.SetNonOperati= onalVdsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running comma= nd: SetNonOperationalVdsCommand internal: true. Entities affected :  I= D: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,786 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVd= sStatusVDSCommand(HostName =3D <hostname>  HostId =3D 1ac98= a04-41ed-40b7-8f02-e1b9cbbc5480, status=3DNonOperational, nonOperationalRea= son=3DCPU_TYPE_INCOMPATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,789 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetV= dsStatusVDSCommand, log id: 24054dd4</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,796 WARN  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219= ] Correlation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message:= Host <hostname> moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU f= eatures : model_Haswell</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,813 INFO  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219= ] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Sta= tus of host <hostname> was set to NonOperational.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,839 INFO  [org.ovirt.engine.core.bll.HandleVdsVers= ionCommand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: H= andleVdsVersionCommand internal: true. Entities affected :  ID: 1ac98a= 04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,841 INFO  [org.ovirt.engine.core.vdsbroker.VdsUpda= teRunTimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-4= 1ed-40b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOp= erational status for reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is skipped.</p> </div> <div><br> </div> <div>It says that the host has not meet the minimum CPU level. =93lscpu&quo= t; has the following output:</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> # lscpu</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Architecture:          x86_64</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU op-mode(s):        32-bit, 64-bit</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Byte Order:            Little Endian</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU(s):                56</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> On-line CPU(s) list:   0-55</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Thread(s) per core:    2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Core(s) per socket:    14</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Socket(s):             2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node(s):          2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Vendor ID:             GenuineIntel</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU family:            6</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Model:                 63</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Model name:            Intel(R) Xeon(R) CPU E= 5-2697 v3 @ 2.60GHz</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Stepping:              2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU MHz:               1957.007</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> BogoMIPS:              5206.30</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Virtualization:        VT-x</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L1d cache:             32K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L1i cache:             32K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L2 cache:              256K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L3 cache:              35840K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node0 CPU(s):     0-13,28-41</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node1 CPU(s):     14-27,42-55</p> </div> <div><br> </div> <div>This model is a haswell: <a href=3D"http://ark.intel.com/products= /81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz">http://ark.intel= .com/products/81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-Ghz</a>&= nbsp;and <a href=3D"http://ark.intel.com/products/codename/42174/Haswe= ll#@All">http://ark.intel.com/products/codename/42174/Haswell#@All</a></div= > <div><br> </div> <div>Is this a bug? Should I make a bug report at bugzilla for this? Or am = I missing something?</div> <div><br> </div> <div>Kind regards,</div> <div><br> </div> <div>Jurri=EBn Bloemen</div> This message (including any attachments) may contain information that is pr= ivileged or confidential. If you are not the intended recipient, please not= ify the sender and delete this email immediately from your systems and dest= roy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy this emai= l or any part of it if you are not the intended recipient </body> </html> --_000_D180F3484A93jurrienbloemendmcamcnetworkscom_--

2 2