July 2015 - Devel - oVirt List Archives

new git repo request: ovirt-setup-lib
by Sandro Bonazzola 13 Jul '15

13 Jul '15

Please create a new repo "ovirt-setup-lib" which will contain code shared between ovirt-hosted-engine-setup and ovirt-engine setup. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Problem with latest vdsm update on Fedora 21
by David Maroshi 12 Jul '15

12 Jul '15

Greetings team, I experience failure trying to update my host. From ovirt-master-snapshot repo. # yum update vdsm .... Error: Package: vdsm-4.17.0-1114.git30a0d1c.el7.noarch (ovirt-master-snapshot) Requires: python >= 2.7.5-18.el7_1.1 ^^^^^^^^^^^ Installed: python-2.7.5-16.el7.x86_64 (@anaconda/7.1) ^^^^^^^^^^^^^^ python = 2.7.5-16.el7 Please update the repo for Fedora 21. Thanks Joy and happiness Dudi -- Dudi Maroshi Software Engineer Red Hat Enterprise Virtualization project http://www.redhat.com/en/technologies/virtualization maroshi(a)redhat.com -------------------------------- I am perfectly imperfect. "There is only one absolute truth, and that is: there in no one absolute truth."

5 7

Reaming VdcFault to EngineFault
by Eli Mesika 12 Jul '15

12 Jul '15

You may get the following error after rebase with master : http://pastebin.test.redhat.com/295552 The reason is that the CommandEntity has a memeber of type VdcReturnValueBase which contains the VdcFault. It is serialized by jackson into the db, and when there is an attempt to deserialize it - you got the error. This can be addressed by a simple update command followed by engine restart: psql -U <user> -c "update command_entities set return_value = replace(return_value,'VdcFault','EngineFault'), return_value_class = replace(return_value_class,'VdcFault','EngineFault');" <db> Please let me know if you have any issues. Thanks Eli Mesika

3 5

ovirt-node specfile update
by Fabian Deutsch 09 Jul '15

09 Jul '15

Hey, just a quick head's up that I did some bigger changes to the ovirt-node specfile. In case that our CI goes red or the (node) world goes down you now know what is happening. Greetings fabian

1 0

Pools are create without vms
by Jakub Niedermertl 09 Jul '15

09 Jul '15

Hi, when I create new pool in engine, no matter how many wms are specified, it is created with zero vms. Anyone experiencing similar problem? Engine commit: 9b82e80 Engine log: 2015-07-08 17:57:44,332 INFO [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [4f71760c] Running command: AddVmPoolWithVmsCommand internal: false. Entities affected : ID: 00000002-0002-0002-0002-00000000026d Type: VdsGroupsAction group CREATE_VM_POOL with role type USER, ID: 53d01889-42ca-4956-8f02-4cdea7078248 Type: VmTemplateAction group CREATE_VM with role type USER 2015-07-08 17:57:44,446 ERROR [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [] Command 'org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand' failed: java.lang.NullPointerException 2015-07-08 17:57:44,446 ERROR [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [] Exception: javax.ejb.EJBException: java.lang.NullPointerException at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInNoTx(CMTTxInterceptor.java:216) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:262) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:399) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) 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.bll.interfaces.BackendInternal$$$view4.runInternalAction(Unknown Source) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2342) [bll.jar:] at org.ovirt.engine.core.bll.CommonVmPoolWithVmsCommand.addVmsToPool(CommonVmPoolWithVmsCommand.java:161) [bll.jar:] at org.ovirt.engine.core.bll.CommonVmPoolWithVmsCommand.executeCommand(CommonVmPoolWithVmsCommand.java:144) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1212) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1356) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1979) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1392) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:375) [bll.jar:] at org.ovirt.engine.core.bll.MultipleActionsRunner.executeValidatedCommand(MultipleActionsRunner.java:202) [bll.jar:] at org.ovirt.engine.core.bll.MultipleActionsRunner.runCommands(MultipleActionsRunner.java:170) [bll.jar:] at org.ovirt.engine.core.bll.MultipleActionsRunner$2.run(MultipleActionsRunner.java:179) [bll.jar:] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:92) [utils.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_45] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] Caused by: java.lang.NullPointerException at org.ovirt.engine.core.bll.CommandBase.parentHasCallback(CommandBase.java:1369) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1382) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:375) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:651) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45] at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:260) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final] ... 60 more 2015-07-08 17:57:44,452 INFO [org.ovirt.engine.core.bll.AddVmPoolWithVmsCommand] (org.ovirt.thread.pool-8-thread-29) [] Command [id=6e59f612-ebe5-4a14-9311-dfa786c32396]: Compensating CHANGED_STATUS_ONLY of org.ovirt.engine.core.common.businessentities.VmTemplate; snapshot: EntityStatusSnapshot:{id='53d01889-42ca-4956-8f02-4cdea7078248', status='OK'}. 2015-07-08 17:57:44,458 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-29) [] Correlation ID: 4f71760c, Job ID: 2a5c64aa-2c78-4beb-a2a0-17651f8fe916, Call Stack: null, Custom Event ID: -1, Message: VM Pool qq (containing 3 VMs) was created by admin@internal. Best regards, Jakub

2 1

ovirt-engine related fedora 21 builds in jenkins
by Sandro Bonazzola 09 Jul '15

09 Jul '15

