[libvirt] Libvirt iSCSI APIs
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. Thanks! Ata
On 2012年07月12日 08:28, 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.
Nice. 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/).
The storage APIs are independant, not associated with domain APIs. AFAIK, the storage management is just common, not tied with specific hypervisor (I may be wrong, perhaps there is specific stuffs I don't known yet). The blog post presents using virsh/virt-manager/virt-install, but if you have the APIs, you can use the APIs (of both domain and storage) to provision the guests with whatever external programs you want. So if I understand you correctly, what you need to do is add the implementations for those APIs in iscsi backend.
My question is; is this as per design not to expose iSCSI related APIs?
No, we'd like to see new useful APIs.
Will an extention to libvirt.c (_virStorageDriver) so that every hypervisor can implement it is acceptable?
Again, either you or me is wrong, my understanding is the storage management is not specific for different hypervisors, and it should keep independant. Regards, Osier
On Thu, Jul 12, 2012 at 11:24:30AM +0800, Osier Yang wrote:
On 2012年07月12日 08:28, 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.
Nice.
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/).
The storage APIs are independant, not associated with domain APIs. AFAIK, the storage management is just common, not tied with specific hypervisor (I may be wrong, perhaps there is specific stuffs I don't known yet).
The blog post presents using virsh/virt-manager/virt-install, but if you have the APIs, you can use the APIs (of both domain and storage) to provision the guests with whatever external programs you want.
So if I understand you correctly, what you need to do is add the implementations for those APIs in iscsi backend.
My question is; is this as per design not to expose iSCSI related APIs?
No, we'd like to see new useful APIs.
Will an extention to libvirt.c (_virStorageDriver) so that every hypervisor can implement it is acceptable?
Again, either you or me is wrong, my understanding is the storage management is not specific for different hypervisors, and it should keep independant.
This isn't quite correct. For any Linux drivers that run in libvirtd, we have the generic storage driver. For drivers that run clientside like VWMare, VirtualBox, Hyper-V, etc, they are responsible for implementing the storage APIs themselves. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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. > Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| Thanks !Ata
participants (3)
-
Ata Bohra -
Daniel P. Berrange -
Osier Yang