- Devel - oVirt List Archives

[VDSM] Support for external leases - possible breakage with development version
by Nir Soffer 24 Dec '16

24 Dec '16

Hi all, I merged today the last patches for supporting external leases. In storage domain version 4 (the default in ovirt 4.1), there is now a new volume named "xleases". When upgrading older storage domain (version 3), we create and format the new volume. If you used a development version with storage domain version 4, your storage domain may not work with current master. You should recreated such storage domain. As a workaround, you can create the special volume manually: File storage: sudo -u vdsm truncate -s 1G /rhev/data-center/mnt/server:_path/domain_uuid/dom_md/xleases Block storage: lvcreate --name xleases --size 1g domain_uuid Note that the volume should be also be formatted to actually use external leases, but having it should be good enough to keep the system happy. Thanks, Nir

1 1

Re: [ovirt-devel] System tests for 4.1 currently failing to run VMs!
by Oved Ourfali 22 Dec '16

22 Dec '16

Why not run it via Jenkins for patches? Like, if you add a comment saying "run: ost" it will run it? It do it automatically based on another thing? On Dec 21, 2016 17:42, "Eyal Edri" <eedri(a)redhat.com> wrote: > > > > On Wed, Dec 21, 2016 at 5:36 PM, Michal Skrivanek < michal.skrivanek(a)redhat.com> wrote: >> >> >>> On 21 Dec 2016, at 16:25, Yaniv Kaul <ykaul(a)redhat.com> wrote: >>> >>> >>> >>> On Wed, Dec 21, 2016 at 5:19 PM, Michal Skrivanek < michal.skrivanek(a)redhat.com> wrote: >>>> >>>> >>>>> On 21 Dec 2016, at 14:56, Michal Skrivanek < michal.skrivanek(a)redhat.com> wrote: >>>>> >>>>> >>>>>> On 21 Dec 2016, at 12:19, Eyal Edri <eedri(a)redhat.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 21, 2016 at 12:56 PM, Vinzenz Feenstra < vfeenstr(a)redhat.com> wrote: >>>>>>> >>>>>>> >>>>>>>> On Dec 21, 2016, at 11:17 AM, Barak Korren <bkorren(a)redhat.com> wrote: >>>>>>>> >>>>>>>> The test for running VMs had been failing since yesterday. >>>>>>>> >>>>>>>> The patch merged before the failures started was: >>>>>>>> https://gerrit.ovirt.org/#/c/68826/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The error we`re seeing is a time-out (after two minutes) while running >>>>>>>> this API call: >>>>>>>> >>>>>>>> api.vms.get(VM0_NAME).status.state == ‘up' >>>>>>> >>>>>>> >>>>>>> This is a REST API call, the patch above is Frontend. So this is unrelated. >>>>>>> >>>>>>> However on Host 0 I can see this: >>>>>>> >>>>>>> 2016-12-20 16:54:43,544 ERROR (vm/d299ab29) [virt.vm] (vmId='d299ab29-284a-435c-a50f-183a6e54def2') The vm start process failed (vm:615) Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 551, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 1991, in _run self._connection.createXML(domxml, flags), File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 941, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3782, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: 2016-12-20T21:54:43.044971Z qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 2016-12-20T21:54:43.045164Z qemu-kvm: warning: All CPU(s) up to maxcpus should be described in NUMA config 2016-12-20T21:54:43.101886Z qemu-kvm: -device usb-ccid,id=ccid0,bus=usb.0,port=1: Warning: speed mismatch trying to attach usb device "QEMU USB CCID" (full speed) to bus "usb.0", port "1" (high speed) >>>>> >>>>> >>>>> it is likely related to the recent USB patches >>>>> investigating >>>> >>>> >>>> hm, there are multiple problems (features/bugs depending on prefferred point of view:) >>>> but there is an easy “fix” taking care of this particular problem, so we can start with that and figure out the proper approach later >>>> arik will push that and merge it soon, likely today >>> >>> >>> Thanks - if there is a quicker way to resolve this by reverting, I think it's a better option. >> >> >> I really need to talk you out of this approach:-) >> It does sound tempting and logical, but with our development model of large patch series combined with late detection it really is quite risky. Here it wouldn’t help much…and figuring out the right revert patch is more complicated then fixing it. > > > Can we start asking developers run OST before they merge so it will be early detection and not late detection? > We have video sessions on how to use OST, so it shouldn't be any issues in running it on a patch. > >> >> I believe the best is to identify it early and notify the maintainer who merged that patch ASAP, as that person is in the best position to asses if revert is safe or if there is a simple follow up patch he can push right away >> >> We can surely improve on reporting, so Barak, how/why did you point to that particular patch in your email? It should start failing on 16c2ec236184b3152f1df8e874b43115f78d0989 (CommitDate: Fri Dec 16 01:56:07 2016 -0500) >> Even though it may be that it was hidden because of c46f653a7846c3c2a76507b8dcf5bc0391ec5709 (CommitDate: Mon Dec 19 15:16:40 2016 -0500) >> >> (fix is ready, waiting on CI now) >> >> Thanks, >> michal >> >>> Y. >>> >>>> >>>> >>>>>>> 2016-12-20 16:54:43,550 INFO (vm/d299ab29) [virt.vm] (vmId='d299ab29-284a-435c-a50f-183a6e54def2') Changed state to Down: internal error: process exited while connecting to monitor: 2016-12-20T21:54:43.044971Z qemu-kvm: warning: CPU(s) not present in any NUMA nodes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 2016-12-20T21:54:43.045164Z qemu-kvm: warning: All CPU(s) up to maxcpus should be described in NUMA config 2016-12-20T21:54:43.101886Z qemu-kvm: -device usb-ccid,id=ccid0,bus=usb.0,port=1: Warning: speed mismatch trying to attach usb device "QEMU USB CCID" (full speed) to bus "usb.0", port "1" (high speed) (code=1) (vm:1197) 2016-12-20 16:54:43,550 INFO (vm/d299ab29) [virt.vm] (vmId='d299ab29-284a-435c-a50f-183a6e54def2') Stopping connection (guestagent:430) >>>>>>> >>>>>>> >>>>>>> >>>>>>> And on The engine loads of these: >>>>>>> >>>>>>> 2016-12-20 16:53:57,844-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-17) [5ecd5a55-2b7a-4dd6-b42b-cc49bbfb3962] Command 'PollVDSCommand(HostName = lago-basic-suite-4-1-host0, VdsIdVDSCommandParametersBase:{runAsync='true', hostId='994b5d79-605f-4415-94f2-02c79cfa246e'})' execution failed: VDSGenericException: VDSNetworkException: Timeout during rpc call 2016-12-20 16:53:57,849-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (SSL Stomp Reactor) [7971dfb4] MESSAGE content-length:80 destination:jms.topic.vdsm_responses content-type:application/json subscription:5b6494d5-d5a0-4771-941c-a8be70f72450 {"jsonrpc": "2.0", "id": "3c95fdb0-5b77-4927-9f6e-adc7395c122d", "result": true}� 2016-12-20 16:53:57,850-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker] (ResponseWorker) [] Message received: {"jsonrpc": "2.0", "id": "3c95fdb0-5b77-4927-9f6e-adc7395c122d", "result": true} 2016-12-20 16:53:57,850-05 ERROR [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for "3c95fdb0-5b77-4927-9f6e-adc7395c122d" 2016-12-20 16:53:57,844-05 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-17) [5ecd5a55-2b7a-4dd6-b42b-cc49bbfb3962] Exception: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: VDSGenericException: VDSNetworkException: Timeout during rpc call at org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:73) [vdsbroker.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.getValue(HostSetupNetworkPoller.java:56) [bll.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(HostSetupNetworkPoller.java:41) [bll.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:426) [bll.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.executeCommand(HostSetupNetworksCommand.java:287) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1249) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1389) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2053) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1449) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:395) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:511) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:493) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:446) [bll.jar:] at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) [:1.8.0_111] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_111] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_111] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.1.0.Final.jar:10.1.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.1.0.Final.jar:10.1.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.jar:10.1.0.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) [:1.8.0_111] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_111] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_111] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.3.5.Final.jar:2.3.5.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:374) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view4.runAction(Unknown Source) [common.jar:] at org.ovirt.engine.api.restapi.resource.BackendResource.doAction(BackendResource.java:250) at org.ovirt.engine.api.restapi.resource.BackendResource.performAction(BackendResource.java:182) at org.ovirt.engine.api.restapi.resource.BackendResource.performAction(BackendResource.java:170) at org.ovirt.engine.api.restapi.resource.BackendHostResource.setupNetworks(BackendHostResource.java:212) at org.ovirt.engine.api.v3.V3Server.adaptAction(V3Server.java:216) at org.ovirt.engine.api.v3.servers.V3HostServer.setupNetworks(V3HostServer.java:182) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_111] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_111] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_111] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_111] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:221) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:147) at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111) at org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:139) at org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:68) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:116) at org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:71) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:78) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:39) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SsoRestApiNegotiationFilter.doFilter(SsoRestApiNegotiationFilter.java:91) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter.doFilter(SsoRestApiAuthFilter.java:47) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:59) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:35) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:111) at org.ovirt.engine.api.restapi.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:102) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.security.CORSSupportFilter.doFilter(CORSSupportFilter.java:183) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111] 2016-12-20 16:53:57,859-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-17) [5ecd5a55-2b7a-4dd6-b42b-cc49bbfb3962] Timeout waiting for VDSM response: Internal timeout occured >>>>>>> >>>>>>> >>>>>>> This is definitely not related to the patch linked above. >>>>>>> >>>>>>> However I am also not quite sure what is the cause of this right now, it might be a breaking change in VDSM. >>>>>>> >>>>>> >>>>>> The DC level is 4.0, is it possible that is the reason for the failure? >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Full test code can be seen here: >>>>>>>> https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=blob;f=basic-sui… >>>>>>>> >>>>>>>> Full test exception can be seen here: >>>>>>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/13/testReport… >>>>>>>> >>>>>>>> Further logs can be seen in Jenkins: >>>>>>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/13/artifact/e… >>>>>>>> >>>>>>>> -- >>>>>>>> Barak Korren >>>>>>>> bkorren(a)redhat.com >>>>>>>> RHCE, RHCi, RHV-DevOps Team >>>>>>>> https://ifireball.wordpress.com/ >>>>>>>> _______________________________________________ >>>>>>>> Devel mailing list >>>>>>>> Devel(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Eyal Edri >>>>>> Associate Manager >>>>>> RHV DevOps >>>>>> EMEA ENG Virtualization R&D >>>>>> Red Hat Israel >>>>>> >>>>>> phone: +972-9-7692018 >>>>>> irc: eedri (on #tlv #rhev-dev #rhev-integ) >>>>>> _______________________________________________ >>>>>> Devel mailing list >>>>>> Devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >> > > > > -- > Eyal Edri > Associate Manager > RHV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel

