August 2020 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 12 Jan '24

12 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error: Adding new Host to ovirt-engine
by Ahmad Khiet 15 Aug '23

15 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

Purging inactive maintainers from vdsm-master-maintainers
by Nir Soffer 21 Jun '21

21 Jun '21

I want to remove inactive contributors from vdsm-master-maintainers. I suggest the simple rule of 2 years of inactivity for removing from this group, based on git log. See the list below for current status: https://gerrit.ovirt.org/#/admin/groups/106,members Thoughts? Nir

6 11

Merge rights changes in the oVirt Engine project
by Tal Nisan 09 Apr '21

09 Apr '21

Hi everyone, As you probably know we are now in a mode in which we develop our next zstream version on the master branch as opposed to how we worked before where the master version was dedicated for the next major version. This makes the rapid changes in master to be delivered to customers in a much higher cadence thus affecting stability. Due to that we think it's best that from now on merges in the master branch will be done only by stable branch maintainers after inspecting those closely. What you need to do in order to get your patch merged: - Have it pass Jenkins - Have it get code review +2 - Have it mark verified +1 - It's always encourage to have it tested by OST, for bigger changes it's a must Once you have all those covered, please add me as a reviewer and I'll examine it and merge if everything seems right, if I haven't done it in a timely manner feel free to ping me.

3 4

Error Java SDK Issue??
by Geschwentner, Patrick 02 Apr '21

02 Apr '21

Dear Ladies and Gentlemen! I am currently working with the java-sdk and I encountered a problem. If I would like to retrieve the disk details, I get the following error: Disk currDisk = ovirtConnection.followLink(diskAttachment.disk()); The Error is occurring in this line: [cid:image001.png@01D44537.AF127FD0] The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok). Error: wrong number of arguments The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/jav… ). Can you confirm the defect? Best regards Patrick

6 11

CentOS Stream support
by Michal Skrivanek 01 Feb '21

01 Feb '21

Hi all, we would like to ask about interest in community about oVirt moving to CentOS Stream. There were some requests before but it’s hard to see how many people would really like to see that. With CentOS releases lagging behind RHEL for months it’s interesting to consider moving to CentOS Stream as it is much more up to date and allows us to fix bugs faster, with less workarounds and overhead for maintaining old code. E.g. our current integration tests do not really pass on CentOS 8.1 and we can’t really do much about that other than wait for more up to date packages. It would also bring us closer to make oVirt run smoothly on RHEL as that is also much closer to Stream than it is to outdated CentOS. So..would you like us to support CentOS Stream? We don’t really have capacity to run 3 different platforms, would you still want oVirt to support CentOS Stream if it means “less support” for regular CentOS? There are some concerns about Stream being a bit less stable, do you share those concerns? Thank you for your comments, michal

6 12

planned Jenkins restart
by Evgheni Dereveanchin 03 Dec '20

03 Dec '20

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new CI jobs will be scheduled during this maintenance period. I will inform you once it is back online. -- Regards, Evgheni Dereveanchin

2 2

Possible i18n for cockpit-ovirt ?
by Juliette Tux 23 Sep '20

23 Sep '20

Hello, Localizator/translator here :) I have a small question regarding the cockpit-ovirt utility[1]. Are there any plans of adding the i18n into the code to facilitate proper translation of cockpit-ovirt? Thank you! [1] https://resources.ovirt.org/pub/ovirt-4.3/src/cockpit-ovirt/ -- С уважением, Дронова Юлия

3 5

device compatibility interface for live migration with assigned devices
by Yan Zhao 15 Sep '20

15 Sep '20

