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(a)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 -=|