On 02/20/14 15:37, Daniel P. Berrange wrote: > On Thu, Feb 20, 2014 at 02:46:03PM +0100, Peter Krempa wrote: >> As you can see in the prototypes of these functions (and from the docs >> for them which I'm not going to copy here) the user can provide the disk >> specification in two possible options: >> >> 1) a full path if it's unambiguous - this is file centric and requires >> the file to be in the local filesystem >> >> 2) a disk name "vda" - this is selected automatically by libvirt but >> allows to specify only the top image. >> >> For systems that want to use remote storage without local representation >> such as gluster+libgfapi, this doesn't allow to use the APIs to start >> block jobs. >> >> To solve this issue we need a way to specify paths on remote storage in >> some way. Below are two options we've discussed on IRC. >> >> 1) Use URIs along with the file path to specify disk images. >> >> This option would add a new, possibly well documented URIs to specify >> paths for disk images. These would be libvirt defined URIs (but >> surprisingly "similar" to qemu URIS) so that hypervisors with different >> storage specification would need a conversion. >> >> This would allow to specify the targets as: >> vda - disk name >> /path/to/file - legacy way, path >> file:///path/to/file - new way of file paths >> block:///dev/blah - new way, block devs >> gluster://server/vol/img - new way, remote images >> ... >> >> Possible caveats: RBD for example allows to use multiple hosts and we'd >> need to introduce a possibility to specify it if we'd add support for >> this on rbd. > > Superficially this is appealing, however, what I dislike about it > is that it has no correspondance to the way you specify the targets > in the XML file. So apps would need to know two different formats > for dealing with network disks. The RBD multiple hosts issues is > another concern. > >> 2) Export the image chain in the XML and allow to use indexed disk names >> This option would require to export the backing chain in the XML in some >> way, either the existing disk source specification in multiple elements >> (which I don't like as it is a bit convoluted), or possibly again via URIs. >> >> Then the user would be allowed to specify vda[2] for the second backing >> image of the vda disk. >> >> With this the internal representations of the backing chain would be >> used without the need for the user to specify path. > > To me this is more appealing because of its simplicity. I think I would > rather like us to expose the backing store info explicitly in the XML > if we go this route, so that the index values are explicitly visible to > apps using the XML. > Ok, for the block chain operations this seems to be the most viable idea here. One further thing we should discuss is the block copy job, where we need to specify a new path that is not part of the backing chain of the disk where the disk gets copied (and efectively becomes the new single element of the backing chain). The for this operation has a very similar interface which we need to figure out too sooner or later. Peter
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list