February 2019 - Devel - oVirt List Archives

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

11 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 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

Python 3 vdsm RPM packages
by Marcin Sobczyk 10 Apr '19

10 Apr '19

Hi, On yesterday's vdsm weekly call, we were discussing the need of making Python 3 vdsm RPM packages. Some facts: - it doesn't make a lot sense to spend much time on trying to package everything - it's completely impossible i.e. to run vdsm without having 'sanlock' module - our current vdsm.spec file is crap Two non-exclusive propositions were raised: - let's try to make a quick-and-dirty patch, that will completely overwrite the existing 'vdsm.spec' (effectively making it Python 3-only) for testing purposes, and maintain it for a while - in the meantime, let's write a completely new, clean and beautiful spec file in an package-by-package, incremental manner, (also Python 3-only) that would eventually substitute the original one The quick-and-dirty spec file would be completely unsupported by CI. The new one would get a proper CI sub-stage in 'build-artifacts' stage. The steps needed to be done are: - prepare autotools/Makefiles to differentiate Python 2/Python 3 RPM builds - prepare the new spec file (for now including only 'vdsm-common' package) - split 'build-artifacts' stage into 'build-py27' and 'build-py36' sub-stages (the latter currently running on fc28 only) The only package we can start with, when making the new spec file, is 'vdsm-common', as it doesn't depend on anything else (or at least I hope so...). There were also propositions about how to change the new spec file in regard to the old one (like making 'vdsm' package a meta-package). This is a good time for these propositions to be raised, reviewed and documented (something like this maybe? https://docs.google.com/document/d/13EXN1Iwq-OPoc2A5Y3PJBpOiNC10ugx6eCE72K6…) so we can align the new spec file as we build it. I can lay the groundwork by doing the autotools/Makefiles and 'build-artifacts' splitting. Gal Zaidman agreed on starting to work on the new spec file. Milan mentioned, that he had something like the quick-and-dirty patch, maybe he can share it with us. Questions, comments are welcome. Regards, Marcin

5 12

[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 27-02-2019 ] [ 002_bootstrap.add_vm2_lease ]
by Dafna Ron 10 Mar '19

10 Mar '19

Hi, We have a failure on the project in basic suite, master branch. The recent failure was in patch: https://gerrit.ovirt.org/#/c/98087/1 - Add pre-seed for ovirt-web-ui CQ is pointing at the below as the root cause (which was merged a while back): https://gerrit.ovirt.org/#/c/97491/ - Add pre-seed for ovirt-web-ui Can you please check the issue as it seems both patches are changing the same thing and the project seem to be broken since https://gerrit.ovirt.org/#/c/97491/3 Latest failure: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/ Logs: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/artifa… errors from logs: Engine: 2019-02-27 13:37:28,479-05 ERROR [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Transaction rolled-back for command 'org.ovirt.engine.core.bll.UpdateVmCommand'. 2019-02-27 13:37:28,483-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [74283e25] EVENT_ID: USER_FAILED_UPDATE_VM(58), Failed to update VM vm2 (User: admin@inter nal-authz). 2019-02-27 13:37:28,485-05 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Lock freed to object 'EngineLock:{exclusiveLocks='[vm2=VM_NAME]', sharedLocks='[3500eb82-e5e2-4e24-b41c-ea 02d9f6adee=VM]'}' 2019-02-27 13:37:28,485-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-1) [74283e25] method: runAction, params: [UpdateVm, VmManagementParametersBase:{commandId='340 59769-05b9-429e-8356-f6b9b9953f55', user='admin', commandType='UpdateVm', vmId='3500eb82-e5e2-4e24-b41c-ea02d9f6adee'}], timeElapsed: 6618ms 2019-02-27 13:37:28,486-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [] 2019-02-27 13:37:28,579-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (EE-ManagedThreadFactory-engineScheduled-Thread-85) [] method: get, params: [e29c0ba1-464c-4eb4-a8f2-c6933d9 9969a], timeElapsed: 3ms vdsm: 2019-02-27 13:37:21,987-0500 INFO (jsonrpc/1) [vdsm.api] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee from=::ffff:192.168.201.4,43920, flow_id=117dec74-ad59-4b12-8148-b2c130337c10, task_id=9c297d41-0aa7-4c74-b268-b710e666bc6c (api:52) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in lease_info File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3702, in lease_info info = dom.lease_info(lease.lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 674, in lease_info return vol.lookup(lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 553, in lookup raise NoSuchLease(lease_id) NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee 2019-02-27 13:37:21,988-0500 INFO (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') aborting: Task is aborted: u'No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee' - code 100 (task:1181) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.Dispatcher] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee (dispatcher:87) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 74, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 108, in wrapper return m(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1189, in prepare raise self.error NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee

5 9

Please don't remove instance type
by Baptiste Agasse 07 Mar '19

07 Mar '19

Hi all, We are happy oVirt users for some years now (we started with 3.6, now on 4.2) and we manage most of our virtualization stacks with it. To provision and manage our machines, we use the foreman (for bare metal and virtual machines) on top of it. I made some little contributions to the foreman and other underlying stuff to have a deeper integration with oVirt, like to be able to select instance type directly from foreman interface/api and we rely on it. We use instance types to standardize our vms by defining system resources (memory, cpu and cpu topology) console type, boot options. On top of that we plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources definitions separated from OS installation help us to keep instance types and templates lists small and don't bother users about some technical underlying stuff. As we are interested in automating oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM oVirt booth if there is any ansible module to manage instance types in Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I asked the question said that you are planning to remove instance types from ovirt, and this make me sad :(. So here I am to ask why do you plan to remove instance types from oVirt. As far as I know, it's fairly common to have "instance types" / "flavors" / "sizes" on one side and then templates (bare OS, preinstalled appliances...) on other side and pick one of each to make an instance. If this first part is missing in future version of ovirt, it will be a pain point for us. So, my question is, do you really plan to remove instances type definitely ? Cheers. -- Baptiste

3 4

oVirt documentation vs. feature pages
by Greg Sheremeta 05 Mar '19

05 Mar '19

Hi, TL;DR: please don't direct users to feature pages -- direct them to end-user documentation instead. And maintain content separation between end-user documentation and technical docs like feature pages. ... Lately we've cleaned up documentation on ovirt.org, and I wanted to share some of my thoughts about it. As a user experience focused person, I really believe that clear and helpful documentation is crucial to the project's success. I've also seen outdated documentation be a source of extreme frustration for our users. In the distant past, most of oVirt's documentation was written by developers on a wiki, typically in the form of "feature pages." Feature pages are basically technical design documents with occasionally some user help sprinkled in. With oVirt 4.0, we put a great set of clear documentation, written by technical writers, on the oVirt website (which was also converted from a wiki to a regular static site). This documentation is up to date with 4.2, and we'll get the 4.3 content out there soon. This official documentation lives at https://ovirt.org/documentation and it should be considered the authoritative place for users to access our documentation. Feature pages, on the other hand, are (now) for developers. When you hear the term "feature page", think "technical design document." Most users should not be interested in this content. It helps to think about the personas. 1. oVirt admins -- the person who sets up oVirt on Day 1 and 2. This is the person who cares about and will read the Installation Guide and the Administration Guide. These live under /documentation, e.g. https://ovirt.org/documentation/install-guide/Installation_Guide.html 2. oVirt users -- the people who use oVirt to create, manage, and use virtual machines, etc. This person will care about and read the VM Portal Guide, User Guides, and such. These also live under /documentation, e.g. https://ovirt.org/documentation/vmm-guide/Virtual_Machine_Management_Guide.… 3. Developers -- you and I, and occasionally highly curious and technical admins. These people might care about how the project works under the hood -- high level designs, code flows, etc. Persona 2, oVirt users, do not care about these details when they are learning to use oVirt, so end-user documentation should not be polluted with this type of content. This content now lives exclusively under /develop, the developer's section of the site. https://ovirt.org/develop/release-management/features/ Let's help our users by directing them to the end-user documentation, not to feature pages. If you would like to contribute end-user documentation, it should go under /documentation and not in a feature page. If you build a new feature, the technical stuff goes under /develop/release-management/features/ and the end-user stuff goes under /documentation. Feedback welcome :) Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

4 5

Can't discover luns on iscisi target when host is running fedora 28
by Fedor Gavrilov 04 Mar '19

04 Mar '19

Hi, Recently I hit an issue when I can't add iscsi storage domain because engine can't see any LUNs there. I wonder if I missed some step in the configuration or something. There is a fedora 29 machine running iscsi target which has a single lun and host (banana) registered in its ACL: [cucumber@cucumber ~]$ sudo targetcli [sudo] password for cucumber: targetcli shell version 2.1.fb48 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /iscsi/iqn.20...e:target/tpg1> ls o- tpg1 ..................................................................................................... [no-gen-acls, no-auth] o- acls ................................................................................................................ [ACLs: 1] | o- iqn.1994-05.com.redhat:4bf5ff1a15b6 ........................................................................ [Mapped LUNs: 1] | o- mapped_lun0 ................................................................................. [lun0 fileio/filestore0 (rw)] o- luns ................................................................................................................ [LUNs: 1] | o- lun0 ................................................................... [fileio/filestore0 (/etc/fileio) (default_tg_pt_gp)] o- portals .......................................................................................................... [Portals: 1] o- 0.0.0.0:3260 ........................................................................................................... [OK] From fedora 28 host I can login and logout, but there is this segfault and when I try getting LUN info it fails: [banana@banana ~]$ sudo iscsiadm --mode discovery --type sendtargets --portal cucumber 192.168.111.4:3260,1 iqn.2016-01.com.example:target [banana@banana ~]$ sudo iscsiadm -m node -T iqn.2016-01.com.example:target -l Logging in to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] (multiple) Login to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] successful. [banana@banana ~]$ sudo iscsiadm -m session -P 3 -r 2 iscsiadm: could not read session targetname: 5 iscsiadm: Could not get session info for sid 2 [banana@banana ~]$ sudo iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 6.2.0.874 Segmentation fault It seems I am hitting this: https://bugzilla.redhat.com/show_bug.cgi?id=1462767 Could this be the reason that there are no LUNs in engine web UI after I discover iscsi target? Is anyone aware of workaround or whether I am doing something wrong? Thanks, Fedor Gavrilov

