summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1338957
blob: 158007a5f1379f5af5954fad5d03c2f0c6f422b9 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
performance: 0.761
semantic: 0.689
graphic: 0.680
device: 0.640
ppc: 0.590
architecture: 0.539
files: 0.520
socket: 0.515
network: 0.493
mistranslation: 0.477
vnc: 0.475
peripherals: 0.463
boot: 0.459
register: 0.455
risc-v: 0.451
hypervisor: 0.438
kernel: 0.419
virtual: 0.418
i386: 0.410
VMM: 0.402
PID: 0.333
permissions: 0.305
TCG: 0.298
x86: 0.276
KVM: 0.241
debug: 0.240
assembly: 0.231
arm: 0.225
user-level: 0.118

RFE: add an event to report block devices watermark

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
Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images.
In order to let the guest run flawlessly and be not unnecessarily paused, oVirt 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 the QEMU monitor
using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios
with hunderds of VM are becoming not unusual.

patch posted on qemu-devel, reviewd, acked and merged into maintainer's branch:
https://github.com/stefanha/qemu/commit/f050ea639522e9dd7e501ef285a2a12709b8726a

Upstream here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e2462113b2003085ad16f15e1