|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC]QEMU disk I/O limits |
Date: | Tue, 31 May 2011 18:30:09 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 |
On 05/31/2011 02:24 PM, Vivek Goyal wrote:
On Tue, May 31, 2011 at 01:39:47PM -0500, Anthony Liguori wrote:On 05/31/2011 12:59 PM, Vivek Goyal wrote:Ok, so we seem to be talking of two requirements. - A consistent experience to guest - Isolation between VMs. If this qcow2 mapping/metada overhead is not significant, then we don't have to worry about IOPs perceived by guest. It will be more or less same. If it is significant then we provide more consistent experience to guest but then weaken the isolation between guest and might overload the backend storage and in turn might not get the expected IOPS for the guest anyway.
That's quite a bit of hand waving considering your following argument is that you can't be precise enough at the QEMU level.
So I think these two things are not independent. I agree though that advantage of qemu is that everything is a file and handling all the complex configuraitons becomes very easy. Having said that, to provide a consistent experience to guest, you also need to know where IO from guest is going and whether underlying storage system can support that kind of IO or not. IO limits are of not much use if if these are put in isolation without knowing where IO is going and how many VMs are doing IO to it. Otherwise there are no gurantees/estimates on minimum bandwidth for guests hence there is no consistent experience.
Consistent and maximum are two very different things.QEMU can, very effectively, enforce a maximum I/O rate. This can then be used to provide mostly consistent performance across different generations of hardware, to implement service levels in a tiered offering, etc.
The level of consistency will then depend on whether you overcommit your hardware and how you have it configured.
Consistency is very hard because at the end of the day, you still have shared resources. Even with blkio, I presume one guest can still impact another guest by forcing the disk to do excessive seeking or something of that nature.
So absolutely consistency can't be the requirement for the use-case. The use-cases we are interested really are more about providing caps than anything else.
Regards, Anthony Liguori
Thanks Vivek
[Prev in Thread] | Current Thread | [Next in Thread] |