6 11

Re: [ovirt-devel] [RFE] treat local NFS storage as localfs
by Pavel Gashev 22 Dec '16

22 Dec '16

On Wed, 2016-12-21 at 16:25 +0100, Martin Sivak wrote: > > So VMs on one host will get better IO performance and the others will > still use NFS as they do now. Performance is not an issue when all I/O bound VMs are co-located with disks. If all VMs are I/O bound, all hosts in a cluster can use local storage. > It is an interesting idea, I am just not sure if having poor-man's > hyperconverged setup with all the drawbacks of NFS is worth it. > Imagine for example what happens when that storage provider host > needs > to be fenced or put into maintenance. The whole cluster would go down > (all VMs would lose storage connection, not just the VMs from the > affected host). Losing a server together with a storage could be an issue, or not. It really depends on setup. At least it would be good to provide such feature :) > I will let someone from the storage team to respond to this, but I do > not think that trading performance (each host has its own local > storage) and resilience (well, at least one failing host does not > affect the others) for migrations is a good deal. > > -- > Martin Sivak > SLA / oVirt > > On Wed, Dec 21, 2016 at 2:18 PM, Sven Kieske <s.kieske(a)mittwald.de> > wrote: > > > > On 21/12/16 11:44, Pavel Gashev wrote: > > > > > > Hello, > > > > > > I'd like to introduce a RFE that allows to use a local storage in > > > multi > > > server environments https://bugzilla.redhat.com/show_bug.cgi?id=1 > > > 406412 > > > > > > Most servers have a local storage. Some servers have very > > > reliable > > > storages with hardware RAID controllers and battery units. > > > > > > Example user cases: > > > https://www.mail-archive.com/users@ovirt.org/msg36719.html > > > https://www.mail-archive.com/users@ovirt.org/msg36772.html > > > > > > The best way to use local storage in multi server "shared" > > > datacenters > > > is exporting it over NFS. Using NFS allows to move disks and VMs > > > among > > > servers. > > > > > > In order to improve performance, disk I/O bound VMs can be pinned > > > to > > > a host with local storage. However there still is a performance > > > drawback of NFS layers. Treating a local NFS storage as a local > > > storage > > > improves performance for VMs pinned to host. > > > > > > Currently setting up of NFS exports is out of scope of oVirt. > > > However > > > this would be a way to get rid of "Local/Shared" storage types of > > > datacenter. So that all storages are shared, but local storages > > > are > > > used as local. > > > > > > Any questions/comments are welcome. > > > > > > Specifically I'd like to request for comment on potential data > > > integrity issues during online VM or disk migration between NFS > > > and > > > localfs. > > > > > > > Just let me say that I really like this as an end user. > > > > Hope this get's in. This seems less overhead than a complete > > hyperconverged gluster setup. > > > > > > -- > > Mit freundlichen Grüßen / Regards > > > > Sven Kieske > > > > Systemadministrator > > Mittwald CM Service GmbH & Co. KG > > Königsberger Straße 6 > > 32339 Espelkamp > > T: +495772 293100 > > F: +495772 293333 > > https://www.mittwald.de > > Geschäftsführer: Robert Meyer > > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad > > Oeynhausen > > Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad > > Oeynhausen > > > > > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel

