On Sun, Feb 10, 2013 at 02:20:02AM +0400, Alexander Gordeev wrote:
В Thu, 7 Feb 2013 16:09:31 +0000
"Daniel P. Berrange" <berrange(a)redhat.com> пишет:
> > It's not a POSIX FS but there is a FUSE client for it that can be
> > used to access and manipulate images. It's quite high speed but only
> > when used with O_DIRECT + aio. I tried to setup several KVMs on top of
> > a Pstorage mount using virt-manager. It worked good, but I had to:
> > 1. tune cache and IO settings for every disk
> > 2. disable space allocation by libvirt because it is using sync IO and
> > is therefore slow
> >
> > I tried to find ways to solve the first issue and IMHO this can be
> > done by adding a way to specify per-pool defaults for cache and IO
> > settings. I didn't find any way for this in the current code and UI.
> > I'd like to add a new storage backend also that will be a 'dir'
backend
> > with extra ability to manage Pstorage mount points and UI integration.
> > I'd like to merge my work to the main tree when it's finished if
> > possible.
>
> I don't think that putting cache/IO defaults in the XML is really
> appropriate. There are too many different scenarios which want
> different settings to be able to clearly identify one set of
> perfect settings. I see this as primarily a documentation problem.
> Someone needs to write something describing the diferrent settings
> for each storage pool & what the pros/cons are for each. Downstream
> app developers can then make decisions about suitable defaults for
> their use cases
If you are against changes in the XML maybe you are ok with a simpler
option: I create a storage backend for Pstorage, add two fields for
cache and io (or maybe just flags) to virStoragePoolTypeInfo and set
the right values for the new pool type. Then add some code to check
them to qemuBuildDriveStr (and to other drivers if possible, of course).
So no changes to XML and API. Is this better?
No, the hypervisor drivers can only access data that is available via
from the storage drivers via the XML or APIs. As I said before this is
a policy decision for application authors to take, not for libvirt
itself.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|