hi folks, we are defining a device migration compatibility interface that helps upper layer stack like openstack/ovirt/libvirt to check if two devices are live migration compatible. The "devices" here could be MDEVs, physical devices, or hybrid of the two. e.g. we could use it to check whether - a src MDEV can migrate to a target MDEV, - a src VF in SRIOV can migrate to a target VF in SRIOV, - a src MDEV can migration to a target VF in SRIOV. (e.g. SIOV/SRIOV backward compatibility case) The upper layer stack could use this interface as the last step to check if one device is able to migrate to another device before triggering a real live migration procedure. we are not sure if this interface is of value or help to you. please don't hesitate to drop your valuable comments. (1) interface definition The interface is defined in below way: __ userspace /\ \ / \write / read \ ________/__________ ___\|/_____________ | migration_version | | migration_version |-->check migration --------------------- --------------------- compatibility device A device B a device attribute named migration_version is defined under each device's sysfs node. e.g. (/sys/bus/pci/devices/0000\:00\:02.0/$mdev_UUID/migration_version). userspace tools read the migration_version as a string from the source device, and write it to the migration_version sysfs attribute in the target device. The userspace should treat ANY of below conditions as two devices not compatible: - any one of the two devices does not have a migration_version attribute - error when reading from migration_version attribute of one device - error when writing migration_version string of one device to migration_version attribute of the other device The string read from migration_version attribute is defined by device vendor driver and is completely opaque to the userspace. for a Intel vGPU, string format can be defined like "parent device PCI ID" + "version of gvt driver" + "mdev type" + "aggregator count". for an NVMe VF connecting to a remote storage. it could be "PCI ID" + "driver version" + "configured remote storage URL" for a QAT VF, it may be "PCI ID" + "driver version" + "supported encryption set". (to avoid namespace confliction from each vendor, we may prefix a driver name to each migration_version string. e.g. i915-v1-8086-591d-i915-GVTg_V5_8-1) (2) backgrounds The reason we hope the migration_version string is opaque to the userspace is that it is hard to generalize standard comparing fields and comparing methods for different devices from different vendors. Though userspace now could still do a simple string compare to check if two devices are compatible, and result should also be right, it's still too limited as it excludes the possible candidate whose migration_version string fails to be equal. e.g. an MDEV with mdev_type_1, aggregator count 3 is probably compatible with another MDEV with mdev_type_3, aggregator count 1, even their migration_version strings are not equal. (assumed mdev_type_3 is of 3 times equal resources of mdev_type_1). besides that, driver version + configured resources are all elements demanding to take into account. So, we hope leaving the freedom to vendor driver and let it make the final decision in a simple reading from source side and writing for test in the target side way. we then think the device compatibility issues for live migration with assigned devices can be divided into two steps: a. management tools filter out possible migration target devices. Tags could be created according to info from product specification. we think openstack/ovirt may have vendor proprietary components to create those customized tags for each product from each vendor. e.g. for Intel vGPU, with a vGPU(a MDEV device) in source side, the tags to search target vGPU are like: a tag for compatible parent PCI IDs, a tag for a range of gvt driver versions, a tag for a range of mdev type + aggregator count for NVMe VF, the tags to search target VF may be like: a tag for compatible PCI IDs, a tag for a range of driver versions, a tag for URL of configured remote storage. b. with the output from step a, openstack/ovirt/libvirt could use our proposed device migration compatibility interface to make sure the two devices are indeed live migration compatible before launching the real live migration process to start stream copying, src device stopping and target device resuming. It is supposed that this step would not bring any performance penalty as -in kernel it's just a simple string decoding and comparing -in openstack/ovirt, it could be done by extending current function check_can_live_migrate_destination, along side claiming target resources.[1] [1] https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi… Thanks Yan

14 117

[ARM64] Possiblity to support oVirt on ARM64
by Zhenyu Zheng 11 Sep '20

11 Sep '20

Hi oVirt, We are currently trying to make oVirt work on ARM64 platform, since I'm quite new to oVirt community, I'm wondering what is the current status about ARM64 support in the oVirt upstream, as I saw the oVirt Wikipedia page mentioned there is an ongoing efforts to support ARM platform. We have a small team here and we are willing to also help to make this work. Thanks alot, Zhenyu Zheng

6 8

Host installation is broken across OST suites
by Marcin Sobczyk 02 Sep '20

