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 <shadow...@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.tutkow...@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 <shadow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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 < >>>>>>>>>>> shadow...@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.tutkow...@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.tutkow...@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 < >>>>>>>>>>>> shadow...@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.tutkow...@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.tutkow...@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 < >>>>>>>>>>>> shadow...@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.tutkow...@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.tutkow...@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 >>>>>>>>>>>> >>> >>>>> <shadow...@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.tutkow...@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 >>>>>>>>>>>> >>> >>>>>> > <shadow...@gmail.com> >>>>>>>>>>>> >>> >>>>>> > wrote: >>>>>>>>>>>> >>> >>>>>> >> >>>>>>>>>>>> >>> >>>>>> >> That's right. All should be well. >>>>>>>>>>>> >>> >>>>>> >> >>>>>>>>>>>> >>> >>>>>> >> On Oct 22, 2013 6:03 PM, "Mike Tutkowski" >>>>>>>>>>>> >>> >>>>>> >> <mike.tutkow...@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.tutkow...@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.tutkow...@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 >>>>>>>>>>>> >>> >>>>>> >>>>> <shadow...@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.tutkow...@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.tutkow...@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.tutkow...@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 >>>>>>>>>>>> >>> >>>>>> >>>>>> >>> <shadow...@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.tutkow...@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.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> >>>>>> >>> o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> >>>>>> >>> Advancing the way the world uses the >>>>>>>>>>>> cloud™ >>>>>>>>>>>> >>> >>>>>> >>>>>> >> >>>>>>>>>>>> >>> >>>>>> >>>>>> >> >>>>>>>>>>>> >>> >>>>>> >>>>>> >> >>>>>>>>>>>> >>> >>>>>> >>>>>> >> >>>>>>>>>>>> >>> >>>>>> >>>>>> >> -- >>>>>>>>>>>> >>> >>>>>> >>>>>> >> Mike Tutkowski >>>>>>>>>>>> >>> >>>>>> >>>>>> >> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>>> >>>>>> >> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> >>>>>> >> o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> >>>>>> >> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>>>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> >>>>>> > -- >>>>>>>>>>>> >>> >>>>>> >>>>>> > Mike Tutkowski >>>>>>>>>>>> >>> >>>>>> >>>>>> > Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>>> >>>>>> > e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> >>>>>> > o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> >>>>>> > Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>>>> >>>>> >>>>>>>>>>>> >>> >>>>>> >>>>> >>>>>>>>>>>> >>> >>>>>> >>>>> >>>>>>>>>>>> >>> >>>>>> >>>>> >>>>>>>>>>>> >>> >>>>>> >>>>> -- >>>>>>>>>>>> >>> >>>>>> >>>>> Mike Tutkowski >>>>>>>>>>>> >>> >>>>>> >>>>> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>>> >>>>> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> >>>>> o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> >>>>> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>>>> >>>> >>>>>>>>>>>> >>> >>>>>> >>>> >>>>>>>>>>>> >>> >>>>>> >>>> >>>>>>>>>>>> >>> >>>>>> >>>> >>>>>>>>>>>> >>> >>>>>> >>>> -- >>>>>>>>>>>> >>> >>>>>> >>>> Mike Tutkowski >>>>>>>>>>>> >>> >>>>>> >>>> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>>> >>>> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> >>>> o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> >>>> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>>>> >>> >>>>>>>>>>>> >>> >>>>>> >>> >>>>>>>>>>>> >>> >>>>>> >>> >>>>>>>>>>>> >>> >>>>>> >>> >>>>>>>>>>>> >>> >>>>>> >>> -- >>>>>>>>>>>> >>> >>>>>> >>> Mike Tutkowski >>>>>>>>>>>> >>> >>>>>> >>> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>>> >>> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> >>> o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> >>> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> > >>>>>>>>>>>> >>> >>>>>> > -- >>>>>>>>>>>> >>> >>>>>> > Mike Tutkowski >>>>>>>>>>>> >>> >>>>>> > Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>>> > e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>>> > o: 303.746.7302 >>>>>>>>>>>> >>> >>>>>> > Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>>> >>>>>>>>>>>> >>> >>>>> >>>>>>>>>>>> >>> >>>>> >>>>>>>>>>>> >>> >>>>> >>>>>>>>>>>> >>> >>>>> -- >>>>>>>>>>>> >>> >>>>> Mike Tutkowski >>>>>>>>>>>> >>> >>>>> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>>> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>>> o: 303.746.7302 >>>>>>>>>>>> >>> >>>>> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >>>> >>>>>>>>>>>> >>> >>>> >>>>>>>>>>>> >>> >>>> >>>>>>>>>>>> >>> >>>> >>>>>>>>>>>> >>> >>>> -- >>>>>>>>>>>> >>> >>>> Mike Tutkowski >>>>>>>>>>>> >>> >>>> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >>>> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >>>> o: 303.746.7302 >>>>>>>>>>>> >>> >>>> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> >> >>>>>>>>>>>> >>> >> >>>>>>>>>>>> >>> >> >>>>>>>>>>>> >>> >> >>>>>>>>>>>> >>> >> -- >>>>>>>>>>>> >>> >> Mike Tutkowski >>>>>>>>>>>> >>> >> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> >> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> >> o: 303.746.7302 >>>>>>>>>>>> >>> >> Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > -- >>>>>>>>>>>> >>> > Mike Tutkowski >>>>>>>>>>>> >>> > Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >>> > e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >>> > o: 303.746.7302 >>>>>>>>>>>> >>> > Advancing the way the world uses the cloud™ >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> -- >>>>>>>>>>>> >> Mike Tutkowski >>>>>>>>>>>> >> Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> >> e: mike.tutkow...@solidfire.com >>>>>>>>>>>> >> o: 303.746.7302 >>>>>>>>>>>> >> Advancing the way the world uses the cloud™ >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > -- >>>>>>>>>>>> > Mike Tutkowski >>>>>>>>>>>> > Senior CloudStack Developer, SolidFire Inc. >>>>>>>>>>>> > e: mike.tutkow...@solidfire.com >>>>>>>>>>>> > o: 303.746.7302 >>>>>>>>>>>> > Advancing the way the world uses the cloud™ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Mike Tutkowski* >>>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>>>>>>> e: mike.tutkow...@solidfire.com >>>>>>>>>>> o: 303.746.7302 >>>>>>>>>>> Advancing the way the world uses the >>>>>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play> >>>>>>>>>>> *™* >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Mike Tutkowski* >>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>>>>>> e: mike.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*