Actually, I see why now.  This code that deletes storage pool used to
be in LibvirtComputingResource.java, named cleanupDisk. It was only
ever called for isos, because we only had Libvirt Storage. Now,
cleanupDisk is called for everything, so that other storage adaptors
can do their cleanup, but LibvirtStorageAdaptor isn't filtering for
isos like it should. The fix will be to detect iso in
LibvirtStorageAdaptor's disconnectPhysicalDiskByPath and only execute
on that.


On Thu, Dec 26, 2013 at 10:49 PM, Marcus Sorensen <shadow...@gmail.com> wrote:
> My notes from the initial version of the patch with instructions read:
>
> LibvirtStorageAdaptor: need to implement dummy
> connectPhysicalDisk/disconnectPhysicalDisk
>
> I must have missed during review that the final implementation
> actually did something.
>
> On Thu, Dec 26, 2013 at 10:47 PM, Marcus Sorensen <shadow...@gmail.com> wrote:
>> Yes, this should be a noop for LibvirtStorageAdaptor. I'm not sure why
>> we decided to delete the pool.
>>
>> On Thu, Dec 19, 2013 at 6:05 PM, Mike Tutkowski
>> <mike.tutkow...@solidfire.com> wrote:
>>> I updated the CRs and assigned them to Marcus.
>>>
>>> Since the issues are not related to the new iSCSI code specifically, I
>>> think Marcus will have a good idea what's going on there.
>>>
>>> In any event, if I can be of assistance, please let me know.
>>>
>>> Thanks
>>>
>>>
>>> On Thu, Dec 19, 2013 at 12:21 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
>>>> Interesting...that commit was a combination of Marcus' and my code. We
>>>> might want to bring him in on this conversation.
>>>>
>>>> I believe the idea is when a VM is stopped that we want to remove, for
>>>> example, its iSCSI connections to its data disks (just using iSCSI as an
>>>> example here). This is similar (but not the same of course) to how we
>>>> disconnect a VBD from a VDI for a VM when the VM is stopped. When the VM is
>>>> restarted, we create a new VBD and connect the VDI to the VM through it
>>>> (and there is an analogous process that LibvirtStorageAdaptor does during
>>>> VM start).
>>>>
>>>>
>>>> On Thu, Dec 19, 2013 at 12:08 PM, Edison Su <edison...@citrix.com> wrote:
>>>>
>>>>>  Hi Mike,
>>>>>
>>>>>    I looked at your commit: 858ce766659101eb731c83c806892dd5d9baa976,
>>>>> seems it will  try to delete primary storage every time when stopping a VM
>>>>> ,which maybe the root cause a kvm blocker bug: CLOUDSTACK-5432, KVM guest
>>>>> vms are crashed during the automation test. From the agent log, I find a
>>>>> lot of “umount ” primary storage error.
>>>>>
>>>>>   In 4.2, we never do that kind of operation. Do you know why we add it
>>>>> in 4.3? I am referring to the code in :
>>>>>
>>>>>
>>>>>
>>>>> disconnectPhysicalDiskByPath in LibvirtStorageAdaptor
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *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>
>>> *™*

Reply via email to