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