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<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>
> *™*
>