02 Sep '20

Hi, OST suites seem to be broken, example runs [1][2]. In 'engine.log' [3] there is a problem reported: 2020-08-31 10:54:50,875+02 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-2) [568e87b9] Host installation failed for host '0524ee6a-815b-4f7c-8ac1-a085b9870325', 'lago-basic-suite-master-host-1': null 2020-08-31 10:54:50,875+02 DEBUG [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-2) [568e87b9] Exception: java.lang.NullPointerException at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand.executeCommand(InstallVdsInternalCommand.java:190) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1169) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1327) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2003) at org.ovirt.engine.core.utils//org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:140) at org.ovirt.engine.core.utils//org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:79) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1387) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:419) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runAction(Backend.java:442) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:424) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:630) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:228) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:430) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:160) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.elytron-private@1.11.4.Final//org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:627) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.interfaces.BackendInternal$$$view2.runInternalAction(Unknown Source) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.module.ejb.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:68) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2381) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.lambda$executeCommand$3(AddVdsCommand.java:219) at org.ovirt.engine.core.utils//org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:96) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:227) Looking at recent patches it might've been introduced by [4]. [1] https://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-master/1470/ [2] https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/11211/ [3] https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/11211… [4] https://gerrit.ovirt.org/#/c/109995/

3 2

[storage] how to find if a snapshot is in preview based on storage domain metadata only?
by Germano Veit Michel 01 Sep '20

01 Sep '20

Hi, Is there a reliable way to figure out if a snapshot is in preview only using information obtained from the storage domain metadata? I'm trying to find a way to distinguish a problematic snapshot chain (double parent) from a snapshot in preview in order to improve dump-volume chains. Currently dump-volume-chains throws an error (DuplicateParentError) if a snapshot is in preview for the image, as there is a 'Y' shape split in the chain with 2 volumes (previous chain + preview) pointing to a common parent: image: dff0a0c0-b731-4e5b-9f32-d97310ca40de Error: more than one volume pointing to the same parent volume e.g: (_BLANK_UUID<-a), (a<-b), (a<-c) Unordered volumes and children: - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <- 5eb2b29d-82d6-4337-8511-3c86705d566e status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 - e0475853-4514-4464-99e7-b185cce9b67d <- deceff83-9d88-4f87-8304-d5bf74d119b1 status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <- e0475853-4514-4464-99e7-b185cce9b67d status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 - 00000000-0000-0000-0000-000000000000 <- e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: PREALLOCATED, capacity: 1073741824, truesize: 1073741824 From the engine side it's easy, but I'd need to solve this problem using only metadata from the storage. The only thing I could think of is that one of the volumes pointing to the common parent has voltype LEAF. Any better ideas? Thanks, Germano

3 8

OST for 4.3 is broken on build stage
by Amit Bawer 26 Aug '20

26 Aug '20

Hi Lookup for el7 repo fails: [2020-06-22T07:46:48.800Z] ERROR: Command failed: [2020-06-22T07:46:48.800Z] # /usr/bin/yum --installroot /var/lib/mock/epel-7-ppc64le-60da95f193baa5a745076a0c6b674c73-bootstrap-6968/root/ --releasever 7 install yum yum-utils --setopt=tsflags=nocontexts [2020-06-22T07:46:48.800Z] Failed to set locale, defaulting to C [2020-06-22T07:46:48.800Z] http://cbs.centos.org/repos/virt7-ovirt-common-candidate/ppc64le/os/repodat…: [Errno 14] HTTPS Error 404 - Not Found [2020-06-22T07:46:48.800Z] Trying other mirror. [2020-06-22T07:46:48.800Z] To address this issue please refer to the below wiki article [2020-06-22T07:46:48.800Z] Taken from https://jenkins.ovirt.org/job/vdsm_standard-check-patch/21966/consoleText Thanks

2 1

ovirt-engine has been tagged (ovirt-engine-4.4.3)
by Tal Nisan 26 Aug '20

26 Aug '20

1 0

