Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1983429

Summary:	Double VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD event when block threshold was set using indexed name
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	Nir Soffer <nsoffer>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
Status:	CLOSED ERRATA	QA Contact:	Han Han <hhan>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	8.5	CC:	coli, jdenemar, lmen, pkrempa, qinwang, virt-maint, xuzhang
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.5	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-7.6.0-1.module+el8.5.0+12097+2c77910b	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-11-16 07:55:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:	7.6.0
Embargoed:

Description Nir Soffer 2021-07-18 13:22:15 UTC

Description of problem:

In bug 1948177 we learned that when setting block threshold[1] using drive name
(vda), libvirt submit block threshold event[2] twice, once for the indexed name
and once for the drive name.

We tried to eliminate the double events by always using the indexed name, but 
libvirt still submit double events. RHV mitigate this by dropping the event 
for the drive name.

Getting multiple events for the same thing may break the caller event handling.
It would be nice if libvirt can avoid duplicate events when using the modern
way (indexed name).

The behavior when setting the threshold using the drive name is also not
documented.

Version-Release number of selected component (if applicable):
libvirt-daemon-7.4.0-1.module+el8.5.0+11218+83343022.x86_64

How reproducible:
Always

How this affects RHV:

- We log all events in INFO level to make it easy to debug issues related
  thin provisioned disks on block storage. The double events add noise
  the logs.

- RHV < 4.4.8 log a warning about unexpected events for the index name
  (turns into lookup error of the disk). Customers are worried by warnings
  in the logs, but we cannot hide such issues.

[1] https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetBlockThreshold
[2] https://libvirt.org/html/libvirt-libvirt-domain.html#VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD

Comment 1 Peter Krempa 2021-07-19 07:40:44 UTC

Fixed upstream:

commit 0ba4066819db8be489f1f2c69865303a94e69361
Author: Peter Krempa <pkrempa>
Date:   Thu Jul 1 16:03:58 2021 +0200

    virDomainSetBlockThreshold: Document that two events are fired when index isn't used
    
    Libvirt started emitting two threshold events, once with index and once
    withouth when the index isn't registered. Document this caveat.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>

commit a3edda6b9eed7c5ea2518ba778a5fe3c19bbb239
Author: Peter Krempa <pkrempa>
Date:   Thu Jul 1 16:03:57 2021 +0200

    qemu: Prevent two threshold events when it was registered with index
    
    Remember whether the user passed an explicit index when registering the
    event so that we can avoid the top level event when it isn't needed.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>

commit 2ddff1cc40f6d0dd821d9979bef430edefb6a553
Author: Peter Krempa <pkrempa>
Date:   Thu Jul 1 16:03:56 2021 +0200

    storage_source: Add flag storing whether threshold event was registered with index
    
    When users register the threshold event for the top level image with an
    explicit index (e.g. vda[3]) they are clearly expecting the index in the
    event.
    
    This flag will help avoiding emission of the second event without the
    index when the client clearly requested one with the index.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Michal Privoznik <mprivozn>

v7.5.0-42-g0ba4066819

Comment 2 Han Han 2021-07-27 03:24:57 UTC

Reproduced on libvirt-7.5.0-1.module+el8.5.0+11664+59f87560.x86_64:
1. Prepare a running VM with following disk XML:
<disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/tmp/vdb.qcow2" index="4"/>
      <backingStore type="file" index="5">
        <format type="raw"/>
        <source file="/tmp/vdb"/>
        <backingStore/>
      </backingStore>
      <target dev="vdb" bus="virtio"/>
      <alias name="virtio-disk1"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x0a" function="0x0"/>
    </disk>

2. Set threshold:
➜  ~ virsh domblkthreshold hhan-1 'vdb[4]' 2048

3. Monitor the VM events and write data to that disk inside VM beyond the threshold:
➜  ~ virsh event hhan-1 --loop --all


[root@localhost ~]# dd if=/dev/urandom of=/dev/vda bs=10M count=10                                                                                                                           
10+0 records in
10+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 1.47574 s, 71.1 MB/s


4. Check the VM events:
event 'block-threshold' for domain 'hhan-1': dev: vdb(/tmp/vdb.qcow2) 2048 194560
event 'block-threshold' for domain 'hhan-1': dev: vdb[4](/tmp/vdb.qcow2) 2048 194560

Double events for block-threshold.

Comment 3 Han Han 2021-07-27 03:27:06 UTC

Pre-verify on libvirt v7.5.0-246-gcd72f0cd9f:
Tested as comment2. Only one events for the domblkthreshold with disk index:
➜  ~ virsh event rhel9 --loop --all            
event 'block-threshold' for domain 'rhel9': dev: vdb[4](/tmp/vdb.qcow2) 20480 176128

Comment 6 Han Han 2021-08-04 07:18:18 UTC

Tested as comment2. PASS
version:
libvirt-7.6.0-1.module+el8.5.0+12097+2c77910b.x86_64
qemu-kvm-6.0.0-26.module+el8.5.0+12044+525f0ebc.x86_64

Comment 8 errata-xmlrpc 2021-11-16 07:55:01 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 (virt:av 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/RHBA-2021:4684