2 2

[ OST Failure Report ] [ oVirt Master ] [ 27-02-2019 ] [ 002_bootstrap.get_host_devices]
by Galit Rosenthal 01 Mar '19

01 Mar '19

Hi, we are failing basic suite master (vdsm, ovirt-engine-sdk ...) It happens sporadically. We disqualify that this is an infra issue. Can you please have a look at the issue? ERROR: <testcase classname="002_bootstrap" name="get_host_devices" time="0.077"> <error type="exceptions.RuntimeError" message="*Could not find block_vda_1 device in host devices*: "><![CDATA[Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 1016, in get_host_devices raise RuntimeError('Could not find block_vda_1 device in host devices: {}'.format(device_list)) RuntimeError: Could not find block_vda_1 device in host devices: ]]></error> Thanks, Galit Examples, Full logs: [1] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… [2] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/WXW6II3NYEXHI… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

9 14

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 28-02-2019 ] [ 002_bootstrap.resize_and_refresh_storage_domain ]
by Dafna Ron 28 Feb '19

28 Feb '19

Hi, The test failed due to not finding master storage domain I am seeing a build of engine that passed so its possible that this is related to the random failures we have been having on other tests but since the change reported is storage related, can you please review the logs to see if anything happened to the master domain while trying to resize? CQ reported this change as root cause: https://gerrit.ovirt.org/#/c/98015/6 - blockSD: Move legacy block size constants to sd build failure: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13175/ logs: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13175/artifa… errors in log: 2019-02-27 17:35:02,222-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-23) [558e4473] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM la go-basic-suite-master-host-1 command ConnectStoragePoolVDS failed: Cannot find master domain: u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58, msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5a9' 2019-02-27 17:35:02,222-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (EE-ManagedThreadFactory-engine-Thread-23) [558e4473] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker. ConnectStoragePoolVDSCommand' return value 'StatusOnlyReturn [status=Status [code=304, message=Cannot find master domain: u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58, msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5 a9']]' 2019-02-27 17:35:02,222-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (EE-ManagedThreadFactory-engine-Thread-23) [558e4473] HostName = lago-basic-suite-master-host-1 2019-02-27 17:35:02,223-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (EE-ManagedThreadFactory-engine-Thread-23) [558e4473] Command 'ConnectStoragePoolVDSCommand(HostName = lago-basic-suite-master-host-1, ConnectStoragePoolVDSCommandParameters:{hostId='1ac0eda2-0980-40df-b029-b262680696a4', vdsId='1ac0eda2-0980-40df-b029-b262680696a4', storagePoolId='1c79b83e-32d6-43e0-bc61-2955e42c3a58', masterVersion='1'})' execution failed: IRSGenericException: IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58, msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5a9' 2019-02-27 17:35:02,223-05 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (EE-ManagedThreadFactory-engine-Thread-23) [558e4473] Exception: org.ovirt.engine.core.vdsbroker.irsbroker.IRSNoMasterDomainException: IRSGenericException: IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: u'spUUID=1c79b83e-32d6-43e0-bc61-2955e42c3a58, msdUUID=7a7e1d7b-08aa-49f6-bdf2-4be64260b5a9' at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:50) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand.proceedConnectProxyReturnValue(ConnectStoragePoolVDSCommand.java:48) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand.proceedProxyReturnValue(ConnectStoragePoolVDSCommand.java:36) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand.executeVdsBrokerCommand(ConnectStoragePoolVDSCommand.java:32) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVdsCommandWithNetworkEvent(VdsBrokerCommand.java:123) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:111) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:396) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor252.invoke(Unknown Source) [:1.8.0_191] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_191] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_191] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source) [:1.8.0_191] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_191] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_191] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.bll.storage.pool.RefreshPoolSingleAsyncOperation.execute(RefreshPoolSingleAsyncOperation.java:59) [bll.jar:] at org.ovirt.engine.core.utils.SynchronizeNumberOfAsyncOperations$AsyncOpThread.call(SynchronizeNumberOfAsyncOperations.java:43) [utils.jar:] at org.ovirt.engine.core.utils.SynchronizeNumberOfAsyncOperations$AsyncOpThread.call(SynchronizeNumberOfAsyncOperations.java:32) [utils.jar:] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalCallable.call(ThreadPoolUtil.java:117) [utils.jar:] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_191] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_191] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_191] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191] at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent-1.0.jar:]

2 2

[ANN] oVirt 4.3.1 is now generally available
by Sandro Bonazzola 28 Feb '19

28 Feb '19

The oVirt Project is pleased to announce the general availability of oVirt 4.3.1, as of February 26th, 2019. This update is the first in a series of stabilization updates to the 4.3 series. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is available for EL7 only - oVirt Node is available for EL7 only [2] - Fedora 28 based appliance and node couldn't be built due to a bug in Lorax (the tool used to build the images) affecting Fedora 28 and still pending a build from Fedora project. oVirt Node has been updated including: - oVirt 4.3.1: http://www.ovirt.org/release/4.3.1/ - ansible-2.7.8: https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.… Relevant EPEL Errata included: - FEDORA-EPEL-2019-5f2f93029f security update in Fedora EPEL 7 for ansible ( https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5f2f93029f ) Relevant CentOS Errata included: - CESA-2019:0231 Important CentOS 7 spice Security Update ( https://lists.centos.org/pipermail/centos-announce/2019-February/023192.html ) - CESA-2019:0368 Important CentOS 7 systemd Security Update ( https://lists.centos.org/pipermail/centos-announce/2019-February/023202.html ) Additional Resources: * Read more about the oVirt 4.3.1 release highlights: http://www.ovirt.org/release/4.3.1/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.1/ [2] http://resources.ovirt.org/pub/ovirt-4.3/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

OST manual: enable engine 4.3
by Nir Soffer 28 Feb '19

28 Feb '19

When starting manual OST job, we can select engine version. The available options are: - master - 42 Since we have now 4.3 branch, we should be able to select 4.3 engine. See attached screenshot.

3 2

Vdsm branch ovirt-4.3 created
by Milan Zamazal 27 Feb '19

27 Feb '19

Hi, I created ovirt-4.3 branch. That means patches for 4.3 must be backported from master since now. Not everything regarding CI is ready yet, but until we make the branch, we can't make some things working nor prove they are working. We need the branch to move forward. *Please don't merge non-4.3 patches to master yet.* Let's make 4.3 backports completely safe and trivial for a while, until we have working CI on 4.3. I'm not particularly happy with the branching process, let's use this experience to improve it next time. At minimum some guidelines should exist rather than just "common knowledge" with missing bits and pieces. Thanks, Milan

5 11

broken OST network suite (?)
by Miguel Duarte de Mora Barroso 26 Feb '19

26 Feb '19

