cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: Managed storage with KVM
Date Fri, 20 Sep 2013 22:26:58 GMT
You may not be able to connect from VM to host on the interface you
have defined. I'm not sure if you've set up your mgmt net as the
host-only or the NAT. Try to telnet from the KVM to your mac's ip for
that network on port 8250.

 All else fails, just build the .deb and install the mgmt server
inside the VM, that's the only way I do KVM development, as I build
the packages anyhow to get the agent installed.

On Fri, Sep 20, 2013 at 4:22 PM, Mike Tutkowski
<mike.tutkowski@solidfire.com> wrote:
> Got most of my KVM code written to support managed storage (I believe).
>
> I'm in the process of testing it, but having a hard time adding a KVM host
> to my MG.
>
> I took a look at agent.log and it repeats the following line many times:
>
> 2013-09-20 14:00:17,264 INFO  [utils.nio.NioClient] (Agent-Selector:null)
> Connecting to 192.168.233.1:8250
> 2013-09-20 14:00:17,265 WARN  [utils.nio.NioConnection]
> (Agent-Selector:null) Unable to connect to remote: is there a server
> running on port 8250
>
> When I go over to the host running my management server (on
> 192.168.233.10), it appears it's listening on port 8250 (the CS MS is
> running on Mac OS X 10.8.3):
>
> mtutkowski-LT:~ mtutkowski$ sudo lsof -i -P | grep 8250
> java      35404     mtutkowski  303u  IPv6 0x91ca095ebc7bd3eb      0t0
>  TCP *:8250 (LISTEN)
>
> The KVM host is on Ubuntu 12.04.1. I don't think any firewalls are in play.
>
> Any thoughts on this?
>
> Thanks!
>
>
> On Wed, Sep 18, 2013 at 1:51 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> Actually, I may have put that code in a place that is never called
>> nowadays.
>>
>> Do you know why we have AttachVolumeCommand in LibvirtComputingResource
>> and AttachCommand DetachCommand in KVMStorageProcessor?
>>
>> They seem like they do the same thing.
>>
>> If I recall, this change went in with 4.2 and it's the same story for
>> XenServer and VMware.
>>
>> Maybe this location (in KVMStorageProcessor) makes more sense:
>>
>>     @Override
>>
>>     public Answer attachVolume(AttachCommand cmd) {
>>
>>         DiskTO disk = cmd.getDisk();
>>
>>         VolumeObjectTO vol = (VolumeObjectTO) disk.getData();
>>
>>         PrimaryDataStoreTO primaryStore = (PrimaryDataStoreTO)
>> vol.getDataStore();
>>
>>         String vmName = cmd.getVmName();
>>
>>         try {
>>
>>             Connect conn = LibvirtConnection.getConnectionByVmName(vmName);
>>
>> *            if (cmd.isManaged()) {*
>>
>> *                storagePoolMgr.createStoragePool(cmd.get_iScsiName(),
>> cmd.getStorageHost(), cmd.getStoragePort(),*
>>
>> *                        vol.getPath(), null, primaryStore.getPoolType());
>> *
>>
>> *            }*
>>
>>             KVMStoragePool primary = storagePoolMgr.getStoragePool(primaryStore.getPoolType(),
>> primaryStore.getUuid());
>>
>>             KVMPhysicalDisk phyDisk =
>> primary.getPhysicalDisk(vol.getPath());
>>
>>             attachOrDetachDisk(conn, true, vmName, phyDisk,
>> disk.getDiskSeq().intValue());
>>
>>             return new AttachAnswer(disk);
>>
>>         } catch (LibvirtException e) {
>>
>>             s_logger.debug("Failed to attach volume: " + vol.getPath() + ",
>> due to " + e.toString());
>>
>>             return new AttachAnswer(e.toString());
>>
>>         } catch (InternalErrorException e) {
>>
>>             s_logger.debug("Failed to attach volume: " + vol.getPath() + ",
>> due to " + e.toString());
>>
>>             return new AttachAnswer(e.toString());
>>
>>         }
>>
>>     }
>>
>>
>>     @Override
>>
>>     public Answer dettachVolume(DettachCommand cmd) {
>>
>>         DiskTO disk = cmd.getDisk();
>>
>>         VolumeObjectTO vol = (VolumeObjectTO) disk.getData();
>>
>>         PrimaryDataStoreTO primaryStore = (PrimaryDataStoreTO)
>> vol.getDataStore();
>>
>>         String vmName = cmd.getVmName();
>>
>>         try {
>>
>>             Connect conn = LibvirtConnection.getConnectionByVmName(vmName);
>>
>>             KVMStoragePool primary = storagePoolMgr.getStoragePool(primaryStore.getPoolType(),
>> primaryStore.getUuid());
>>
>>             KVMPhysicalDisk phyDisk =
>> primary.getPhysicalDisk(vol.getPath());
>>
>>             attachOrDetachDisk(conn, false, vmName, phyDisk,
>> disk.getDiskSeq().intValue());
>>
>> *            if (cmd.isManaged()) {*
>>
>> *                storagePoolMgr.deleteStoragePool(primaryStore.getPoolType(),
>> cmd.get_iScsiName());*
>>
>> *            }*
>>
>>             return new DettachAnswer(disk);
>>
>>         } catch (LibvirtException e) {
>>
>>             s_logger.debug("Failed to attach volume: " + vol.getPath() + ",
>> due to " + e.toString());
>>
>>             return new DettachAnswer(e.toString());
>>
>>         } catch (InternalErrorException e) {
>>
>>             s_logger.debug("Failed to attach volume: " + vol.getPath() + ",
>> due to " + e.toString());
>>
>>             return new DettachAnswer(e.toString());
>>
>>         }
>>
>>     }
>>
>>
>> On Wed, Sep 18, 2013 at 1:07 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> Hey Marcus,
>>>
>>> What do you think about something relatively simple like this (below)? It
>>> parallels the XenServer and VMware code nicely.
>>>
>>> The idea is to only deal with the AttachVolumeCommand.
>>>
>>> If we are attaching a volume AND the underlying storage is so-called
>>> managed storage, at this point I invoke createStoragePool to create my
>>> iScsiAdmStoragePool object, establish a connection with the LUN, and
>>> prepare a KVMPhysicalDisk object, which will be requested a bit later
>>> during the actual attach.
>>>
>>> If we are detaching a volume AND the underlying storage is managed, the
>>> KVMStoragePool already exists, so we don't have to do anything special
>>> until after the volume is detached. At this point, we delete the storage
>>> pool (remove the iSCSI connection to the LUN and remove the reference to
>>> the iScsiAdmStoragePool from my adaptor).
>>>
>>>     private AttachVolumeAnswer execute(AttachVolumeCommand cmd) {
>>>
>>>         try {
>>>
>>>             Connect conn =
>>> LibvirtConnection.getConnectionByVmName(cmd.getVmName());
>>>
>>> *            if (cmd.getAttach() && cmd.isManaged()) {*
>>>
>>> *                _storagePoolMgr.createStoragePool(cmd.get_iScsiName(),
>>> cmd.getStorageHost(), cmd.getStoragePort(),*
>>>
>>> *                        cmd.getVolumePath(), null, cmd.getPooltype());*
>>>
>>> *            }*
>>>
>>>             KVMStoragePool primary = _storagePoolMgr.getStoragePool(
>>>
>>>                     cmd.getPooltype(),
>>>
>>>                     cmd.getPoolUuid());
>>>
>>>             KVMPhysicalDisk disk =
>>> primary.getPhysicalDisk(cmd.getVolumePath());
>>>
>>>             attachOrDetachDisk(conn, cmd.getAttach(), cmd.getVmName(),
>>> disk,
>>>
>>>                     cmd.getDeviceId().intValue(), cmd.getBytesReadRate(),
>>> cmd.getBytesWriteRate(), cmd.getIopsReadRate(), cmd.getIopsWriteRate());
>>>
>>> *            if (!cmd.getAttach() && cmd.isManaged()) {*
>>>
>>> *                _storagePoolMgr.deleteStoragePool(cmd.getPooltype(),
>>> cmd.get_iScsiName());*
>>>
>>> *            }*
>>>
>>>         } catch (LibvirtException e) {
>>>
>>>             return new AttachVolumeAnswer(cmd, e.toString());
>>>
>>>         } catch (InternalErrorException e) {
>>>
>>>             return new AttachVolumeAnswer(cmd, e.toString());
>>>
>>>         }
>>>
>>>
>>>         return new AttachVolumeAnswer(cmd, cmd.getDeviceId(),
>>> cmd.getVolumePath());
>>>
>>>     }
>>>
>>>
>>> On Wed, Sep 18, 2013 at 11:27 AM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>>
>>>> Since a KVMStoragePool returns a capacity, used, and available number of
>>>> bytes, I will probably need to look into having this information ignored if
>>>> the storage_pool in question is "managed" as - in my case - it wouldn't
>>>> really make any sense.
>>>>
>>>>
>>>> On Wed, Sep 18, 2013 at 10:53 AM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>>
>>>>> Sure, sounds good.
>>>>>
>>>>> Right now there are only two storage plug-ins: Edison's default plug-in
>>>>> and the SolidFire plug-in.
>>>>>
>>>>> As an example, when createAsync is called in the plug-in, mine creates
>>>>> a new volume (LUN) on the SAN with a capacity and number of Min, Max, and
>>>>> Burst IOPS. Edison's sends a command to the hypervisor to take a chunk out
>>>>> of preallocated storage for a new volume (like create a new VDI in an
>>>>> existing SR).
>>>>>
>>>>>
>>>>> On Wed, Sep 18, 2013 at 10:49 AM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>>>>>
>>>>>> That wasn't my question, but I feel we're getting off in the weeds and
>>>>>> I can just look at the storage framework to see how it works and what
>>>>>> options it supports.
>>>>>>
>>>>>> On Wed, Sep 18, 2013 at 10:44 AM, Mike Tutkowski
>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>> > At the time being, I am not aware of any other storage vendor with
>>>>>> truly
>>>>>> > guaranteed QoS.
>>>>>> >
>>>>>> > Most implement QoS in a relative sense (like thread priorities).
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Sep 18, 2013 at 7:57 AM, Marcus Sorensen <
>>>>>> shadowsor@gmail.com>wrote:
>>>>>> >
>>>>>> >> Yeah, that's why I thought it was specific to your implementation.
>>>>>> Perhaps
>>>>>> >> that's true, then?
>>>>>> >> On Sep 18, 2013 12:04 AM, "Mike Tutkowski" <
>>>>>> mike.tutkowski@solidfire.com>
>>>>>> >> wrote:
>>>>>> >>
>>>>>> >> > I totally get where you're coming from with the tiered-pool
>>>>>> approach,
>>>>>> >> > though.
>>>>>> >> >
>>>>>> >> > Prior to SolidFire, I worked at HP and the product I worked on
>>>>>> allowed a
>>>>>> >> > single, clustered SAN to host multiple pools of storage. One pool
>>>>>> might
>>>>>> >> be
>>>>>> >> > made up of all-SSD storage nodes while another pool might be made
>>>>>> up of
>>>>>> >> > slower HDDs.
>>>>>> >> >
>>>>>> >> > That kind of tiering is not what SolidFire QoS is about, though,
>>>>>> as that
>>>>>> >> > kind of tiering does not guarantee QoS.
>>>>>> >> >
>>>>>> >> > In the SolidFire SAN, QoS was designed in from the beginning and
>>>>>> is
>>>>>> >> > extremely granular. Each volume has its own performance and
>>>>>> capacity. You
>>>>>> >> > do not have to worry about Noisy Neighbors.
>>>>>> >> >
>>>>>> >> > The idea is to encourage businesses to trust the cloud with their
>>>>>> most
>>>>>> >> > critical business applications at a price point on par with
>>>>>> traditional
>>>>>> >> > SANs.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Tue, Sep 17, 2013 at 11:52 PM, Mike Tutkowski <
>>>>>> >> > mike.tutkowski@solidfire.com> wrote:
>>>>>> >> >
>>>>>> >> > > Ah, I think I see the miscommunication.
>>>>>> >> > >
>>>>>> >> > > I should have gone into a bit more detail about the SolidFire
>>>>>> SAN.
>>>>>> >> > >
>>>>>> >> > > It is built from the ground up to support QoS on a LUN-by-LUN
>>>>>> basis.
>>>>>> >> > Every
>>>>>> >> > > LUN is assigned a Min, Max, and Burst number of IOPS.
>>>>>> >> > >
>>>>>> >> > > The Min IOPS are a guaranteed number (as long as the SAN itself
>>>>>> is not
>>>>>> >> > > over provisioned). Capacity and IOPS are provisioned
>>>>>> independently.
>>>>>> >> > > Multiple volumes and multiple tenants using the same SAN do not
>>>>>> suffer
>>>>>> >> > from
>>>>>> >> > > the Noisy Neighbor effect.
>>>>>> >> > >
>>>>>> >> > > When you create a Disk Offering in CS that is storage tagged to
>>>>>> use
>>>>>> >> > > SolidFire primary storage, you specify a Min, Max, and Burst
>>>>>> number of
>>>>>> >> > IOPS
>>>>>> >> > > to provision from the SAN for volumes created from that Disk
>>>>>> Offering.
>>>>>> >> > >
>>>>>> >> > > There is no notion of RAID groups that you see in more
>>>>>> traditional
>>>>>> >> SANs.
>>>>>> >> > > The SAN is built from clusters of storage nodes and data is
>>>>>> replicated
>>>>>> >> > > amongst all SSDs in all storage nodes (this is an SSD-only SAN)
>>>>>> in the
>>>>>> >> > > cluster to avoid hot spots and protect the data should a drives
>>>>>> and/or
>>>>>> >> > > nodes fail. You then scale the SAN by adding new storage nodes.
>>>>>> >> > >
>>>>>> >> > > Data is compressed and de-duplicated inline across the cluster
>>>>>> and all
>>>>>> >> > > volumes are thinly provisioned.
>>>>>> >> > >
>>>>>> >> > >
>>>>>> >> > > On Tue, Sep 17, 2013 at 11:27 PM, Marcus Sorensen <
>>>>>> shadowsor@gmail.com
>>>>>> >> > >wrote:
>>>>>> >> > >
>>>>>> >> > >> I'm surprised there's no mention of pool on the SAN in your
>>>>>> >> description
>>>>>> >> > of
>>>>>> >> > >> the framework. I had assumed this was specific to your
>>>>>> implementation,
>>>>>> >> > >> because normally SANs host multiple disk pools, maybe multiple
>>>>>> RAID
>>>>>> >> 50s
>>>>>> >> > >> and
>>>>>> >> > >> 10s, or however the SAN admin wants to split it up. Maybe a
>>>>>> pool
>>>>>> >> > intended
>>>>>> >> > >> for root disks and a separate one for data disks. Or one pool
>>>>>> for
>>>>>> >> > >> cloudstack and one dedicated to some other internal db
>>>>>> application.
>>>>>> >> But
>>>>>> >> > it
>>>>>> >> > >> sounds as though there's no place to specify which disks or
>>>>>> pool on
>>>>>> >> the
>>>>>> >> > >> SAN
>>>>>> >> > >> to use.
>>>>>> >> > >>
>>>>>> >> > >> We implemented our own internal storage SAN plugin based on
>>>>>> 4.1. We
>>>>>> >> used
>>>>>> >> > >> the 'path' attribute of the primary storage pool object to
>>>>>> specify
>>>>>> >> which
>>>>>> >> > >> pool name on the back end SAN to use, so we could create
>>>>>> all-ssd pools
>>>>>> >> > and
>>>>>> >> > >> slower spindle pools, then differentiate between them based on
>>>>>> storage
>>>>>> >> > >> tags. Normally the path attribute would be the mount point for
>>>>>> NFS,
>>>>>> >> but
>>>>>> >> > >> its
>>>>>> >> > >> just a string. So when registering ours we enter San dns host
>>>>>> name,
>>>>>> >> the
>>>>>> >> > >> san's rest api port, and the pool name. Then luns created from
>>>>>> that
>>>>>> >> > >> primary
>>>>>> >> > >> storage come from the matching disk pool on the SAN. We can
>>>>>> create and
>>>>>> >> > >> register multiple pools of different types and purposes on the
>>>>>> same
>>>>>> >> SAN.
>>>>>> >> > >> We
>>>>>> >> > >> haven't yet gotten to porting it to the 4.2 frame work, so it
>>>>>> will be
>>>>>> >> > >> interesting to see what we can come up with to make it work
>>>>>> similarly.
>>>>>> >> > >>  On Sep 17, 2013 10:43 PM, "Mike Tutkowski" <
>>>>>> >> > mike.tutkowski@solidfire.com
>>>>>> >> > >> >
>>>>>> >> > >> wrote:
>>>>>> >> > >>
>>>>>> >> > >> > What you're saying here is definitely something we should
>>>>>> talk
>>>>>> >> about.
>>>>>> >> > >> >
>>>>>> >> > >> > Hopefully my previous e-mail has clarified how this works a
>>>>>> bit.
>>>>>> >> > >> >
>>>>>> >> > >> > It mainly comes down to this:
>>>>>> >> > >> >
>>>>>> >> > >> > For the first time in CS history, primary storage is no
>>>>>> longer
>>>>>> >> > required
>>>>>> >> > >> to
>>>>>> >> > >> > be preallocated by the admin and then handed to CS. CS
>>>>>> volumes don't
>>>>>> >> > >> have
>>>>>> >> > >> > to share a preallocated volume anymore.
>>>>>> >> > >> >
>>>>>> >> > >> > As of 4.2, primary storage can be based on a SAN (or some
>>>>>> other
>>>>>> >> > storage
>>>>>> >> > >> > device). You can tell CS how many bytes and IOPS to use from
>>>>>> this
>>>>>> >> > >> storage
>>>>>> >> > >> > device and CS invokes the appropriate plug-in to carve out
>>>>>> LUNs
>>>>>> >> > >> > dynamically.
>>>>>> >> > >> >
>>>>>> >> > >> > Each LUN is home to one and only one data disk. Data disks -
>>>>>> in this
>>>>>> >> > >> model
>>>>>> >> > >> > - never share a LUN.
>>>>>> >> > >> >
>>>>>> >> > >> > The main use case for this is so a CS volume can deliver
>>>>>> guaranteed
>>>>>> >> > >> IOPS if
>>>>>> >> > >> > the storage device (ex. SolidFire SAN) delivers guaranteed
>>>>>> IOPS on a
>>>>>> >> > >> > LUN-by-LUN basis.
>>>>>> >> > >> >
>>>>>> >> > >> >
>>>>>> >> > >> > On Tue, Sep 17, 2013 at 10:16 PM, Marcus Sorensen <
>>>>>> >> > shadowsor@gmail.com
>>>>>> >> > >> > >wrote:
>>>>>> >> > >> >
>>>>>> >> > >> > > I guess whether or not a solidfire device is capable of
>>>>>> hosting
>>>>>> >> > >> > > multiple disk pools is irrelevant, we'd hope that we could
>>>>>> get the
>>>>>> >> > >> > > stats (maybe 30TB availabie, and 15TB allocated in LUNs).
>>>>>> But if
>>>>>> >> > these
>>>>>> >> > >> > > stats aren't collected, I can't as an admin define
>>>>>> multiple pools
>>>>>> >> > and
>>>>>> >> > >> > > expect cloudstack to allocate evenly from them or fill one
>>>>>> up and
>>>>>> >> > move
>>>>>> >> > >> > > to the next, because it doesn't know how big it is.
>>>>>> >> > >> > >
>>>>>> >> > >> > > Ultimately this discussion has nothing to do with the KVM
>>>>>> stuff
>>>>>> >> > >> > > itself, just a tangent, but something to think about.
>>>>>> >> > >> > >
>>>>>> >> > >> > > On Tue, Sep 17, 2013 at 10:13 PM, Marcus Sorensen <
>>>>>> >> > >> shadowsor@gmail.com>
>>>>>> >> > >> > > wrote:
>>>>>> >> > >> > > > Ok, on most storage pools it shows how many GB free/used
>>>>>> when
>>>>>> >> > >> listing
>>>>>> >> > >> > > > the pool both via API and in the UI. I'm guessing those
>>>>>> are
>>>>>> >> empty
>>>>>> >> > >> then
>>>>>> >> > >> > > > for the solid fire storage, but it seems like the user
>>>>>> should
>>>>>> >> have
>>>>>> >> > >> to
>>>>>> >> > >> > > > define some sort of pool that the luns get carved out
>>>>>> of, and
>>>>>> >> you
>>>>>> >> > >> > > > should be able to get the stats for that, right? Or is a
>>>>>> solid
>>>>>> >> > fire
>>>>>> >> > >> > > > appliance only one pool per appliance? This isn't about
>>>>>> billing,
>>>>>> >> > but
>>>>>> >> > >> > > > just so cloudstack itself knows whether or not there is
>>>>>> space
>>>>>> >> left
>>>>>> >> > >> on
>>>>>> >> > >> > > > the storage device, so cloudstack can go on allocating
>>>>>> from a
>>>>>> >> > >> > > > different primary storage as this one fills up. There
>>>>>> are also
>>>>>> >> > >> > > > notifications and things. It seems like there should be
>>>>>> a call
>>>>>> >> you
>>>>>> >> > >> can
>>>>>> >> > >> > > > handle for this, maybe Edison knows.
>>>>>> >> > >> > > >
>>>>>> >> > >> > > > On Tue, Sep 17, 2013 at 8:46 PM, Marcus Sorensen <
>>>>>> >> > >> shadowsor@gmail.com>
>>>>>> >> > >> > > wrote:
>>>>>> >> > >> > > >> You respond to more than attach and detach, right?
>>>>>> Don't you
>>>>>> >> > create
>>>>>> >> > >> > > luns as
>>>>>> >> > >> > > >> well? Or are you just referring to the hypervisor stuff?
>>>>>> >> > >> > > >>
>>>>>> >> > >> > > >> On Sep 17, 2013 7:51 PM, "Mike Tutkowski" <
>>>>>> >> > >> > mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >
>>>>>> >> > >> > > >> wrote:
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> Hi Marcus,
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> I never need to respond to a CreateStoragePool call
>>>>>> for either
>>>>>> >> > >> > > XenServer
>>>>>> >> > >> > > >>> or
>>>>>> >> > >> > > >>> VMware.
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> What happens is I respond only to the Attach- and
>>>>>> >> Detach-volume
>>>>>> >> > >> > > commands.
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> Let's say an attach comes in:
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> In this case, I check to see if the storage is
>>>>>> "managed."
>>>>>> >> > Talking
>>>>>> >> > >> > > >>> XenServer
>>>>>> >> > >> > > >>> here, if it is, I log in to the LUN that is the disk
>>>>>> we want
>>>>>> >> to
>>>>>> >> > >> > attach.
>>>>>> >> > >> > > >>> After, if this is the first time attaching this disk,
>>>>>> I create
>>>>>> >> > an
>>>>>> >> > >> SR
>>>>>> >> > >> > > and a
>>>>>> >> > >> > > >>> VDI within the SR. If it is not the first time
>>>>>> attaching this
>>>>>> >> > >> disk,
>>>>>> >> > >> > the
>>>>>> >> > >> > > >>> LUN
>>>>>> >> > >> > > >>> already has the SR and VDI on it.
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> Once this is done, I let the normal "attach" logic run
>>>>>> because
>>>>>> >> > >> this
>>>>>> >> > >> > > logic
>>>>>> >> > >> > > >>> expected an SR and a VDI and now it has it.
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> It's the same thing for VMware: Just substitute
>>>>>> datastore for
>>>>>> >> SR
>>>>>> >> > >> and
>>>>>> >> > >> > > VMDK
>>>>>> >> > >> > > >>> for VDI.
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> Does that make sense?
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> Thanks!
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> On Tue, Sep 17, 2013 at 7:34 PM, Marcus Sorensen
>>>>>> >> > >> > > >>> <shadowsor@gmail.com>wrote:
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> > What do you do with Xen? I imagine the user enter
>>>>>> the SAN
>>>>>> >> > >> details
>>>>>> >> > >> > > when
>>>>>> >> > >> > > >>> > registering the pool? A the pool details are
>>>>>> basically just
>>>>>> >> > >> > > instructions
>>>>>> >> > >> > > >>> > on
>>>>>> >> > >> > > >>> > how to log into a target, correct?
>>>>>> >> > >> > > >>> >
>>>>>> >> > >> > > >>> > You can choose to log in a KVM host to the target
>>>>>> during
>>>>>> >> > >> > > >>> > createStoragePool
>>>>>> >> > >> > > >>> > and save the pool in a map, or just save the pool
>>>>>> info in a
>>>>>> >> > map
>>>>>> >> > >> for
>>>>>> >> > >> > > >>> > future
>>>>>> >> > >> > > >>> > reference by uuid, for when you do need to log in.
>>>>>> The
>>>>>> >> > >> > > createStoragePool
>>>>>> >> > >> > > >>> > then just becomes a way to save the pool info to the
>>>>>> agent.
>>>>>> >> > >> > > Personally,
>>>>>> >> > >> > > >>> > I'd
>>>>>> >> > >> > > >>> > log in on the pool create and look/scan for specific
>>>>>> luns
>>>>>> >> when
>>>>>> >> > >> > > they're
>>>>>> >> > >> > > >>> > needed, but I haven't thought it through thoroughly.
>>>>>> I just
>>>>>> >> > say
>>>>>> >> > >> > that
>>>>>> >> > >> > > >>> > mainly
>>>>>> >> > >> > > >>> > because login only happens once, the first time the
>>>>>> pool is
>>>>>> >> > >> used,
>>>>>> >> > >> > and
>>>>>> >> > >> > > >>> > every
>>>>>> >> > >> > > >>> > other storage command is about discovering new luns
>>>>>> or maybe
>>>>>> >> > >> > > >>> > deleting/disconnecting luns no longer needed. On the
>>>>>> other
>>>>>> >> > hand,
>>>>>> >> > >> > you
>>>>>> >> > >> > > >>> > could
>>>>>> >> > >> > > >>> > do all of the above: log in on pool create, then
>>>>>> also check
>>>>>> >> if
>>>>>> >> > >> > you're
>>>>>> >> > >> > > >>> > logged in on other commands and log in if you've lost
>>>>>> >> > >> connection.
>>>>>> >> > >> > > >>> >
>>>>>> >> > >> > > >>> > With Xen, what does your registered pool   show in
>>>>>> the UI
>>>>>> >> for
>>>>>> >> > >> > > avail/used
>>>>>> >> > >> > > >>> > capacity, and how does it get that info? I assume
>>>>>> there is
>>>>>> >> > some
>>>>>> >> > >> > sort
>>>>>> >> > >> > > of
>>>>>> >> > >> > > >>> > disk pool that the luns are carved from, and that
>>>>>> your
>>>>>> >> plugin
>>>>>> >> > is
>>>>>> >> > >> > > called
>>>>>> >> > >> > > >>> > to
>>>>>> >> > >> > > >>> > talk to the SAN and expose to the user how much of
>>>>>> that pool
>>>>>> >> > has
>>>>>> >> > >> > been
>>>>>> >> > >> > > >>> > allocated. Knowing how you already solves these
>>>>>> problems
>>>>>> >> with
>>>>>> >> > >> Xen
>>>>>> >> > >> > > will
>>>>>> >> > >> > > >>> > help
>>>>>> >> > >> > > >>> > figure out what to do with KVM.
>>>>>> >> > >> > > >>> >
>>>>>> >> > >> > > >>> > If this is the case, I think the plugin can continue
>>>>>> to
>>>>>> >> handle
>>>>>> >> > >> it
>>>>>> >> > >> > > rather
>>>>>> >> > >> > > >>> > than getting details from the agent. I'm not sure if
>>>>>> that
>>>>>> >> > means
>>>>>> >> > >> > nulls
>>>>>> >> > >> > > >>> > are
>>>>>> >> > >> > > >>> > OK for these on the agent side or what, I need to
>>>>>> look at
>>>>>> >> the
>>>>>> >> > >> > storage
>>>>>> >> > >> > > >>> > plugin arch more closely.
>>>>>> >> > >> > > >>> > On Sep 17, 2013 7:08 PM, "Mike Tutkowski" <
>>>>>> >> > >> > > mike.tutkowski@solidfire.com>
>>>>>> >> > >> > > >>> > wrote:
>>>>>> >> > >> > > >>> >
>>>>>> >> > >> > > >>> > > Hey Marcus,
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > I'm reviewing your e-mails as I implement the
>>>>>> necessary
>>>>>> >> > >> methods
>>>>>> >> > >> > in
>>>>>> >> > >> > > new
>>>>>> >> > >> > > >>> > > classes.
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > "So, referencing StorageAdaptor.java,
>>>>>> createStoragePool
>>>>>> >> > >> accepts
>>>>>> >> > >> > > all of
>>>>>> >> > >> > > >>> > > the pool data (host, port, name, path) which would
>>>>>> be used
>>>>>> >> > to
>>>>>> >> > >> log
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > > host into the initiator."
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > Can you tell me, in my case, since a storage pool
>>>>>> (primary
>>>>>> >> > >> > > storage) is
>>>>>> >> > >> > > >>> > > actually the SAN, I wouldn't really be logging into
>>>>>> >> anything
>>>>>> >> > >> at
>>>>>> >> > >> > > this
>>>>>> >> > >> > > >>> > point,
>>>>>> >> > >> > > >>> > > correct?
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > Also, what kind of capacity, available, and used
>>>>>> bytes
>>>>>> >> make
>>>>>> >> > >> sense
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > report
>>>>>> >> > >> > > >>> > > for KVMStoragePool (since KVMStoragePool
>>>>>> represents the
>>>>>> >> SAN
>>>>>> >> > >> in my
>>>>>> >> > >> > > case
>>>>>> >> > >> > > >>> > and
>>>>>> >> > >> > > >>> > > not an individual LUN)?
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > Thanks!
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > On Fri, Sep 13, 2013 at 11:42 PM, Marcus Sorensen <
>>>>>> >> > >> > > shadowsor@gmail.com
>>>>>> >> > >> > > >>> > > >wrote:
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > > Ok, KVM will be close to that, of course,
>>>>>> because only
>>>>>> >> the
>>>>>> >> > >> > > >>> > > > hypervisor
>>>>>> >> > >> > > >>> > > > classes differ, the rest is all mgmt server.
>>>>>> Creating a
>>>>>> >> > >> volume
>>>>>> >> > >> > is
>>>>>> >> > >> > > >>> > > > just
>>>>>> >> > >> > > >>> > > > a db entry until it's deployed for the first
>>>>>> time.
>>>>>> >> > >> > > >>> > > > AttachVolumeCommand
>>>>>> >> > >> > > >>> > > > on the agent side (LibvirtStorageAdaptor.java is
>>>>>> >> analogous
>>>>>> >> > >> to
>>>>>> >> > >> > > >>> > > > CitrixResourceBase.java) will do the iscsiadm
>>>>>> commands
>>>>>> >> > (via
>>>>>> >> > >> a
>>>>>> >> > >> > KVM
>>>>>> >> > >> > > >>> > > > StorageAdaptor) to log in the host to the target
>>>>>> and
>>>>>> >> then
>>>>>> >> > >> you
>>>>>> >> > >> > > have a
>>>>>> >> > >> > > >>> > > > block device.  Maybe libvirt will do that for
>>>>>> you, but
>>>>>> >> my
>>>>>> >> > >> quick
>>>>>> >> > >> > > read
>>>>>> >> > >> > > >>> > > > made it sound like the iscsi libvirt pool type is
>>>>>> >> > actually a
>>>>>> >> > >> > > pool,
>>>>>> >> > >> > > >>> > > > not
>>>>>> >> > >> > > >>> > > > a lun or volume, so you'll need to figure out if
>>>>>> that
>>>>>> >> > works
>>>>>> >> > >> or
>>>>>> >> > >> > if
>>>>>> >> > >> > > >>> > > > you'll have to use iscsiadm commands.
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > If you're NOT going to use LibvirtStorageAdaptor
>>>>>> >> (because
>>>>>> >> > >> > Libvirt
>>>>>> >> > >> > > >>> > > > doesn't really manage your pool the way you
>>>>>> want),
>>>>>> >> you're
>>>>>> >> > >> going
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > > > have to create a version of KVMStoragePool class
>>>>>> and a
>>>>>> >> > >> > > >>> > > > StorageAdaptor
>>>>>> >> > >> > > >>> > > > class (see LibvirtStoragePool.java and
>>>>>> >> > >> > > LibvirtStorageAdaptor.java),
>>>>>> >> > >> > > >>> > > > implementing all of the methods, then in
>>>>>> >> > >> KVMStorageManager.java
>>>>>> >> > >> > > >>> > > > there's a "_storageMapper" map. This is used to
>>>>>> select
>>>>>> >> the
>>>>>> >> > >> > > correct
>>>>>> >> > >> > > >>> > > > adaptor, you can see in this file that every
>>>>>> call first
>>>>>> >> > >> pulls
>>>>>> >> > >> > the
>>>>>> >> > >> > > >>> > > > correct adaptor out of this map via
>>>>>> getStorageAdaptor.
>>>>>> >> So
>>>>>> >> > >> you
>>>>>> >> > >> > can
>>>>>> >> > >> > > >>> > > > see
>>>>>> >> > >> > > >>> > > > a comment in this file that says "add other
>>>>>> storage
>>>>>> >> > adaptors
>>>>>> >> > >> > > here",
>>>>>> >> > >> > > >>> > > > where it puts to this map, this is where you'd
>>>>>> register
>>>>>> >> > your
>>>>>> >> > >> > > >>> > > > adaptor.
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > So, referencing StorageAdaptor.java,
>>>>>> createStoragePool
>>>>>> >> > >> accepts
>>>>>> >> > >> > > all
>>>>>> >> > >> > > >>> > > > of
>>>>>> >> > >> > > >>> > > > the pool data (host, port, name, path) which
>>>>>> would be
>>>>>> >> used
>>>>>> >> > >> to
>>>>>> >> > >> > log
>>>>>> >> > >> > > >>> > > > the
>>>>>> >> > >> > > >>> > > > host into the initiator. I *believe* the method
>>>>>> >> > >> getPhysicalDisk
>>>>>> >> > >> > > will
>>>>>> >> > >> > > >>> > > > need to do the work of attaching the lun.
>>>>>> >> > >>  AttachVolumeCommand
>>>>>> >> > >> > > calls
>>>>>> >> > >> > > >>> > > > this and then creates the XML diskdef and
>>>>>> attaches it to
>>>>>> >> > the
>>>>>> >> > >> > VM.
>>>>>> >> > >> > > >>> > > > Now,
>>>>>> >> > >> > > >>> > > > one thing you need to know is that
>>>>>> createStoragePool is
>>>>>> >> > >> called
>>>>>> >> > >> > > >>> > > > often,
>>>>>> >> > >> > > >>> > > > sometimes just to make sure the pool is there.
>>>>>> You may
>>>>>> >> > want
>>>>>> >> > >> to
>>>>>> >> > >> > > >>> > > > create
>>>>>> >> > >> > > >>> > > > a map in your adaptor class and keep track of
>>>>>> pools that
>>>>>> >> > >> have
>>>>>> >> > >> > > been
>>>>>> >> > >> > > >>> > > > created, LibvirtStorageAdaptor doesn't have to
>>>>>> do this
>>>>>> >> > >> because
>>>>>> >> > >> > it
>>>>>> >> > >> > > >>> > > > asks
>>>>>> >> > >> > > >>> > > > libvirt about which storage pools exist. There
>>>>>> are also
>>>>>> >> > >> calls
>>>>>> >> > >> > to
>>>>>> >> > >> > > >>> > > > refresh the pool stats, and all of the other
>>>>>> calls can
>>>>>> >> be
>>>>>> >> > >> seen
>>>>>> >> > >> > in
>>>>>> >> > >> > > >>> > > > the
>>>>>> >> > >> > > >>> > > > StorageAdaptor as well. There's a createPhysical
>>>>>> disk,
>>>>>> >> > >> clone,
>>>>>> >> > >> > > etc,
>>>>>> >> > >> > > >>> > > > but
>>>>>> >> > >> > > >>> > > > it's probably a hold-over from 4.1, as I have
>>>>>> the vague
>>>>>> >> > idea
>>>>>> >> > >> > that
>>>>>> >> > >> > > >>> > > > volumes are created on the mgmt server via the
>>>>>> plugin
>>>>>> >> now,
>>>>>> >> > >> so
>>>>>> >> > >> > > >>> > > > whatever
>>>>>> >> > >> > > >>> > > > doesn't apply can just be stubbed out (or
>>>>>> optionally
>>>>>> >> > >> > > >>> > > > extended/reimplemented here, if you don't mind
>>>>>> the hosts
>>>>>> >> > >> > talking
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > > > the san api).
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > There is a difference between attaching new
>>>>>> volumes and
>>>>>> >> > >> > > launching a
>>>>>> >> > >> > > >>> > > > VM
>>>>>> >> > >> > > >>> > > > with existing volumes.  In the latter case, the
>>>>>> VM
>>>>>> >> > >> definition
>>>>>> >> > >> > > that
>>>>>> >> > >> > > >>> > > > was
>>>>>> >> > >> > > >>> > > > passed to the KVM agent includes the disks,
>>>>>> >> > (StartCommand).
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > I'd be interested in how your pool is defined
>>>>>> for Xen, I
>>>>>> >> > >> > imagine
>>>>>> >> > >> > > it
>>>>>> >> > >> > > >>> > > > would need to be kept the same. Is it just a
>>>>>> definition
>>>>>> >> to
>>>>>> >> > >> the
>>>>>> >> > >> > > SAN
>>>>>> >> > >> > > >>> > > > (ip address or some such, port number) and
>>>>>> perhaps a
>>>>>> >> > volume
>>>>>> >> > >> > pool
>>>>>> >> > >> > > >>> > > > name?
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > > If there is a way for me to update the ACL
>>>>>> list on the
>>>>>> >> > >> SAN to
>>>>>> >> > >> > > have
>>>>>> >> > >> > > >>> > > only a
>>>>>> >> > >> > > >>> > > > > single KVM host have access to the volume,
>>>>>> that would
>>>>>> >> be
>>>>>> >> > >> > ideal.
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > That depends on your SAN API.  I was under the
>>>>>> >> impression
>>>>>> >> > >> that
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > > > storage plugin framework allowed for acls, or
>>>>>> for you to
>>>>>> >> > do
>>>>>> >> > >> > > whatever
>>>>>> >> > >> > > >>> > > > you want for create/attach/delete/snapshot, etc.
>>>>>> You'd
>>>>>> >> > just
>>>>>> >> > >> > call
>>>>>> >> > >> > > >>> > > > your
>>>>>> >> > >> > > >>> > > > SAN API with the host info for the ACLs prior to
>>>>>> when
>>>>>> >> the
>>>>>> >> > >> disk
>>>>>> >> > >> > is
>>>>>> >> > >> > > >>> > > > attached (or the VM is started).  I'd have to
>>>>>> look more
>>>>>> >> at
>>>>>> >> > >> the
>>>>>> >> > >> > > >>> > > > framework to know the details, in 4.1 I would do
>>>>>> this in
>>>>>> >> > >> > > >>> > > > getPhysicalDisk just prior to connecting up the
>>>>>> LUN.
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > > > On Fri, Sep 13, 2013 at 10:27 PM, Mike Tutkowski
>>>>>> >> > >> > > >>> > > > <mike.tutkowski@solidfire.com> wrote:
>>>>>> >> > >> > > >>> > > > > OK, yeah, the ACL part will be interesting.
>>>>>> That is a
>>>>>> >> > bit
>>>>>> >> > >> > > >>> > > > > different
>>>>>> >> > >> > > >>> > > from
>>>>>> >> > >> > > >>> > > > how
>>>>>> >> > >> > > >>> > > > > it works with XenServer and VMware.
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > Just to give you an idea how it works in 4.2
>>>>>> with
>>>>>> >> > >> XenServer:
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > * The user creates a CS volume (this is just
>>>>>> recorded
>>>>>> >> in
>>>>>> >> > >> the
>>>>>> >> > >> > > >>> > > > cloud.volumes
>>>>>> >> > >> > > >>> > > > > table).
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > * The user attaches the volume as a disk to a
>>>>>> VM for
>>>>>> >> the
>>>>>> >> > >> > first
>>>>>> >> > >> > > >>> > > > > time
>>>>>> >> > >> > > >>> > (if
>>>>>> >> > >> > > >>> > > > the
>>>>>> >> > >> > > >>> > > > > storage allocator picks the SolidFire plug-in,
>>>>>> the
>>>>>> >> > storage
>>>>>> >> > >> > > >>> > > > > framework
>>>>>> >> > >> > > >>> > > > invokes
>>>>>> >> > >> > > >>> > > > > a method on the plug-in that creates a volume
>>>>>> on the
>>>>>> >> > >> > SAN...info
>>>>>> >> > >> > > >>> > > > > like
>>>>>> >> > >> > > >>> > > the
>>>>>> >> > >> > > >>> > > > IQN
>>>>>> >> > >> > > >>> > > > > of the SAN volume is recorded in the DB).
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > * CitrixResourceBase's
>>>>>> execute(AttachVolumeCommand) is
>>>>>> >> > >> > > executed.
>>>>>> >> > >> > > >>> > > > > It
>>>>>> >> > >> > > >>> > > > > determines based on a flag passed in that the
>>>>>> storage
>>>>>> >> in
>>>>>> >> > >> > > question
>>>>>> >> > >> > > >>> > > > > is
>>>>>> >> > >> > > >>> > > > > "CloudStack-managed" storage (as opposed to
>>>>>> >> > "traditional"
>>>>>> >> > >> > > >>> > preallocated
>>>>>> >> > >> > > >>> > > > > storage). This tells it to discover the iSCSI
>>>>>> target.
>>>>>> >> > Once
>>>>>> >> > >> > > >>> > > > > discovered
>>>>>> >> > >> > > >>> > > it
>>>>>> >> > >> > > >>> > > > > determines if the iSCSI target already
>>>>>> contains a
>>>>>> >> > storage
>>>>>> >> > >> > > >>> > > > > repository
>>>>>> >> > >> > > >>> > > (it
>>>>>> >> > >> > > >>> > > > > would if this were a re-attach situation). If
>>>>>> it does
>>>>>> >> > >> contain
>>>>>> >> > >> > > an
>>>>>> >> > >> > > >>> > > > > SR
>>>>>> >> > >> > > >>> > > > already,
>>>>>> >> > >> > > >>> > > > > then there should already be one VDI, as well.
>>>>>> If
>>>>>> >> there
>>>>>> >> > >> is no
>>>>>> >> > >> > > SR,
>>>>>> >> > >> > > >>> > > > > an
>>>>>> >> > >> > > >>> > SR
>>>>>> >> > >> > > >>> > > > is
>>>>>> >> > >> > > >>> > > > > created and a single VDI is created within it
>>>>>> (that
>>>>>> >> > takes
>>>>>> >> > >> up
>>>>>> >> > >> > > about
>>>>>> >> > >> > > >>> > > > > as
>>>>>> >> > >> > > >>> > > > much
>>>>>> >> > >> > > >>> > > > > space as was requested for the CloudStack
>>>>>> volume).
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > * The normal attach-volume logic continues (it
>>>>>> depends
>>>>>> >> > on
>>>>>> >> > >> the
>>>>>> >> > >> > > >>> > existence
>>>>>> >> > >> > > >>> > > > of
>>>>>> >> > >> > > >>> > > > > an SR and a VDI).
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > The VMware case is essentially the same
>>>>>> (mainly just
>>>>>> >> > >> > substitute
>>>>>> >> > >> > > >>> > > datastore
>>>>>> >> > >> > > >>> > > > > for SR and VMDK for VDI).
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > In both cases, all hosts in the cluster have
>>>>>> >> discovered
>>>>>> >> > >> the
>>>>>> >> > >> > > iSCSI
>>>>>> >> > >> > > >>> > > target,
>>>>>> >> > >> > > >>> > > > > but only the host that is currently running
>>>>>> the VM
>>>>>> >> that
>>>>>> >> > is
>>>>>> >> > >> > > using
>>>>>> >> > >> > > >>> > > > > the
>>>>>> >> > >> > > >>> > > VDI
>>>>>> >> > >> > > >>> > > > (or
>>>>>> >> > >> > > >>> > > > > VMKD) is actually using the disk.
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > Live Migration should be OK because the
>>>>>> hypervisors
>>>>>> >> > >> > communicate
>>>>>> >> > >> > > >>> > > > > with
>>>>>> >> > >> > > >>> > > > > whatever metadata they have on the SR (or
>>>>>> datastore).
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > I see what you're saying with KVM, though.
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > In that case, the hosts are clustered only in
>>>>>> >> > CloudStack's
>>>>>> >> > >> > > eyes.
>>>>>> >> > >> > > >>> > > > > CS
>>>>>> >> > >> > > >>> > > > controls
>>>>>> >> > >> > > >>> > > > > Live Migration. You don't really need a
>>>>>> clustered
>>>>>> >> > >> filesystem
>>>>>> >> > >> > on
>>>>>> >> > >> > > >>> > > > > the
>>>>>> >> > >> > > >>> > > LUN.
>>>>>> >> > >> > > >>> > > > The
>>>>>> >> > >> > > >>> > > > > LUN could be handed over raw to the VM using
>>>>>> it.
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > If there is a way for me to update the ACL
>>>>>> list on the
>>>>>> >> > >> SAN to
>>>>>> >> > >> > > have
>>>>>> >> > >> > > >>> > > only a
>>>>>> >> > >> > > >>> > > > > single KVM host have access to the volume,
>>>>>> that would
>>>>>> >> be
>>>>>> >> > >> > ideal.
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > Also, I agree I'll need to use iscsiadm to
>>>>>> discover
>>>>>> >> and
>>>>>> >> > >> log
>>>>>> >> > >> > in
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > > > > the
>>>>>> >> > >> > > >>> > > > iSCSI
>>>>>> >> > >> > > >>> > > > > target. I'll also need to take the resultant
>>>>>> new
>>>>>> >> device
>>>>>> >> > >> and
>>>>>> >> > >> > > pass
>>>>>> >> > >> > > >>> > > > > it
>>>>>> >> > >> > > >>> > > into
>>>>>> >> > >> > > >>> > > > the
>>>>>> >> > >> > > >>> > > > > VM.
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > Does this sound reasonable? Please call me out
>>>>>> on
>>>>>> >> > >> anything I
>>>>>> >> > >> > > seem
>>>>>> >> > >> > > >>> > > > incorrect
>>>>>> >> > >> > > >>> > > > > about. :)
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > Thanks for all the thought on this, Marcus!
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > On Fri, Sep 13, 2013 at 8:25 PM, Marcus
>>>>>> Sorensen <
>>>>>> >> > >> > > >>> > shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > > wrote:
>>>>>> >> > >> > > >>> > > > >>
>>>>>> >> > >> > > >>> > > > >> Perfect. You'll have a domain def ( the VM),
>>>>>> a disk
>>>>>> >> > def,
>>>>>> >> > >> and
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > > attach
>>>>>> >> > >> > > >>> > > > >> the disk def to the vm. You may need to do
>>>>>> your own
>>>>>> >> > >> > > >>> > > > >> StorageAdaptor
>>>>>> >> > >> > > >>> > and
>>>>>> >> > >> > > >>> > > > run
>>>>>> >> > >> > > >>> > > > >> iscsiadm commands to accomplish that,
>>>>>> depending on
>>>>>> >> how
>>>>>> >> > >> the
>>>>>> >> > >> > > >>> > > > >> libvirt
>>>>>> >> > >> > > >>> > > iscsi
>>>>>> >> > >> > > >>> > > > >> works. My impression is that a 1:1:1
>>>>>> pool/lun/volume
>>>>>> >> > >> isn't
>>>>>> >> > >> > > how it
>>>>>> >> > >> > > >>> > > works
>>>>>> >> > >> > > >>> > > > on
>>>>>> >> > >> > > >>> > > > >> xen at the momen., nor is it ideal.
>>>>>> >> > >> > > >>> > > > >>
>>>>>> >> > >> > > >>> > > > >> Your plugin will handle acls as far as which
>>>>>> host can
>>>>>> >> > see
>>>>>> >> > >> > > which
>>>>>> >> > >> > > >>> > > > >> luns
>>>>>> >> > >> > > >>> > > as
>>>>>> >> > >> > > >>> > > > >> well, I remember discussing that months ago,
>>>>>> so that
>>>>>> >> a
>>>>>> >> > >> disk
>>>>>> >> > >> > > won't
>>>>>> >> > >> > > >>> > > > >> be
>>>>>> >> > >> > > >>> > > > >> connected until the hypervisor has exclusive
>>>>>> access,
>>>>>> >> so
>>>>>> >> > >> it
>>>>>> >> > >> > > will
>>>>>> >> > >> > > >>> > > > >> be
>>>>>> >> > >> > > >>> > > safe
>>>>>> >> > >> > > >>> > > > and
>>>>>> >> > >> > > >>> > > > >> fence the disk from rogue nodes that
>>>>>> cloudstack loses
>>>>>> >> > >> > > >>> > > > >> connectivity
>>>>>> >> > >> > > >>> > > > with. It
>>>>>> >> > >> > > >>> > > > >> should revoke access to everything but the
>>>>>> target
>>>>>> >> > host...
>>>>>> >> > >> > > Except
>>>>>> >> > >> > > >>> > > > >> for
>>>>>> >> > >> > > >>> > > > during
>>>>>> >> > >> > > >>> > > > >> migration but we can discuss that later,
>>>>>> there's a
>>>>>> >> > >> migration
>>>>>> >> > >> > > prep
>>>>>> >> > >> > > >>> > > > process
>>>>>> >> > >> > > >>> > > > >> where the new host can be added to the acls,
>>>>>> and the
>>>>>> >> > old
>>>>>> >> > >> > host
>>>>>> >> > >> > > can
>>>>>> >> > >> > > >>> > > > >> be
>>>>>> >> > >> > > >>> > > > removed
>>>>>> >> > >> > > >>> > > > >> post migration.
>>>>>> >> > >> > > >>> > > > >>
>>>>>> >> > >> > > >>> > > > >> On Sep 13, 2013 8:16 PM, "Mike Tutkowski" <
>>>>>> >> > >> > > >>> > > mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > >> wrote:
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>> Yeah, that would be ideal.
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>> So, I would still need to discover the iSCSI
>>>>>> target,
>>>>>> >> > >> log in
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > > > >>> it,
>>>>>> >> > >> > > >>> > > then
>>>>>> >> > >> > > >>> > > > >>> figure out what /dev/sdX was created as a
>>>>>> result
>>>>>> >> (and
>>>>>> >> > >> leave
>>>>>> >> > >> > > it
>>>>>> >> > >> > > >>> > > > >>> as
>>>>>> >> > >> > > >>> > is
>>>>>> >> > >> > > >>> > > -
>>>>>> >> > >> > > >>> > > > do
>>>>>> >> > >> > > >>> > > > >>> not format it with any file
>>>>>> system...clustered or
>>>>>> >> > not).
>>>>>> >> > >> I
>>>>>> >> > >> > > would
>>>>>> >> > >> > > >>> > pass
>>>>>> >> > >> > > >>> > > > that
>>>>>> >> > >> > > >>> > > > >>> device into the VM.
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>> Kind of accurate?
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>> On Fri, Sep 13, 2013 at 8:07 PM, Marcus
>>>>>> Sorensen <
>>>>>> >> > >> > > >>> > > shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > >>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>
>>>>>> >> > >> > > >>> > > > >>>> Look in LibvirtVMDef.java (I think) for the
>>>>>> disk
>>>>>> >> > >> > > definitions.
>>>>>> >> > >> > > >>> > There
>>>>>> >> > >> > > >>> > > > are
>>>>>> >> > >> > > >>> > > > >>>> ones that work for block devices rather
>>>>>> than files.
>>>>>> >> > You
>>>>>> >> > >> > can
>>>>>> >> > >> > > >>> > > > >>>> piggy
>>>>>> >> > >> > > >>> > > > back off
>>>>>> >> > >> > > >>> > > > >>>> of the existing disk definitions and attach
>>>>>> it to
>>>>>> >> the
>>>>>> >> > >> vm
>>>>>> >> > >> > as
>>>>>> >> > >> > > a
>>>>>> >> > >> > > >>> > block
>>>>>> >> > >> > > >>> > > > device.
>>>>>> >> > >> > > >>> > > > >>>> The definition is an XML string per libvirt
>>>>>> XML
>>>>>> >> > format.
>>>>>> >> > >> > You
>>>>>> >> > >> > > may
>>>>>> >> > >> > > >>> > want
>>>>>> >> > >> > > >>> > > > to use
>>>>>> >> > >> > > >>> > > > >>>> an alternate path to the disk rather than
>>>>>> just
>>>>>> >> > /dev/sdx
>>>>>> >> > >> > > like I
>>>>>> >> > >> > > >>> > > > mentioned,
>>>>>> >> > >> > > >>> > > > >>>> there are by-id paths to the block devices,
>>>>>> as well
>>>>>> >> > as
>>>>>> >> > >> > other
>>>>>> >> > >> > > >>> > > > >>>> ones
>>>>>> >> > >> > > >>> > > > that will
>>>>>> >> > >> > > >>> > > > >>>> be consistent and easier for management,
>>>>>> not sure
>>>>>> >> how
>>>>>> >> > >> > > familiar
>>>>>> >> > >> > > >>> > > > >>>> you
>>>>>> >> > >> > > >>> > > > are with
>>>>>> >> > >> > > >>> > > > >>>> device naming on Linux.
>>>>>> >> > >> > > >>> > > > >>>>
>>>>>> >> > >> > > >>> > > > >>>> On Sep 13, 2013 8:00 PM, "Marcus Sorensen"
>>>>>> >> > >> > > >>> > > > >>>> <shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > wrote:
>>>>>> >> > >> > > >>> > > > >>>>>
>>>>>> >> > >> > > >>> > > > >>>>> No, as that would rely on virtualized
>>>>>> >> network/iscsi
>>>>>> >> > >> > > initiator
>>>>>> >> > >> > > >>> > > inside
>>>>>> >> > >> > > >>> > > > >>>>> the vm, which also sucks. I mean attach
>>>>>> /dev/sdx
>>>>>> >> > (your
>>>>>> >> > >> > lun
>>>>>> >> > >> > > on
>>>>>> >> > >> > > >>> > > > hypervisor) as
>>>>>> >> > >> > > >>> > > > >>>>> a disk to the VM, rather than attaching
>>>>>> some image
>>>>>> >> > >> file
>>>>>> >> > >> > > that
>>>>>> >> > >> > > >>> > > resides
>>>>>> >> > >> > > >>> > > > on a
>>>>>> >> > >> > > >>> > > > >>>>> filesystem, mounted on the host, living on
>>>>>> a
>>>>>> >> target.
>>>>>> >> > >> > > >>> > > > >>>>>
>>>>>> >> > >> > > >>> > > > >>>>> Actually, if you plan on the storage
>>>>>> supporting
>>>>>> >> live
>>>>>> >> > >> > > migration
>>>>>> >> > >> > > >>> > > > >>>>> I
>>>>>> >> > >> > > >>> > > > think
>>>>>> >> > >> > > >>> > > > >>>>> this is the only way. You can't put a
>>>>>> filesystem
>>>>>> >> on
>>>>>> >> > it
>>>>>> >> > >> > and
>>>>>> >> > >> > > >>> > > > >>>>> mount
>>>>>> >> > >> > > >>> > it
>>>>>> >> > >> > > >>> > > > in two
>>>>>> >> > >> > > >>> > > > >>>>> places to facilitate migration unless its a
>>>>>> >> > clustered
>>>>>> >> > >> > > >>> > > > >>>>> filesystem,
>>>>>> >> > >> > > >>> > > in
>>>>>> >> > >> > > >>> > > > which
>>>>>> >> > >> > > >>> > > > >>>>> case you're back to shared mount point.
>>>>>> >> > >> > > >>> > > > >>>>>
>>>>>> >> > >> > > >>> > > > >>>>> As far as I'm aware, the xenserver SR
>>>>>> style is
>>>>>> >> > >> basically
>>>>>> >> > >> > > LVM
>>>>>> >> > >> > > >>> > with a
>>>>>> >> > >> > > >>> > > > xen
>>>>>> >> > >> > > >>> > > > >>>>> specific cluster management, a custom
>>>>>> CLVM. They
>>>>>> >> > don't
>>>>>> >> > >> > use
>>>>>> >> > >> > > a
>>>>>> >> > >> > > >>> > > > filesystem
>>>>>> >> > >> > > >>> > > > >>>>> either.
>>>>>> >> > >> > > >>> > > > >>>>>
>>>>>> >> > >> > > >>> > > > >>>>> On Sep 13, 2013 7:44 PM, "Mike Tutkowski"
>>>>>> >> > >> > > >>> > > > >>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>> When you say, "wire up the lun directly
>>>>>> to the
>>>>>> >> vm,"
>>>>>> >> > >> do
>>>>>> >> > >> > you
>>>>>> >> > >> > > >>> > > > >>>>>> mean
>>>>>> >> > >> > > >>> > > > >>>>>> circumventing the hypervisor? I didn't
>>>>>> think we
>>>>>> >> > >> could do
>>>>>> >> > >> > > that
>>>>>> >> > >> > > >>> > > > >>>>>> in
>>>>>> >> > >> > > >>> > > CS.
>>>>>> >> > >> > > >>> > > > >>>>>> OpenStack, on the other hand, always
>>>>>> circumvents
>>>>>> >> > the
>>>>>> >> > >> > > >>> > > > >>>>>> hypervisor,
>>>>>> >> > >> > > >>> > > as
>>>>>> >> > >> > > >>> > > > far as I
>>>>>> >> > >> > > >>> > > > >>>>>> know.
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>> On Fri, Sep 13, 2013 at 7:40 PM, Marcus
>>>>>> Sorensen
>>>>>> >> <
>>>>>> >> > >> > > >>> > > > shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > >>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>> Better to wire up the lun directly to
>>>>>> the vm
>>>>>> >> > unless
>>>>>> >> > >> > > there is
>>>>>> >> > >> > > >>> > > > >>>>>>> a
>>>>>> >> > >> > > >>> > > good
>>>>>> >> > >> > > >>> > > > >>>>>>> reason not to.
>>>>>> >> > >> > > >>> > > > >>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>> On Sep 13, 2013 7:40 PM, "Marcus
>>>>>> Sorensen" <
>>>>>> >> > >> > > >>> > shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > >>>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>> You could do that, but as mentioned I
>>>>>> think
>>>>>> >> its a
>>>>>> >> > >> > > mistake
>>>>>> >> > >> > > >>> > > > >>>>>>>> to
>>>>>> >> > >> > > >>> > go
>>>>>> >> > >> > > >>> > > to
>>>>>> >> > >> > > >>> > > > >>>>>>>> the trouble of creating a 1:1 mapping
>>>>>> of CS
>>>>>> >> > >> volumes to
>>>>>> >> > >> > > luns
>>>>>> >> > >> > > >>> > and
>>>>>> >> > >> > > >>> > > > then putting
>>>>>> >> > >> > > >>> > > > >>>>>>>> a filesystem on it, mounting it, and
>>>>>> then
>>>>>> >> > putting a
>>>>>> >> > >> > > QCOW2
>>>>>> >> > >> > > >>> > > > >>>>>>>> or
>>>>>> >> > >> > > >>> > > even
>>>>>> >> > >> > > >>> > > > RAW disk
>>>>>> >> > >> > > >>> > > > >>>>>>>> image on that filesystem. You'll lose a
>>>>>> lot of
>>>>>> >> > iops
>>>>>> >> > >> > > along
>>>>>> >> > >> > > >>> > > > >>>>>>>> the
>>>>>> >> > >> > > >>> > > > way, and have
>>>>>> >> > >> > > >>> > > > >>>>>>>> more overhead with the filesystem and
>>>>>> its
>>>>>> >> > >> journaling,
>>>>>> >> > >> > > etc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>> On Sep 13, 2013 7:33 PM, "Mike
>>>>>> Tutkowski"
>>>>>> >> > >> > > >>> > > > >>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>> Ah, OK, I didn't know that was such
>>>>>> new ground
>>>>>> >> > in
>>>>>> >> > >> KVM
>>>>>> >> > >> > > with
>>>>>> >> > >> > > >>> > CS.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>> So, the way people use our SAN with
>>>>>> KVM and CS
>>>>>> >> > >> today
>>>>>> >> > >> > > is by
>>>>>> >> > >> > > >>> > > > >>>>>>>>> selecting SharedMountPoint and
>>>>>> specifying the
>>>>>> >> > >> > location
>>>>>> >> > >> > > of
>>>>>> >> > >> > > >>> > > > >>>>>>>>> the
>>>>>> >> > >> > > >>> > > > share.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>> They can set up their share using Open
>>>>>> iSCSI
>>>>>> >> by
>>>>>> >> > >> > > >>> > > > >>>>>>>>> discovering
>>>>>> >> > >> > > >>> > > their
>>>>>> >> > >> > > >>> > > > >>>>>>>>> iSCSI target, logging in to it, then
>>>>>> mounting
>>>>>> >> it
>>>>>> >> > >> > > somewhere
>>>>>> >> > >> > > >>> > > > >>>>>>>>> on
>>>>>> >> > >> > > >>> > > > their file
>>>>>> >> > >> > > >>> > > > >>>>>>>>> system.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>> Would it make sense for me to just do
>>>>>> that
>>>>>> >> > >> discovery,
>>>>>> >> > >> > > >>> > > > >>>>>>>>> logging
>>>>>> >> > >> > > >>> > > in,
>>>>>> >> > >> > > >>> > > > >>>>>>>>> and mounting behind the scenes for
>>>>>> them and
>>>>>> >> > >> letting
>>>>>> >> > >> > the
>>>>>> >> > >> > > >>> > current
>>>>>> >> > >> > > >>> > > > code manage
>>>>>> >> > >> > > >>> > > > >>>>>>>>> the rest as it currently does?
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>> On Fri, Sep 13, 2013 at 7:27 PM, Marcus
>>>>>> >> Sorensen
>>>>>> >> > >> > > >>> > > > >>>>>>>>> <shadowsor@gmail.com> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> Oh, hypervisor snapshots are a bit
>>>>>> >> different. I
>>>>>> >> > >> need
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > catch
>>>>>> >> > >> > > >>> > > up
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> on the work done in KVM, but this is
>>>>>> >> basically
>>>>>> >> > >> just
>>>>>> >> > >> > > disk
>>>>>> >> > >> > > >>> > > > snapshots + memory
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> dump. I still think disk snapshots
>>>>>> would
>>>>>> >> > >> preferably
>>>>>> >> > >> > be
>>>>>> >> > >> > > >>> > handled
>>>>>> >> > >> > > >>> > > > by the SAN,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> and then memory dumps can go to
>>>>>> secondary
>>>>>> >> > >> storage or
>>>>>> >> > >> > > >>> > something
>>>>>> >> > >> > > >>> > > > else. This is
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> relatively new ground with CS and
>>>>>> KVM, so we
>>>>>> >> > will
>>>>>> >> > >> > > want to
>>>>>> >> > >> > > >>> > see
>>>>>> >> > >> > > >>> > > > how others are
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> planning theirs.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> On Sep 13, 2013 7:20 PM, "Marcus
>>>>>> Sorensen" <
>>>>>> >> > >> > > >>> > > shadowsor@gmail.com
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > >>>>>>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> Let me back up and say I don't think
>>>>>> you'd
>>>>>> >> > use a
>>>>>> >> > >> > vdi
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> style
>>>>>> >> > >> > > >>> > on
>>>>>> >> > >> > > >>> > > > an
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> iscsi lun. I think you'd want to
>>>>>> treat it
>>>>>> >> as a
>>>>>> >> > >> RAW
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> format.
>>>>>> >> > >> > > >>> > > > Otherwise you're
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> putting a filesystem on your lun,
>>>>>> mounting
>>>>>> >> it,
>>>>>> >> > >> > > creating
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> a
>>>>>> >> > >> > > >>> > > > QCOW2 disk image,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> and that seems unnecessary and a
>>>>>> performance
>>>>>> >> > >> > killer.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> So probably attaching the raw iscsi
>>>>>> lun as a
>>>>>> >> > >> disk
>>>>>> >> > >> > to
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > VM,
>>>>>> >> > >> > > >>> > > > and
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> handling snapshots on the San side
>>>>>> via the
>>>>>> >> > >> storage
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> plugin
>>>>>> >> > >> > > >>> > is
>>>>>> >> > >> > > >>> > > > best. My
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> impression from the storage plugin
>>>>>> refactor
>>>>>> >> > was
>>>>>> >> > >> > that
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> there
>>>>>> >> > >> > > >>> > > was
>>>>>> >> > >> > > >>> > > > a snapshot
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> service that would allow the San to
>>>>>> handle
>>>>>> >> > >> > snapshots.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> On Sep 13, 2013 7:15 PM, "Marcus
>>>>>> Sorensen" <
>>>>>> >> > >> > > >>> > > > shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> Ideally volume snapshots can be
>>>>>> handled by
>>>>>> >> > the
>>>>>> >> > >> SAN
>>>>>> >> > >> > > back
>>>>>> >> > >> > > >>> > end,
>>>>>> >> > >> > > >>> > > > if
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> the SAN supports it. The cloudstack
>>>>>> mgmt
>>>>>> >> > server
>>>>>> >> > >> > > could
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> call
>>>>>> >> > >> > > >>> > > > your plugin for
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> volume snapshot and it would be
>>>>>> hypervisor
>>>>>> >> > >> > > agnostic. As
>>>>>> >> > >> > > >>> > far
>>>>>> >> > >> > > >>> > > > as space, that
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> would depend on how your SAN
>>>>>> handles it.
>>>>>> >> With
>>>>>> >> > >> > ours,
>>>>>> >> > >> > > we
>>>>>> >> > >> > > >>> > carve
>>>>>> >> > >> > > >>> > > > out luns from a
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> pool, and the snapshot spave comes
>>>>>> from the
>>>>>> >> > >> pool
>>>>>> >> > >> > > and is
>>>>>> >> > >> > > >>> > > > independent of the
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> LUN size the host sees.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> On Sep 13, 2013 7:10 PM, "Mike
>>>>>> Tutkowski"
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>> <mike.tutkowski@solidfire.com>
>>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Hey Marcus,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> I wonder if the iSCSI storage pool
>>>>>> type
>>>>>> >> for
>>>>>> >> > >> > libvirt
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> won't
>>>>>> >> > >> > > >>> > > > work
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> when you take into consideration
>>>>>> >> hypervisor
>>>>>> >> > >> > > snapshots?
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> On XenServer, when you take a
>>>>>> hypervisor
>>>>>> >> > >> > snapshot,
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > VDI
>>>>>> >> > >> > > >>> > > > for
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> the snapshot is placed on the same
>>>>>> storage
>>>>>> >> > >> > > repository
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> as
>>>>>> >> > >> > > >>> > > the
>>>>>> >> > >> > > >>> > > > volume is on.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Same idea for VMware, I believe.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> So, what would happen in my case
>>>>>> (let's
>>>>>> >> say
>>>>>> >> > >> for
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> XenServer
>>>>>> >> > >> > > >>> > > and
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> VMware for 4.3 because I don't
>>>>>> support
>>>>>> >> > >> hypervisor
>>>>>> >> > >> > > >>> > snapshots
>>>>>> >> > >> > > >>> > > > in 4.2) is I'd
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> make an iSCSI target that is
>>>>>> larger than
>>>>>> >> > what
>>>>>> >> > >> the
>>>>>> >> > >> > > user
>>>>>> >> > >> > > >>> > > > requested for the
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> CloudStack volume (which is fine
>>>>>> because
>>>>>> >> our
>>>>>> >> > >> SAN
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> thinly
>>>>>> >> > >> > > >>> > > > provisions volumes,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> so the space is not actually used
>>>>>> unless
>>>>>> >> it
>>>>>> >> > >> needs
>>>>>> >> > >> > > to
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> be).
>>>>>> >> > >> > > >>> > > > The CloudStack
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> volume would be the only "object"
>>>>>> on the
>>>>>> >> SAN
>>>>>> >> > >> > volume
>>>>>> >> > >> > > >>> > until a
>>>>>> >> > >> > > >>> > > > hypervisor
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> snapshot is taken. This snapshot
>>>>>> would
>>>>>> >> also
>>>>>> >> > >> > reside
>>>>>> >> > >> > > on
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> the
>>>>>> >> > >> > > >>> > > > SAN volume.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> If this is also how KVM behaves
>>>>>> and there
>>>>>> >> is
>>>>>> >> > >> no
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> creation
>>>>>> >> > >> > > >>> > of
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> LUNs within an iSCSI target from
>>>>>> libvirt
>>>>>> >> > >> (which,
>>>>>> >> > >> > > even
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> if
>>>>>> >> > >> > > >>> > > > there were support
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> for this, our SAN currently only
>>>>>> allows
>>>>>> >> one
>>>>>> >> > >> LUN
>>>>>> >> > >> > per
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> iSCSI
>>>>>> >> > >> > > >>> > > > target), then I
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> don't see how using this model
>>>>>> will work.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Perhaps I will have to go enhance
>>>>>> the
>>>>>> >> > current
>>>>>> >> > >> way
>>>>>> >> > >> > > this
>>>>>> >> > >> > > >>> > > works
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> with DIR?
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> What do you think?
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Thanks
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> On Fri, Sep 13, 2013 at 6:28 PM,
>>>>>> Mike
>>>>>> >> > >> Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> <mike.tutkowski@solidfire.com>
>>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> That appears to be the way it's
>>>>>> used for
>>>>>> >> > >> iSCSI
>>>>>> >> > >> > > access
>>>>>> >> > >> > > >>> > > today.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> I suppose I could go that route,
>>>>>> too,
>>>>>> >> but I
>>>>>> >> > >> > might
>>>>>> >> > >> > > as
>>>>>> >> > >> > > >>> > well
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> leverage what libvirt has for
>>>>>> iSCSI
>>>>>> >> > instead.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> On Fri, Sep 13, 2013 at 6:26 PM,
>>>>>> Marcus
>>>>>> >> > >> Sorensen
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> <shadowsor@gmail.com> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> To your question about
>>>>>> >> SharedMountPoint, I
>>>>>> >> > >> > > believe
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> it
>>>>>> >> > >> > > >>> > > just
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> acts like a
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> 'DIR' storage type or something
>>>>>> similar
>>>>>> >> to
>>>>>> >> > >> > that.
>>>>>> >> > >> > > The
>>>>>> >> > >> > > >>> > > > end-user
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> is
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> responsible for mounting a file
>>>>>> system
>>>>>> >> > that
>>>>>> >> > >> all
>>>>>> >> > >> > > KVM
>>>>>> >> > >> > > >>> > hosts
>>>>>> >> > >> > > >>> > > > can
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> access,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> and CloudStack is oblivious to
>>>>>> what is
>>>>>> >> > >> > providing
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > > > storage.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> It could
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> be NFS, or OCFS2, or some other
>>>>>> >> clustered
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> filesystem,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> cloudstack just
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> knows that the provided
>>>>>> directory path
>>>>>> >> has
>>>>>> >> > >> VM
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> images.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> On Fri, Sep 13, 2013 at 6:23 PM,
>>>>>> Marcus
>>>>>> >> > >> > Sorensen
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> <shadowsor@gmail.com> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> > Oh yes, you can use NFS, LVM,
>>>>>> and
>>>>>> >> iSCSI
>>>>>> >> > >> all
>>>>>> >> > >> > at
>>>>>> >> > >> > > the
>>>>>> >> > >> > > >>> > same
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> > time.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> > Multiples, in fact.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> > On Fri, Sep 13, 2013 at 6:19
>>>>>> PM, Mike
>>>>>> >> > >> > Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> > <mike.tutkowski@solidfire.com>
>>>>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> Looks like you can have
>>>>>> multiple
>>>>>> >> > storage
>>>>>> >> > >> > > pools:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> mtutkowski@ubuntu:~$ virsh
>>>>>> pool-list
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> Name                 State
>>>>>> >> >  Autostart
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > -----------------------------------------
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> default              active
>>>>>>   yes
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> iSCSI                active
>>>>>>   no
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> On Fri, Sep 13, 2013 at 6:12
>>>>>> PM, Mike
>>>>>> >> > >> > > Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> <mike.tutkowski@solidfire.com
>>>>>> >
>>>>>> >> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> Reading through the docs you
>>>>>> pointed
>>>>>> >> > >> out.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> I see what you're saying now.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> You can create an iSCSI
>>>>>> (libvirt)
>>>>>> >> > >> storage
>>>>>> >> > >> > > pool
>>>>>> >> > >> > > >>> > based
>>>>>> >> > >> > > >>> > > on
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> an iSCSI target.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> In my case, the iSCSI target
>>>>>> would
>>>>>> >> > only
>>>>>> >> > >> > have
>>>>>> >> > >> > > one
>>>>>> >> > >> > > >>> > LUN,
>>>>>> >> > >> > > >>> > > > so
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> there would only
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> be one iSCSI (libvirt)
>>>>>> storage
>>>>>> >> volume
>>>>>> >> > in
>>>>>> >> > >> > the
>>>>>> >> > >> > > >>> > > (libvirt)
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> storage pool.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> As you say, my plug-in
>>>>>> creates and
>>>>>> >> > >> destroys
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> iSCSI
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> targets/LUNs on the
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> SolidFire SAN, so it is not a
>>>>>> >> problem
>>>>>> >> > >> that
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> libvirt
>>>>>> >> > >> > > >>> > > does
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> not support
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> creating/deleting iSCSI
>>>>>> >> targets/LUNs.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> It looks like I need to test
>>>>>> this a
>>>>>> >> > bit
>>>>>> >> > >> to
>>>>>> >> > >> > > see
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> if
>>>>>> >> > >> > > >>> > > > libvirt
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> supports
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> multiple iSCSI storage pools
>>>>>> (as you
>>>>>> >> > >> > > mentioned,
>>>>>> >> > >> > > >>> > since
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> each one of its
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> storage pools would map to
>>>>>> one of my
>>>>>> >> > >> iSCSI
>>>>>> >> > >> > > >>> > > > targets/LUNs).
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> On Fri, Sep 13, 2013 at 5:58
>>>>>> PM,
>>>>>> >> Mike
>>>>>> >> > >> > > Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> <
>>>>>> mike.tutkowski@solidfire.com>
>>>>>> >> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> LibvirtStoragePoolDef has
>>>>>> this
>>>>>> >> type:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>     public enum poolType {
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         ISCSI("iscsi"),
>>>>>> >> > NETFS("netfs"),
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> LOGICAL("logical"),
>>>>>> DIR("dir"),
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> RBD("rbd");
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         String _poolType;
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         poolType(String
>>>>>> poolType) {
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>             _poolType =
>>>>>> poolType;
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         }
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         @Override
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         public String
>>>>>> toString() {
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>             return
>>>>>> _poolType;
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>         }
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>     }
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> It doesn't look like the
>>>>>> iSCSI type
>>>>>> >> > is
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> currently
>>>>>> >> > >> > > >>> > > being
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> used, but I'm
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> understanding more what you
>>>>>> were
>>>>>> >> > >> getting
>>>>>> >> > >> > at.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> Can you tell me for today
>>>>>> (say,
>>>>>> >> 4.2),
>>>>>> >> > >> when
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> someone
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> selects the
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> SharedMountPoint option and
>>>>>> uses it
>>>>>> >> > >> with
>>>>>> >> > >> > > iSCSI,
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> is
>>>>>> >> > >> > > >>> > > > that
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> the "netfs" option
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> above or is that just for
>>>>>> NFS?
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> Thanks!
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> On Fri, Sep 13, 2013 at
>>>>>> 5:50 PM,
>>>>>> >> > Marcus
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> Sorensen
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> <shadowsor@gmail.com>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> wrote:
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> 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.tutkowski@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.tutkowski@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
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> <shadowsor@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.tutkowski@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.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>>> Advancing the way the
>>>>>> world
>>>>>> >> > uses
>>>>>> >> > >> the
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>>> cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> Senior CloudStack
>>>>>> Developer,
>>>>>> >> > >> SolidFire
>>>>>> >> > >> > > Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> e:
>>>>>> >> mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >> Advancing the way the
>>>>>> world
>>>>>> >> uses
>>>>>> >> > >> the
>>>>>> >> > >> > > cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> >
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> > --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> > Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> > Senior CloudStack
>>>>>> Developer,
>>>>>> >> > >> SolidFire
>>>>>> >> > >> > > Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> > e:
>>>>>> mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> > o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>> > Advancing the way the
>>>>>> world uses
>>>>>> >> > the
>>>>>> >> > >> > > cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> Senior CloudStack Developer,
>>>>>> >> > SolidFire
>>>>>> >> > >> > Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> e:
>>>>>> mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>> Advancing the way the world
>>>>>> uses
>>>>>> >> the
>>>>>> >> > >> > cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> Senior CloudStack Developer,
>>>>>> >> SolidFire
>>>>>> >> > >> Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> e:
>>>>>> mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>> Advancing the way the world
>>>>>> uses the
>>>>>> >> > >> cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> Senior CloudStack Developer,
>>>>>> >> SolidFire
>>>>>> >> > >> Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> e:
>>>>>> mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>> >> Advancing the way the world
>>>>>> uses the
>>>>>> >> > >> cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> Senior CloudStack Developer,
>>>>>> SolidFire
>>>>>> >> Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>> Advancing the way the world uses
>>>>>> the
>>>>>> >> cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Senior CloudStack Developer,
>>>>>> SolidFire
>>>>>> >> Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>>>>>> Advancing the way the world uses
>>>>>> the
>>>>>> >> cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>>>> --
>>>>>> >> > >> > > >>> > > > >>>>>>>>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>>>>> Senior CloudStack Developer, SolidFire
>>>>>> Inc.
>>>>>> >> > >> > > >>> > > > >>>>>>>>> e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>>>>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>>>>> Advancing the way the world uses the
>>>>>> cloud™
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>>
>>>>>> >> > >> > > >>> > > > >>>>>> --
>>>>>> >> > >> > > >>> > > > >>>>>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>>>>> Senior CloudStack Developer, SolidFire
>>>>>> Inc.
>>>>>> >> > >> > > >>> > > > >>>>>> e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>>>>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>>>>> Advancing the way the world uses the
>>>>>> cloud™
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>>
>>>>>> >> > >> > > >>> > > > >>> --
>>>>>> >> > >> > > >>> > > > >>> Mike Tutkowski
>>>>>> >> > >> > > >>> > > > >>> Senior CloudStack Developer, SolidFire Inc.
>>>>>> >> > >> > > >>> > > > >>> e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > >>> o: 303.746.7302
>>>>>> >> > >> > > >>> > > > >>> Advancing the way the world uses the cloud™
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > >
>>>>>> >> > >> > > >>> > > > > --
>>>>>> >> > >> > > >>> > > > > Mike Tutkowski
>>>>>> >> > >> > > >>> > > > > Senior CloudStack Developer, SolidFire Inc.
>>>>>> >> > >> > > >>> > > > > e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > > > o: 303.746.7302
>>>>>> >> > >> > > >>> > > > > Advancing the way the world uses the cloud™
>>>>>> >> > >> > > >>> > > >
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> > > --
>>>>>> >> > >> > > >>> > > *Mike Tutkowski*
>>>>>> >> > >> > > >>> > > *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> >> > >> > > >>> > > e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> > > o: 303.746.7302
>>>>>> >> > >> > > >>> > > Advancing the way the world uses the
>>>>>> >> > >> > > >>> > > cloud<
>>>>>> http://solidfire.com/solution/overview/?video=play>
>>>>>> >> > >> > > >>> > > *™*
>>>>>> >> > >> > > >>> > >
>>>>>> >> > >> > > >>> >
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>>
>>>>>> >> > >> > > >>> --
>>>>>> >> > >> > > >>> *Mike Tutkowski*
>>>>>> >> > >> > > >>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> >> > >> > > >>> e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > > >>> o: 303.746.7302
>>>>>> >> > >> > > >>> Advancing the way the world uses the
>>>>>> >> > >> > > >>> cloud<
>>>>>> http://solidfire.com/solution/overview/?video=play>
>>>>>> >> > >> > > >>> *™*
>>>>>> >> > >> > >
>>>>>> >> > >> >
>>>>>> >> > >> >
>>>>>> >> > >> >
>>>>>> >> > >> > --
>>>>>> >> > >> > *Mike Tutkowski*
>>>>>> >> > >> > *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> >> > >> > e: mike.tutkowski@solidfire.com
>>>>>> >> > >> > o: 303.746.7302
>>>>>> >> > >> > Advancing the way the world uses the
>>>>>> >> > >> > cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>> >> > >> > *™*
>>>>>> >> > >> >
>>>>>> >> > >>
>>>>>> >> > >
>>>>>> >> > >
>>>>>> >> > >
>>>>>> >> > > --
>>>>>> >> > > *Mike Tutkowski*
>>>>>> >> > > *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> >> > > e: mike.tutkowski@solidfire.com
>>>>>> >> > > o: 303.746.7302
>>>>>> >> > > Advancing the way the world uses the cloud<
>>>>>> >> > http://solidfire.com/solution/overview/?video=play>
>>>>>> >> > > *™*
>>>>>> >> > >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > --
>>>>>> >> > *Mike Tutkowski*
>>>>>> >> > *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> >> > e: mike.tutkowski@solidfire.com
>>>>>> >> > o: 303.746.7302
>>>>>> >> > Advancing the way the world uses the
>>>>>> >> > cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>> >> > *™*
>>>>>> >> >
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > *Mike Tutkowski*
>>>>>> > *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> > e: mike.tutkowski@solidfire.com
>>>>>> > o: 303.746.7302
>>>>>> > Advancing the way the world uses the
>>>>>> > cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>> > *™*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Mike Tutkowski*
>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>> e: mike.tutkowski@solidfire.com
>>>>> o: 303.746.7302
>>>>> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
>>>>> *™*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Mike Tutkowski*
>>>>  *Senior CloudStack Developer, SolidFire Inc.*
>>>> e: mike.tutkowski@solidfire.com
>>>> o: 303.746.7302
>>>> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
>>>> *™*
>>>>
>>>
>>>
>>>
>>> --
>>> *Mike Tutkowski*
>>>  *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
>>> *™*
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
>> *™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*

Mime
View raw message