Regarding local storage pool allocator

[Devdeep Singh <de...@citrix.com>]

Hi,

I am looking into an issue where migration of a vm with its volume (storage motion) fails. The root volume of the vm is on local storage. The issue is that when LocalStoragePoolAllocator::select gets called and the hostid is included in the plan, the function ends up returning local storage pools from other hosts in the cluster too. This is happening because we list local storage pools on a host only if the volume type is 'Data'; otherwise we list all the storage pools in the cluster.

<code snippet>
// 4.4-forward branch, ./engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java, Line 76
if (dskCh.getType() == Volume.Type.DATADISK && plan.getHostId() != null) {
</code snippet>

Anyone aware why the check for data disk type was added in the first place? Will it break any scenario if I remove this check?

Regards,
Devdeep

Re: Regarding local storage pool allocator

[Koushik Das <ko...@citrix.com>]

Earlier there was no scenarios where deployment plan had host id specified for a ROOT disk. If new scenarios like storage migration needs them, the condition can be relaxed to remove data disk type check.

On 28-May-2014, at 2:18 PM, Wido den Hollander <wi...@widodh.nl> wrote:

> 
> 
> On 05/28/2014 10:20 AM, Devdeep Singh wrote:
>> Hi,
>> 
>> I am looking into an issue where migration of a vm with its volume (storage motion) fails. The root volume of the vm is on local storage. The issue is that when LocalStoragePoolAllocator::select gets called and the hostid is included in the plan, the function ends up returning local storage pools from other hosts in the cluster too. This is happening because we list local storage pools on a host only if the volume type is 'Data'; otherwise we list all the storage pools in the cluster.
>> 
>> <code snippet>
>> // 4.4-forward branch, ./engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java, Line 76
>> if (dskCh.getType() == Volume.Type.DATADISK && plan.getHostId() != null) {
>> </code snippet>
>> 
>> Anyone aware why the check for data disk type was added in the first place? Will it break any scenario if I remove this check?
> 
> Looking at it this seems like a bug to me. A ROOT or DATA volume is bound to the host where it's stored on. So there is no difference between ROOT and DATA.
> 
> Wido
> 
>> 
>> Regards,
>> Devdeep
>> 

Re: Regarding local storage pool allocator

[Wido den Hollander <wi...@widodh.nl>]

On 05/28/2014 10:20 AM, Devdeep Singh wrote:
> Hi,
>
> I am looking into an issue where migration of a vm with its volume (storage motion) fails. The root volume of the vm is on local storage. The issue is that when LocalStoragePoolAllocator::select gets called and the hostid is included in the plan, the function ends up returning local storage pools from other hosts in the cluster too. This is happening because we list local storage pools on a host only if the volume type is 'Data'; otherwise we list all the storage pools in the cluster.
>
> <code snippet>
> // 4.4-forward branch, ./engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java, Line 76
> if (dskCh.getType() == Volume.Type.DATADISK && plan.getHostId() != null) {
> </code snippet>
>
> Anyone aware why the check for data disk type was added in the first place? Will it break any scenario if I remove this check?

Looking at it this seems like a bug to me. A ROOT or DATA volume is 
bound to the host where it's stored on. So there is no difference 
between ROOT and DATA.

Wido

>
> Regards,
> Devdeep
>