Hi, I'm seeing the following error on the OST network suite: 17:05:56 Collecting pylint==1.6.4 17:05:57 Downloading https://files.pythonhosted.org/packages/92/f3/41deb50322d579517f779c3421b92… (569kB) 17:05:57 Collecting isort>=4.2.5 (from pylint==1.6.4) 17:05:57 Downloading https://files.pythonhosted.org/packages/35/c5/025aaa76f0f337e3d91197973c42b… (62kB) 17:05:58 Complete output from command python setup.py egg_info: 17:05:58 /usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'python_requires' 17:05:58 warnings.warn(msg) 17:05:58 error in isort setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers; Expected version spec in futures; python_version < "3.2" at ; python_version < "3.2" This happens on - at least - [0]. From my understanding, isort released a couple of new versions - according to [1] - and looks like that pylint version is too old for whatever new stuff isort now has. On other project I'm running pylint 1.8.4, which runs fine against that isort version: tox -e pylint pylint recreate: /home/mduarted/ovirt/ovirt-provider-ovn/.tox/pylint pylint installdeps: pytest==3.5.1, pylint==1.8.4, -r/home/mduarted/ovirt/ovirt-provider-ovn/requirements.txt pylint installed: DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.,astroid==1.6.5,attrs==18.2.0,backports.functools-lru-cache==1.5,certifi==2018.11.29,chardet==3.0.4,configparser==3.7.3,enum34==1.1.6,extras==1.0.0,fixtures==3.0.0,funcsigs==1.0.2,futures==3.2.0,idna==2.8,isort==4.3.9,lazy-object-proxy==1.3.1,linecache2==1.0.0,mccabe==0.6.1,more-itertools==5.0.0,netaddr==0.7.19,ovs==2.10.0,ovsdbapp==0.15.0,pbr==5.1.2,pluggy==0.6.0,py==1.8.0,pylint==1.8.4,pytest==3.5.1,python-mimeparse==1.6.0,requests==2.21.0,singledispatch==3.4.0.3,six==1.12.0,sortedcontainers==2.1.0,testtools==2.3.0,traceback2==1.4.0,unittest2==1.1.0,urllib3==1.24.1,wrapt==1.11.1 pylint runtests: PYTHONHASHSEED='2585806524' pylint runtests: commands[0] | pylint --errors-only provider driver Using config file /home/mduarted/ovirt/ovirt-provider-ovn/.pylintrc make lint3____________________________________ summary _____________________________________ pylint: commands succeeded congratulations :) Pyling 2.2.2 also runs fine. Is there a reason for us to be using such an outdated version ? [0] - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4155/console [1] - https://pypi.org/project/isort/#history

1 1

[VDSM] Simplifying project ACL
by Nir Soffer 26 Feb '19

26 Feb '19

Hi all, I learned recently that we have these groups in the project: vdsm-maintainers: https://gerrit.ovirt.org/#/admin/groups/15,members vdsm-master-maintainers: https://gerrit.ovirt.org/#/admin/groups/106,members And we have this complicated access control list: https://gerrit.ovirt.org/#/admin/projects/vdsm,access Developers in vdsm-master-maintainers can approve patches, but cannot submit. I find this strange and more complicated than needed. I think we can trust people in the vdsm-master-maintainers group to do the right thing. I sent this patch to simplify the ACL (with help of Gerrit UI): https://gerrit.ovirt.org/c/97738/ Thoughts? Nir

2 2

Misc configuration': Failed to start service 'rh-postgresql95-postgresql
by Galit Rosenthal 24 Feb '19

24 Feb '19

Hi I receive this error message both in CQ and check_patch: 2019-02-16 16:28:06,874-0500 DEBUG otopi.plugins.otopi.services.systemd systemd.state:130 starting service rh-postgresql95-postgresql 2019-02-16 16:28:06,874-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service'), executable='None', cwd='None', env=None 2019-02-16 16:28:07,913-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service'), rc=1 2019-02-16 16:28:07,914-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service') stdout: 2019-02-16 16:28:07,914-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service') stderr: Job for rh-postgresql95-postgresql.service failed because the control process exited with error code. See "systemctl status rh-postgresql95-postgresql.service" and "journalctl -xe" for details. 2019-02-16 16:28:07,915-0500 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_hba.conf'' 2019-02-16 16:28:07,916-0500 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/provisioning/postgres.py", line 201, in _misc self._provisioning.provision() File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/postgres.py", line 498, in provision self.restartPG() File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/postgres.py", line 399, in restartPG state=state, File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 141, in state service=name, RuntimeError: Failed to start service 'rh-postgresql95-postgresql' 2019-02-16 16:28:07,918-0500 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Failed to start service 'rh-postgresql95-postgresql' 2019-02-16 16:28:07,958-0500 DEBUG otopi.plugins.otopi.debug.debug_failure.debug_failure debug_failure._notification:100 tcp connections: id uid local foreign state pid exe What can cause it? Thanks Galit https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta… Regards, Galit -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

12 33

OST failes since build 4134
by Nir Soffer 23 Feb '19

23 Feb '19

https://jenkins.ovirt.org/job/ovirt-system-tests_manual/buildTimeTrend Here are the failures since build 4134: - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4135/testReport/jun… Not related to the patch tested: https://gerrit.ovirt.org/c/97996/ I started a new build: https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4140/ - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4136/ (no test results) - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4137/ (no tests results) - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4138/ (no test results) - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4139/testReport/jun… UI test failure/error? Nir

3 3

Fwd: Planned Outage - Fedora Core Services 2019-02-27 20:00 UTC
by Sandro Bonazzola 22 Feb '19

22 Feb '19

FYI ---------- Forwarded message --------- From: Stephen John Smoogen <smooge(a)gmail.com> Date: ven 22 feb 2019 alle ore 20:43 Subject: Planned Outage - Fedora Core Services 2019-02-27 20:00 UTC To: <announce(a)lists.fedoraproject.org>, Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, Fedora Infrastructure < infrastructure(a)lists.fedoraproject.org> There will be an outage starting at 2019-02-27 20:00 UTC, which will last approximately 4-6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2019-02-27 20:00UTC' Reason for outage: Fedora Infrastructure would like to update and reboot all core systems and services. This will update kernels, glibc, and systemd plus many other services on the affected systems. Affected Services: All systems under fedoraproject.org will be affected. Important databases and authentication will be updated and rebooted first. Then other non-build systems will follow. Then build systems will finalize the update/reboot cycle Ticket Link: https://pagure.io/fedora-infrastructure/issue/7591 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

[Ovirt] [CQ weekly status] [22-02-2019]
by Dafna Ron 22 Feb '19

22 Feb '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) 1. rh-postgress was failing to start due to missing selinux policy causing engine to fail installation. Bug: https://bugzilla.redhat.com/show_bug.cgi Issue resolved by didi and Galit by: 1. adding a workaround to add the selinuc poslicy and also a proposed fix (as described in comment #6) 2. created new lago images with new selinux package *CQ-Master:* GREEN (#1) 1. The same issue in 4.2 has effected master (for upgrade suite) Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

Installing oVirt on Physical machine
by emmanualvnebu1＠gmail.com 22 Feb '19

22 Feb '19

Hi Guys, I am trying to install oVirt node on a physical machine. Once selected the option to install oVirt 4.3 it give a screen "dracut-initqueue time out And then get into emergency mode & gives dracut cmd line. if I exit the command line, it continue bootinto the installation window. However it gives a message "Kickstart file /run/install/ks.config is missing" (Pane is dead). Tried the same on vmware, it boot fine & am able to install it. Can someone tell me how could I fix this?

2 1

Query regarding copying and executing files inside guest OS
by Pravin Amin 22 Feb '19

22 Feb '19

Hi, We are looking for a way to copy files and execute scripts inside Virtual Machines hosted on oVirt manager (Any supported guest OS) either through REST API or using Guest Tools. Please let me know how we can achieve it. -Thanks, Pravin Amin Principal SQA Engineer Netbackup Veritas Technologies LLC Office: (91) 20 - 66157288 / Mobile: (91) 9881139050 pravin.amin(a)veritas.com<mailto:pravin.amin@veritas.com> [signature_394478960]<https://www.veritas.com/product/backup-and-recovery/netbackup-8?om_camp_id=…> This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.

4 5

ovirt-engine-sdk-go: Integration with TravisCI to support pushing auto-generated codes
by Joey Ma 22 Feb '19

22 Feb '19

Hi all, With the generous help of several nice guys, currently the Go SDK related projects, oVirt/ovirt-engine-sdk-go and oVirt/go-ovirt, are already available under oVirt org, and the integration of oVirt/ovirt-engine-sdk-go with oVirt STD-CI is also completed [1]. Sincerely thank you to everyone. While there is still an issue left that we need a proper solution to integrate oVirt/ovirt-engine-sdk-go with TravisCI which could push the auto-generated codes into oVirt/go-ovirt. Previously I adopted my personal github access token which is stored encrypted [2] to work it out. But as it's been under oVirt community, we need a more regular way to make this. As @Evgheni <ederevea(a)redhat.com> suggested, maybe a new access token from a dedicated github account or via the Jenkins job will work? Any one could help? Any insights into this would be appreciated and thanks in advance. Best regards, Joey [1]: https://github.com/oVirt/ovirt-engine-sdk-go/pull/144 [2]: https://docs.travis-ci.com/user/environment-variables#defining-encrypted-va…

