Project

General

Profile

Bug #2700

blkdeviotune method at libvirt doesn`t work on RBD volumes

Added by Andrey Korolyov about 7 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Target version:
-
Start date:
07/03/2012
Due date:
% Done:

100%

Spent time:
Source:
Development
Tags:
Backport:
Regression:
No
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

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

0001-qemu-Do-not-require-devices-to-be-blocks-or-files-wh.patch View (962 Bytes) Wido den Hollander, 04/05/2013 08:39 AM

History

#1 Updated by Josh Durgin over 6 years ago

This is something that we should fix. Is it still an issue in current libvirt?

#2 Updated by Andrey Korolyov over 6 years ago

Just checked, problem with blkdeviotune still exists in the 1.0.2.

#3 Updated by Wido den Hollander over 6 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.

#4 Updated by Wido den Hollander over 6 years ago

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.

#5 Updated by Wido den Hollander over 6 years ago

  • % Done changed from 0 to 60

#6 Updated by Andrey Korolyov over 6 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.

#7 Updated by Wido den Hollander over 6 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.

#8 Updated by Wido den Hollander over 6 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.

Also available in: Atom PDF