implementing hotplugCd/hotunplugCd in vdsm
by Fedor Gavrilov 25 Aug '20

25 Aug '20

Hey, So in an attempt to fix change CD functionality we discovered a few other potential issues and what Nir suggested was to implement two [somewhat] new functions in VDSM: hotplug and hotunplug for CDs similar to how it works for normal disks now. Existing changeCD function will be left as is for backwards compatibility. As I found out, engine already calculates iface and index before invoking VDSM functions, so we will just pass these along with PDIV to the VDSM. Suggested flow is, let me quote: >So the complete change CD flow should be: > >1. get the previous drivespec from vm metadata >2. prepare new drivespec >3. add new drivespec to vm metadata >4. attach a new device to vm >5. teardown the previous drivespec >6. remove previous drivespec from vm metadata > >When the vm is stopped, it must do: > >1. get drive spec from vm metadata >2. teardown drivespec > >During attach, there are interesting races: >- what happens if vdsm crashes after step 2? who will teardown the volume? > maybe you need to add the new drivespec to the metadata first, >before preparing it. >- what happens if attach failed? who will remove the new drive from >the metadata? Now, what makes hotplugDisk/hotunplugDisk different? From what I understand, the flow is same there, so what difference is there as far as VDSM is concerned? If none, this means if I more or less copy that code, changing minor details and data accordingly for CDs, this should work, shouldn't it? Thanks! Fedor

4 11

Engine build-artifacts is broken - "ERROR: Error fetching remote repo 'origin'"
by Nir Soffer 24 Aug '20

24 Aug '20

Since Friday, engine build-artifacts job is broken. Here are latest failing builds: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7425/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7426/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7427/ Error from last failing build: [2020-08-22T18:16:16.995Z] No credentials specified [2020-08-22T18:16:17.019Z] Fetching changes from the remote Git repository [2020-08-22T18:16:17.035Z] Cleaning workspace [2020-08-22T18:16:17.006Z] > git rev-parse --is-inside-work-tree # timeout=10 [2020-08-22T18:16:17.028Z] > git config remote.origin.url https://gerrit.ovirt.org/ovirt-engine # timeout=10 [2020-08-22T18:16:17.046Z] > git rev-parse --verify HEAD # timeout=10 [2020-08-22T18:16:17.136Z] Resetting working tree [2020-08-22T18:16:17.136Z] > git reset --hard # timeout=10 [2020-08-22T18:16:17.797Z] > git clean -fdx # timeout=10 [2020-08-22T18:16:18.179Z] ERROR: Error fetching remote repo 'origin' [2020-08-22T18:16:18.179Z] hudson.plugins.git.GitException: Failed to fetch from https://gerrit.ovirt.org/ovirt-engine [2020-08-22T18:16:18.179Z] at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909) [2020-08-22T18:16:18.179Z] at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131) [2020-08-22T18:16:18.179Z] at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) [2020-08-22T18:16:18.179Z] at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) [2020-08-22T18:16:18.179Z] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [2020-08-22T18:16:18.179Z] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [2020-08-22T18:16:18.180Z] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [2020-08-22T18:16:18.180Z] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [2020-08-22T18:16:18.180Z] at java.lang.Thread.run(Thread.java:748) [2020-08-22T18:16:18.180Z] Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned status code 1: [2020-08-22T18:16:18.180Z] stdout: [2020-08-22T18:16:18.180Z] stderr: warning: failed to remove rpmbuild/BUILD/ovirt-engine-4.4.2.3/frontend/webadmin/modules/webadmin/target/tmp/gwtc15338967752245717048.tmp/org.ovirt.engine.ui.webadmin.WebAdmin/compiler/permutation-0.js [2020-08-22T18:16:18.180Z] [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2430) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2360) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2356) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1916) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1928) [2020-08-22T18:16:18.180Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:1010) [2020-08-22T18:16:18.180Z] at sun.reflect.GeneratedMethodAccessor1271.invoke(Unknown Source) [2020-08-22T18:16:18.180Z] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [2020-08-22T18:16:18.180Z] at java.lang.reflect.Method.invoke(Method.java:498) [2020-08-22T18:16:18.180Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:931) [2020-08-22T18:16:18.180Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:905) [2020-08-22T18:16:18.180Z] at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:857) [2020-08-22T18:16:18.180Z] at hudson.remoting.UserRequest.perform(UserRequest.java:211) [2020-08-22T18:16:18.180Z] at hudson.remoting.UserRequest.perform(UserRequest.java:54) [2020-08-22T18:16:18.180Z] at hudson.remoting.Request$2.run(Request.java:369) [2020-08-22T18:16:18.180Z] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) [2020-08-22T18:16:18.180Z] ... 4 more [2020-08-22T18:16:18.182Z] Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to vm0006.workers-phx.ovirt.org [2020-08-22T18:16:18.182Z] at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1788) [2020-08-22T18:16:18.182Z] at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356) [2020-08-22T18:16:18.182Z] at hudson.remoting.Channel.call(Channel.java:998) [2020-08-22T18:16:18.182Z] at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:285) [2020-08-22T18:16:18.182Z] at com.sun.proxy.$Proxy89.clean(Unknown Source) [2020-08-22T18:16:18.182Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:455) [2020-08-22T18:16:18.182Z] at hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:44) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.extensions.GitSCMExtension.decorateFetchCommand(GitSCMExtension.java:288) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:905) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131) [2020-08-22T18:16:18.183Z] at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) [2020-08-22T18:16:18.183Z] at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) [2020-08-22T18:16:18.183Z] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [2020-08-22T18:16:18.183Z] ... 4 more Error fetching remote repo 'origin'

