Finally got it to happen again. This time two VMs were placed on the same PS instead of each on their own PS.
All appears to be configured properly. This is just a log shot, but could this possibly be happening because the iSCSI targets that are being used for storage repositories are not formatted from scratch each time I use them? Right now I'm just re-using the same 10 iSCSI targets each time I run my tests. At the end, I delete the VMs, the primary storages, and the compute offerings. The iSCSI targets are then re-used in the next run (the volumes/LUNs these iSCSI targets represent are not deleted and re-created each run). Not sure why that would cause such a problem, but figured I'd throw it out there. In the real world, I'd be creating a new iSCSI target before running the rest of my code. On Mon, Apr 8, 2013 at 10:39 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > 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> > *™* > -- *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> *™*
