Take a look at this: http://libvirt.org/storage.html#StorageBackendISCSI
"Volumes must be pre-allocated on the iSCSI server, and cannot be created via the libvirt APIs.", which I believe your plugin will take care of. Libvirt just does the work of logging in and hooking it up to the VM (I believe the Xen api does that work in the Xen stuff). What I'm not sure about is whether this provides a 1:1 mapping, or if it just allows you to register 1 iscsi device as a pool. You may need to write some test code or read up a bit more about this. Let us know. If it doesn't, you may just have to write your own storage adaptor rather than changing LibvirtStorageAdaptor.java. We can cross that bridge when we get there. As far as interfacing with libvirt, see the java bindings doc. http://libvirt.org/sources/java/javadoc/ Normally, you'll see a connection object be made, then calls made to that 'conn' object. You can look at the LibvirtStorageAdaptor to see how that is done for other pool types, and maybe write some test java code to see if you can interface with libvirt and register iscsi storage pools before you get started. On Fri, Sep 13, 2013 at 5:31 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > So, Marcus, I need to investigate libvirt more, but you figure it supports > connecting to/disconnecting from iSCSI targets, right? > > > On Fri, Sep 13, 2013 at 5:29 PM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: >> >> OK, thanks, Marcus >> >> I am currently looking through some of the classes you pointed out last >> week or so. >> >> >> On Fri, Sep 13, 2013 at 5:26 PM, Marcus Sorensen <shadow...@gmail.com> >> wrote: >>> >>> Yes, my guess is that you will need the iscsi initiator utilities >>> installed. There should be standard packages for any distro. Then you'd call >>> an agent storage adaptor to do the initiator login. See the info I sent >>> previously about LibvirtStorageAdaptor.java and libvirt iscsi storage type >>> to see if that fits your need. >>> >>> On Sep 13, 2013 4:55 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> As you may remember, during the 4.2 release I developed a SolidFire >>>> (storage) plug-in for CloudStack. >>>> >>>> This plug-in was invoked by the storage framework at the necessary times >>>> so that I could dynamically create and delete volumes on the SolidFire SAN >>>> (among other activities). >>>> >>>> This is necessary so I can establish a 1:1 mapping between a CloudStack >>>> volume and a SolidFire volume for QoS. >>>> >>>> In the past, CloudStack always expected the admin to create large >>>> volumes ahead of time and those volumes would likely house many root and >>>> data disks (which is not QoS friendly). >>>> >>>> To make this 1:1 mapping scheme work, I needed to modify logic in the >>>> XenServer and VMware plug-ins so they could create/delete storage >>>> repositories/datastores as needed. >>>> >>>> For 4.3 I want to make this happen with KVM. >>>> >>>> I'm coming up to speed with how this might work on KVM, but I'm still >>>> pretty new to KVM. >>>> >>>> Does anyone familiar with KVM know how I will need to interact with the >>>> iSCSI target? For example, will I have to expect Open iSCSI will be >>>> installed on the KVM host and use it for this to work? >>>> >>>> Thanks for any suggestions, >>>> Mike >>>> >>>> -- >>>> Mike Tutkowski >>>> Senior CloudStack Developer, SolidFire Inc. >>>> e: mike.tutkow...@solidfire.com >>>> o: 303.746.7302 >>>> Advancing the way the world uses the cloud™ >> >> >> >> >> -- >> Mike Tutkowski >> Senior CloudStack Developer, SolidFire Inc. >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud™ > > > > > -- > Mike Tutkowski > Senior CloudStack Developer, SolidFire Inc. > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud™
