[Libvir] Concepts in storage management

[Daniel P. Berrange]

On Wed, Oct 17, 2007 at 02:55:21PM +0100, Mark McLoughlin wrote:
> Hi Dan,
> 	FWIW, this looks pretty much spot on to me ... I'm not sure there's a
> lot to discuss :-)
> 
> On Tue, 2007-10-16 at 16:19 +0100, Daniel P. Berrange wrote:
> 
> > Application users
> > =================
> > 
> >  - virt-manager / virt-install
> >     - Enumerate available pools
> >     - Allocate volume from pool
> >     - Create guest with volume
> 
> 	Nice that you list these and concentrate on them.
> 
> > Two core concepts
> > 
> >  - Volume
> >     - a chunk of storage
> >     - assignable to a guest
> >     - assignable to a pool
> >     - optionally part of a pool
> > 
> >  - Pool
> >     - a chunk of storage
> >     - contains free space
> >     - allocate to provide volumes
> >     - compromised of volumes
> > 
> > Recursive! 
> > 
> >   n x Volume -> Pool -> n x Volume 
> > 
> > Nesting to many levels...
> 
> 	Hmm, I'd try and avoid the confusion associated with this nesting
> concept ...
> 
> 	What kind of uses for it are you thinking? 

This mention of recursion seems  to have caused alot of confusion...

All I really mean by it is that libvirt has two notions

 - A volume
 - A pool

When you define a pool, the XML description may refer to one of more
volumes which are the source of the pool. eg if you define a new LVM
volume group, you provide one or more physical volumes.

Given a pool you may carve out out or more volumes. eg you carve out
logical volumes.


So, the APIs from a libvirt level aren't directly 'recursive' - you just
have a concept of a pool & a volume object. As you work with these two
concepts you may end up creating things which are recursive in nature.
In fact even if you don't conciously define anything recursive, it is
indirectly recursive, since a Fedora guest will turn a disk it is assigned
into a LVM vol group & logical vols.  

So in summary, the 'recursion' is just a fundamental property of the 
storage stack, but not something we need to directly express in libvirt 
APIs - the mere concepts of a volume & a pool is sufficient.

> > Operations
> > ==========
> > 
> > Limited set of operations to perform
> > 
> >  - List host volumes   (physical attached devices)
> >  - List pools          (logical volume groups, partitioned devs, filesystems)
> >  - List pool volumes   (dev partitions, LVM logical volumes, files)
> 
> 	Perhaps there should be a default pool for each host so that to list
> host volumes you just list the volumes from the default pool?

It depends on deployment scenario, but certainly in a 'fat dom0' scenario
I imagine you couldd always provide a default pool (eg /var/lib/xen/images) 

Whether to treat the host as pool for its physically attached devices is
interesting idea. One alternative is to have an explicit API for listing
all host devices (eg,  'lshal'), since I'd certainly like to be able to
enumerate any USB, devices & any PCI devices, as well as any physical
network adapters.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|