Bug #2700
closedblkdeviotune method at libvirt doesn`t work on RBD volumes
100%
Description
Since qemu implemented its own i/o limiting mechanism rather than cgroups, all block backends may be controlled over blkdeviotune, but right now libvirt throws an error instead of setting the limit. Probably should be fixed as Wido suggested in [1] (I`m using this hack for a long time without running into any problem).
1. http://comments.gmane.org/gmane.comp.file-systems.ceph.devel/5861
Files
Updated by Josh Durgin about 11 years ago
This is something that we should fix. Is it still an issue in current libvirt?
Updated by Andrey Korolyov about 11 years ago
Just checked, problem with blkdeviotune still exists in the 1.0.2.
Updated by Wido den Hollander about 11 years ago
- Assignee set to Wido den Hollander
Sage just pinged me about this bug report.
I'll pick this up and write patch for libvirt to fix this.
Updated by Wido den Hollander about 11 years ago
- File 0001-qemu-Do-not-require-devices-to-be-blocks-or-files-wh.patch 0001-qemu-Do-not-require-devices-to-be-blocks-or-files-wh.patch added
I've just submitted a patch for this to libvirt (also attached).
I tested it locally with libvirt 1.0.4 and it works just fine on my test system.
One thing I noted, which doesn't seem related to RBD is that a Virtual Machine becomes very slow and unresponsive when you hit the I/O limit, much slower then with a 100% utilized disk.
Updated by Andrey Korolyov about 11 years ago
One thing I noted, which doesn't seem related to RBD is that a Virtual Machine becomes very slow and unresponsive when you hit the I/O limit, much slower then with a 100% utilized disk.
You meant in comparison with physical machine? Qemu is a way slower due to single-threaded self-nature, and seems that it is unsolvable in near future or so.
Updated by Wido den Hollander about 11 years ago
Andrey Korolyov wrote:
One thing I noted, which doesn't seem related to RBD is that a Virtual Machine becomes very slow and unresponsive when you hit the I/O limit, much slower then with a 100% utilized disk.
You meant in comparison with physical machine? Qemu is a way slower due to single-threaded self-nature, and seems that it is unsolvable in near future or so.
Yes, compared to a physical machine. The VM becomes so slow it's not useable anymore. The throttling works nice though, it's not going over the limits.
With a physical machine stuff still works, but very slow. A VM completely stalls.
Updated by Wido den Hollander almost 11 years ago
- Status changed from New to Resolved
- % Done changed from 60 to 100
The patch got accepted into libvirt: http://www.libvirt.org/git/?p=libvirt.git;a=commit;h=e3e866aee0f8b0b125da74e1afcfe7242c2fe3d2
Closing this one as it is resolved.