On Thu, Oct 18, 2007 at 06:11:48PM +0100, Richard W.M. Jones wrote:
> This is an outline for the storage API, for discussion only. It is
> mostly unimplemented, but presented as a kind of "literate patch", so
> you can read the API calls and how they could be implemented.
>
> I've tried to follow as far as possible operations which are needed in
> order to make virt-install / virt-manager work in the remote case, and
> also to support discovery and creation of partitions / LVs / iSCSI LUNs.
>
> The new API calls are:
>
> virStorageFileLocations
> - returns a list of locations which can be used
> for creating file-backed guests
>
> virStorageFileStat
> virStorageFileStatVFS
> virStorageCreateFile
> - for creating file-backed guest storage
>
> virStorageListGroups
> virStorageCreateVolume
> - for discovering and creating partitions, LVs, LUNs, &c.
I don't really like any of this. We're basically going to end up with two
parallel sets of storage APIs one operating on files the other operating
on blocks. The APIs for creating volumes/files are not extensible since
they're taking a fixed set of parameters. The means of enumerating storage
areas doesn't provide for any extensible metdata.
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.
Both sets of APIs can easily be implemented in terms of the 2 concepts of
a pool (a directory or LVM VG), and a volume (a file, or LVM LV or partition)
As we did with the networking APIs we should try & maintain the style of
existing APIs
virStoragePoolListNames(virConnectPtr, char **names)
virStoragePoolLookupByName(virConnectPtr, char *name)
virStoragePoolLookupByUUID(virConnectPtr, unsigned char *uuid)
/* Config for a pool - eg, a directory path /var/lib/xen/images,
or an NFS server+export, or an iSCSI server + target */
virStoragePoolDefine(virConnectPtr, char *xml)
/* Mount the NFS server, or login to iSCSI target, activate the
LVM volume group */
virStoragePoolStart(virStoragePoolPtr)
/* Unmount the NFS server, or logout of iSCSI, deactive the
LVM volume group */
virStoragePoolDestroy(virStoragePoolPtr)
/* Remove the config from libvirtd */
virStoragePoolUndefine(virStoragePoolPtr)
char *virStoragePoolDumpXML(virStoragePoolPtr);
long long virStoragePoolGetSize(virStoragePoolPtr);
long long virStoragePoolGetFreeSpace(virStoragePoolPtr);
virStorageVolListNames(virStoragePoolPtr, char **names)
virStorageVolPtr virStorageVolLookupByName(virStoragePoolPtr, char *name)
virStorageVolPtr virStorageVolLookupByUUID(virStoragePoolPtr, unsigned char *uuid)
/* Search storage vols to find a vlume based on a path - eg to
translate a guest disk into a storage volume */
virStorageVolPtr virStorageVolLookupByPath(virConnectPtr, char *path)
/* Allocate a new volume in a pool, eg create a file,
add an LVM logical volume, add a disk partition */
virStorageVolPtr virStorageVolCreate(virStoragePoolPtr, const char *xml)
virStorageVolDestroy(virStorageVolPtr);
char *virStorageVolDumpXML(virStorageVolPtr)
/* The local path suitable for defining a disk in a guest */
char *virStoragePoolGetPath(virStorageVolPtr)
long long virStorageVolGetSize(virStorageVolPtr);
Even if we only implement this for LVM & local directories to start with,
the API is capable of representing the other various types of storage
outlined previously.
Regards,
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