1 1

Vdsm: ovirt-4.4.2 branch created
by Milan Zamazal 19 Aug '20

19 Aug '20

Hi, ovirt-4.4.2 branch has been created in Vdsm repository. Any future changes for 4.4.2 must be backported there. You can merge non-4.4.2 stuff to master now. Regards, Milan

1 0

Max running ansible-playbook
by Tommaso - Shellrent 19 Aug '20

19 Aug '20

Hi to all. on our angine we always see max 1 ansible-playbook running on the same time. We use OVA export to make some backup, but the whole task takes a lot of time because only one ansible-playbook "/usr/share/ovirt-engine/playbooks/ovirt-ova-export.yml" run at the same time. How can we ingrease this value? -- -- Shellrent - Il primo hosting italiano Security First *Tommaso De Marchi* /COO - Chief Operating Officer/ Shellrent Srl Via dell'Edilizia, 19 - 36100 Vicenza Tel. 0444321155 <tel:+390444321155> | Fax 04441492177

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.11.4)
by Tal Nisan 19 Aug '20

19 Aug '20

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.2.3)
by Tal Nisan 19 Aug '20

19 Aug '20

1 0

KVM with RDP using RDPMux for oVirt?
by Neal Gompa 18 Aug '20

18 Aug '20

Hello, At the urging of Sandro Bonazzola, I'm bringing up something that was being discussed on Twitter earlier today: supporting RDP with KVM directly. As it turns out, about four years ago, Datto developed support for QEMU to display to RDP in a similar fashion to what was done for SPICE years ago. The way this was done was by patching QEMU[1] to send buffers to a service called RDPMux[2], which would provide RDP connections. Additionally, libvirt was adjusted to support this[3]. Now, a couple years ago, I attempted to start rebasing this to QEMU 2.12.0 for my own use[4], but while I was able to make it compile[5], it always hung when I tried to use the functionality. This came up on Twitter earlier today when talking about how KVM lacks RDP but had SPICE (which didn't catch on, and is apparently deprecated now[6]?!?) Is anyone interested in potentially helping me get this working with the latest QEMU and libvirt? I'd be happy to package up RDPMux for Fedora and get that in the distribution for people to use in that case... Best regards, Neal [1]: https://pagure.io/virt-with-rdp/blob/master/f/qemu-2.5 [2]: https://github.com/datto/RDPMux [3]: https://pagure.io/virt-with-rdp/blob/master/f/libvirt-1.3.1 [4]: https://pagure.io/virt-with-rdp/blob/master/f/qemu-2.12.0 [5]: https://copr.fedorainfracloud.org/coprs/ngompa/virt-with-rdp/build/774882/ [6]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-be… -- 真実はいつも一つ！/ Always, there's only one truth!