1 0

Re: [ovirt-devel] [RFE] treat local NFS storage as localfs
by Michal Skrivanek 22 Dec '16

22 Dec '16

> On 21 Dec 2016, at 16:26, Martin Sivak <msivak(a)redhat.com> wrote: > > Hi, > >> Hope this get's in. This seems less overhead than a complete >> hyperconverged gluster setup. > > But NFS still is a single point of failure. Hyperconverged is supposed > to address that. > >>> In order to improve performance, disk I/O bound VMs can be pinned to >>> a host with local storage. However there still is a performance >>> drawback of NFS layers. Treating a local NFS storage as a local storage >>> improves performance for VMs pinned to host. > > So VMs on one host will get better IO performance and the others will > still use NFS as they do now. > > It is an interesting idea, I am just not sure if having poor-man's > hyperconverged setup with all the drawbacks of NFS is worth it. > Imagine for example what happens when that storage provider host needs > to be fenced or put into maintenance. The whole cluster would go down > (all VMs would lose storage connection, not just the VMs from the > affected host). > > I will let someone from the storage team to respond to this, but I do > not think that trading performance (each host has its own local > storage) and resilience (well, at least one failing host does not > affect the others) for migrations is a good deal. If disk performance is critical then there is an option to use direct access on local host using either PCI passthrough of a local storage controller or SCSI passthrough of LUNs. > > -- > Martin Sivak > SLA / oVirt > >> On Wed, Dec 21, 2016 at 2:18 PM, Sven Kieske <s.kieske(a)mittwald.de> wrote: >>> On 21/12/16 11:44, Pavel Gashev wrote: >>> Hello, >>> >>> I'd like to introduce a RFE that allows to use a local storage in multi >>> server environments https://bugzilla.redhat.com/show_bug.cgi?id=1406412 >>> >>> Most servers have a local storage. Some servers have very reliable >>> storages with hardware RAID controllers and battery units. >>> >>> Example user cases: >>> https://www.mail-archive.com/users@ovirt.org/msg36719.html >>> https://www.mail-archive.com/users@ovirt.org/msg36772.html >>> >>> The best way to use local storage in multi server "shared" datacenters >>> is exporting it over NFS. Using NFS allows to move disks and VMs among >>> servers. >>> >>> In order to improve performance, disk I/O bound VMs can be pinned to >>> a host with local storage. However there still is a performance >>> drawback of NFS layers. Treating a local NFS storage as a local storage >>> improves performance for VMs pinned to host. >>> >>> Currently setting up of NFS exports is out of scope of oVirt. However >>> this would be a way to get rid of "Local/Shared" storage types of >>> datacenter. So that all storages are shared, but local storages are >>> used as local. >>> >>> Any questions/comments are welcome. >>> >>> Specifically I'd like to request for comment on potential data >>> integrity issues during online VM or disk migration between NFS and >>> localfs. >>> >> >> Just let me say that I really like this as an end user. >> >> Hope this get's in. This seems less overhead than a complete >> hyperconverged gluster setup. >> >> >> -- >> Mit freundlichen Grüßen / Regards >> >> Sven Kieske >> >> Systemadministrator >> Mittwald CM Service GmbH & Co. KG >> Königsberger Straße 6 >> 32339 Espelkamp >> T: +495772 293100 >> F: +495772 293333 >> https://www.mittwald.de >> Geschäftsführer: Robert Meyer >> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen >> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen >> >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > >

