From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>,
qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, Juan Quintela <quintela@redhat.com>
Subject: [Qemu-devel] Re: KVM call agenda for Mar 16
Date: Tue, 16 Mar 2010 15:23:49 +0000 [thread overview]
Message-ID: <20100316152346.GM23617@redhat.com> (raw)
In-Reply-To: <4B9F9E44.9050807@codemonkey.ws>
On Tue, Mar 16, 2010 at 10:05:40AM -0500, Anthony Liguori wrote:
> On 03/16/2010 05:45 AM, Daniel P. Berrange wrote:
> >On Tue, Mar 16, 2010 at 12:38:02PM +0200, Avi Kivity wrote:
> >
> >>On 03/16/2010 12:31 PM, Daniel P. Berrange wrote:
> >>
> >>>>Polling loops are an indication that something is wrong.
> >>>>
> >>>>
> >>>Except when people suggest they are the right answer, qcow high
> >>>watermark ;-P
> >>>
> >>>
> >>I liked Anthony's suggestion of an lvm2 block format driver. No polling.
> >>
> >Doesn't that require giving QEMU privileges to perform LVM operations which
> >implies QEMU having CAP_SYS_ADMIN ?
> >
>
> If QEMU is able to resize an LVM partition, it needs to carry privileges.
>
> I'm not sure how this can be done safely in a lesser privileged
> environment. Presumably, you're over committing storage and there's not
> much you can do if the guests exhaust their storage all at once.
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.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2010-03-16 15:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-16 7:01 [Qemu-devel] KVM call agenda for Mar 16 Chris Wright
2010-03-16 9:18 ` [Qemu-devel] " Juan Quintela
2010-03-16 9:29 ` Daniel P. Berrange
2010-03-16 9:43 ` Avi Kivity
2010-03-16 10:31 ` Daniel P. Berrange
2010-03-16 10:38 ` Avi Kivity
2010-03-16 10:45 ` Christoph Hellwig
2010-03-16 10:45 ` Daniel P. Berrange
2010-03-16 11:16 ` Avi Kivity
2010-03-16 15:05 ` Anthony Liguori
2010-03-16 15:23 ` Daniel P. Berrange [this message]
2010-03-16 15:46 ` Anthony Liguori
2010-03-16 10:09 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100316152346.GM23617@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).