4 7

Improving VM behavior in case of IO errors
by Shubha Kulkarni 16 Aug '20

16 Aug '20

Hello, In OVirt, we have a property propagate_error at the disk level that decides in case of an error, how this error be propagated to the VM. This value is maintained in the database table with the default value set as Off. The default setting(Off) results in a policy that ends up pausing the VM rather than propagating the errors to VM. There is no provision in the UI currently to configure this property for disk (images or luns). So there is no easy way to set this value. Further, even if the value is manually set to "On" in db, it gets overwriiten by UI everytime some other property is updated as described here - https://bugzilla.redhat.com/show_bug.cgi?id=1669367 Setting the value to "Off" is not ideal for multipath devices where a single path failure causes vm to pause. It puts serious restrictions for the DR situation and unlike VMWare * Hyper-V, oVirt is not able to support the DR functionality - https://bugzilla.redhat.com/show_bug.cgi?id=1314160 While we wait for RFE, the proposal here is to revise the out of the box behavior for LUNs. For LUNs, we should propagate the errors to VM rather than directly stopping those. This will allow us to handle short-term multipath outages and improve availability. This is a simple change in behavior but will have good positive impact. I would like to seek feedback about this to make sure that everyone is ok with the proposal. Thanks, Shubha

3 11

ovirt-engine 4.4.2 has been branched
by Tal Nisan 14 Aug '20

14 Aug '20

I've now branched oVirt 4.4.2, this will allow us to start working on 4.4.3 bugs/features and also maintain the stability of 4.4.2 before the final build. How does it affect you: If you are working on 4.4.3 content you can now submit your work to master and it will be included in 4.4.3 If you are working on 4.4.2 content you will have to push it to master first and then backport it to the ovirt-engine-4.4.2.z branch

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.2.2)
by Tal Nisan 13 Aug '20

13 Aug '20

3 4

192.168.200.90 unreachable (was: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 1696 - Still Failing!)
by Yedidyah Bar David 12 Aug '20

12 Aug '20

On Tue, Aug 4, 2020 at 6:40 AM <jenkins(a)jenkins.phx.ovirt.org> wrote: > > Project: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/ > Build: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/1696/ This is failing for a few days now, all with the same error: > FAILED: 004_basic_sanity.hotplug_disk > > Error Message: > False != True after 180 seconds > -------------------- >> begin captured logging << -------------------- > lago.ssh: DEBUG: start task:cef1ecf3-76fd-4aad-a1fb-093eeda8193a:Get ssh client for lago-he-basic-suite-master-host-1: > lago.ssh: DEBUG: end task:cef1ecf3-76fd-4aad-a1fb-093eeda8193a:Get ssh client for lago-he-basic-suite-master-host-1: > lago.ssh: DEBUG: Running 833afb8a on lago-he-basic-suite-master-host-1: ping -4 -c 1 192.168.200.90 > lago.ssh: DEBUG: Command 833afb8a on lago-he-basic-suite-master-host-1 returned with 1 > lago.ssh: DEBUG: Command 833afb8a on lago-he-basic-suite-master-host-1 output: > PING 192.168.200.90 (192.168.200.90) 56(84) bytes of data. > From 192.168.200.3 icmp_seq=1 Destination Host Unreachable This is after Michal pushed a patch to restore the removed function (and related) get_vm0_ip_address, which failed build 1691. I guess this patch was not enough - either the VM now gets a different IP address, not 192.168.200.90, or its network is down, or whatever. Any idea? Thanks, -- Didi

4 5