From mboxrd@z Thu Jan 1 00:00:00 1970 From: Blue Swirl Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits Date: Sat, 4 Jun 2011 11:54:45 +0300 Message-ID: References: <20110530050923.GF18832@f12.cn.ibm.com> <20110531134537.GE16382@redhat.com> <4DE4F230.2040203@us.ibm.com> <20110531140402.GF16382@redhat.com> <4DE4FA5B.1090804@codemonkey.ws> <20110531175955.GI16382@redhat.com> <4DE535F3.6040400@codemonkey.ws> <20110531192434.GK16382@redhat.com> <4DE57A01.1070205@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Vivek Goyal , kwolf@redhat.com, stefanha@linux.vnet.ibm.com, Mike Snitzer , guijianfeng@cn.fujitsu.com, qemu-devel@nongnu.org, wuzhy@cn.ibm.com, herbert@gondor.hengli.com.au, Joe Thornber , Zhi Yong Wu , luowenj@cn.ibm.com, kvm@vger.kernel.org, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com, llim@redhat.com, Ryan A Harper To: Anthony Liguori Return-path: Received: from mail-qy0-f181.google.com ([209.85.216.181]:51881 "EHLO mail-qy0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753335Ab1FDIzF convert rfc822-to-8bit (ORCPT ); Sat, 4 Jun 2011 04:55:05 -0400 Received: by qyg14 with SMTP id 14so1273400qyg.19 for ; Sat, 04 Jun 2011 01:55:05 -0700 (PDT) In-Reply-To: <4DE57A01.1070205@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jun 1, 2011 at 2:30 AM, Anthony Liguori = wrote: > 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 o= r less >> same. If it is significant then we provide more consistent experienc= e 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 underlyin= g >> storage system can support that kind of IO or not. >> >> IO limits are of not much use if if these are put in isolation witho= ut >> knowing where IO is going and how many VMs are doing IO to it. Other= wise >> there are no gurantees/estimates on minimum bandwidth for guests hen= ce >> there is no consistent experience. > > Consistent and maximum are two very different things. > > QEMU can, very effectively, enforce a maximum I/O rate. =C2=A0This ca= n then be > used to provide mostly consistent performance across different genera= tions > of hardware, to implement service levels in a tiered offering, etc. What is the point of view, guest or host? It is not possible to enforce any rates which would make sense to guests without taking into account guest clock and execution speed. If instead you mean host rate (which would not be in sync with I/O rates seen by guest), then I'd suppose metadata accesses would also matter and then the host facilities should produce same results. On a positive side, they may only exist on newer Linux and not on other OS so introducing them to QEMU would not be so bad idea. > The level of consistency will then depend on whether you overcommit y= our > hardware and how you have it configured. > > Consistency is very hard because at the end of the day, you still hav= e > shared resources. =C2=A0Even with blkio, I presume one guest can stil= l impact > another guest by forcing the disk to do excessive seeking or somethin= g 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 >> > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSmdQ-0008G0-HC for qemu-devel@nongnu.org; Sat, 04 Jun 2011 04:55:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSmdO-0007cs-0j for qemu-devel@nongnu.org; Sat, 04 Jun 2011 04:55:08 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:61881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSmdN-0007cn-PZ for qemu-devel@nongnu.org; Sat, 04 Jun 2011 04:55:05 -0400 Received: by qyk10 with SMTP id 10so1345603qyk.4 for ; Sat, 04 Jun 2011 01:55:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DE57A01.1070205@codemonkey.ws> References: <20110530050923.GF18832@f12.cn.ibm.com> <20110531134537.GE16382@redhat.com> <4DE4F230.2040203@us.ibm.com> <20110531140402.GF16382@redhat.com> <4DE4FA5B.1090804@codemonkey.ws> <20110531175955.GI16382@redhat.com> <4DE535F3.6040400@codemonkey.ws> <20110531192434.GK16382@redhat.com> <4DE57A01.1070205@codemonkey.ws> From: Blue Swirl Date: Sat, 4 Jun 2011 11:54:45 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, Mike Snitzer , guijianfeng@cn.fujitsu.com, qemu-devel@nongnu.org, wuzhy@cn.ibm.com, herbert@gondor.hengli.com.au, Joe Thornber , Zhi Yong Wu , luowenj@cn.ibm.com, kvm@vger.kernel.org, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com, llim@redhat.com, Ryan A Harper , Vivek Goyal On Wed, Jun 1, 2011 at 2:30 AM, Anthony Liguori wro= te: > 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 le= ss >> 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. =C2=A0This can th= en be > used to provide mostly consistent performance across different generation= s > of hardware, to implement service levels in a tiered offering, etc. What is the point of view, guest or host? It is not possible to enforce any rates which would make sense to guests without taking into account guest clock and execution speed. If instead you mean host rate (which would not be in sync with I/O rates seen by guest), then I'd suppose metadata accesses would also matter and then the host facilities should produce same results. On a positive side, they may only exist on newer Linux and not on other OS so introducing them to QEMU would not be so bad idea. > 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. =C2=A0Even with blkio, I presume one guest can still im= pact > 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 >> > > >