2 5

[VDSM] check-patch job fail - Cannot download x86_64/ovirt-imageio-common-1.5.0-0.201901061027.gita4be4ca.fc28.x86_64.rpm: All mirrors were tried
by Nir Soffer 21 Feb '19

21 Feb '19

In this buidl: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/3035/artifact/ci_bu… 2 sub stages failed: This failed without generating any log, but we can see the error in the blue ocean interface: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/3035//artifact/chec… https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… This failed with this log: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/3035//artifact/chec… Both failed becasue: Cannot download x86_64/ovirt-imageio-common-1.5.0-0.201901061027.gita4be4ca.fc28.x86_64.rpm: All mirrors were tried The other sub stages succeeded, and building the patch on top succeeded: https://gerrit.ovirt.org/c/97847 Looks like temporary error, failing to find a package from tested repository? How can we prevent these errors? Nir

2 3

ovirt-engine has been tagged (ovirt-engine-4.2.8.5)
by Tal Nisan 21 Feb '19

21 Feb '19

1 0

oVirt 4.3.1 test day
by Sandro Bonazzola 20 Feb '19

20 Feb '19

Hi, We are planning to release the first candidate of 4.3.1 on February 20th[1] and the final release on February 26th. Please join us testing this release candidate right after it will be announced! We are going to coordinate the testing effort with a public Trello board at https://trello.com/b/5ZNJgPC3 You'll find instructions on how to use the board there. If you have an environment dedicated to testing, remember you can setup a few VMs and test the deployment with nested virtualization. To ease the setup of such environment you can use Lago ( https://github.com/lago-project) The oVirt team will monitor the Trello board, the #ovirt IRC channel on irc.oftc.net server and the users(a)ovirt.org mailing list to assist with the testing. [1] https://www.ovirt.org/develop/release-management/releases/4.3.z/release-man… -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

[ANN] oVirt 4.3.1 First Release Candidate is now available
by Sandro Bonazzola 20 Feb '19

20 Feb '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.1 First Release Candidate, as of February 20th, 2019. This update is a release candidate of the first in a series of stabilization updates to the 4.3 series. This is pre-release software. This pre-release should not to be used in production. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is available for EL7 only - oVirt Node is available for EL7 only [2] - Fedora 28 based appliance and node couldn't be built due to a bug in Lorax (the tool used to build the images) affecting Fedora 28. Additional Resources: * Read more about the oVirt 4.3.1 release highlights: http://www.ovirt.org/release/4.3.1/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.1/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

Vdsm: Intention to make ovirt-4.3 branch
by Milan Zamazal 20 Feb '19

20 Feb '19

Hi, I'm going to make ovirt-4.3 Vdsm branch next week. If there are any very important reasons not to make it, please let me know. Thanks, Milan

4 8

ovirt-engine has been tagged (ovirt-engine-4.3.1.1)
by Tal Nisan 20 Feb '19

20 Feb '19

2 2

ovirt-engine has been tagged (ovirt-engine-4.3.1)
by Tal Nisan 19 Feb '19

19 Feb '19

7 14

ovirt-engine has been tagged (ovirt-engine-4.2.8.4)
by Tal Nisan 19 Feb '19

19 Feb '19

1 0

Re: Query regarding initial size value given to rest api for creating QCOW2 disk
by Himani Vaidya 19 Feb '19

19 Feb '19

Hi Nir, Daniel And Devel Guys, We have query regarding initial size attribute that we need specify in create disk API for qcow2 format. As per our discussions with you all it came up that we need initial size to be specified at qcow2 disk creation/restore so that that much size is preallocated. Based on that we specify request body for qcow2 to /ovirt-engine/api/disks as follows:- <disk> <storage_domains> <storage_domain id="aaaa"/> </storage_domains> <name>mydisk</name> <provisioned_size>xxxx</provisioned_size> <initial_size>yyyy<initial_size> <format>cow</format> </disk> Consider provisioned_size = 1 GB (Guest offset)(raw thick disk) Initial_size = > 1GB Initial_size > provisioned_size Also as per disk struct specified in http://ovirt.github.io/ovirt-engine-api-model/4.3/#types/disk Initial_size and provisioned size both are different attributes .Therefore these need to specified differently as per above request body. But unfortunately we saw it fails at write offset greater that provisioned size at data restore time. It doesn't consider initial_size attribute specified in request body only considers provisioned size . Can you please confirm whether for COW format what attributes and actual values(consider 1GB example) are needed in request body of create disk API /ovirt-engine/api/disks ? Thanks Himani Vaidya From: Mohammed Eliyas Shaikh Sent: Thursday, January 31, 2019 8:39 PM To: Daniel Erez <derez(a)redhat.com>; Nir Soffer <nsoffer(a)redhat.com> Cc: pchavva(a)redhat.com; Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com>; Abhay Marode <Abhay.Marode(a)veritas.com>; DL-VTAS-ENG-NBU-Midas <DL-VTAS-ENG-NBU-Midas(a)veritas.com>; Himani Vaidya <Himani.Vaidya(a)veritas.com> Subject: RE: Query regarding initial size for QCOW2 file restore Hi Pavan, Can we get direct number of Nir / Daniel to check if they are available for a short call now? Thanks, Mohammed Eliyas. From: Mohammed Eliyas Shaikh Sent: Thursday, January 31, 2019 1:39 PM To: Daniel Erez <derez(a)redhat.com<mailto:derez@redhat.com>>; Nir Soffer <nsoffer(a)redhat.com<mailto:nsoffer@redhat.com>> Cc: pchavva(a)redhat.com<mailto:pchavva@redhat.com>; Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com<mailto:Suchitra.Herwadkar@veritas.com>>; Abhay Marode <Abhay.Marode(a)veritas.com<mailto:Abhay.Marode@veritas.com>>; DL-VTAS-ENG-NBU-Midas <DL-VTAS-ENG-NBU-Midas(a)veritas.com<mailto:DL-VTAS-ENG-NBU-Midas@veritas.com>>; Himani Vaidya <Himani.Vaidya(a)veritas.com<mailto:Himani.Vaidya@veritas.com>> Subject: Query regarding initial size for QCOW2 file restore Hi Nir and Daniel, We had a few questions around restoring a qcow2 file to RHV. We plan to support restoring a qcow2 file to RHV. The source of the backups could be from RAW thin/thick or qcow2. When restoring qcow2 we need to provide an initial size. The backup image being restored will have guest data in fragments. When writing these fragments into the qcow2 file we would need to pad them to the qcow2 cluster boundary for every fragment. When providing the initial size to RHV we should have included the amount of padding we would need for every fragment and this would be difficult to get upfront when the qcow2 file is being created at restore time. It will be a function of the guest data fragmentation which would be difficult to get upfront at the start of the restore. We would like to check if there is an easy way around this situation from the RHV side. 1. Can we make the initial size requirement optional when creating a qcow2 file? 2. If not then * Can we write beyond the initial size we provided when creating the file? * Can we use the provisioned size of the virtual disk as the initial size of the qcow2 file (after adding size for headers) and then truncate the file to its actual size after writing the file completely. Though we could run into cases where customers don't have enough space for the provisioned size. Any other ideas to work around this initial size requirement. Thanks, Himani and Mohammed Eliyas.

1 0

oVirt 4.3.1 blockers
by Sandro Bonazzola 19 Feb '19

19 Feb '19

