Bug 1788424

Summary: Importing a VM having direct LUN attached using virtio driver is failing with error "VirtIO-SCSI is disabled for the VM"
Product: Red Hat Enterprise Virtualization Manager Reporter: nijin ashok <nashok>
Component: ovirt-engineAssignee: Steven Rosenberg <srosenbe>
Status: CLOSED ERRATA QA Contact: Evelina Shames <eshames>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3.6CC: aefrat, mtessun, pelauter, rdlugyhe, srosenbe
Target Milestone: ovirt-4.4.1Flags: nashok: needinfo-
lsvaty: testing_plan_complete-
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: rhv-4.4.0-29 Doc Type: Bug Fix
Doc Text:
Previously, if you disabled the virtio-scsi drive and imported the virtual machine that had a direct LUN attached, the import validation failed with a "Cannot import VM. VirtIO-SCSI is disabled for the VM" error. This happened because the validation tried to verify that the virtio-scsi drive was still attached to the VM. The current release fixes this issue. If the Disk Interface Type is not virtio-scsi, the validation does not search for the virtio-scsi drive. Disk Interface Type uses an alternative driver, and the validation passes.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-04 13:21:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screen shot with the VM already imported to the iSci Storage domain
none
VM No Virt IO with LUN disks snap shot
none
VM No Virt IO in the edit showing Virt-IO scisi is disabled
none
error about virtio-scsi.
none
ovf of the VM none

Description nijin ashok 2020-01-07 07:34:44 UTC
Description of problem:

The VM is not having VirtIO-SCSI driver enabled. It's only having direct LUN disks that are attached using "virtio" driver. The VMs OVF has the correct data and the LUN is attached using VirtIO.

====
(taken from unregistered_ovf_of_entities table)

ovf:boot="true" ovf:disk-interface="VirtIO" ovf:read-only="false" ovf:scsi_reservation="false" ovf:plugged="true" ovf:lun_id="36001405dae0b035ca514e7cb7d64a9
f7"><Connection ovf:connection="192.168.1.2" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"></Connection>
===

While trying to import this VM using GUI, we will get an "Uncaught exception" error in the UI. The UI log has the below error.

===
2020-01-07 02:20:14,852-05 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-1) [3f28a13f-1656-4994-9aa5-a613d9e6795d] Uncaught exception: com.google.gwt.event.shared.UmbrellaException: Exception caught: undefined
        at java.lang.Throwable.Throwable(Throwable.java:70) [rt.jar:1.8.0_201]
        at java.lang.RuntimeException.RuntimeException(RuntimeException.java:32) [rt.jar:1.8.0_201]
        at com.google.web.bindery.event.shared.UmbrellaException.UmbrellaException(UmbrellaException.java:64) [gwt-servlet.jar:]
        at com.google.gwt.event.shared.UmbrellaException.UmbrellaException(UmbrellaException.java:25) [gwt-servlet.jar:]
        at com.google.gwt.event.shared.HandlerManager.$fireEvent(HandlerManager.java:117) [gwt-servlet.jar:]
        at com.google.gwt.user.client.ui.Widget.$fireEvent(Widget.java:127) [gwt-servlet.jar:]
        at com.google.gwt.user.client.ui.Widget.fireEvent(Widget.java:127) [gwt-servlet.jar:]
        at com.google.gwt.event.dom.client.DomEvent.fireNativeEvent(DomEvent.java:110) [gwt-servlet.jar:]
        at com.google.gwt.user.client.ui.Widget.$onBrowserEvent(Widget.java:163) [gwt-servlet.jar:]
        at com.google.gwt.user.client.ui.Widget.onBrowserEvent(Widget.java:163) [gwt-servlet.jar:]
        at com.google.gwt.user.client.DOM.dispatchEvent(DOM.java:1415) [gwt-servlet.jar:]
        at com.google.gwt.user.client.impl.DOMImplStandard.dispatchEvent(DOMImplStandard.java:312) [gwt-servlet.jar:]
        at com.google.gwt.core.client.impl.Impl.apply(Impl.java:236) [gwt-servlet.jar:]
        at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:275) [gwt-servlet.jar:]
        at Unknown.Tu/<(https://dhcp0-3.ansirhv.redhat.com/ovirt-engine/webadmin/?locale=en_US line 9 > scriptElement)
        at Unknown.anonymous(Unknown)
Caused by: java.lang.ClassCastException
====

So used the Python SDK to import as below.

===
vm = vm_service.register(
    cluster=types.Cluster(
        name='Default',
    ),
    vm=types.Vm(
        name='test_import_vm',
    ),
)
===

While importing using SDK, it's failing with the below error in the engine log.

===
2020-01-07 01:33:23,021-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-2) [] Operation Failed: [Cannot import VM. VirtIO-SCSI is disabled for the VM]
===

