Bug #2700
closed
This is something that we should fix. Is it still an issue in current libvirt?
Just checked, problem with blkdeviotune still exists in the 1.0.2.
- 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.
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.
- % Done changed from 0 to 60
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.
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.
- Status changed from New to Resolved
- % Done changed from 60 to 100
Also available in: Atom
PDF