I'm not that familiar with this part of the codebase, but the code in the "Stopped" if block looks incorrect when it assigns to proxy instead of doing a return.
Thoughts? @Override public ConsoleProxyVO startProxy(long proxyVmId) { try { ConsoleProxyVO proxy = _consoleProxyDao.findById(proxyVmId); if (proxy.getState() == VirtualMachine.State.Running) { return proxy; } String restart = _configDao.getValue(Config.ConsoleProxyRestart .key()); if (restart != null && restart.equalsIgnoreCase("false")) { return null; } if (proxy.getState() == VirtualMachine.State.Stopped) { _itMgr.advanceStart(proxy.getUuid(), null, null); proxy = _consoleProxyDao.findById(proxy.getId()); } // For VMs that are in Stopping, Starting, Migrating state, let client to wait by returning null // as sooner or later, Starting/Migrating state will be transited to Running and Stopping will be transited // to // Stopped to allow // Starting of it s_logger.warn("Console proxy is not in correct state to be started: " + proxy.getState()); return null; } catch (StorageUnavailableException e) { s_logger.warn("Exception while trying to start console proxy", e); return null; } catch (InsufficientCapacityException e) { s_logger.warn("Exception while trying to start console proxy", e); return null; } catch (ResourceUnavailableException e) { s_logger.warn("Exception while trying to start console proxy", e); return null; } catch (ConcurrentOperationException e) { s_logger.warn("Runtime Exception while trying to start console proxy", e); return null; } catch (CloudRuntimeException e) { s_logger.warn("Runtime Exception while trying to start console proxy", e); return null; } catch (OperationTimedoutException e) { s_logger.warn("Runtime Exception while trying to start console proxy", e); return null; } } On Thu, Jan 2, 2014 at 12:48 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > I did notice one issue, but I don't think it's the cause because after > correcting it the system VMs still do not start. > > In the wizard, I said I wanted to use local storage; however, I see the > system.vm.use.local.storage property was still false after my cloud was > created. I changed it to true and re-started the CS MS, but now I get an > exception and still no system VMs start: > > ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-9:ctx-5a124def) > Unexpected exception > java.lang.NullPointerException > at > com.google.gson.JsonPrimitive.isPrimitiveOrString(JsonPrimitive.java:316) > at com.google.gson.JsonPrimitive.setValue(JsonPrimitive.java:97) > at com.google.gson.JsonPrimitive.<init>(JsonPrimitive.java:67) > at > org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper$ThrowableTypeAdapter.serialize(JobSerializerHelper.java:195) > at > org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper$ThrowableTypeAdapter.serialize(JobSerializerHelper.java:158) > at > com.google.gson.JsonSerializationVisitor.findAndInvokeCustomSerializer(JsonSerializationVisitor.java:184) > at > com.google.gson.JsonSerializationVisitor.visitFieldUsingCustomHandler(JsonSerializationVisitor.java:204) > at > com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63) > at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120) > at > com.google.gson.JsonSerializationContextDefault.serialize(JsonSerializationContextDefault.java:62) > at > com.google.gson.JsonSerializationContextDefault.serialize(JsonSerializationContextDefault.java:53) > at com.google.gson.Gson.toJsonTree(Gson.java:220) > at com.google.gson.Gson.toJson(Gson.java:260) > at com.google.gson.Gson.toJson(Gson.java:240) > at > org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.toSerializedString(JobSerializerHelper.java:65) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:105) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:522) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:679) > > > > On Thu, Jan 2, 2014 at 12:40 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Cool...sounds good >> >> Does anyone have any thoughts on the system VM issue (with them not >> starting on Xen or KVM)? >> >> Console proxy is not in correct state to be started: Stopped >> >> >> On Thu, Jan 2, 2014 at 12:35 PM, Daan Hoogland >> <daan.hoogl...@gmail.com>wrote: >> >>> hey guys, >>> >>> have been sick in bed all day, sorry to react slowly. I saw your >>> explanation Marcus and I should check for the case that only one of >>> the two is null and return false. >>> I will update and if you haven't already I will put in a fix. >>> >>> regards, >>> Daan >>> >>> On Thu, Jan 2, 2014 at 8:55 AM, Marcus Sorensen <shadow...@gmail.com> >>> wrote: >>> > There are some other issues near that commit as well. A fix for >>> > CLOUDSTACK-5502 that makes 'untagged' invalid needs to be backed out. >>> > >>> > >>> > >>> > On Thu, Jan 2, 2014 at 12:14 AM, Mike Tutkowski >>> > <mike.tutkow...@solidfire.com> wrote: >>> >> Yeah, this does appear to be a bug. >>> >> >>> >> I re-ran the attempted creation of my CloudStack cloud with a >>> different >>> >> XenServer host and was left in the same state (NPE). >>> >> >>> >> I plan to try this with KVM tomorrow (er, later today, I guess). >>> >> >>> >> >>> >> On Wed, Jan 1, 2014 at 11:10 PM, Mike Tutkowski < >>> >> mike.tutkow...@solidfire.com> wrote: >>> >> >>> >>> Looks like Daan added the method: >>> >>> >>> >>> >>> >>> >>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=utils/src/com/cloud/utils/net/NetUtils.java;h=a315b935495469648a0a82a25c39c9c53f0226f6;hp=11a483c3f7e420056dce7893a86946de5c40e244;hb=94abbb1367bc817bae98f369e78679f0ddb7727f;hpb=6897984970df1455fa1ee0490157758ccfb68cff >>> >>> >>> >>> >>> >>> On Wed, Jan 1, 2014 at 10:33 PM, Mike Tutkowski < >>> >>> mike.tutkow...@solidfire.com> wrote: >>> >>> >>> >>>> OK, thanks! >>> >>>> >>> >>>> >>> >>>> On Wed, Jan 1, 2014 at 10:32 PM, Marcus Sorensen < >>> shadow...@gmail.com>wrote: >>> >>>> >>> >>>>> git blame will show you the commit and committer. >>> >>>>> >>> >>>>> On Wed, Jan 1, 2014 at 10:19 PM, Mike Tutkowski >>> >>>>> <mike.tutkow...@solidfire.com> wrote: >>> >>>>> > Yeah, but I wasn't sure of the coder's intend and if your >>> replacement >>> >>>>> code >>> >>>>> > meet their expectations, so I didn't change it. I was hoping >>> someone >>> >>>>> would >>> >>>>> > claim the code and chime in. :) >>> >>>>> > >>> >>>>> > >>> >>>>> > On Wed, Jan 1, 2014 at 10:16 PM, Marcus Sorensen < >>> shadow...@gmail.com >>> >>>>> >wrote: >>> >>>>> > >>> >>>>> >> Yeah, it would be clearer if they were checked separately: >>> >>>>> >> >>> >>>>> >> if (one == null || one.isEmpty()) { >>> >>>>> >> return true; >>> >>>>> >> } else if ( other == null || other.isEmpty()) [ >>> >>>>> >> return true; >>> >>>>> >> } >>> >>>>> >> >>> >>>>> >> or something like that. >>> >>>>> >> >>> >>>>> >> On Wed, Jan 1, 2014 at 10:00 PM, Mike Tutkowski >>> >>>>> >> <mike.tutkow...@solidfire.com> wrote: >>> >>>>> >> > I should say this check doesn't have to catch it...it might, >>> but it >>> >>>>> >> doesn't >>> >>>>> >> > have to (depends on the value of one). >>> >>>>> >> > >>> >>>>> >> > >>> >>>>> >> > On Wed, Jan 1, 2014 at 9:59 PM, Mike Tutkowski < >>> >>>>> >> mike.tutkow...@solidfire.com >>> >>>>> >> >> wrote: >>> >>>>> >> > >>> >>>>> >> >> Yeah, in my case I'm just setting up a basic zone with a >>> XenServer >>> >>>>> host. >>> >>>>> >> >> >>> >>>>> >> >> The code in NetUtils checks for null or "" on the variable in >>> >>>>> question >>> >>>>> >> >> that's passed in. However, in a certain case, null for that >>> >>>>> variable can >>> >>>>> >> >> slip by and lead to a NPE. >>> >>>>> >> >> >>> >>>>> >> >> if ((one == null || one.equals("")) >>> >>>>> >> >> >>> >>>>> >> >> && >>> >>>>> >> >> >>> >>>>> >> >> (other == null || other.equals(""))) >>> >>>>> >> >> >>> >>>>> >> >> { >>> >>>>> >> >> >>> >>>>> >> >> return true; >>> >>>>> >> >> >>> >>>>> >> >> } >>> >>>>> >> >> >>> >>>>> >> >> if other == null, this will not catch it and it can throw a >>> NPE >>> >>>>> later. >>> >>>>> >> >> >>> >>>>> >> >> >>> >>>>> >> >> On Wed, Jan 1, 2014 at 9:51 PM, Marcus Sorensen < >>> >>>>> shadow...@gmail.com >>> >>>>> >> >wrote: >>> >>>>> >> >> >>> >>>>> >> >>> You can do "git blame (file)" and it will show you each >>> line and >>> >>>>> the >>> >>>>> >> >>> commit. You can also do a git log on the file. The issue >>> may not >>> >>>>> be as >>> >>>>> >> >>> obvious as that, though, there may be something totally >>> unrelated >>> >>>>> >> causing >>> >>>>> >> >>> that object to end up null in this code. Or it may be >>> specific to >>> >>>>> your >>> >>>>> >> >>> setup, some obscure bug nobody else is hitting. >>> >>>>> >> >>> On Jan 1, 2014 4:22 PM, "Mike Tutkowski" < >>> >>>>> mike.tutkow...@solidfire.com >>> >>>>> >> > >>> >>>>> >> >>> wrote: >>> >>>>> >> >>> >>> >>>>> >> >>> > This is in 4.3. >>> >>>>> >> >>> > >>> >>>>> >> >>> > I know the file is NetUtils, but I'm not sure in Git how >>> to >>> >>>>> look at >>> >>>>> >> the >>> >>>>> >> >>> > history of a particular file like I could do in SVN. >>> >>>>> >> >>> > >>> >>>>> >> >>> > >>> >>>>> >> >>> > On Wed, Jan 1, 2014 at 3:55 PM, Marcus Sorensen < >>> >>>>> shadow...@gmail.com >>> >>>>> >> > >>> >>>>> >> >>> > wrote: >>> >>>>> >> >>> > >>> >>>>> >> >>> > > Which branch? I see these in master, you can check out >>> the >>> >>>>> commit >>> >>>>> >> just >>> >>>>> >> >>> > > before these and see if it helps: >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > commit b477e4e830597100f0c0171dd8e56f4033bd07aa >>> >>>>> >> >>> > > Author: Daan Hoogland <dhoogl...@schubergphilis.com> >>> >>>>> >> >>> > > Date: Tue Dec 31 12:52:51 2013 +0100 >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > some xtra cases >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > commit 2cf356e047e26977c1d294fafc57e986c04fc5f4 >>> >>>>> >> >>> > > Author: Daan Hoogland <dhoogl...@schubergphilis.com> >>> >>>>> >> >>> > > Date: Tue Dec 31 12:25:17 2013 +0100 >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > isSameIsolationId >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > commit 04570eefed9a0ee1eca1fd700ed5732ba67150ce >>> >>>>> >> >>> > > Author: Daan Hoogland <d...@onecht.net> >>> >>>>> >> >>> > > Date: Fri Dec 20 16:47:58 2013 +0100 >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > check vlans and other isolation types >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > commit d50517e931e68daef6735bd18273499fee0d4649 >>> >>>>> >> >>> > > Author: Sateesh Chodapuneedi <sate...@apache.org> >>> >>>>> >> >>> > > Date: Tue Dec 31 07:16:35 2013 +0530 >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > I also have a commit just after these, but it was pretty >>> >>>>> minor and >>> >>>>> >> >>> > > only to KVM agent code. >>> >>>>> >> >>> > > >>> >>>>> >> >>> > > On Wed, Jan 1, 2014 at 3:27 PM, Mike Tutkowski >>> >>>>> >> >>> > > <mike.tutkow...@solidfire.com> wrote: >>> >>>>> >> >>> > > > Hey guys, >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > The NPE I saw last night was related to "isolation >>> id." Is >>> >>>>> it >>> >>>>> >> >>> possible >>> >>>>> >> >>> > > this >>> >>>>> >> >>> > > > NPE is related to something new that was put that you >>> are >>> >>>>> talking >>> >>>>> >> >>> about >>> >>>>> >> >>> > > > here? >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > Thank! >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > ERROR [c.c.a.ApiServer] (1583467451@qtp-185135566-2 >>> >>>>> :ctx-ae5d80b2 >>> >>>>> >> >>> > > > ctx-5c12c4d9) unhandled exception executing api >>> command: >>> >>>>> >> >>> > > createVlanIpRange >>> >>>>> >> >>> > > > java.lang.NullPointerException >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > >>> >>>>> com.cloud.utils.net.NetUtils.isSameIsolationId(NetUtils.java:1419) >>> >>>>> >> >>> > > > at >>> com.cloud.configuration.ConfigurationManagerImpl. >>> >>>>> >> >>> > > > >>> >>>>> createVlanAndPublicIpRange(ConfigurationManagerImpl.java:2474) >>> >>>>> >> >>> > > > at >>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >>>>> >> Method) >>> >>>>> >> >>> > > > at sun.reflect.NativeMethodAccessorImpl.invoke( >>> >>>>> >> >>> > > > NativeMethodAccessorImpl.java:57) >>> >>>>> >> >>> > > > at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke( >>> >>>>> >> >>> > > > DelegatingMethodAccessorImpl.java:43) >>> >>>>> >> >>> > > > at >>> java.lang.reflect.Method.invoke(Method.java:616) >>> >>>>> >> >>> > > > at org.springframework.aop.support.AopUtils. >>> >>>>> >> >>> > > > invokeJoinpointUsingReflection(AopUtils.java:317) >>> >>>>> >> >>> > > > at >>> >>>>> >> org.springframework.aop.framework.ReflectiveMethodInvocation. >>> >>>>> >> >>> > > > invokeJoinpoint(ReflectiveMethodInvocation.java:183) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > > >>> >>>>> >> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>> >>>>> >> >>> > > > ReflectiveMethodInvocation.java:150) >>> >>>>> >> >>> > > > at com.cloud.event.ActionEventInterceptor.invoke( >>> >>>>> >> >>> > > > ActionEventInterceptor.java:50) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > > >>> >>>>> >> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>> >>>>> >> >>> > > > ReflectiveMethodInvocation.java:161) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> >>> org.springframework.aop.interceptor.ExposeInvocationInterceptor. >>> >>>>> >> >>> > > > invoke(ExposeInvocationInterceptor.java:91) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > > >>> >>>>> >> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>> >>>>> >> >>> > > > ReflectiveMethodInvocation.java:172) >>> >>>>> >> >>> > > > at >>> org.springframework.aop.framework.JdkDynamicAopProxy. >>> >>>>> >> >>> > > > invoke(JdkDynamicAopProxy.java:204) >>> >>>>> >> >>> > > > at >>> sun.proxy.$Proxy96.createVlanAndPublicIpRange(Unknown >>> >>>>> >> Source) >>> >>>>> >> >>> > > > at org.apache.cloudstack.api.command.admin.vlan. >>> >>>>> >> >>> > > > >>> CreateVlanIpRangeCmd.execute(CreateVlanIpRangeCmd.java:211) >>> >>>>> >> >>> > > > at >>> >>>>> >> com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) >>> >>>>> >> >>> > > > at >>> >>>>> com.cloud.api.ApiServer.queueCommand(ApiServer.java:530) >>> >>>>> >> >>> > > > at >>> >>>>> com.cloud.api.ApiServer.handleRequest(ApiServer.java:373) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > > >>> >>>>> >> >>> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) >>> >>>>> >> >>> > > > at >>> >>>>> com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) >>> >>>>> >> >>> > > > at >>> com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) >>> >>>>> >> >>> > > > at org.apache.cloudstack.managed.context.impl. >>> >>>>> >> >>> > > > >>> DefaultManagedContext$1.call(DefaultManagedContext.java:56) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > >>> >>>>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext. >>> >>>>> >> >>> > > > callWithContext(DefaultManagedContext.java:103) >>> >>>>> >> >>> > > > at >>> >>>>> >> >>> > >>> >>>>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext. >>> >>>>> >> >>> > > > runWithContext(DefaultManagedContext.java:53) >>> >>>>> >> >>> > > > at >>> >>>>> >> com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > On Wed, Jan 1, 2014 at 2:33 PM, Marcus Sorensen < >>> >>>>> >> >>> shadow...@gmail.com> >>> >>>>> >> >>> > > wrote: >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > >> That's just it. The isolation type *is* provided when >>> >>>>> creating >>> >>>>> >> >>> > > >> physical network. If I create a physical network with >>> >>>>> isolation >>> >>>>> >> >>> type >>> >>>>> >> >>> > > >> 'VXLAN', and then add traffic type of 'Public', it >>> doesn't >>> >>>>> obey >>> >>>>> >> it. >>> >>>>> >> >>> > > >> There's physical_networks and networks, when the >>> zone is >>> >>>>> >> created, >>> >>>>> >> >>> an >>> >>>>> >> >>> > > >> entry goes in network that is Public/Vlan, >>> hardcoded. The >>> >>>>> Public >>> >>>>> >> >>> > > >> traffic type uses this, regardless of what the >>> >>>>> physical_network >>> >>>>> >> its >>> >>>>> >> >>> > > >> being added to says. So if we updated the the public >>> >>>>> network >>> >>>>> >> table >>> >>>>> >> >>> row >>> >>>>> >> >>> > > >> with the correct isolation method for that physical >>> >>>>> network we >>> >>>>> >> are >>> >>>>> >> >>> > > >> adding traffic type to when we add the public traffic >>> >>>>> type, that >>> >>>>> >> >>> would >>> >>>>> >> >>> > > >> work. It's worth noting that a zone can only have one >>> >>>>> physical >>> >>>>> >> >>> network >>> >>>>> >> >>> > > >> with traffic type of public. >>> >>>>> >> >>> > > >> >>> >>>>> >> >>> > > >> On Wed, Jan 1, 2014 at 12:37 PM, Daan Hoogland < >>> >>>>> >> >>> > daan.hoogl...@gmail.com >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > >> wrote: >>> >>>>> >> >>> > > >> >> While I've got your attention, what's the deal >>> with >>> >>>>> isolation >>> >>>>> >> >>> > method >>> >>>>> >> >>> > > vs >>> >>>>> >> >>> > > >> broadcast method? These are always set to the same >>> thing >>> >>>>> as far >>> >>>>> >> as >>> >>>>> >> >>> > I've >>> >>>>> >> >>> > > >> seen. >>> >>>>> >> >>> > > >> > >>> >>>>> >> >>> > > >> > I've been asking this but haven't found the answer >>> yet. >>> >>>>> There >>> >>>>> >> is >>> >>>>> >> >>> an >>> >>>>> >> >>> > > >> > overlap but both have some extra values the other >>> hasn't. >>> >>>>> >> >>> > > >> > >>> >>>>> >> >>> > > >> > I don't like either of your solutions but haven't >>> got a >>> >>>>> good >>> >>>>> >> >>> > > >> > alternative. Best would be to be able to set the >>> >>>>> isolation >>> >>>>> >> type >>> >>>>> >> >>> on >>> >>>>> >> >>> > > >> > each physical network on creation. The wizard and >>> zone >>> >>>>> >> creation >>> >>>>> >> >>> api >>> >>>>> >> >>> > > >> > command would have to be extended and allow for >>> vlan as >>> >>>>> >> default. >>> >>>>> >> >>> > > >> > >>> >>>>> >> >>> > > >> > regards, >>> >>>>> >> >>> > > >> > >>> >>>>> >> >>> > > >> > On Wed, Jan 1, 2014 at 8:53 AM, Marcus Sorensen < >>> >>>>> >> >>> > shadow...@gmail.com> >>> >>>>> >> >>> > > >> wrote: >>> >>>>> >> >>> > > >> >> I suppose the answer might be to update the >>> network >>> >>>>> with the >>> >>>>> >> >>> proper >>> >>>>> >> >>> > > >> >> isolation method when the traffic type is added. >>> Look >>> >>>>> up the >>> >>>>> >> >>> > physical >>> >>>>> >> >>> > > >> >> network's isolation method, grab network object >>> for the >>> >>>>> >> public >>> >>>>> >> >>> > > network, >>> >>>>> >> >>> > > >> and >>> >>>>> >> >>> > > >> >> set the right isolation. >>> >>>>> >> >>> > > >> >> On Jan 1, 2014 12:46 AM, "Marcus Sorensen" < >>> >>>>> >> shadow...@gmail.com >>> >>>>> >> >>> > >>> >>>>> >> >>> > > wrote: >>> >>>>> >> >>> > > >> >> >>> >>>>> >> >>> > > >> >>> I ran into an issue today that I'm still >>> trying to >>> >>>>> wrap my >>> >>>>> >> >>> head >>> >>>>> >> >>> > > >> >>> around, and I wanted to bounce this off of you >>> guys. I >>> >>>>> have >>> >>>>> >> a >>> >>>>> >> >>> > > physical >>> >>>>> >> >>> > > >> >>> network whose isolation method is set to 'VXLAN' >>> >>>>> (v4.3+). I >>> >>>>> >> >>> add my >>> >>>>> >> >>> > > >> >>> Public traffic type to it. I'd assume that nics >>> >>>>> generated >>> >>>>> >> for >>> >>>>> >> >>> > public >>> >>>>> >> >>> > > >> >>> traffic would have the standard vxlan:// URI for >>> >>>>> isolation >>> >>>>> >> >>> URI >>> >>>>> >> >>> > and >>> >>>>> >> >>> > > >> >>> broadcast URI, but they just have a vlan://. >>> Digging >>> >>>>> into >>> >>>>> >> it, >>> >>>>> >> >>> it >>> >>>>> >> >>> > > seems >>> >>>>> >> >>> > > >> >>> that public traffic is hard-coded to >>> >>>>> >> BroadcastDomainType.Vlan. >>> >>>>> >> >>> I >>> >>>>> >> >>> > > fixed >>> >>>>> >> >>> > > >> >>> this fairly easily for my testing, there were >>> only a >>> >>>>> few >>> >>>>> >> >>> places to >>> >>>>> >> >>> > > >> >>> fix, by pulling the BroadcastDomainType from the >>> >>>>> network >>> >>>>> >> object >>> >>>>> >> >>> > > rather >>> >>>>> >> >>> > > >> >>> than hardcoding it, but that found another >>> problem. >>> >>>>> This >>> >>>>> >> only >>> >>>>> >> >>> > works >>> >>>>> >> >>> > > if >>> >>>>> >> >>> > > >> >>> I change the broadcast type in the 'networks' >>> mysql >>> >>>>> table by >>> >>>>> >> >>> hand, >>> >>>>> >> >>> > > as >>> >>>>> >> >>> > > >> >>> during zone deployment the public network >>> creation is >>> >>>>> also >>> >>>>> >> >>> > > hard-coded >>> >>>>> >> >>> > > >> >>> to vlan. >>> >>>>> >> >>> > > >> >>> >>> >>>>> >> >>> > > >> >>> I'm not sure how to go about fixing this, >>> since the >>> >>>>> >> Public, >>> >>>>> >> >>> > > Control, >>> >>>>> >> >>> > > >> >>> Management networks are created upon zone >>> deployment, >>> >>>>> (see >>> >>>>> >> >>> > > >> >>> createDefaultSystemNetworks). The immediate >>> thing that >>> >>>>> >> jumped >>> >>>>> >> >>> out >>> >>>>> >> >>> > > was >>> >>>>> >> >>> > > >> >>> a config variable for public isolation method, >>> set >>> >>>>> prior to >>> >>>>> >> >>> zone >>> >>>>> >> >>> > > >> >>> deployment, or perhaps even one that overrides >>> what's >>> >>>>> in the >>> >>>>> >> >>> > table. >>> >>>>> >> >>> > > >> >>> >>> >>>>> >> >>> > > >> >>> While I've got your attention, what's the deal >>> with >>> >>>>> >> isolation >>> >>>>> >> >>> > > method >>> >>>>> >> >>> > > >> >>> vs broadcast method? These are always set to the >>> same >>> >>>>> thing >>> >>>>> >> as >>> >>>>> >> >>> far >>> >>>>> >> >>> > > as >>> >>>>> >> >>> > > >> >>> I've seen. >>> >>>>> >> >>> > > >> >>> >>> >>>>> >> >>> > > >> >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > >>> >>>>> >> >>> > > > -- >>> >>>>> >> >>> > > > *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> >>> >> *™* >>> >> >> >> >> -- >> *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> *™*