Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of mike.tutkowski@solidfire.com
 designates 209.85.219.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALFpzo5rMiXCps9VQLL9KmcxcUx7kHJy23DEgg3Xn2s_FAJQtQ@mail.gmail.com>
References: 
 <CACOnxCjSfEpC1OwpBed4GiD-2bmUxP7omP9404rquGUo2mFj7g@mail.gmail.com>
	<CEF4C222.33B52%nitin.mehta@citrix.com>
	<CALFpzo5rMiXCps9VQLL9KmcxcUx7kHJy23DEgg3Xn2s_FAJQtQ@mail.gmail.com>
Date: Thu, 9 Jan 2014 22:53:19 -0700
Message-ID: 
 <CACOnxCjmvjut-e5judzU6EzpdMU2r5G3sbPZggKjpD0Kr0wbcQ@mail.gmail.com>
Subject: Re: deployVm with data disk
From: Mike Tutkowski <mike.tutkowski@solidfire.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=001a11c30ce2d6364104ef97577e

--001a11c30ce2d6364104ef97577e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Now that you mention it, I think CS does get confused about this. I may
have seen this last week.

The way it works (depending on if you're using an ISO or a template), CS
acts in a non-intuitive way. In one case (I can't remember if this is for
ISOs or templates), you pick a Compute Offering and a Disk Offering, but
the Compute Offering is really only used for non-storage parameters whereas
the Disk Offering is used to determine how large to make the disk, etc. If
the storage tags are the same (for the CO and DO), it works; otherwise, it
doesn't.

I believe I wrote a note to myself to log a bug for this. It appears you've
stumbled upon it, though, already.


On Thu, Jan 9, 2014 at 10:45 PM, Marcus Sorensen <shadowsor@gmail.com>wrote=
:

> No, we have two primary storages, one tagged "foo", one tagged "bar".
> We have two disk offerings implementing these. We can verify that data
> disks deploy properly to both. Then we have a service offering with
> storage tag "foo". We can deploy a VM with a data disk tagged "foo"
> but not one named "bar". It's as if the deploy command sees a conflict
> between storage tags. According to the logs it doesn't even find a
> storage pool to try, but if we deploy the offering without a data disk
> it works fine.
>
> I spent a little while this evening trying to unravel how the
> allocators and deployment planner work, but really at this point all I
> have is the behavior, and it seems to indicate that one cannot deploy
> a service offering with a data disk that has a non-matching tag.
>
> On Thu, Jan 9, 2014 at 10:19 PM, Nitin Mehta <Nitin.Mehta@citrix.com>
> wrote:
> > In addition, do check if there are at least 1 PS for each of the tags i=
n
> > the same cluster.
> > Pasting the snippet of logs with failure would help. (But do paste the
> > entire snippet for vm deployment)
> >
> >
> > On 09/01/14 8:14 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
> wrote:
> >
> >>Are you saying there was no primary storage tagged "bar"?
> >>
> >>If that is the case, I guess I would expect the deployment of the VM to
> >>fail because not all of the criteria could be met.
> >>
> >>
> >>On Thu, Jan 9, 2014 at 7:08 PM, Marcus Sorensen <shadowsor@gmail.com>
> >>wrote:
> >>
> >>> Is this a bug (perhaps fixed), or expected behavior?
> >>>
> >>> If I create a service offering with storage tag=3Dfoo, and a disk
> >>> offering with storage tag=3Dbar, I cannot provide this disk offering =
as
> >>> a data disk to deploy along with this service offering. The root
> >>> volume gets allocated, and then the data disk fails.
> >>>
> >>
> >>
> >>
> >>--
> >>*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=3Dplay>
> >>* *
> >
>


--=20
*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=3Dplay>
*=99*

--001a11c30ce2d6364104ef97577e--