cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: VM deployed to wrong storage repository
Date Sun, 07 Apr 2013 06:38:50 GMT
If someone would like me to demo this problem, please let me know.

I noticed it while writing code that makes use of the 4.1 API.

I assumed at first I had done something wrong, so I tried it manually using
the wizard in the GUI and noticed the same behavior:  CloudStack was not
always honoring my storage tags (and it was easy to reproduce the problem).


On Sun, Apr 7, 2013 at 12:25 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Hi,
>
> I'm currently using 4.1 (from like a week or so ago).
>
> I have three tiers of shared, iSCSI-based storage represented in three
> storage repositories in XenServer:
>
> SR_2
> SR_3
> SR_4
>
> SR_2 maps into CS via primary storage PS_2, which has the storage tag PS_2
> SR_3 maps into CS via primary storage PS_3, which has the storage tag PS_3
> SR_4 maps into CS via primary storage PS_4, which has the storage tag PS_4
>
> I have three compute offerings:
>
> CO_2, which only uses storage tag PS_2
> CO_3, which only uses storage tag PS_3
> CO_4, which only uses storage tag PS_4
>
> I walk through the wizard and select CO_3.  My VM ends up on SR_4.
>
> I have double checked the relationships and don't see any errors in how I
> have CS configured.
>
> Does anyone know of this being noted as a current bug?
>
> Thanks!
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message