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 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
