- Devel - oVirt List Archives

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

v2v_conversion_host jenkins job bugged
by Sandro Bonazzola 02 Mar '19

02 Mar '19

Hi, just noticed today we have a jenkins job: https://jenkins.ovirt.org/job/oVirt_v2v-conversion-host_standard-on-ghpush/… which generates packages named like: v2v-conversion-host-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.src.rpm v2v-conversion-host-1.11.0.tar.gz v2v-conversion-host-ansible-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.noarch.rpm v2v-conversion-host-debugsource-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-provider-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-provider-debuginfo-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-wrapper-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.noarch.rpm which are breaking NVR naming conventions for RPMs and are probably the result of a bug within jenkins job. Please fix the job as soon as possible and clean up - https://resources.ovirt.org/repos/ovirt/tested/master - https://resources.ovirt.org/repos/ovirt/tested/4.2 - https://resources.ovirt.org/pub/ovirt-4.2-snapshot - https://resources.ovirt.org/pub/ovirt-master-snapshot 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

Re: [Vdo-devel] impact of --emulate512 setting for VDO volumes
by Guillaume Pavese 02 Mar '19

02 Mar '19

Thank you very much for your answer. I am copying ovirt-devel too as that could be of interest to them. Guillaume Pavese Ingénieur Système et Réseau Interactiv-Group On Sat, Mar 2, 2019 at 7:00 AM Michael Sclafani <sclafani(a)redhat.com> wrote: > Hi! > > 512 emulation was intended to support drivers that only do a fraction of > their I/O in blocks smaller 4KB. It is not optimized for performance in any > way. Under the covers, VDO is still operating on 4KB physical blocks, so > each 512-byte read is potentially amplified to a 4KB read, and each > 512-byte write to a 4KB read followed by a 4KB write. A workload consisting > exclusively of 512-byte randomly-distributed writes could effectively be > amplified by a factor of 16. > > We have a suite of automated tests we run in 512e mode on a nightly basis. > That suite is a subset of our regular tests, containing only ones we expect > would be likely to expose problems specific to the emulation. > > There should be no penalty to having emulation enabled on a volume that no > longer uses it. If the I/O is 4KB-aligned and 4KB or larger, having it > enabled won't affect it. > It does not appear the setting can be modified by the VDO manager, but I > cannot remember at this moment why that should be so. > > Hope this helps. > > On Fri, Mar 1, 2019 at 2:24 PM Guillaume Pavese < > guillaume.pavese(a)interactiv-group.com> wrote: > >> Hello, >> >> We are planning to deploy VDO with oVirt 4.3 on centos 7.6 (on SSD >> devices). >> As oVirt does not support 4K devices yet, VDO volumes are created with >> the parameter "--emulate512 enabled" >> >> What are the implications of this setting? Does it impact performance? If >> so, is it IOPS or throughput that is impacted? What about reliability (is >> that mode equally tested as standard mode)? >> >> As I saw on RH Bugzilla, support for 4K devices in oVirt will need to >> wait at least for Centos 7.7 >> Once that is supported, would it be possible to transition/upgrade an >> emulate512 vdo volume to a standard one? >> >> Thanks, >> >> Guillaume Pavese >> Ingénieur Système et Réseau >> Interactiv-Group >> _______________________________________________ >> Vdo-devel mailing list >> Vdo-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/vdo-devel >> >

1 0

[RHV] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '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-RHV-4.2:* GREEN (#1) Last failure was on 28-02-2019 for project rhevm-appliance due to a failed build-artifacts job. this issue is still happening and message was sent to developer. *CQ-RHV-Master:* GREEN (#1) Last failure is identical to 4.2 - build-artifacts for the same project. ** We do not yet have a 4.3 CQ job which we will start working on next week. Current running jobs for 4.2 [1] and for master [2] can be found below: [1] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… [2] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… 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)

1 0

[Ovirt] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '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) Last CQ job failure on 4.2 was 27-02-2019 on project ovirt-provider-ovn due to a failed build-artifacts job. this issue is now fixed. Please note that this is a CQ job failure but not an OST job failure as we exit if no package is available. *CQ-4.3*: RED (#1) We added a CQ job for 4.3 but not all projects created the branch yet. I created a google sheet to follow the advancement of this work and I will use this report to ask all the managers to go over the doc and add info: https://docs.google.com/spreadsheets/d/1i142cTN_0QwOvogtlQiF6bcIYxTpBqYBed2… *CQ-Master:* RED (#1) We have sporadic failures in test get_host_devices this is effecting all projects and we have yet to know what is causing the issue. Michal checked the issue and thinks the test should be modified to do a re-try as the info is filled by the host 4 seconds after the query is sent. Milan was asked to add a loop with 1s delay to get_host_devices to fix the test. Please note that we have ruled out a possible infra cause for this failure before alerting dev as the failure is sporadic and happens on multiple projects. Jira: https://ovirt-jira.atlassian.net/browse/OVIRT-2686 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

[ 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

unboundid-ldapsdk-4.0.9 is now available for testing
by Sandro Bonazzola 01 Mar '19

01 Mar '19

On Fedora we had previously 4.0.7. The new releases 4.0.7 will be soon available within repositories for Fedora >= 30 and includes several bug fixes and enhancements. You can see release notes for 4.0.8 and 4.0.9 here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide feedback here. Martin, Ravi, let me know if you see value in backporting this version to Fedora 28 and EL7 for oVirt 4.3 consumption. 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>

1 0

[NOTICE] infra issue in progress in jenkins
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, We had a job fail due to a failure in yum. it seems yum is searching for repodata in a wrong location. Evgheni is currently working to investigate and fix the problem and will update soon Jira opened: https://ovirt-jira.atlassian.net/browse/OVIRT-2689 Thanks, Dafna

1 1

[ 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