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