Hi, we are building 4.3.1 RC1 today and we still have 21 blocker bugs for this release. Please review all of them since we can't release 4.3.1 next week with known blockers. 1484053 <https://bugzilla.redhat.com/show_bug.cgi?id=1484053> ovirt-engine BLL.Storage ASSIGNED eshenitz(a)redhat.com ebenahar(a)redhat.com Storage create_lease task is not ordered to be cleared and gets s... <https://bugzilla.redhat.com/show_bug.cgi?id=1484053> 1520546 <https://bugzilla.redhat.com/show_bug.cgi?id=1520546> ovirt-engine BLL.Storage NEW bzlotnik(a)redhat.com ebenahar(a)redhat.com Storage LSM with continuous I/O to the VM failed and auto generat... <https://bugzilla.redhat.com/show_bug.cgi?id=1520546> 1528944 <https://bugzilla.redhat.com/show_bug.cgi?id=1528944> ovirt-engine BLL.Virt NEW michal.skrivanek(a)redhat.com mavital(a)redhat.com Virt [UI] - 'Migrate VMs' dialog - 'Select Host Automatically'... <https://bugzilla.redhat.com/show_bug.cgi?id=1528944> 1552344 <https://bugzilla.redhat.com/show_bug.cgi?id=1552344> vdsm Core NEW dchaplyg(a)redhat.com ebenahar(a)redhat.com Storage [Backup restore API][libgfapi] Start VM, with snapshot di... <https://bugzilla.redhat.com/show_bug.cgi?id=1552344> 1557272 <https://bugzilla.redhat.com/show_bug.cgi?id=1557272> ovirt-engine BLL.Virt NEW michal.skrivanek(a)redhat.com mavital(a)redhat.com Virt If VMs are paused while cluster compatiblity level is upg... <https://bugzilla.redhat.com/show_bug.cgi?id=1557272> 1570368 <https://bugzilla.redhat.com/show_bug.cgi?id=1570368> ovirt-engine RestAPI NEW omachace(a)redhat.com ebenahar(a)redhat.com Virt REST-API: GET diskattachments for a vm is missing a logic... <https://bugzilla.redhat.com/show_bug.cgi?id=1570368> 1597019 <https://bugzilla.redhat.com/show_bug.cgi?id=1597019> vdsm Core NEW bzlotnik(a)redhat.com ebenahar(a)redhat.com Storage LSM's diskReplicateFinish failed on libvirtError: interna... <https://bugzilla.redhat.com/show_bug.cgi?id=1597019> 1615974 <https://bugzilla.redhat.com/show_bug.cgi?id=1615974> ovirt-engine-metrics RFEs POST sradco(a)redhat.com isaranov(a)redhat.com Metrics [RFE][Tracker] - Replace fluentd for shipping metrics and... <https://bugzilla.redhat.com/show_bug.cgi?id=1615974> 1636901 <https://bugzilla.redhat.com/show_bug.cgi?id=1636901> ovirt-engine BLL.Virt NEW michal.skrivanek(a)redhat.com mavital(a)redhat.com Virt [UI] - User <UNKNOWN> got disconnected from VM 'VM name' ... <https://bugzilla.redhat.com/show_bug.cgi?id=1636901> 1641617 <https://bugzilla.redhat.com/show_bug.cgi?id=1641617> ovirt-engine BLL.Virt NEW rbarry(a)redhat.com pagranat(a)redhat.com Virt [Executor] Worker blocked vdsm error happens while HE VM ... <https://bugzilla.redhat.com/show_bug.cgi?id=1641617> 1646161 <https://bugzilla.redhat.com/show_bug.cgi?id=1646161> ovirt-engine BLL.Storage NEW sleviim(a)redhat.com ebenahar(a)redhat.com Storage IndexOutOfBoundsException: Index: 0, Size: 0 during impor... <https://bugzilla.redhat.com/show_bug.cgi?id=1646161> 1647491 <https://bugzilla.redhat.com/show_bug.cgi?id=1647491> ovirt-engine BLL.Storage NEW bzlotnik(a)redhat.com ebenahar(a)redhat.com Storage All VMs on the same host crash when a snapshot fail on on... <https://bugzilla.redhat.com/show_bug.cgi?id=1647491> 1649328 <https://bugzilla.redhat.com/show_bug.cgi?id=1649328> ovirt-engine BLL.Virt NEW akrejcir(a)redhat.com pagranat(a)redhat.com Virt no memory deflation/inflation in mom (unchanged balloonIn... <https://bugzilla.redhat.com/show_bug.cgi?id=1649328> 1654679 <https://bugzilla.redhat.com/show_bug.cgi?id=1654679> vdsm Gluster NEW sankarshan(a)redhat.com sasundar(a)redhat.com Gluster Provide upgrade instructions for oVirt 4.3 which is based... <https://bugzilla.redhat.com/show_bug.cgi?id=1654679> 1661888 <https://bugzilla.redhat.com/show_bug.cgi?id=1661888> ovirt-engine Frontend.UserPortal NEW smelamud(a)redhat.com lsvaty(a)redhat.com Virt Cluster compatibility version could not be updated by UI. <https://bugzilla.redhat.com/show_bug.cgi?id=1661888> 1663242 <https://bugzilla.redhat.com/show_bug.cgi?id=1663242> ovirt-ansible-roles General NEW omachace(a)redhat.com lsvaty(a)redhat.com Infra Check for update on host doesn't work with dnf installed <https://bugzilla.redhat.com/show_bug.cgi?id=1663242> 1665072 <https://bugzilla.redhat.com/show_bug.cgi?id=1665072> ovirt-engine Packaging.rpm NEW sbonazzo(a)redhat.com lsvaty(a)redhat.com Metrics [blocked] On engine side add write_syslog collectd output... <https://bugzilla.redhat.com/show_bug.cgi?id=1665072> 1670312 <https://bugzilla.redhat.com/show_bug.cgi?id=1670312> ovirt-imageio Daemon POST derez(a)redhat.com ebenahar(a)redhat.com Storage ovirt-imageio-daemon fails to start after reboot <https://bugzilla.redhat.com/show_bug.cgi?id=1670312> 1672318 <https://bugzilla.redhat.com/show_bug.cgi?id=1672318> vdsm General NEW srakonde(a)redhat.com lsvaty(a)redhat.com Gluster "failed to fetch volume file" when trying to activate hos... <https://bugzilla.redhat.com/show_bug.cgi?id=1672318> 1672859 <https://bugzilla.redhat.com/show_bug.cgi?id=1672859> ovirt-engine BLL.Virt NEW rbarry(a)redhat.com mavital(a)redhat.com Virt Cannot correctly upgrade an hosted engine env from 4.2 to... <https://bugzilla.redhat.com/show_bug.cgi?id=1672859> 1677361 <https://bugzilla.redhat.com/show_bug.cgi?id=1677361> ovirt-engine Setup.Engine POST stirabos(a)redhat.com pmatyas(a)redhat.com Integration Unsupported custom compatibility version check for VMs is... <https://bugzilla.redhat.com/show_bug.cgi?id=1677361> IDProductComponentStatusAssigneeQAContactoVirt TeamSummary -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

vdsm has been tagged (v4.20.47)
by Milan Zamazal 19 Feb '19

19 Feb '19

1 0

vdsm has been tagged (v4.30.9)
by Milan Zamazal 19 Feb '19

19 Feb '19

6 9

Permissions for Hosted-Engine VM and Storage Domain
by Ravi Shankar Nori 18 Feb '19

18 Feb '19

Hi All, This is in regard to BZ 1511697 - Unable to set permission on all but Hosted-Engine VM and Storage Domain The Issue: --------------- As described in the BZ, inherited permissions for HE VM/SD lets non SUPER_USER admins perform operations on the VM. Currently as far as permissions go there is no way to distinguish between a HE VM/SD and normal VMs/SDs and there is no way to set permissions only for the HE VM/SD. So all admins can perform operation on the HE VM/SD. Proposed Solution: -------------------------- The proposed solution is to prevent operations on a HE VM/SD for all users who do not have SUPER_USER system privilages as per [2]. Moving host to maintenance is allowed for all admins and the HE VM/SD is listed in search queries. Only when performing operations on the VM/SD we check user permissions. This requires documentation change as not all admin users can perform actions on a HE VM/SD. Please let me know if you have any objections to the proposed change before it is merged. Thanks Ravi [1] https://bugzilla.redhat.com/show_bug.cgi?id=1511697 [2] https://gerrit.ovirt.org/#/c/97689/

1 0

Reminder: please build packaged for 4.3.1 RC today
by Sandro Bonazzola 18 Feb '19

18 Feb '19

We are composing 4.3.1 RC tomorrow morning (11:00 CET timezone), please build your packages before that time and be sure to update the releng-tools configuration files for the release including your builds. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 1

[ OST Failure Report ] [ oVirt Master) ] [ 17-02-2019 ]
by Galit Rosenthal 18 Feb '19

18 Feb '19

