On Thu, Oct 18, 2007 at 07:30:22PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >Virt-manager may currently handle these two concepts of block & files
> >separately, but this is only because we had no choice due to lack of any
> >storage API. I have long wanted to clean this up to just have the concept
> >of storage pools & volumes within it.
>
> I did notice that there was an overlap between files and volumes once I
> started writing down the structures required. For example:
>
> struct virStorageGroup {
> int magic; /* Magic / structure version. */
> char *name; /* Volume group name. */
> int flags; /* Flags. */
> unsigned long long size; /* Total size in kilobytes. */
> unsigned long long avail; /* Available (free) space in kilobytes. */
> };
>
> struct virStorageStatVFSBuffer {
> unsigned long bsize; /* Block size. */
> unsigned long long bavail; /* Blocks available. */
> };
>
> have a kind of common structure. I kept them separate for easy of
> retrofitting into virt-manager, but combining them is also a possibility.
Using structures in the public API is not in keeping with the rest of
the libvirt APIs. We should be using XML for the main metadata description
of volumes & pools.
> Another point which I thought about but forgot to put in the original
> email is what happens if you have (for example) LVM volume groups and
> iSCSI available. Then you need to do something like:
>
> list_groups = "(vgs | vgs2xml) <combine> (iscsiadm | iscsi2xml)"
>
> where <combine> is some sort of XML-combining operation. If we combine
> directories (for file-backed storage) with LVM VGs, then we'll also need
> this operation.
This is just one reason why I don't like the idea of simply running shell
scripts in the back end. This will result in a unreliable, hard-to debug
system. It may be a short term win on implementation speed, but it will be
a PITA for long term maintainence. One thing you will immediately get is
people writing scripts which add all kinda of custom crap to the XML
destroying the benefit of libvirt which is the standardization. For any
given storage backend, we know what operations we need to be able to
perform & so we have a finite set of commands we need to run with known
predictable arguments. We just don't need the 'flexibility' of running
arbitrary shell scripts & XML filters in the backend end.
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