cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Review Request 14381: KVM: add connect/disconnect capabilities to StorageAdaptors so that external storage services can attach/detach devices on-demand
Date Sat, 26 Oct 2013 04:05:05 GMT
Hey Marcus,

I've been running all sorts of tests today and just noticed one issue.

When I have a disk attached and reset (not reboot) the VM, the VM comes up
just fine.

If I then try to detach the disk, I get the following error:

com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume:
Vol-6 from VM: VM-KVM-1; org.libvirt.LibvirtException: unsupported
configuration: This type of disk cannot be hot unplugged

Normally I have no problem detaching a disk. Once I get into this state;
however, I seem to be stuck with an attached disk.

Any thoughts on this?

Thanks


On Fri, Oct 25, 2013 at 12:58 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Excellent - thanks!
>
>
> On Fri, Oct 25, 2013 at 12:10 AM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>
>> tests passed with latest commit hash you sent.
>>
>> On Thu, Oct 24, 2013 at 10:10 PM, Mike Tutkowski
>> <mike.tutkowski@solidfire.com> wrote:
>> > Just playing around with this on XenServer now.
>> >
>> > When I stop a VM, XenCenter no longer shows the VM (i.e. it behaves
>> like VMM
>> > does when a VM is stopped).
>> >
>> >
>> > On Thu, Oct 24, 2013 at 9:53 PM, Marcus Sorensen <shadowsor@gmail.com>
>> > wrote:
>> >>
>> >>
>> >> On Oct 24, 2013 7:39 PM, "Mike Tutkowski" <
>> mike.tutkowski@solidfire.com>
>> >> wrote:
>> >> >
>> >> > But what happens when, say, XenServer crashes and knows about VMs it
>> had
>> >> > running before it crashed?
>> >>
>> >> Not sure what XenCenter does but I thought it would/could start them on
>> >> other nodes.
>> >> >
>> >> > I guess I was thinking you meant that CS purposefully creates VMs on
>> KVM
>> >> > in such a fashion that KVM will not remember them in the event of a
>> crash.
>> >>
>> >> You're right about that, you get what I mean. Its done since there's no
>> >> central manager and it causes problems for each host to keep a local
>> config.
>> >> I meant that CS doesn't necessarily tell the other hypervisors to
>> remember,
>> >> per se. They just do because its working through a cluster manager and
>> >> that's what they do.
>> >>
>> >> >
>> >> >
>> >> > On Thu, Oct 24, 2013 at 7:25 PM, Marcus Sorensen <
>> shadowsor@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> I just mean that they're still visible on those platforms because
>> >> >> they're being tracked by some central source outside of cloudstack.
>> >> >> Cloudstack itself I don't think cares, it just manages the
>> resources as it
>> >> >> sees in ITs database. I don't really see it as cloudstack treating
>> KVM
>> >> >> differently, rather just KVM lacking a central authority or cluster
>> manager.
>> >> >>
>> >> >> On Oct 24, 2013 7:19 PM, "Mike Tutkowski"
>> >> >> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>
>> >> >>> So, I guess the moral is CloudStack has KVM treat VMs ephemerally,
>> but
>> >> >>> we (you and I) don't know how CS has XenServer and VMware treat
>> VMs.
>> >> >>>
>> >> >>> I plan to do some testing with XenServer and VMware in a bit, so I
>> can
>> >> >>> stop a VM and see if it remains visible in their GUIs.
>> >> >>>
>> >> >>>
>> >> >>> On Thu, Oct 24, 2013 at 7:17 PM, Mike Tutkowski
>> >> >>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>
>> >> >>>> My guess is XenCenter gets info about stopped VMs from the
>> XenServer
>> >> >>>> hosts it logs in to. I don't think it maintains a DB like vCenter
>> does.
>> >> >>>>
>> >> >>>>
>> >> >>>> On Thu, Oct 24, 2013 at 7:15 PM, Mike Tutkowski
>> >> >>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>
>> >> >>>>> Actually, I don't know if XenCenter remembers the VMs per se or
>> if
>> >> >>>>> it gets that information from querying the XenServer hosts it
>> has access to.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Thu, Oct 24, 2013 at 7:14 PM, Mike Tutkowski
>> >> >>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>
>> >> >>>>>> No, it does allow you to do that. I wasn't sure what you meant
>> by
>> >> >>>>>> your comparison, but XenCenter does remember VMs as far as I
>> know.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Thu, Oct 24, 2013 at 7:08 PM, Marcus Sorensen
>> >> >>>>>> <shadowsor@gmail.com> wrote:
>> >> >>>>>>>
>> >> >>>>>>> Oh, xencenter doesn't remember VMS and allow you to start one
>> if
>> >> >>>>>>> the host it was on is down? I haven't played with it in a year
>> but I thought
>> >> >>>>>>> it synced with each xen server.
>> >> >>>>>>>
>> >> >>>>>>> On Oct 24, 2013 7:06 PM, "Mike Tutkowski"
>> >> >>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>> Well...XenCenter is "just" the GUI (like VI Client is for
>> >> >>>>>>>> vSphere). As far as I know, XenServer has no equivalent to
>> vCenter Server.
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> On Thu, Oct 24, 2013 at 6:52 PM, Marcus Sorensen
>> >> >>>>>>>> <shadowsor@gmail.com> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>> That is probably true, but there is no xencenter or vsphere
>> >> >>>>>>>>> equivalent for KVM, no central authority. Its cloudstack.
>> >> >>>>>>>>>
>> >> >>>>>>>>> On Oct 24, 2013 6:22 PM, "Mike Tutkowski"
>> >> >>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> OK, thanks for that info, Marcus...I was not aware that
>> >> >>>>>>>>>> CloudStack treated VMs ephemerally with KVM.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> I guess I should try to stop a VM on XenServer and ESX and
>> see
>> >> >>>>>>>>>> what happens. I was under the impression they remained
>> accessible using
>> >> >>>>>>>>>> XenCenter or VI Client, but perhaps I am wrong about that.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Since my KVM VM's root disk was on local storage, I
>> expected it
>> >> >>>>>>>>>> to remain accessible in VMM after I had stopped it via CS.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On Thu, Oct 24, 2013 at 6:16 PM, Marcus Sorensen
>> >> >>>>>>>>>> <shadowsor@gmail.com> wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> Are you talking cloudstack VMS or your own?  If a vm is
>> >> >>>>>>>>>>> 'created' it is ephemeral, the definition will disappear
>> when stopped. This
>> >> >>>>>>>>>>> is what cloudstack does so that a KVM host that crashes or
>> loses power won't
>> >> >>>>>>>>>>> remember and try to start VMS that were previously on it
>> (they are likely
>> >> >>>>>>>>>>> running elsewhere now). However, for your desktop and your
>> own VMS you
>> >> >>>>>>>>>>> usually 'define' VMS, which saves the XML to a file and
>> leaves them
>> >> >>>>>>>>>>> persistent. I use vmm occasionally, but usually virsh, the
>> CLI version. Both
>> >> >>>>>>>>>>> just talk to libvirt.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> On Oct 24, 2013 6:08 PM, "Mike Tutkowski"
>> >> >>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Hey Marcus,
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I assume you use Virtual Machine Manager with KVM?
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I was wondering, is there a way when you stop a VM to
>> have it
>> >> >>>>>>>>>>>> not disappear from the GUI?
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> In XenCenter and VI Client, stopped VMs just show up with
>> a
>> >> >>>>>>>>>>>> different icon, but are still easy to interact with.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Thanks!
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:46 PM, Mike Tutkowski
>> >> >>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Also, the way I determined if the attach/detach worked
>> was
>> >> >>>>>>>>>>>>> to use fdisk -l and see if the device was present or not
>> in the hypervisor
>> >> >>>>>>>>>>>>> and VM instance.
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:42 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Here are some of the tests I ran on this code:
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> attach/detach/attach volume while VM is running: works
>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reboot: works
>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reset: works
>> >> >>>>>>>>>>>>>> volume detached while VM is stopped, then start: works
>> >> >>>>>>>>>>>>>> volume attached while VM is stopped, then start: works
>> >> >>>>>>>>>>>>>> deleted VM with attached volume: works (volume goes into
>> >> >>>>>>>>>>>>>> the attachable state after VM is expunged)
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:40 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> By the way, in case you're looking at the diff and
>> >> >>>>>>>>>>>>>>> wondering why I took out a StopCommand check and call
>> to execute in
>> >> >>>>>>>>>>>>>>> LibvirtComputingResource, there were two of them.
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> -            } else if (cmd instanceof StopCommand) {
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> -                return execute((StopCommand) cmd);
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:26 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> This is a newer link, Marcus:
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>
>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/e84de7577ad38fea88d1492d4949672d1989889b
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> I just rebased on top of master today.
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 3:46 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> Hey Marcus,
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> If you're interested in running the simulator against
>> >> >>>>>>>>>>>>>>>>> your code + my code, I have it on GitHub here:
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>
>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/776f3eb9dda45745f43e6765b026d34fbc6be072
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> Thanks!
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 11:06 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> I'm trying to attach my diff to
>> >> >>>>>>>>>>>>>>>>>> https://reviews.apache.org/r/13865/, but I don't
>> see the necessary buttons.
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> I wonder if I need to get edit access back again? We
>> >> >>>>>>>>>>>>>>>>>> had trouble with the Wiki. Was this also impacted?
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:47 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>> Sure, I can create a diff file and attach it to
>> Review
>> >> >>>>>>>>>>>>>>>>>>> Board.
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:40 PM, Marcus Sorensen
>> >> >>>>>>>>>>>>>>>>>>> <shadowsor@gmail.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> Sure. The majority of it only affects people who
>> are
>> >> >>>>>>>>>>>>>>>>>>>> on your storage
>> >> >>>>>>>>>>>>>>>>>>>> anyway. Perhaps you can post a patch and I can
>> run it
>> >> >>>>>>>>>>>>>>>>>>>> through the
>> >> >>>>>>>>>>>>>>>>>>>> simulator to verify that the minor change to the
>> >> >>>>>>>>>>>>>>>>>>>> existing code hasn't
>> >> >>>>>>>>>>>>>>>>>>>> broken the standard storages. I don't think it is
>> >> >>>>>>>>>>>>>>>>>>>> since I've
>> >> >>>>>>>>>>>>>>>>>>>> thoroughly tested the code I posted, but I know
>> there
>> >> >>>>>>>>>>>>>>>>>>>> were some
>> >> >>>>>>>>>>>>>>>>>>>> additional changes.
>> >> >>>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:35 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> > OK, Marcus, I made the change to detect my
>> volumes
>> >> >>>>>>>>>>>>>>>>>>>> > and it seems to work just
>> >> >>>>>>>>>>>>>>>>>>>> > fine.
>> >> >>>>>>>>>>>>>>>>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> > Perhaps another day of testing and we can check
>> >> >>>>>>>>>>>>>>>>>>>> > this code in. What do you
>> >> >>>>>>>>>>>>>>>>>>>> > think?
>> >> >>>>>>>>>>>>>>>>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> > On Wed, Oct 23, 2013 at 9:14 PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> > <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, Marcus...I hadn't read that note, but
>> that
>> >> >>>>>>>>>>>>>>>>>>>> >> makes sense.
>> >> >>>>>>>>>>>>>>>>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >> Yes, that must be the root disk for the VM. I
>> can
>> >> >>>>>>>>>>>>>>>>>>>> >> put in code, as you
>> >> >>>>>>>>>>>>>>>>>>>> >> recommend, to handle only my volumes.
>> >> >>>>>>>>>>>>>>>>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >> On Wed, Oct 23, 2013 at 5:37 PM, Marcus
>> Sorensen
>> >> >>>>>>>>>>>>>>>>>>>> >> <shadowsor@gmail.com>
>> >> >>>>>>>>>>>>>>>>>>>> >> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> It should be sending the path info for each
>> disk
>> >> >>>>>>>>>>>>>>>>>>>> >>> per the XML of the
>> >> >>>>>>>>>>>>>>>>>>>> >>> VM... so it will send all disks regardless of
>> >> >>>>>>>>>>>>>>>>>>>> >>> whether or not your
>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor manages that disk, and it's up to your
>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor to ignore any
>> >> >>>>>>>>>>>>>>>>>>>> >>> that aren't managed by it. There should be
>> notes
>> >> >>>>>>>>>>>>>>>>>>>> >>> to that effect in the
>> >> >>>>>>>>>>>>>>>>>>>> >>> code near the disconnectPhysicalDisk
>> interface in
>> >> >>>>>>>>>>>>>>>>>>>> >>> StorageAdaptor:
>> >> >>>>>>>>>>>>>>>>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>>     // given local path to file/device (per
>> >> >>>>>>>>>>>>>>>>>>>> >>> Libvirt XML), 1) check
>> >> >>>>>>>>>>>>>>>>>>>> >>> that device is
>> >> >>>>>>>>>>>>>>>>>>>> >>>     // handled by your adaptor, return false
>> if
>> >> >>>>>>>>>>>>>>>>>>>> >>> not. 2) clean up
>> >> >>>>>>>>>>>>>>>>>>>> >>> device, return true
>> >> >>>>>>>>>>>>>>>>>>>> >>>     public boolean
>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDiskByPath(String
>> localPath);
>> >> >>>>>>>>>>>>>>>>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> Since we only have XML disk definitions when
>> we
>> >> >>>>>>>>>>>>>>>>>>>> >>> stop or migrate a VM,
>> >> >>>>>>>>>>>>>>>>>>>> >>> we have to try all adaptors against all
>> defined
>> >> >>>>>>>>>>>>>>>>>>>> >>> disks. So in your
>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk you might do something
>> >> >>>>>>>>>>>>>>>>>>>> >>> like check that the path
>> >> >>>>>>>>>>>>>>>>>>>> >>> starts with '/dev/disk/by-path' and contains
>> >> >>>>>>>>>>>>>>>>>>>> >>> 'iscs-iqn' (maybe there's
>> >> >>>>>>>>>>>>>>>>>>>> >>> some way that's more robust like checking the
>> >> >>>>>>>>>>>>>>>>>>>> >>> full path against a lun
>> >> >>>>>>>>>>>>>>>>>>>> >>> listing or something). If it doesn't match,
>> then
>> >> >>>>>>>>>>>>>>>>>>>> >>> your
>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk just does nothing.
>> >> >>>>>>>>>>>>>>>>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> I assume this is a root disk or some other
>> local
>> >> >>>>>>>>>>>>>>>>>>>> >>> storage disk. If it's
>> >> >>>>>>>>>>>>>>>>>>>> >>> not, then your VM XML is messed up somehow.
>> >> >>>>>>>>>>>>>>>>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> On Wed, Oct 23, 2013 at 5:01 PM, Mike
>> Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> > I found the problem.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> > disconnectPhysicalDiskByPath is being
>> passed in
>> >> >>>>>>>>>>>>>>>>>>>> >>> > (in my situation) the
>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> /var/lib/libvirt/images/9887d511-8dc7-4cb4-96f9-01230fe4bbb6
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> > Due to the name of the method, my code was
>> >> >>>>>>>>>>>>>>>>>>>> >>> > expecting data such as the
>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> /dev/disk/by-path/ip-192.168.233.10:3260-iscsi-iqn.2012-03.com.solidfire:volume1-lun-0
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> > Was it intentional to send the data into
>> this
>> >> >>>>>>>>>>>>>>>>>>>> >>> > method in the current
>> >> >>>>>>>>>>>>>>>>>>>> >>> > way?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> > On Wed, Oct 23, 2013 at 1:57 PM, Mike
>> Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> > <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> You know, I forgot we supposed to be doing
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> that! :) Multi-tasking too
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> much
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> today, I guess.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Anyways, it must not be working because I
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> still had a hypervisor
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> connection after I shut down the VM.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Let me investigate.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> On Wed, Oct 23, 2013 at 1:48 PM, Marcus
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Sorensen <shadowsor@gmail.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> Are we not disconnecting when we stop the
>> vm?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> There's a method for
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> it, we
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> should be. disconnectPhysicalDiskViaVmSpec
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> On Oct 23, 2013 1:28 PM, "Mike Tutkowski"
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> <mike.tutkowski@solidfire.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> I see one problem for us now, Marcus.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You have a running VM that you attach a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume to.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You stop the VM.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You detach the volume.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You start up the VM.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> The VM will not be connected to the
>> volume
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> (which is good), but the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> hypervisor will still be connected to the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> It would be great if we actually sent a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> command to the last host ID
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> of
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> the stopped VM when detaching a volume
>> (to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> have the hypervisor
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> disconnect
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> from the volume).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> What do you think about that?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> On Wed, Oct 23, 2013 at 1:15 PM, Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> OK, whatever way you prefer then, Marcus
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> (createVdb first or
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> second).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> If I leave createVdb first and return
>> 0, it
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> does seem to work.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> On Wed, Oct 23, 2013 at 11:13 AM, Marcus
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> Sorensen
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> <shadowsor@gmail.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I think we could flip-flop these two
>> lines
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> if necessary:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>             createVbd(conn, vmSpec,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> vmName, vm);
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> _storagePoolMgr.connectPhysicalDisksViaVmSpec(vmSpec);
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I haven't actually tried it though.
>> But in
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> general I don't see the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Libvirt DiskDef using size at all,
>> which
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> is what createVbd does
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> (creates XML definitions for disks to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> attach to the VM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> definition). It
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> just takes the device at it's native
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> advertised size when it
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> actually
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> goes to use it.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> On Wed, Oct 23, 2013 at 10:52 AM, Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> <mike.tutkowski@solidfire.com> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Little problem that I wanted to get
>> your
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > take on, Marcus.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When a VM is being started, we call
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > createVdb before calling
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > The problem is that createVdb calls
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > getPhysicalDisk and my
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > volume
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > has not
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet been connected because
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec has not
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > been
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > called.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When I try to read up the size of the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > disk to populate a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > PhysicalDisk, I get
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > an error, of course, because the path
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > does not yet exist.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > I could populate a 0 for the size of
>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > physical disk and then
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > next
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > time getPhysicalDisk is called, it
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > should be filled in with a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > proper
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > size.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Do you see a problem with that
>> approach?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > On Tue, Oct 22, 2013 at 6:40 PM,
>> Marcus
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Sorensen
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > <shadowsor@gmail.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> That's right. All should be well.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> On Oct 22, 2013 6:03 PM, "Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> Tutkowski"
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> <mike.tutkowski@solidfire.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Looks like we disconnect physical
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disks when the VM is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I didn't see that before.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I suppose that means the disks are
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> physically disconnected
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> when
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the VM is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped, but the CloudStack DB
>> still
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> has the VM associated
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> with
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the disks
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> for the next time the VM may be
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> started up (unless someone
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> does a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disconnect
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> while the VM is in the Stopped
>> State).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> On Tue, Oct 22, 2013 at 4:19 PM,
>> Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> <mike.tutkowski@solidfire.com>
>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Hey Marcus,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Quick question for you related to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> attaching/detaching volumes
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> when the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is in the Stopped State.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If I detach a volume from a VM
>> that
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> is in the Stopped State,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> DB
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> seems to get updated, but I don't
>> see
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> a command going to the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> KVM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> hypervisor
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that leads to the removal of the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> iSCSI target.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> It seems the iSCSI target is only
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> removed the next time the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> started.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Do you know if this is true?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If it is, I'm concerned that the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume could be attached to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> another VM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> before the Stopped VM is
>> re-started
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> and when the Stopped VM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> gets
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> restarted
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that it would disconnect the iSCSI
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume from underneath the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that now
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> has the volume attached.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> I still want to perform some
>> tests on
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> this, but am first
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> trying
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> to get a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM to start after I've attached a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume to it when it was in
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Stopped
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> State.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Thanks,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> On Mon, Oct 21, 2013 at 10:57 PM,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> <mike.tutkowski@solidfire.com>
>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks for that info, Marcus.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> By the way, I wanted to see if I
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> could attach my volume to a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> VM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> in the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Stopped State.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The attach logic didn't trigger
>> any
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> exceptions; however,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> when I
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> started
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the VM, I received an
>> Insufficient
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Capacity exception.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> If I detach the volume and then
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> start the VM, the VM starts
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> just
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> fine.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I noticed a problem here (in
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> StoragePoolHostDaoImpl):
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>     @Override
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>     public StoragePoolHostVO
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findByPoolHost(long poolId,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> long
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId) {
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> SearchCriteria<StoragePoolHostVO> sc =
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> PoolHostSearch.create();
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> sc.setParameters("pool_id",
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId);
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> sc.setParameters("host_id",
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId);
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>         return
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findOneIncludingRemovedBy(sc);
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>     }
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The findOneIncludingRemovedBy
>> method
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> returns null (the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> my
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage pool's ID and the hostId
>> is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the expected host ID).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I'm not sure what this method is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I looked in the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage_pool_host_ref table (is
>> that the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> correct
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> table?) and it only has one row,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> which maps the local
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> pool of the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> KVM host to the KVM host (which
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> explains why no match is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> found
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> for my
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> situation).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Do you understand what this
>> logic is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks!
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> On Mon, Oct 21, 2013 at 8:08 PM,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Marcus Sorensen
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> <shadowsor@gmail.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Do you have the capability to
>> clone
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the root disk? Normally
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template is installed to
>> primary,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and then cloned for each
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> disk.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In some cases (such as CLVM),
>> this
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> isn't efficient and so
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> is copied fresh to populate each
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root disk.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm actually not 100% sure how
>> this
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> works in the new code.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> used to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be handled by copyPhysicalDisk
>> in
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the storage adaptor,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> called
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> by
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyTemplateToPrimaryStorage,
>> which
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> runs on the agent. It
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> pass
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template/secondary storage info,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and the destination
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> volume/primary
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> storage info, and
>> copyPhysicalDisk
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would do the work of
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> installing the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> image to the destination.  Then
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> subsequent root disks would
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> cloned
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in CreateCommand by calling
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> createDiskFromTemplate.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In master it looks like this was
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> moved to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> KVMStorageProcessor
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> 'cloneVolumeFromBaseTemplate',
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> although I think this just
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> takes
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> over
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> as default, and there's
>> something
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in your storage driver
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> that
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> should
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be capable of cloning templates
>> on
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the mgmt server side.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> less sure
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> about how the template gets to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> primary storage in the first
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> place, I
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> assume
>> copyTemplateToPrimaryStorage
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in KVMStorageProcessor
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> calling
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyPhysicalDisk in your
>> adaptor.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It's a bit tough for me
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> tell
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> since our earlier storage
>> adaptor
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> did everything on the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> host it
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> mostly
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> just worked with the default
>> stuff.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> On Mon, Oct 21, 2013 at 4:49 PM,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> <mike.tutkowski@solidfire.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Hey Marcus,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > So...now that this works well
>> for
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > data disks, I was
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wondering
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > what
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > might be
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > involved in getting this
>> process
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > to work for root disks.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Can you point me in the right
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > direction as far as what
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > gets
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > invoked
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > when a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > VM is being created on KVM (so
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > that its root disk can be
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > created and
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > necessary template laid down
>> or
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > ISO installed)?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Thanks!
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > On Mon, Oct 21, 2013 at 1:14
>> PM,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > <mike.tutkowski@solidfire.com
>> >
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> Hey Marcus,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> Just wanted to let you know
>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> branch of mine that has
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> your
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> code
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> and mine
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> appears to work well with
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> regards to attaching a data
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> disk
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> to a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> running VM:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> fdisk -l from hypervisor:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> http://i.imgur.com/NkP5fo0.png
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> fdisk -l from within VM:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> http://i.imgur.com/8YwiiC7.png
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> I plan to do more testing on
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> this over the coming days.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> If all goes well, perhaps we
>> can
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> check this code in by
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> end of
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> week?
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> Talk to you later,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> On Sun, Oct 20, 2013 at 10:23
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> PM, Mike Tutkowski
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> <
>> mike.tutkowski@solidfire.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> Don't ask me, but it works
>> now
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> (I've been having this
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> trouble
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> quite a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> while today).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> I guess the trick is to send
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> you an e-mail. :)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> On Sun, Oct 20, 2013 at
>> 10:05
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> PM, Marcus Sorensen
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> <shadowsor@gmail.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> Did you create a service
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> offering that uses local
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> storage,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> or add
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> shared primary storage? By
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> default there is no storage
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> that
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> matches the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> built in offerings.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> On Oct 20, 2013 9:39 PM,
>> "Mike
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> Tutkowski"
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> <
>> mike.tutkowski@solidfire.com>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Hey Marcus,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> So, I went back to the
>> branch
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> of mine that has your
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> code
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> and
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> mine and
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> was able to create a new
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> CloudStack install from
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> scratch
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> with it
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> (once
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> again, after manually
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> deleting what was in
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> /var/lib/libvirt/images to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> get system VMs to start).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Anyways, my system VMs are
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> running now and I tried to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> kick off a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> VM
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> using the CentOS 6.3 image
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> you provided me a while
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> back.
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> The virtual router has a
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Status of Running;
>> however,
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> my
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> VM fails
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> to
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> start (with the generic
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> message of Insufficient
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Capacity).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> I've not seen this
>> exception
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> before (related to the
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> VR).
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Do you
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> have
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> any insight into this?:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.exception.ResourceUnavailableException:
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Resource
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> [Pod:1] is
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> unreachable: Unable to
>> apply
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> userdata and password
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> entry
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> on
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> router
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3793)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyUserData(VirtualNetworkApplianceManagerImpl.java:3017)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.network.element.VirtualRouterElement.addPasswordAndUserdata(VirtualRouterElement.java:933)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1172)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1288)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1224)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:826)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:508)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> java.util.concurrent.FutureTask.run(FutureTask.java:262)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> at
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> java.lang.Thread.run(Thread.java:724)
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>>> Thanks!
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>>
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> --
>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >>> 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™
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>> --
>> >> >>>>>>>>>>>>>>>>>>> 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™
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> 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>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message