3 3

Branching Vdsm to ovirt-4.1
by Yaniv Bronheim 22 Dec '16

22 Dec '16

Hello devels, I just introduced ovirt-4.1 branch in vdsm - which will be the base for ovirt-4.1 alpha build. Now master is tagged v4.20.0 and first ovirt-4.1 tag is v4.19.1. Basically it means that every fix that should be in 4.1 needs to be backported and merged to ovirt-4.1 branch by fromani or me. We both in #vdsm so ping us if needed and add us to the patches. Bare in mind that in most of the cases we will ask for Bug-Url link in the commit message and same commit-id as in the master branch patch. For any further questions or wonders feel free to reply. Greetings, -- *Yaniv Bronhaim.*

1 0

Fwd: Fedora 23 End Of Life
by Sandro Bonazzola 21 Dec '16

21 Dec '16

FYI. ---------- Messaggio inoltrato ---------- Da: "Mohan Boddu" <mboddu(a)redhat.com> Data: 21/Dic/2016 04:05 Oggetto: Fedora 23 End Of Life A: <announce(a)lists.fedoraproject.org>, < test-announce(a)lists.fedoraproject.org>, < devel-announce(a)lists.fedoraproject.org> Cc: As of the 20th of December 2016, Fedora 23 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 23. A previous reminder was sent on 28th of November 2016 [0]. Fedora 24 will continue to receive updates until approximately one month after the release of Fedora 26. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions [2] on how to upgrade from a previous release of Fedora to a version receiving updates. Mohan Boddu. [0]https://lists.fedoraproject.org/archives/list/devel@lists. fedoraproject.org/thread/HLHKRTIB33EDZXP624GHF2OZLHWAGKSJ/# Q5O44X4BEBOYEKAEVLSXVI44DSNVHBYG [1]https://fedoraproject.org/wiki/Fedora_Release_Life_ Cycle#Maintenance_Schedule [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

