> Hi, > I'm trying to write a Remote Storage driver for XenAPI. > I see that target-path is used for both storage pools and volumes. > In the case of XenAPI remote storage, the storage is not mounted on the > local host where libvirt is running. Storage is maintained in a remote location only. > In this case how do I specify target-path and how do I go about creating > a VM with storage using libvirt APIs with virsh and virt-manager. > Virt-manager expects me to give an absolute path for target-path. But In my case > I don't have an absolute path. > Can I have a target path like this for a particular storage volume > "/storage pool uuid/storage-vol uuid"? This will help me identify which storage pool is > Libvirt talking about and which volume in it. Using this information I can fetch data from > The remote location and give it back to libvirt. Is this approach > ok or does libvirt support my specific remote storage case in some way. Could someone > clarify please? >It may help to understand the usage scenario. > - App creates a storage pool with a target '/foo' In the case of XenAPI there will be no target, it can be '/' for now as you said. The <source> tag will have the host name and path. > - App creates a storage volume called 'bar' The volume target path will be /sr-uuid/vol-uuid > - Storage pool driver creates a path for volume based on pool target and > volume name. eg it might decide /foo/bar driver creates the path /sr-uuid/vol-uuid > - App queries path of new volume and gets '/foo/bar' virStorageVolGetPath() will return same as above for any volume > - App creates a new disk, passing '/foo/bar' in the <disk> element in > the guest XML source in the disk element will have the same path. Here using sr-uuid the driver would locate the actual location of the SR and the specified volume in it using vol-uuid and attach it to the new VM being created. >The real key thing here is that 'virStorageVolGetPath' *must* return a path >suitable for use in the guest XML <disk> element <source file=/foo/bar> >To answer your question then, we ned to know what the path looks like that >you use to configure the guest disk when starting the guest ? Once you >know that, then the storage driver must be implemented such that >virStorageVolGetPath() returns a path that matches what XenAPI wants for >the guest config. This will be the UUID path as usual. As I said earlier XenAPI will get the Actual location from the UUIDs and attach with the new guest VM. >As for pool target, if nothing else you can simply require that the pool >is configured with a target path of '/' at which point it is essentially >ignorable, since all paths start with a '/' anyway. There is no pool target so I'll just leave it with '/' for now. |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- 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