Hi, CQ is failing on 'upgrade-from-release-suite-master' It seems like something has happened with rh-postgresql95-postgresql The log from the engine: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12918/artifa… Can someone please take a look at the issue? Thanks Galit Error: 2019-02-16 16:28:06,874-0500 DEBUG otopi.plugins.otopi.services.systemd systemd.state:130 starting service rh-postgresql95-postgresql 2019-02-16 16:28:06,874-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service'), executable='None', cwd='None', env=None 2019-02-16 16:28:07,913-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service'), rc=1 2019-02-16 16:28:07,914-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service') stdout: 2019-02-16 16:28:07,914-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'rh-postgresql95-postgresql.service') stderr: Job for rh-postgresql95-postgresql.service failed because the control process exited with error code. See "systemctl status rh-postgresql95-postgresql.service" and "journalctl -xe" for details. 2019-02-16 16:28:07,915-0500 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_hba.conf'' 2019-02-16 16:28:07,916-0500 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/provisioning/postgres.py", line 201, in _misc self._provisioning.provision() File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/postgres.py", line 498, in provision self.restartPG() File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/postgres.py", line 399, in restartPG state=state, File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 141, in state service=name, RuntimeError: Failed to start service 'rh-postgresql95-postgresql' 2019-02-16 16:28:07,918-0500 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Failed to start service 'rh-postgresql95-postgresql' 2019-02-16 16:28:07,958-0500 DEBUG otopi.plugins.otopi.debug.debug_failure.debug_failure debug_failure._notification:100 tcp connections: id uid local foreign state pid exe [CQ]: 97705, 6 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause A system test invoked by the "ovirt-master" change queue including change 97705,6 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 97719,3 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 97719,3 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/97705/6 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/97719/3 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12916/ _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt .org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt .org/message/LSBTLNTO6PE723XG5TELUHPXFLZEHODK/ -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

2 1

new easy way to open issues for ovirt.org and documentation
by Greg Sheremeta 18 Feb '19

18 Feb '19

Hi, I created some footer links on ovirt.org to make it super easy to open GitHub issues. We often get questions about where to report documentation issues and things like that -- hopefully this eases the pain. When you are visiting any page on ovirt.org and you see a problem or have an idea for enhancement, simply scroll down and click 'Report an issue on GitHub'. [image: Selection_393.png] Full demo (2 minutes): https://www.youtube.com/watch?v=TbORKknLVL4 (and, of course, if you're so inclined, the Edit link starts a PR for you ...) Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

2 2

[VDSM] Flaky protocol detector test
by Nir Soffer 17 Feb '19

17 Feb '19

Recently this test cause too many random failures. I guess this is the known issue with handling SUBSCRIBE in protocol detector. I posted https://gerrit.ovirt.org/c/97099/ To mark it as broken until we have time to dig deeper ====================================================================== FAIL: test_detect_slow_client_concurrency(True) (protocoldetector_test.AcceptorTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testlib.py", line 142, in wrapper return f(self, *args) File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/protocoldetector_test.py", line 167, in test_detect_slow_client_concurrency self.check_concurrently(self.check_slow_client, use_ssl) File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/protocoldetector_test.py", line 266, in check_concurrently self.assertTrue(all(done)) AssertionError: False is not true -------------------- >> begin captured logging << -------------------- 2019-01-19 20:47:16,021 DEBUG (MainThread) [vds.MultiProtocolAcceptor] Creating socket (host='127.0.0.1', port=0, family=2, socketype=1, proto=6) (protocoldetector:225) 2019-01-19 20:47:16,022 INFO (MainThread) [vds.MultiProtocolAcceptor] Listening at 127.0.0.1:46009 (protocoldetector:183) 2019-01-19 20:47:16,023 DEBUG (MainThread) [vds.MultiProtocolAcceptor] Adding detector <protocoldetector_test.Echo object at 0x7f1bb77f8dd0> (protocoldetector:210) 2019-01-19 20:47:16,024 DEBUG (MainThread) [vds.MultiProtocolAcceptor] Adding detector <protocoldetector_test.Uppercase object at 0x7f1bb77f8c90> (protocoldetector:210) 2019-01-19 20:47:16,031 INFO (Thread-61) [ProtocolDetector.AcceptorImpl] Accepted connection from 127.0.0.1:51950 (protocoldetector:61) 2019-01-19 20:47:16,047 INFO (Thread-61) [ProtocolDetector.AcceptorImpl] Accepted connection from 127.0.0.1:51952 (protocoldetector:61) 2019-01-19 20:47:16,048 INFO (Thread-61) [ProtocolDetector.AcceptorImpl] Accepted connection from 127.0.0.1:51954 (protocoldetector:61) 2019-01-19 20:47:16,065 INFO (Thread-61) [ProtocolDetector.AcceptorImpl] Accepted connection from 127.0.0.1:51956 (protocoldetector:61) 2019-01-19 20:47:16,068 INFO (Thread-61) [ProtocolDetector.AcceptorImpl] Accepted connection from 127.0.0.1:51958 (protocoldetector:61) 2019-01-19 20:47:16,069 DEBUG (Thread-61) [ProtocolDetector.Detector] Using required_size=9 (protocoldetector:89) 2019-01-19 20:47:16,097 DEBUG (Thread-61) [ProtocolDetector.Detector] Using required_size=9 (protocoldetector:89) 2019-01-19 20:47:16,099 DEBUG (Thread-61) [ProtocolDetector.Detector] Using required_size=9 (protocoldetector:89) 2019-01-19 20:47:16,107 DEBUG (Thread-61) [ProtocolDetector.Detector] Using required_size=9 (protocoldetector:89) 2019-01-19 20:47:16,109 DEBUG (Thread-61) [ProtocolDetector.Detector] Using required_size=9 (protocoldetector:89) 2019-01-19 20:47:16,574 INFO (Thread-61) [ProtocolDetector.Detector] Detected protocol echo from 127.0.0.1:51950 (protocoldetector:125) 2019-01-19 20:47:17,570 DEBUG (Thread-61) [ProtocolDetector.Detector] Timed out while waiting for data (protocoldetector:94) 2019-01-19 20:47:17,571 DEBUG (Thread-61) [ProtocolDetector.Detector] Timed out while waiting for data (protocoldetector:94) 2019-01-19 20:47:17,576 DEBUG (Thread-61) [ProtocolDetector.Detector] Timed out while waiting for data (protocoldetector:94) 2019-01-19 20:47:17,578 DEBUG (Thread-61) [ProtocolDetector.Detector] Timed out while waiting for data (protocoldetector:94) --------------------- >> end captured logging << ---------------------

2 7

GitHub now has draft PRs
by Greg Sheremeta 17 Feb '19

17 Feb '19

GitHub now has draft PRs! https://github.blog/2019-02-14-introducing-draft-pull-requests/ For those of us using github instead of gerrit, please submit draft PRs early :) Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

2 1

[ OST Failure Report ] [ oVirt Master/4.2 (ovirt-vmconsole) ] [ 15-02-2019 ] [ TEST NAME ]
by Dafna Ron 16 Feb '19

16 Feb '19

Hi, We are failing to deploy hosts in upgrade suites on both master and 4.2 for project ovirt-vmconsole. it seems we are missing packages for selinux-policy. Root cause identified by CQ as: https://gerrit.ovirt.org/#/c/97704/ - spec: clean up and reorganize can you please take a look at this issue? Sandro requested a bug so I opened one: https://bugzilla.redhat.com/show_bug.cgi?id=1677630 Error: 019-02-14 12:11:42,063-0500 ERROR otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum [u'ovirt-vmconsole-1.0.6-3.el7.noarch requires selinux-policy >= 3.13.1-229.el7_6.9', u'ovirt-vmconsole-1.0.6-3.el7.noarch requires selinux-policy-base >= 3.13.1-229.el7_6.9'] 2019-02-14 12:11:42,063-0500 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/tmp/ovirt-8JzESBo7eU/pythonlib/otopi/context.py", line 132, in _executeMethod method['method']() File "/tmp/ovirt-8JzESBo7eU/otopi-plugins/otopi/packagers/yumpackager.py", line 248, in _packages self.processTransaction() File "/tmp/ovirt-8JzESBo7eU/otopi-plugins/otopi/packagers/yumpackager.py", line 262, in processTransaction if self._miniyum.buildTransaction(): File "/tmp/ovirt-8JzESBo7eU/pythonlib/otopi/miniyum.py", line 920, in buildTransaction raise yum.Errors.YumBaseError(msg) YumBaseError: [u'ovirt-vmconsole-1.0.6-3.el7.noarch requires selinux-policy >= 3.13.1-229.el7_6.9', u'ovirt-vmconsole-1.0.6-3.el7.noarch requires selinux-policy-base >= 3.13.1-229.el7_6.9'] 2019-02-14 12:11:42,064-0500 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Package installation': [u'ovirt-vmconsole-1.0.6-3.el7.noarch requires selinux-policy >= 3.13.1-229.el7_6.9', u'ovirt-vmconsole-1.0.6-3.el7.noarch requires selinux-policy-base >= 3.13.1-229.el7_6.9'] Thanks, Dafna

3 8

[Ovirt] [CQ weekly status] [15-02-2019]
by Dafna Ron 15 Feb '19