Version-Release number of selected component (if applicable):

rhvm-4.3.7.2-0.1.el7.noarch

How reproducible:

100%

Steps to Reproduce:

1. Create a VM and disable the VirtIO-SCSI for the VM.
2. Attach a direct LUN to the VM using virtio driver.
3. Detach the storage domain and attach it back.
4. Try to import the VM. From UI, it will fail with the Uncaught exception.
5. Try to import it using API/Python SDK/Ansible. It will fail with the error below.

ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot import VM. VirtIO-SCSI is disabled for the VM]". HTTP response code is 409.

Actual results:

Importing a VM having direct LUN attached using virtio driver is failing with error "VirtIO-SCSI is disabled for the VM"

Expected results:

Importing should work.

Additional info:

Comment 3 Steven Rosenberg 2020-01-08 16:42:49 UTC
Could you provide more information on simulating this issue? For example if one creates a VM within the WebAdmin, what exactly are you importing? If the VM is created externally and being imported it makes sense, but then it is not clear how you are creating it.

Anyway I simulated steps 1-3 with no errors via the WebAdmin. Please advise on step 4 accordingly.

Comment 4 Ryan Barry 2020-01-08 19:04:30 UTC
Note that this is from a storage domain import. Follow the steps in comment#1, detach the storage domain, re-attach it, and try to import it. This is where the reported problem is

