[Libvir] Concepts in storage management

Daniel P. Berrange berrange at redhat.com
Wed Oct 17 15:29:02 UTC 2007


On Wed, Oct 17, 2007 at 04:02:01PM +0100, Daniel P. Berrange wrote:
> On Wed, Oct 17, 2007 at 02:55:21PM +0100, Mark McLoughlin wrote:
> > > 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...

Recursion is actually the wrong word. It is really a directed acyclic
graph / multi-level heirachy. Still, we only need 2 levels in any
libvirt API, a pool & a volume.

> 
> 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  -=| 
> 
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

-- 
|=- 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  -=| 




More information about the libvir-list mailing list