Please see comments inline.

> Date: Thu, 12 Jul 2012 10:34:32 +0100
> From: berrange@redhat.com
> To: ata.husain@hotmail.com
> CC: libvirt-list@redhat.com
> Subject: Re: [libvirt] Libvirt iSCSI APIs
>
> On Wed, Jul 11, 2012 at 05:28:07PM -0700, Ata Bohra wrote:
> >
> >
> >
> >
> > Hi All,
> >
> > I am interested in extending libvirt APIs to support iSCSI operations such as: add/remove targets, list targets, list remote LUNs, rescan luns etc. The intention is to provide an interface that external programs can hook to manage iSCSI storage devices on a given hypervisor(I would be adding interfaces for ESX first). Looking at the libvirt.c interface for storage driver I'm unable find routines that can be overridden for specific hypervisor. Googling lead to a nice blog presentation that provisions VMs on remote LUN(s) for KVM but uses virish. (http://berrange.com/tags/iscsi/).
> >
> > My question is; is this as per design not to expose iSCSI related APIs? Will an extention to libvirt.c (_virStorageDriver) so that every hypervisor can implement it is acceptable? Please correct me if I am missing something serious here.
>
> The libvirt model is to *not* expose iSCSI specific APIs. We expose a general
> purpose storage API, which (for KVM, UML, LXC & Xen) already supports ISCSI
> target connections. This existing API can be implemented for VMWare or
> other hypervisors as needed.
>

[AB]: I am sorry for not being specific in my question earlier. Rephrasing the question: Reading libvirt.c it provides driver structures so that client hypervisor driver can provide specific implementation, such as ".domainLookupByID = esxDomainLookupById". But searching for iSCSI related APIs, storage_backend_iscsi driver implements APIs such as "virStorageBackendISCSIRescanLUNs" but they are not part of libvirt.c interface yet. I was curious to know if I provide a driver structure in libvirt.c for these backend iSCSI operations, would that be reasonable? Please pardon my ignorance, but browsing the code I am still trying to find out if there is any other way. Thanks for your explanation.

Thanks !

Ata