15 Feb '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: RED (#1) 1. We had 4.2 failure due to selinux-policy package not downloaded automatically by ost as a dependency to vmconsoule package. The package stopped downloading after this change in vconsole: https://gerrit.ovirt.org/#/c/97704/ - clean up and reorganize I reported the issue to the list after discussing it with Sandro and after a discussion with the developer Sandro approved merging a patch to CI that would manually add the package: https://gerrit.ovirt.org/#/c/97785/ I am re-running the project's last patch now. - Action item for Galit to check why OST is not detecting the package if the project deps are ok. *CQ-Master:* RED (#1) 1. The same failure in vmconsole was causing upgrade suite to fail on master. Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

[VDSM] Running the new storage tests on your laptop
by Nir Soffer 15 Feb '19

15 Feb '19

I want to share our new block storage tests, running on your laptop, from your editor, creating real block storage domain with real logical volumes. One catch, these tests require root - there is no way to create devices without root. To make it easy to run as root only the tests that need root, they are marked with "root" mark. Here an example of running the root tests for block storage domain: $ sudo ~/.local/bin/tox -e storage-py27 tests/storage/blocksd_test.py -- -m root And for lvm: $ sudo ~/.local/bin/tox -e storage-py27 tests/storage/lvm_test.py -- -m root To run all storage tests that require root: $ sudo ~/.local/bin/tox -e storage-py27 -- -m root tests/storage Another issue - after running the tests as root, you need to fix ownership of some files in .tox/, tests/htmlcov*, and /var/tmp/vdsm. You can: $ sudo chown -R $USER:$USER .tox tests /var/tmp/vdsm We will improve this later. Note that I'm running tox installed as user: $ pip install --user tox This gets most recent tox with minimal breakage of system python. With the new tests, our code coverage is now 57%: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/2888/artifact/check… - blockSD: 47% https://jenkins.ovirt.org/job/vdsm_standard-check-patch/2888/artifact/check… - lvm: 74% https://jenkins.ovirt.org/job/vdsm_standard-check-patch/2888/artifact/check… These tests are rather slow, all the root tests take 26 seconds. But OST takes more then 40 minutes, and cover less code in this area. OST coverage for lvm mudle: 71% https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4071/artifact/expor… To get debug the tests, you can use new option in recent pytest --log-cli-level: $ sudo ~/.local/bin/tox -e storage-py27 tests/storage/blocksd_test.py -- -m root --log-cli-level=info Here is an example output from a test creating a storage domain (use --log-cli-leve=debug if this is not verbose enough) ------------------------------------------------------------------------------- live log call ------------------------------------------------------------------------------- blockSD.py 1034 INFO sdUUID=d4d7649d-4849-4413-bdc2-b7b84f239092 domainName=loop-domain domClass=1 vgUUID=3OJX6U-UDLc-VFtg-2cRO-q3kR-UH2g-Nvf78I storageType=3 version=3, block_size=512, alignment=1048576 blockSD.py 600 INFO size 512 MB (metaratio 262144) lvm.py 1168 INFO Creating LV (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, lv=metadata, size=512m, activate=True, contiguous=False, initialTags=(), device=None) lvm.py 1198 WARNING Could not change ownership of one or more volumes in vg (d4d7649d-4849-4413-bdc2-b7b84f239092) - metadata blockSD.py 522 INFO Create: SORT MAPPING: ['/dev/loop2'] lvm.py 1168 INFO Creating LV (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, lv=inbox, size=16m, activate=True, contiguous=False, initialTags=(), device=None) lvm.py 1198 WARNING Could not change ownership of one or more volumes in vg (d4d7649d-4849-4413-bdc2-b7b84f239092) - inbox lvm.py 1168 INFO Creating LV (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, lv=outbox, size=16m, activate=True, contiguous=False, initialTags=(), device=None) lvm.py 1198 WARNING Could not change ownership of one or more volumes in vg (d4d7649d-4849-4413-bdc2-b7b84f239092) - outbox lvm.py 1168 INFO Creating LV (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, lv=ids, size=8m, activate=True, contiguous=False, initialTags=(), device=None) lvm.py 1198 WARNING Could not change ownership of one or more volumes in vg (d4d7649d-4849-4413-bdc2-b7b84f239092) - ids lvm.py 1168 INFO Creating LV (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, lv=leases, size=2048m, activate=True, contiguous=False, initialTags=(), device=None) lvm.py 1198 WARNING Could not change ownership of one or more volumes in vg (d4d7649d-4849-4413-bdc2-b7b84f239092) - leases lvm.py 1168 INFO Creating LV (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, lv=master, size=1024m, activate=True, contiguous=False, initialTags=(), device=None) lvm.py 1198 WARNING Could not change ownership of one or more volumes in vg (d4d7649d-4849-4413-bdc2-b7b84f239092) - master lvm.py 1333 INFO Deactivating lvs: vg=d4d7649d-4849-4413-bdc2-b7b84f239092 lvs=['master'] blockdev.py 84 INFO Zeroing device /dev/d4d7649d-4849-4413-bdc2-b7b84f239092/metadata (size=41943040) utils.py 454 INFO Zero device /dev/d4d7649d-4849-4413-bdc2-b7b84f239092/metadata: 0.00 seconds blockdev.py 84 INFO Zeroing device /dev/d4d7649d-4849-4413-bdc2-b7b84f239092/inbox (size=1024000) utils.py 454 INFO Zero device /dev/d4d7649d-4849-4413-bdc2-b7b84f239092/inbox: 0.02 seconds blockdev.py 84 INFO Zeroing device /dev/d4d7649d-4849-4413-bdc2-b7b84f239092/outbox (size=1024000) utils.py 454 INFO Zero device /dev/d4d7649d-4849-4413-bdc2-b7b84f239092/outbox: 0.02 seconds lvm.py 1438 INFO Changing VG tags (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, delTags=[], addTags=['MDT_LEASETIMESEC=60', 'MDT_IOOPTIMEOUTSEC=10', 'MDT_LEASERETRIES=3', 'MDT_LOCKRENEWALINTERVALSEC=5', 'MDT_SDUUID=d4d7649d-4849-4413-bdc2-b7b84f239092', 'MDT_ROLE=Regular', 'MDT_POOL_UUID=', 'MDT_PV0=pv:loop2&44&uuid:wzupcF-uQME-3PIa-4WNf-THJJ-57MS-3UIdxD&44&pestart:0&44&pecount:157&44&mapoffset:0', 'MDT_CLASS=Data', 'MDT__SHA_CKSUM=ee58868dee52c4cc128f0ee89a0c382de1fe6419', 'MDT_LOGBLKSIZE=512', 'MDT_VGUUID=3OJX6U-UDLc-VFtg-2cRO-q3kR-UH2g-Nvf78I', 'MDT_PHYBLKSIZE=512', 'MDT_DESCRIPTION=loop-domain', 'MDT_TYPE=ISCSI', 'MDT_VERSION=3', 'MDT_LOCKPOLICY=']) lvm.py 1438 INFO Changing VG tags (vg=d4d7649d-4849-4413-bdc2-b7b84f239092, delTags=['RHAT_storage_domain_UNREADY'], addTags=['RHAT_storage_domain']) lvm.py 1325 INFO Activating lvs: vg=d4d7649d-4849-4413-bdc2-b7b84f239092 lvs=['master'] PASSED [ 50%] Nir

2 2

Reviews
by Germano Veit Michel 15 Feb '19

15 Feb '19

Hello, I've pinged this a few times before, sorry for doing it again. If there is interest to incorporate these changes in ovirt to make troubleshooting LSM/Snapshots easier please review these changes, otherwise we can abandon them. https://gerrit.ovirt.org/#/q/topic:snapshot-tools https://gerrit.ovirt.org/#/q/topic:dump-chains-sqlite Thanks,

2 1

Failed dependencies Ovirt 4.3 on clean install Centos 7.6
by Erick Perez 15 Feb '19

15 Feb '19

Centos 7.6 (minimal install ISO) UEFI boot yum -y update reboot [root@ovirt01] yum install cockpit-ovirt-dashboard Error: Package: 1:openvswitch-2.10.1-1.el7.x86_64 (ovirt-4.3-centos-ovirt43) Requires: librte_mbuf.so.3()(64bit) Available: dpdk-17.11-13.el7.x86_64 (extras) librte_mbuf.so.3()(64bit) Available: dpdk-17.11-15.el7.x86_64 (extras) librte_mbuf.so.3()(64bit) Installed:dpdk-18.11-2.el7_6.x86_64 (@extras) ~librte_mbuf.so.4()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@ovirt01] Note: The above message appears for librte_mbuf/mempool/pmd and several others. It seems openvswitch specifically need DPDK v17 and not v18. Please clarify. thanks,

