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 <w...@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
>>
