It could be by chance. I've run a bunch of tests, however, and can no longer get it to choose incorrectly. Before, though, it was placing both VMs on the same PS and each should have been on a different one. I can't see anything different in my config then versus now.
I'm still trying to repro now. On Mon, Apr 8, 2013 at 9:18 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > Could it just be that it occasionally chooses the right storage by chance? > On Apr 8, 2013 8:36 PM, "Prachi Damle" <prachi.da...@citrix.com> wrote: > > > If you are seeing the tags honored sometimes then I guess this might be > > related to ordering of allocators. > > > > Kelven, is your fix to maintain the order in which allocators are loaded, > > in 4.1 as well? > > > > Prachi > > > > > > On Apr 8, 2013, at 6:45 PM, "Mike Tutkowski" < > mike.tutkow...@solidfire.com> > > wrote: > > > > > Yeah, that dawned on me later, Marcus. :) I updated the Bug a couple > > hours > > > ago to note that it might have been due to lack of memory (I had > > mentioned > > > this issue in the Bug). That certainly is likely, in fact, since I'm > > > running two XenServers in VMs on my laptop. :) It just didn't click > right > > > away that capacity might not be related to storage space. > > > > > > The main issue of the Bug is that the storage tags doesn't seem to be > > > honored (although, as I run and re-run my tests, several times it is > > > honored...I'm not seeing a pattern to it, though). > > > > > > > > > On Mon, Apr 8, 2013 at 7:36 PM, Marcus Sorensen <shadow...@gmail.com> > > wrote: > > > > > >> By the way, the insufficient capacity in itself may not indicate > storage > > >> space. It could be lack of memory or CPU as well. > > >> On Apr 8, 2013 2:48 PM, "Mike Tutkowski" < > mike.tutkow...@solidfire.com> > > >> wrote: > > >> > > >>> I went ahead and logged Bug 1971 for this issue. > > >>> > > >>> Currently I cannot get the system to deploy to the correct primary > > >> storage > > >>> and it claims to run out of space when deploying a third VM: > > >>> > > >>> INFO [user.vm.DeployVMCmd] (Job-Executor-19:job-19) > > >>> com.cloud.exception.InsufficientServerCapacityException: Unable to > > >> create a > > >>> deployment for > > >> VM[User|aa33dcdb-792f-4903-86fc-c55802be63c6]Scope=interface > > >>> com.cloud.dc.DataCenter; id=1 > > >>> > > >>> > > >>> On Mon, Apr 8, 2013 at 1:00 PM, Mike Tutkowski < > > >>> mike.tutkow...@solidfire.com > > >>>> wrote: > > >>> > > >>>> Hey guys, > > >>>> > > >>>> In nonossComponentContext.xml.in, I see the following for storage > > >>>> allocators: > > >>>> > > >>>> <!-- > > >>>> > > >>>> Storage pool allocators > > >>>> > > >>>> --> > > >>>> > > >>>> <bean id="LocalStoragePoolAllocator" > > >>>> class="com.cloud.storage.allocator.LocalStoragePoolAllocator"> > > >>>> > > >>>> <property name="name" value="LocalStorage"/> > > >>>> > > >>>> </bean> > > >>>> > > >>>> <bean id="FirstFitStoragePoolAllocator" > > >>>> class="com.cloud.storage.allocator.FirstFitStoragePoolAllocator"> > > >>>> > > >>>> <property name="name" value="Storage"/> > > >>>> > > >>>> </bean> > > >>>> > > >>>> > > >>>> On Mon, Apr 8, 2013 at 12:52 PM, Mike Tutkowski < > > >>>> mike.tutkow...@solidfire.com> wrote: > > >>>> > > >>>>> Actually, now that I know to look for "componentContext.xml" and > not > > >>>>> "components.xml," I found this page: > > >> > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+Spring+in+CloudStack > > >>>>> > > >>>>> > > >>>>> On Mon, Apr 8, 2013 at 12:39 PM, Mike Tutkowski < > > >>>>> mike.tutkow...@solidfire.com> wrote: > > >>>>> > > >>>>>> I wrote that last filename incorrect (I meant one > > >>>>>> nonossComponentContext.xml.in). > > >>>>>> > > >>>>>> > > >>>>>> On Mon, Apr 8, 2013 at 12:37 PM, Mike Tutkowski < > > >>>>>> mike.tutkow...@solidfire.com> wrote: > > >>>>>> > > >>>>>>> Thanks, guys! > > >>>>>>> > > >>>>>>> I do see componentContext.xml. > > >>>>>>> > > >>>>>>> Not to be too much of a pain here :) (I looked for this on the > Wiki > > >>> and > > >>>>>>> couldn't find relevant info), but I have three > componentContext.xml > > >>> files, > > >>>>>>> one componentContext.xml.in file, three > nonossComponentContext.xml > > >>>>>>> files, and one nonComponentContext.xml.in file. > > >>>>>>> > > >>>>>>> I am running with -Dnonoss. Do I need to modify all of the ones > > >> that > > >>>>>>> start with nonoss (I suspect not)? > > >>>>>>> > > >>>>>>> Thanks for your time!! > > >>>>>>> > > >>>>>>> > > >>>>>>> On Mon, Apr 8, 2013 at 12:29 PM, Chip Childers < > > >>>>>>> chip.child...@sungard.com> wrote: > > >>>>>>> > > >>>>>>>> On Mon, Apr 08, 2013 at 12:19:48PM -0600, Mike Tutkowski wrote: > > >>>>>>>>> FYI that the closest I find are both called > > >>> migration-components.xml > > >>>>>>>> (2 of > > >>>>>>>>> them). > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Mon, Apr 8, 2013 at 12:09 PM, Mike Tutkowski < > > >>>>>>>>> mike.tutkow...@solidfire.com> wrote: > > >>>>>>>>> > > >>>>>>>>>> Hi, > > >>>>>>>>>> > > >>>>>>>>>> I've never modified this file before and even seem to be > having > > >>>>>>>> trouble > > >>>>>>>>>> finding it. I can't find component.xml (singular) or > > >>>>>>>> components.xml > > >>>>>>>>>> (plural). > > >>>>>>>>>> > > >>>>>>>>>> Can you tell me where this file should be located (I'm running > > >>> the > > >>>>>>>>>> software from compiled source)? > > >>>>>>>>>> > > >>>>>>>>>> Thanks! > > >>>>>>>> > > >>>>>>>> componentContext.xml or nonossComponentContext.xml > > >>>>>>>> > > >>>>>>>> I have copies here: > > >>>>>>>> > > >>>>>>>> find . -iname '*componentcontext.xml' > > >> > > > ./client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/componentContext.xml > > >> > > > ./client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/nonossComponentContext.xml > > >> ./client/target/generated-webapp/WEB-INF/classes/componentContext.xml > > >> > > > ./client/target/generated-webapp/WEB-INF/classes/nonossComponentContext.xml > > >>>>>>>> ./client/target/conf/componentContext.xml > > >>>>>>>> ./client/target/conf/nonossComponentContext.xml > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -- > > >>>>>>> *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> > > >>>>>> *™* > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> *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> > > >>>> *™* > > >>> > > >>> > > >>> > > >>> -- > > >>> *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> > > > *™* > > > -- *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> *™*
