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.
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.
OK, so your points are taken on board and I'll have another look at this
tomorrow.
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903