Comment 5 Steven Rosenberg 2020-01-09 09:53:06 UTC
(In reply to Ryan Barry from comment #4)
> Note that this is from a storage domain import. Follow the steps in
> comment#1, detach the storage domain, re-attach it, and try to import it.
> This is where the reported problem is

It states on step 4 to import the VM not the Storage Domain. It is not clear from where the VM is to be imported from if it was created in the WebAdmin to begin with.

Comment 6 nijin ashok 2020-01-09 09:58:52 UTC
(In reply to Steven Rosenberg from comment #5)
> (In reply to Ryan Barry from comment #4)
> > Note that this is from a storage domain import. Follow the steps in
> > comment#1, detach the storage domain, re-attach it, and try to import it.
> > This is where the reported problem is
> 
> It states on step 4 to import the VM not the Storage Domain. It is not clear
> from where the VM is to be imported from if it was created in the WebAdmin
> to begin with.

You just have to import the VM. Storage domain => Click on the storage => Import VM.

Please note that you have to try with the VM which only has a direct LUN.

Comment 7 Steven Rosenberg 2020-01-09 11:00:52 UTC
Created attachment 1650938 [details]
Screen shot with the VM already imported to the iSci Storage domain

The VM was already imported to the Storage Domain successfully

Comment 8 nijin ashok 2020-01-09 11:26:33 UTC
(In reply to Steven Rosenberg from comment #7)
> Created attachment 1650938 [details]
> Screen shot with the VM already imported to the iSci Storage domain
> 
> The VM was already imported to the Storage Domain successfully

To confirm, was the VM only has direct LUN or it was having regular disks from the storage domain?

Comment 9 Steven Rosenberg 2020-01-09 11:46:18 UTC
Created attachment 1650943 [details]
VM No Virt IO with LUN disks snap shot

Comment 10 Steven Rosenberg 2020-01-09 11:47:17 UTC
Created attachment 1650944 [details]
VM No Virt IO in the edit showing Virt-IO scisi is disabled

Comment 11 nijin ashok 2020-01-09 12:57:10 UTC
(In reply to Steven Rosenberg from comment #10)
> Created attachment 1650944 [details]
> VM No Virt IO in the edit showing Virt-IO scisi is disabled

I just now tried in another environment. Looks like the UI exception was specific to the environment I am using. However, I can still reproduce the "Virtio-SCSI disabled error". This error was also observed for the customer. Please refer to the attached screenshot.

Can you please let me know the versions you are using? I am having rhvm-4.3.7.2-0.1.el7.noarch. Also, can you attach your VMs OVF?

Comment 12 nijin ashok 2020-01-09 12:58:02 UTC
Created attachment 1650961 [details]
error about virtio-scsi.

Comment 13 Steven Rosenberg 2020-01-09 17:22:45 UTC
(In reply to nijin ashok from comment #11)
> (In reply to Steven Rosenberg from comment #10)
> > Created attachment 1650944 [details]
> > VM No Virt IO in the edit showing Virt-IO scisi is disabled
> 
> I just now tried in another environment. Looks like the UI exception was
> specific to the environment I am using. However, I can still reproduce the
> "Virtio-SCSI disabled error". This error was also observed for the customer.
> Please refer to the attached screenshot.
> 
> Can you please let me know the versions you are using? I am having
> rhvm-4.3.7.2-0.1.el7.noarch. Also, can you attach your VMs OVF?

I am running from the master branch which will be version 4.4. 

Your screenshot shows from the name that it is nfs-data. Is it truely Block scsi?

Could you please provide your screenshots for each step so we can synchronize what you are doing with what I am doing, especially for step 2. 

We are wondering why disabling the VirtIO-SCSI allows you to attach a Direct LUN as well.

Comment 14 Steven Rosenberg 2020-01-09 17:24:41 UTC
Created attachment 1651043 [details]
ovf of the VM

This is my ovf

Comment 15 nijin ashok 2020-01-10 05:18:52 UTC
(In reply to Steven Rosenberg from comment #14)
> Created attachment 1651043 [details]
> ovf of the VM
> 
> This is my ovf

I cannot see any disk in your OVF.

====
<Section xsi:type="ovf:DiskSection_Type">
<Info>List of Virtual Disks</Info>                           ====> No virtual disk here
</Section>
<Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type">
<Name>VmNoVirtIO</Name>
====

Please see my OVF uploaded in comment 1.

====
<Section xsi:type="ovf:DiskSection_Type">
<Info>List of Virtual Disks</Info>
<Disk ovf:diskId="32b6b130-7645-46cd-aa51-4854ab0c5416" ovf:disk-alias="test_import-vm_Disk1" ovf:disk-description="a9f7" ovf:pass-discard="false" ovf:fileRef="32b6b130-7645-46cd-aa51-4854ab0c5416" ovf:shareable="false" ovf:boot="true" ovf:disk-interface="VirtIO" ovf:read-only="false" ovf:scsi_reservation="false" ovf:plugged="true" ovf:lun_id="36001405dae0b035ca514e7cb7d64a9f7">
<Connection ovf:connection="192.168.1.2" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
<Connection ovf:connection="192.168.2.4" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
<Connection ovf:connection="192.168.3.4" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
</Disk>
</Section>
<Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type">
<Name>test_import-vm</Name>
====

Without the disk in the OVF, I am not sure how you were able to import the VM with the disk. Did you attempt to do the "import" task from "VM import" tab? The VM will not get removed when you detach the storage domain if the VM only has the direct LUN. You have to remove the VM manually and have to try the import to test. Could you please confirm this?
 
> Your screenshot shows from the name that it is nfs-data. Is it truely Block
> scsi?

The storage domain was NFS however the VM doesn't have any disk from this storage domain. The direct LUN was attached which is from ISCSI storage domain.

> We are wondering why disabling the VirtIO-SCSI allows you to attach a Direct
> LUN as well.

You can attach direct LUN as VirtIO or IDE even if VirtIO-SCSI is disabled.

Comment 16 Steven Rosenberg 2020-01-12 09:46:12 UTC
(In reply to nijin ashok from comment #15)
> (In reply to Steven Rosenberg from comment #14)
> > Created attachment 1651043 [details]
> > ovf of the VM
> > 
> > This is my ovf
> 
> I cannot see any disk in your OVF.
> 
> ====
> <Section xsi:type="ovf:DiskSection_Type">
> <Info>List of Virtual Disks</Info>                           ====> No
> virtual disk here
> </Section>
> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type">
> <Name>VmNoVirtIO</Name>
> ====
> 
> Please see my OVF uploaded in comment 1.
> 
> ====
> <Section xsi:type="ovf:DiskSection_Type">
> <Info>List of Virtual Disks</Info>
> <Disk ovf:diskId="32b6b130-7645-46cd-aa51-4854ab0c5416"
> ovf:disk-alias="test_import-vm_Disk1" ovf:disk-description="a9f7"
> ovf:pass-discard="false" ovf:fileRef="32b6b130-7645-46cd-aa51-4854ab0c5416"
> ovf:shareable="false" ovf:boot="true" ovf:disk-interface="VirtIO"
> ovf:read-only="false" ovf:scsi_reservation="false" ovf:plugged="true"
> ovf:lun_id="36001405dae0b035ca514e7cb7d64a9f7">
> <Connection ovf:connection="192.168.1.2"
> ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b"
> ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
> <Connection ovf:connection="192.168.2.4"
> ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b"
> ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
> <Connection ovf:connection="192.168.3.4"
> ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b"
> ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
> </Disk>
> </Section>
> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type">
> <Name>test_import-vm</Name>
> ====
> 
> Without the disk in the OVF, I am not sure how you were able to import the
> VM with the disk. Did you attempt to do the "import" task from "VM import"
> tab? The VM will not get removed when you detach the storage domain if the
> VM only has the direct LUN. You have to remove the VM manually and have to
> try the import to test. Could you please confirm this?
>  
> > Your screenshot shows from the name that it is nfs-data. Is it truely Block
> > scsi?
> 
> The storage domain was NFS however the VM doesn't have any disk from this
> storage domain. The direct LUN was attached which is from ISCSI storage
> domain.
> 
> > We are wondering why disabling the VirtIO-SCSI allows you to attach a Direct
> > LUN as well.
> 
> You can attach direct LUN as VirtIO or IDE even if VirtIO-SCSI is disabled.

I received a warning that the LUN disk would not be included in the ovf when exporting which is why you do not see it there. I did provide the screenshot showing the LUN was attached. As per my previous comments, the VM was imported automatically when reattaching the Storage Domain, so we are not simulating the same thing.

Again could you please provide screen shots on what you are doing, especially step 2? It is not clear how you are doing that with the virtIO Driver, especially since you are disabling the virtio-scsi in the first place. T

Comment 18 Steven Rosenberg 2020-01-14 17:06:29 UTC
Should we even allow step 2 of setting a scsi disk to the VM when the VirtIO-SCSI is disabled? Also when I exported the VM, it did not save the scsi disk. Maybe we should be consistent with the Storage Domain when it attaches to the DC.

Comment 19 nijin ashok 2020-01-15 10:15:13 UTC
Please note that the older operating system (RHEL 5 and below) doesn't support VirtIO-SCSI. The customer who faced this bug was having RHEL 5 VMs where there is no option to enable VirtIO-SCSI.

Comment 20 Martin Tessun 2020-01-17 09:23:33 UTC
Hi Steven,

(In reply to Steven Rosenberg from comment #18)
> Should we even allow step 2 of setting a scsi disk to the VM when the
> VirtIO-SCSI is disabled? Also when I exported the VM, it did not save the
> scsi disk. Maybe we should be consistent with the Storage Domain when it
> attaches to the DC.

looking at the OVF, I believe this is about direct attached iSCSI LUN:

====
<Section xsi:type="ovf:DiskSection_Type">
    <Info>List of Virtual Disks</Info>
    <Disk ovf:diskId="32b6b130-7645-46cd-aa51-4854ab0c5416" ovf:disk-alias="test_import-vm_Disk1" ovf:disk-description="a9f7" ovf:pass-discard="false" ovf:fileRef="32b6b130-7645-46cd-aa51-4854ab0c5416" ovf:shareable="false" ovf:boot="true" ovf:disk-interface="VirtIO" ovf:read-only="false" ovf:scsi_reservation="false" ovf:plugged="true" ovf:lun_id="36001405dae0b035ca514e7cb7d64a9f7">
        <Connection ovf:connection="192.168.1.2" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
        <Connection ovf:connection="192.168.2.4" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
        <Connection ovf:connection="192.168.3.4" ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b" ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
    </Disk>
</Section>
====

This disk is an iSCSI LUN, so ít cannot be part of the OVA, but it is a direct attached LUN with 3 paths. I am not sure how to best handle this, as re-attaching these disks, means we need to ensure that the IQN is accessible from the RHV domain that imports that VM and it needs to be available as a Direct LUN in RHV-M as well, but the error message is definitely wrong - or are direct LUNs always attached to a virtio-SCSI controller? At least on qemu/libvirt level this disk can also be attached to a virtio-blk controller.

Looking at the screencast it looks like Nishin did the following:
1. Create a VM
2. Disable virtio-scsi
3. Attach an iSCSI direct LUN
4. Detach the Storage Domain
5. Delete the VM
6. (Re-)Import the Storage Domain
7. (Re-)Import the VM

In case we need virtio-scsi for direct attached LUNs, I would expect that the attach direct LUN step would fail and not the re-import.
What I would like to see is the definition of the VM as libvirt-xml, so an additional step:

3a Start VM
3b run virsh -r dumpxml <name> on the host

@Nishin: can you do this and attach the XML here, so we can have a look how the VM gets generated?

@Steven: In any case this is a bug. Either we need to forbid step (3) in case there is no virtio-scsi or we have to fix (7).

Cheers,
Martin

Comment 21 Steven Rosenberg 2020-01-19 09:21:22 UTC
(In reply to Martin Tessun from comment #20)
> Hi Steven,
> 
> (In reply to Steven Rosenberg from comment #18)
> > Should we even allow step 2 of setting a scsi disk to the VM when the
> > VirtIO-SCSI is disabled? Also when I exported the VM, it did not save the
> > scsi disk. Maybe we should be consistent with the Storage Domain when it
> > attaches to the DC.
> 
> looking at the OVF, I believe this is about direct attached iSCSI LUN:
> 
> ====
> <Section xsi:type="ovf:DiskSection_Type">
>     <Info>List of Virtual Disks</Info>
>     <Disk ovf:diskId="32b6b130-7645-46cd-aa51-4854ab0c5416"
> ovf:disk-alias="test_import-vm_Disk1" ovf:disk-description="a9f7"
> ovf:pass-discard="false" ovf:fileRef="32b6b130-7645-46cd-aa51-4854ab0c5416"
> ovf:shareable="false" ovf:boot="true" ovf:disk-interface="VirtIO"
> ovf:read-only="false" ovf:scsi_reservation="false" ovf:plugged="true"
> ovf:lun_id="36001405dae0b035ca514e7cb7d64a9f7">
>         <Connection ovf:connection="192.168.1.2"
> ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b"
> ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
>         <Connection ovf:connection="192.168.2.4"
> ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b"
> ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
>         <Connection ovf:connection="192.168.3.4"
> ovf:iqn="iqn.2003-01.org.linux-iscsi.storage.x8664:sn.52fd3f4b2f0b"
> ovf:port="3260" xsi:storage_type="ISCSI" xsi:portal="1"/>
>     </Disk>
> </Section>
> ====
> 
> This disk is an iSCSI LUN, so ít cannot be part of the OVA, but it is a
> direct attached LUN with 3 paths. I am not sure how to best handle this, as
> re-attaching these disks, means we need to ensure that the IQN is accessible
> from the RHV domain that imports that VM and it needs to be available as a
> Direct LUN in RHV-M as well, but the error message is definitely wrong - or
> are direct LUNs always attached to a virtio-SCSI controller? At least on
> qemu/libvirt level this disk can also be attached to a virtio-blk controller.
> 
> Looking at the screencast it looks like Nishin did the following:
> 1. Create a VM
> 2. Disable virtio-scsi
> 3. Attach an iSCSI direct LUN
> 4. Detach the Storage Domain
> 5. Delete the VM
> 6. (Re-)Import the Storage Domain
> 7. (Re-)Import the VM
> 
> In case we need virtio-scsi for direct attached LUNs, I would expect that
> the attach direct LUN step would fail and not the re-import.
> What I would like to see is the definition of the VM as libvirt-xml, so an
> additional step:
> 
> 3a Start VM
> 3b run virsh -r dumpxml <name> on the host
> 
> @Nishin: can you do this and attach the XML here, so we can have a look how
> the VM gets generated?
> 
> @Steven: In any case this is a bug. Either we need to forbid step (3) in
> case there is no virtio-scsi or we have to fix (7).
> 
> Cheers,
> Martin

Thank you for your response. We eventually addressed this issue by fixing step 7.

Comment 23 Evelina Shames 2020-04-21 07:28:59 UTC
Verified on engine-4.4.0-0.33.master.el8ev with the following steps:

1. Create a VM with disabled virtio-scsi and disk on iscsi Storage Domain
2. Attach an iSCSI direct LUN
3. Detach the Storage Domain
4. Delete the direct LUN
5. Import the Storage Domain 
6. Import the VM -> VM is imported with both image disk and direct LUN.

Comment 30 errata-xmlrpc 2020-08-04 13:21:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:3247