From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrYzT-0006T4-0Y for qemu-devel@nongnu.org; Tue, 16 Mar 2010 11:47:31 -0400 Received: from [199.232.76.173] (port=51623 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrYzS-0006Sj-IJ for qemu-devel@nongnu.org; Tue, 16 Mar 2010 11:47:30 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrYzR-00078r-7g for qemu-devel@nongnu.org; Tue, 16 Mar 2010 11:47:30 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:59017) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrYzQ-00078n-V1 for qemu-devel@nongnu.org; Tue, 16 Mar 2010 11:47:29 -0400 Received: by pwi9 with SMTP id 9so73741pwi.4 for ; Tue, 16 Mar 2010 08:47:27 -0700 (PDT) Message-ID: <4B9FA7ED.5040206@codemonkey.ws> Date: Tue, 16 Mar 2010 10:46:53 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20100316070155.GK3732@x200.localdomain> <20100316092944.GB23617@redhat.com> <4B9F52D4.2030208@redhat.com> <20100316103146.GF23617@redhat.com> <4B9F5F8A.4080105@redhat.com> <20100316104537.GH23617@redhat.com> <4B9F9E44.9050807@codemonkey.ws> <20100316152346.GM23617@redhat.com> In-Reply-To: <20100316152346.GM23617@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KVM call agenda for Mar 16 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Chris Wright , qemu-devel@nongnu.org, Avi Kivity , kvm@vger.kernel.org, Juan Quintela On 03/16/2010 10:23 AM, Daniel P. Berrange wrote: > In the context of the RHEV management application, iSCSI/SCSI Fibre are > providing the raw storage, with LVM VGs on top and the carving LVs for > the guests. In the common case the admin/app would monitor VG usage& LV > rate of increase to ensure extra space was available in the VG ahead of > it being needed. eg if the VG comes close to exhaustion then further LUNS > can be obtained and added as PVs to the LVM volume group. So you can't > guarentee that a VM won't stop on ENOSPC, but it is very unlikely if the > system is operating correctly. > > As an added complication, since cluster-LVM isn't used, all LVM operations > have to be performed on a dedicated/exclusive storage host and then metadata > refreshed/propagated to other hosts running VMs. This last issue implies that > letting QEMU resize its LV would never be possible, even if it were not for > the permissions problem. > Sounds like a good argument for polling :-) Regards, Anthony Liguori > Regards, > Daniel >