3 3

oVirt Glance repo not accessible blocked OST
by Tian Xu 15 Feb '19

15 Feb '19

Hi Experts, I am trying to run ovirt-system-test in my local lab, which need proxy to access internet. ovirt cannot work with proxy to access ovirt glance repository, whose URL is: http://glance.ovirt.org:9292, a related bugzilla was filed by someone and in open status: https://bugzilla.redhat.com/show_bug.cgi?id=1362433 Some ovirt system tests depend on ovirt glance repository for VM images, these tests either skipped or failed, then subsequent VM related tests cannot be run. Here is the test file: https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-4.2/tes…, and the verify_glance_import failed, then other test blocked too. Below is exception message and details test log see attachment. Running test scenario 004_basic_sanity.py <?xml version="1.0" encoding="UTF-8"?> <testsuite name="nosetests" tests="3" errors="1" failures="0" skip="1"> <testcase classname="004_basic_sanity" name="add_blank_vms" time="2.473"/> <testcase classname="004_basic_sanity" name="verify_glance_import" time="0.050"> <skipped type="unittest.case.SkipTest" message="Glance is not available"><![CDATA[SkipTest: Glance is not available ]]></skipped> </testcase> <testcase classname="004_basic_sanity" name="add_vm1_from_template" time="0.266"> <error type="exceptions.IndexError" message="list index out of range"><![CDATA[Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/mnt/zz/bak/ovirt-system-tests-master/basic-suite-4.2/test-scenarios/004_basic_sanity.py", line 748, in add_vm1_from_template )[0] IndexError: list index out of range ]]></error> </testcase> </testsuite> Thanks， Xu

2 3

Fwd: [ovirt-users] Ovirt Cluster completely unstable
by Sandro Bonazzola 14 Feb '19

14 Feb '19

Any suggestion from Gluster team on how to get back to a stable system in a very short loop? opened https://bugzilla.redhat.com/show_bug.cgi?id=1677160 to track this on gluster side. ---------- Forwarded message --------- From: <dscott(a)umbctraining.com> Date: gio 14 feb 2019 alle ore 00:26 Subject: [ovirt-users] Ovirt Cluster completely unstable To: <users(a)ovirt.org> I'm abandoning my production ovirt cluster due to instability. I have a 7 host cluster running about 300 vms and have been for over a year. It has become unstable over the past three days. I have random hosts both, compute and storage disconnecting. AND many vms disconnecting and becoming unusable. 7 host are 4 compute hosts running Ovirt 4.2.8 and three glusterfs hosts running 3.12.5. I submitted a bugzilla bug and they immediately assigned it to the storage people but have not responded with any meaningful information. I have submitted several logs. I have found some discussion on problems with instability with gluster 3.12.5. I would be willing to upgrade my gluster to a more stable version if that's the culprit. I installed gluster using the ovirt gui and this is the version the ovirt gui installed. Is there an ovirt health monitor available? Where should I be looking to get a resolution the problems I'm facing. _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BL4M3JQA3IEXC… -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

disk cache issues
by Hetz Ben Hamo 14 Feb '19

14 Feb '19

Hi, After digging around and finding a bit of info about viodiskcache - I understand that if the user enable it - then the VM cannot be live migrated. Umm, unless the op decides to do a live migration including changing storage - I don't understand why the live migration is disabled. If the VM will only be live migrated between nodes, then the storage is the same, nothing is saved locally on the node's hard disk, so what is the reason to disable live migration? Thanks, Hetz

3 2

=?utf-8?q?=5Bovirt-devel=5D?=(reddit) 2 months with oVirt review
by Sandro Bonazzola 13 Feb '19

13 Feb '19

Hi, thanks to Greg for sharing the link to https://www.reddit.com/r/homelab/comments/ahq29c/2_months_with_ovirt_review/ This is a very constructive feedback from community, let's see what can be done for improving on the highlighted parts. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 1

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 13-02-2019 ] [ 001_initialize_engine.initialize_engine ]
by Dafna Ron 13 Feb '19

13 Feb '19

Hi, we are failing on project ovirt-engine in master branch on initialize engine Change suspected: https://gerrit.ovirt.org/#/c/95743/8 - core: Remove unused field VdsStatic.vdsStrength setup log is here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12864/artifa… full logs are here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12864/artifa… Can you please check the issue? Thanks, Dafna <error> INSERT INTO gluster_config_master(config_key, config_description, minimum_supported_cluster, config_possible_values, config_feature) values('use_meta_volume', 'Meta volume for the geo-replication session', '3.5', 'false;true', 'geo_replication'); ************************** INSERT 0 1 2019-02-13 09:03:04,406-0500 Saving custom users permissions on database objects... ********* QUERY ********** copy ( select count(*) from pg_available_extensions where name = 'uuid-ossp' and installed_version IS NOT NULL ) to stdout with delimiter as '|'; ************************** 2019-02-13 09:03:04,906-0500 dbfunc_psql_die --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_00_0000_set_version.sql ********* QUERY ********** select 4000000; ************************** 4000000 2019-02-13 09:03:05,534-0500 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.executeRaw:863 execute-result: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20190213090242-msviji.log', '-c', 'apply'], rc=1 2019-02-13 09:03:05,534-0500 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:921 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20190213090242-msviji.log', '-c', 'apply'] stdout: 2019-02-13 09:03:05,535-0500 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20190213090242-msviji.log', '-c', 'apply'] stderr: FATAL: Operation aborted, found duplicate version: 04030790 2019-02-13 09:03:05,535-0500 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:435 schema.sh: FATAL: Operation aborted, found duplicate version: 04030790 2019-02-13 09:03:05,535-0500 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", line 437, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2019-02-13 09:03:05,536-0500 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Misc configuration': Engine schema refresh failed 2019-02-13 09:03:05,562-0500 DEBUG otopi.plugins.otopi.debug.debug_failure.debug_failure debug_failure._notification:100 tcp connections: id uid local foreign state pid exe <error>

2 3

Recovering from power failure
by Sandro Bonazzola 13 Feb '19

13 Feb '19

Moving the discussion to devel list on this scenario. Il giorno mar 12 feb 2019 alle ore 11:16 Hetz Ben Hamo <hetz(a)hetz.biz> ha scritto: > Hi, > > Well, there is a severe bug that I complained about it on 4.2 (or 4.1? I > don't remember) and it's regarding "yanking the power cable". > Basically I'm performing a simple test: kill all hosts immediately to > simulate a power loss without UPS. > > For this test I have 2 nodes, and 4 storage domains: hosted_storage (that > was setup during the HE installation), 1 iSCSI domain, 1 NAS domain and 1 > ISO domain. > > After all the nodes loose power, I power them on and the following > procedure happens: > 1. The node with HE finishes booting, and it takes few minutes until the > HE is up. > 2. When the HE is up, all the storage domains comes back to life as online > and VM's with high availability starting to boot. > 3. Few minutes later, *all* (with the exception of hosted_storage) > storage domains are going down > 4. After about 5 minutes, all the other storage domains which went down, > are coming up, but by then, and VM's without high availability that are not > hosted on hosted_storage remains down, you'll need to power them manually > back. > > This whole procedure takes about 15-25 minutes after booting the nodes, > and this issue is always repeatable, just kill the power to the nodes, > power them up again and see for yourself. > > The solution would be to change the code and if a storage domain is up - *leave > it up*, skip the check. > > Tal, Nir, what do you think about this? > Thanks > > > On Tue, Feb 12, 2019 at 11:56 AM Sandro Bonazzola <sbonazzo(a)redhat.com> > wrote: > >> Hi, >> We are planning to release the first candidate of 4.3.1 on February >> 20th[1] and the final release on February 26th. >> Please join us testing this release candidate right after it will be >> announced! >> We are going to coordinate the testing effort with a public Trello board >> at https://trello.com/b/5ZNJgPC3 >> You'll find instructions on how to use the board there. >> >> If you have an environment dedicated to testing, remember you can setup a >> few VMs and test the deployment with nested virtualization. >> To ease the setup of such environment you can use Lago ( >> https://github.com/lago-project) >> >> The oVirt team will monitor the Trello board, the #ovirt IRC channel on >> irc.oftc.net server and the users(a)ovirt.org mailing list to assist with >> the testing. >> >> [1] >> https://www.ovirt.org/develop/release-management/releases/4.3.z/release-man… >> >> -- >> >> SANDRO BONAZZOLA >> >> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV >> >> Red Hat EMEA <https://www.redhat.com/> >> >> sbonazzo(a)redhat.com >> <https://red.ht/sig> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/URIGV3LPTE2RO… >> > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 2