[libvirt] libvirt and Parallels Cloud Storage

[Alexander Gordeev]

В Mon, 11 Feb 2013 09:57:05 +0000
"Daniel P. Berrange" <berrange at redhat.com> пишет:

> 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 at 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.

Ok, I certainly see the point about policy decisions but shouldn't
libvirt store the selected policy somehow? :)

-- 
  Alexander