Hi, while dropping fc20 builds from master as announced 2 weeks ago[1] I've seen that several packages implying ovirt-engine availability on fc21 were still built on jenkins also if we dropped fc21 support for 3.6 in favor of fc22. Since there's no commitment from integration team and from infrastructure / CI team to support FC21 I would have liked to drop them. I've been stopped doing that since it seems there are developers using fc21 as development environment. I'd like to understand why. I would have understood having developers stuck on fedora 20 for supporting 3.5 and I totally understand developers already on fedora 22. But being fedora 21 the only unsupported version I don't see any real reason for keep wasting CI resources on such distribution. Is there any serious motivation for keeping fedora 21 engine related builds in jenkins? I may understand keeping vdsm related builds since vdsm is supposed to work on fc21 also for 3.5 so i've no objection in keeping vdsm and its deps on fc21 as long as vdsm team supports it. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 6

Renamed classes
by Eli Mesika 08 Jul '15

08 Jul '15

Hi Please note that the following classes were renamed : *DAODbFacadeImpl.java => *DaoImpl.java VdsIdParametersBase => IdQueryableParameter VdcBllErrors => EngineBllError VdcBllMessages => EngineBllMessage VdcFault => EngineFault Thanks Eli Mesika

1 0

VM won't start because of -incoming flag after upgrading to alpha-2
by Christopher Pereira 08 Jul '15

08 Jul '15

This is a multi-part message in MIME format. --------------040500060504070207030504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, After upgrading from alpha-1 to alpha-2 and restarting services, a VM won't start because of the following qemu error: Domain id=5 is tainted: hook-script 2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0 qemu: warning: error while loading state section id 2 2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed: Invalid argument The reason is that Engine was starting the VM with the -incoming flag (for "incoming migrations"). 1) Why did engine enable the -incoming flag? VM was configured with "Allow manual migration only". Maybe this ocurred because I set the host in maintenance mode before upgrading. 2) How can I clean the -incoming flag in oVirt? 3) Note that the "domain is tainted" error was also freezing the monitor socket between libvirt and vdsm, requiring a libvirtd + vdsmd restart. --------------040500060504070207030504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi, After upgrading from alpha-1 to alpha-2 and restarting services, a VM won't start because of the following qemu error: <blockquote>Domain id=5 is tainted: hook-script 2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0 qemu: warning: error while loading state section id 2 2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed: Invalid argument </blockquote> The reason is that Engine was starting the VM with the -incoming flag (for "incoming migrations"). 1) Why did engine enable the -incoming flag? VM was configured with "Allow manual migration only". Maybe this ocurred because I set the host in maintenance mode before upgrading. 2) How can I clean the -incoming flag in oVirt? 3) Note that the "domain is tainted" error was also freezing the monitor socket between libvirt and vdsm, requiring a libvirtd + vdsmd restart. </body> </html> --------------040500060504070207030504--

5 14

oVirt Node Weekly Meeting Minutes - 2015-07-06
by Fabian Deutsch 06 Jul '15

06 Jul '15

================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 14:04:04 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2015/ovirt.2015-07-06-14.04.log.html . Meeting summary --------------- * Agenda (fabiand, 14:06:04) * Jenkins status (fabiand, 14:06:12) * Other Items (fabiand, 14:06:16) * Jenkins status (fabiand, 14:06:21) * we now have all of our jobs (ovirt-node and the plugins) yamlized (fabiand, 14:08:07) * ACTION: tlitovsk to let us know the status of the publishers (fabiand, 14:10:00) * All master publishers are done (fabiand, 14:11:42) * ACTION: tlitovsk to modify the builds to let the rpms include the git hashes (fabiand, 14:13:57) * ACTION: rbarry to modify the jobs to extract the rpm manifest from the iso (fabiand, 14:14:16) Meeting ended at 14:16:47 UTC. Action Items ------------ * tlitovsk to let us know the status of the publishers * tlitovsk to modify the builds to let the rpms include the git hashes * rbarry to modify the jobs to extract the rpm manifest from the iso Action Items, by person ----------------------- * rbarry * rbarry to modify the jobs to extract the rpm manifest from the iso * tlitovsk * tlitovsk to let us know the status of the publishers * tlitovsk to modify the builds to let the rpms include the git hashes * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (47) * tlitovsk (7) * rbarry (5) * dougsland (2) * ovirtbot (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Shared gluster storage domain for templates
by Christopher Pereira 04 Jul '15

04 Jul '15

Hi, I'm trying to setup a gluster data storage domain exclusively for templates (read only) and share it among different geo distributed ovirt data centers. I believe this is a common requirement. Do you know if there is a clean/efficient way to do this? My experiment: I geo-replicated the templates storage domain in order to keep a local copy on each data center for faster new VM instantiation or thin template provisioning. The problem I faced is it's not possible to import a replicated storage domain when the original Storage Domain UUID is already registered in the same Engine installation. A workarround was to detach the original SD (from Data Center 1) and attach the replicated SD (on Data Center 2)...or use another Engine installation. This works, but still requires to detach and reattach the storage domain. Is there anyway to copy a storage domain or change its UUID? I guess I can change the Storage Domain UUID (dirname and dom_md/metadata), but I'm afraid of the multiple references inside the binary file 'dom_md/ids'. BTW, using a gluster replica-n volume seems to be the cleanest solution because this way Engine would only be showing one single templates storage domain (ideal). The only reason I didn't go this way is because it is not designed between geo distributed data networks.

2 1