Bug 1181648

Summary:	[RFE] Add an event to report if a block device usage exceeds a threshold.
Product:	Red Hat Enterprise Linux 7	Reporter:	Francesco Romani <fromani>
Component:	qemu-kvm-rhev	Assignee:	Stefan Hajnoczi <stefanha>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	chayang, dzheng, hhuang, huding, juzhang, knoel, michal.skrivanek, mrezanin, sherold, stefanha, virt-maint, xfu
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	qemu-kvm-rhev-2.3.0-1.el7	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-04 16:25:24 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:
Embargoed:
Bug Depends On:
Bug Blocks:	1154205, 1181659, 1181665

Description Francesco Romani 2015-01-13 14:27:29 UTC

Description of problem:
Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query-blockstats output.

Rationale for the RFE:
RHEV makes extensive use of thin-provisioned disk images.
In order to let the guest run flawlessly and be not unnecessarily paused, RHEV sets a watermark and automatically resized the image once the watermark is reached or exceeded.

In order to detect the mark crossing, the managing application has no choice than aggressively polling using libvirt, which in turn enters the qemu monitor. This lead to unnecessary system load, and is made even worse under scale: scenarios with hunderds of VM are becoming not unusual.


Additional info:
This is the -rhev counterpart of the upstream bug: 
https://bugs.launchpad.net/qemu/+bug/1338957?comments=all

A patch implementing the feature was patch posted on qemu-devel, reviewd, acked and merged into this branch:
https://github.com/stefanha/qemu/commit/f050ea639522e9dd7e501ef285a2a12709b8726a

RHEV would like to make use of this feature in the new release, to improve scalability.

Comment 2 Michal Skrivanek 2015-01-13 15:53:19 UTC

7.2 should be ok for our needs

Comment 8 Jun Li 2015-06-25 05:17:51 UTC

Verify:

Version of components:
qemu-kvm-rhev-2.3.0-4.el7.x86_64

Steps:
1, boot guest with a data-disk.
Such as:
# qemu-img info /home/juli/test.raw 
image: /home/juli/test.raw
file format: raw
virtual size: 5.0G (5368709120 bytes)
disk size: 211M

# /usr/libexec/qemu-kvm -m 2G -drive file=/home/juli/RHEL-Server-7.2-64-virtio.raw,if=none,id=sys,snapshot=on -device virtio-blk-pci,drive=sys,id=sys-sys  -drive file=/home/juli/test.raw,if=none,id=img,node-name=juli -device virtio-blk-pci,drive=img,id=sys-img -monitor stdio -vnc :1 -qmp tcp::8888,server,nowait

2, using block-set-write-threshold to set data-disk with 1k.
e.g:
{"execute":"qmp_capabilities"}
{ "execute": "query-named-block-nodes" }
{ "execute": "block-set-write-threshold",
  "arguments": { "node-name": "juli",
                 "write-threshold": 1000 } }

3, login guest and do some write operations for this data-disk.
e.g:
# mkfs.ext4 /dev/vdb

4, during step3, check the output of qmp.
{"timestamp": {"seconds": 1435209056, "microseconds": 499179}, "event": "BLOCK_WRITE_THRESHOLD", "data": {"node-name": "juli", "write-threshold": 1000, "amount-exceeded": 2632728}}

As above show, this bz has been verified.

Comment 9 Jun Li 2015-06-25 05:24:10 UTC

According to comment 8, set this bz as verified. Any issue, free to correct me. Thx.

Comment 11 errata-xmlrpc 2015-12-04 16:25:24 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, 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://rhn.redhat.com/errata/RHBA-2015-2546.html