1 0

test mail
by Evgheni Dereveanchin 21 Dec '16

21 Dec '16

Hi, this is a test message to check that archiving is back to normal as part of OVIRT-949 [1] Please ignore. Regards, Evgheni Dereveanchin [1] https://ovirt-jira.atlassian.net/browse/OVIRT-949

1 0

Heads-up: moving Libvirt xml creation to the engine
by Arik Hadas 08 Dec '16

08 Dec '16

Hi All, We are working on something that is expected to have a big impact, hence this heads-up. First, we want you to be aware of this change and provide your feedback to make it as good as possible. Second, until the proposed mechanism is fully merged there will be a chase to cover all features unless new features are also implemented with the new mechanism. So please, if you are working on something that adds/changes something in the Libvirt's domain xml, do it with this new mechanism as well (first version would be merged soon). * Goal Creating Libvirt XML in the engine rather than in VDSM. ** Today's flow Engine: VM business entity -> VM properties map VDSM: VM properties map -> Libvirt XML ** Desired flow Engine: VM business entity -> Libvirt XML * Potential Benefits 1. Reduce the number of conversions from 2 to 1, reducing chances for mistakes in the process. 2. Reduce the amount of code in VDSM. 3. Make VM related changes easier - today many of these changes need to be reviewed in 2 projects, this will eliminate the one that tends to take longer. 4. Prevent shortcuts in the form of VDSM-only changes that should be better reflected in the engine. 5. Not to re-generate the XML on each rerun attempt of VM run/migration. 6. Future - not to re-generate the XML on each attempt to auto-start HA VM when using vm-leases (need to make sure we're using the up-to-date VM configuration though). 7. We already found improvements and cleanups that could be made while touching this area (e.g., remove the boot order from devices in the database). * Challenges 1. Not to move host-specific information to the engine. For example, path to storage domain or sockets of channels. The solution is to use place-holders that will be replaced by VDSM. 2. Backward compatibility. 3. The more challenging part is the other direction - that will be the next phase. * Status As a first step, we began with producing the Libvirt XML in the engine by converting the VM properties map to XML in the engine [1] And using the XML that is received as an input in VDSM [2] [1] https://gerrit.ovirt.org/#/c/64473/ [2] https://gerrit.ovirt.org/#/c/65182/ Regards, Arik

11 24

Red Hat Summit: oVirt Talk(s) Submission
by Brian Proffitt 08 Dec '16

08 Dec '16

One of the big events for the year is the Red Hat Summit, which has a dedicated open source community track for upstream projects. At the very least this is an opportunity to give a "state of the union" talk for the various communities, including oVirt. There are a significant number of downstream-related talks for Summit, but if you would like to submit an oVirt-related talk for the open source community track[1] before the CFP for Summit closes on Dec. 16, please do so! Peace, Brian [1] https://rh2017.smarteventscloud.com/portal/cfp/cfpLogin.ww?sc_cid=701600000… -- Brian Proffitt Principal Community Analyst Open Source and Standards @TheTechScribe 574.383.9BKP

1 0

ovirt-appliance (today) is 1.5G...
by Yaniv Kaul 08 Dec '16

08 Dec '16

I'm sure it was less just days ago, but now[1] it is again quite big. 4.0's is 'only' 1G in size[2]. Which anyway raises the question - should we provide delta RPMs for it? Thanks, Y. [1] http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-e… [2] http://resources.ovirt.org/pub/ovirt-4.0-snapshot/rpm/el7/noarch/ovirt-engi…

3 4