cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tutkowski, Mike" <Mike.Tutkow...@netapp.com>
Subject Re: CLOUDSTACK-9822
Date Wed, 08 Mar 2017 19:30:44 GMT
Great – thanks!

While trying to get my system VMs patched, I came across two issues (I'll note them here because
maybe you are already aware of them if you work with VMware in CloudStack frequently):

1) In a basic zone, I cannot get the virtual router to transition from the Starting state
to the Running state on VMware. This works on XenServer for me.

2) I actually had planned on running the virtual router on XenServer instead of on VMware
(to simplify what I was working on so that the system VMs would be running elsewhere and I
could just have my user VMs easily visible). I disabled my VMware cluster and then spun up
a user VM on my XenServer cluster so that CloudStack would spin up a virtual router. Since
I only had one cluster enabled, I expected the virtual router to end up there, but it ended
up on my disabled VMware cluster.

I can open tickets for these, but I figured I would run them past you first.

Thanks!

> On Mar 8, 2017, at 12:03 PM, Sergey Levitskiy <Sergey.Levitskiy@autodesk.com> wrote:
> 
> Thanks, Mike. BTW issue with storage tags will be  addressed shortly 
> 
> On 3/8/17, 12:24 AM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
> 
>    OK, I have an update to report.
> 
>    I think we can close out both of these tickets as non issues.
> 
>    It appears I had inadvertently left in one modified file (I was playing around with
fixing a bug for 4.11) in my code for RC1 (I’m using source, not a pre-built binary to test
RC1). While I was waiting for something else to be fixed in RC1, I had made a few code changes
in one file to test out an idea I had for a bug fix to go into 4.11. I had forgotten about
this changed file and the bug fix wasn’t complete, so it looks like this caused both 9822
and 9823.
> 
>    I’d like to do more testing later (it’s about 1:30 AM here, so I’m starting
to get a bit tired), but I can close those tickets out if my testing works out as expected.
> 
>    On 3/7/17, 5:30 PM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
> 
>        Hi,
> 
>        I tried the following with both an NFS datastore and a VMFS datastore.
> 
>        A new CloudStack environment running under RC1 with VMware places a ROOT-x-000001.vmdk
file in the VM’s folder for its root disk.
> 
>        However, in my new, clean environment, I cannot reproduce either of those issues
I logged.
> 
>        I’m not sure how I got the system into whatever state it was in before, but
a fresh install works.
> 
>        Let’s hold off on having anyone look into those tickets. I can play around with
this more over the coming days and see if I can reproduce either or both issues.
> 
>        Thanks,
>        Mike
> 
>        On 3/7/17, 9:10 AM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
> 
>            I believe the VM was deployed that way.
> 
>            I know that suffix typically only shows up when VM snapshots are involved,
but let me rebuild my environment and try to reproduce it from scratch.
> 
>> On Mar 7, 2017, at 8:17 AM, Sergey Levitskiy <Sergey.Levitskiy@autodesk.com>
wrote:
>> 
>> 
>> Changing the subject to start a new thread.
>> It would be helpful to figure out when your volume obtained 00001 suffix in DB.
>> I believe it is supposed to happen only when VMsnapohsot is created. Was snapshotting
part of your tests? If os was VM running or stopped?
>> 
>> 
>> On 3/7/17, 7:10 AM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
>> 
>>   No VM snapshot.
>> 
>>   I tried while the VM was in the Running state and then I also tried in the Stopped
state. Same results.
>> 
>>> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <Sergey.Levitskiy@autodesk.com>
wrote:
>>> 
>>> Is VM has an VMsnaphsot? Is VM in Stopped state?
>>> 
>>> On 3/6/17, 10:32 PM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
>>> 
>>>  I seem to have found another blocker:
>>> 
>>>  https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>>> 
>>>  On 3/6/17, 9:51 PM, "Rajani Karuturi" <rajani@apache.org> wrote:
>>> 
>>>      PRs are ready for the blockers. Waiting for reviews and test
>>>      results. Once they are ready, I will merge them(and a few more
>>>      bug fixes) and create RC2 (probably tomorrow, Wednesday)
>>> 
>>>      Thanks,
>>> 
>>>      ~ Rajani
>>> 
>>>      http://cloudplatform.accelerite.com/
>>> 
>>>      On March 3, 2017 at 4:30 PM, Rajani Karuturi (rajani@apache.org)
>>>      wrote:
>>> 
>>>      I will create RC2 on Monday with the fixes mentioned in my
>>>      previous mail.
>>> 
>>>      ~ Rajani
>>> 
>>>      http://cloudplatform.accelerite.com/
>>> 
>>>      On March 3, 2017 at 2:36 PM, Rohit Yadav
>>>      (rohit.yadav@shapeblue.com) wrote:
>>> 
>>>      Thanks Koushik, I did not realize Kishan had sent this already.
>>>      Let's get either of the PRs merged and kick a RC2.
>>> 
>>>      Regards.
>>> 
>>>      ________________________________
>>>      From: Koushik Das <koushik.das@accelerite.com>
>>>      Sent: 03 March 2017 14:14:56
>>>      To: dev@cloudstack.apache.org
>>>      Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
>>> 
>>>      Looks like there is already a PR for the same issue
>>>      https://github.com/apache/cloudstack/pull/1982 from Kishan.
>>> 
>>>      -Koushik
>>> 
>>>      On 03/03/17, 1:58 PM, "Rohit Yadav" <rohit.yadav@shapeblue.com>
>>>      wrote:
>>> 
>>>      -1 (binding)
>>> 
>>>      All, I've found an upgrade blocker. Pre 4.6 users are required
>>>      to seed 4.6 systemvmtemplate to proceed with the upgrade
>>>      otherwise upgrade fails, and from 4.9 upgrade to 4.10 does no
>>>      check/enforcement that 4.10 based systemvmtemplate has been
>>>      seeded/registered, nor the minimum required systemvmtemplate
>>>      version is changed from 4.6.0 to 4.10.0.
>>> 
>>>      After we have merged the strongswan/java8 PR, I had updated the
>>>      upgrade docs on how to upgrade the systemvmtemplate here:
>>> 
>>>      http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.9.html
>>> 
>>>      Using the above, I've tried to fix these issues here, please
>>>      review and merge for RC2:
>>> 
>>>      https://github.com/apache/cloudstack/pull/1983
>>> 
>>>      <https://github.com/apache/cloudstack/pull/1983>With above fix,
>>>      the aim is that users only seed the 4.10 systemvmtemplate before
>>>      upgrade and post-upgrade the upgrade paths fix the entries,
>>>      global setting etc.
>>> 
>>>      Regards.
>>> 
>>>      ________________________________
>>>      From: Tutkowski, Mike <Mike.Tutkowski@netapp.com>
>>>      Sent: 02 March 2017 22:39:08
>>>      To: dev@cloudstack.apache.org
>>>      Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
>>> 
>>>      I rolled back to my master branch at
>>>      da66b06e7d562393da2e4b52206943f8bad49d10 and it works.
>>> 
>>>      It appears something that went into after that commit has broken
>>>      this. It looks like this SHA is about two weeks old and that 43
>>>      commits have gone into master since it.
>>> 
>>>      On 3/2/17, 7:06 AM, "Tutkowski, Mike"
>>>      <Mike.Tutkowski@netapp.com> wrote:
>>> 
>>>      According to where the code fails, though, it appears to be a
>>>      networking problem. If I set a breakpoint before the failure and
>>>      change a variable to say that security groups are not being used,
>>>      then the VM starts.
>>> 
>>>      I think this is a recently introduced problem because I have
>>>      another branch based off of a slightly older version of master
>>>      and it works fine here.
>>> 
>>>> On Mar 2, 2017, at 6:51 AM, Pierre-Luc Dion
>>>      <pdion@cloudops.com> wrote:
>>>> 
>>>> Hi Mike,
>>>> Try vm with at least 512MB for memory.
>>>> 
>>>>> On Mar 1, 2017 15:01, "Tutkowski, Mike"
>>>      <Mike.Tutkowski@netapp.com> wrote:
>>>>> 
>>>>> I see the following exception when trying to deploy a user VM
>>>      in a Basic
>>>>> Zone with two XenServer 6.5 hosts in one cluster. My system
>>>      VMs have all
>>>>> deployed properly. The user template gets downloaded fine. I
>>>      can see the
>>>>> user VM begin to start on a XenServer host, then it goes
>>>      away. We then
>>>>> automatically try on the other host. I can see the VM begin
>>>      to start there
>>>>> for a moment, then it goes away.
>>>>> 
>>>>> I am just deploying the user VM’s template and root disk to
>>>      NFS (same
>>>>> place where the template and root disks of my system VMs
>>>      are).
>>>>> 
>>>>> I am using the built-in XenServer CentOS 5.6 (64 bit)
>>>      template with 1
>>>>> vCPU, 500 MHz, and 256 MB memory.
>>>>> 
>>>>> WARN [c.c.a.r.v.VirtualRoutingResource]
>>>      (DirectAgent-7:ctx-35aded78)
>>>>> (logid:aab9c320) Expected 1 answers while executing
>>>      VmDataCommand but
>>>>> received 2
>>>>> WARN [c.c.v.VirtualMachinePowerStateSyncImpl]
>>>      (DirectAgentCronJob-14:ctx-27fb1ac3)
>>>>> (logid:2c342f23) VM state was updated but update time is
>>>      null?! vm id: 6
>>>>> INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
>>>      (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce)
>>>>> (logid:a56a9a8c) Begin cleanup expired async-jobs
>>>>> INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
>>>      (AsyncJobMgr-Heartbeat-1:ctx-2c7d2dce)
>>>>> (logid:a56a9a8c) End cleanup expired async-jobs
>>>>> INFO [c.c.u.AccountManagerImpl]
>>>      (AccountChecker-1:ctx-383a632c)
>>>>> (logid:541e9ba5) Found 0 removed accounts to cleanup
>>>>> INFO [c.c.u.AccountManagerImpl]
>>>      (AccountChecker-1:ctx-383a632c)
>>>>> (logid:541e9ba5) Found 0 disabled accounts to cleanup
>>>>> INFO [c.c.u.AccountManagerImpl]
>>>      (AccountChecker-1:ctx-383a632c)
>>>>> (logid:541e9ba5) Found 0 inactive domains to cleanup
>>>>> INFO [c.c.u.AccountManagerImpl]
>>>      (AccountChecker-1:ctx-383a632c)
>>>>> (logid:541e9ba5) Found 0 disabled projects to cleanup
>>>>> WARN [c.c.h.x.r.CitrixResourceBase]
>>>      (DirectAgent-16:ctx-7c901443)
>>>>> (logid:aab9c320) callHostPlugin failed for cmd:
>>>      default_network_rules with
>>>>> args secIps: 0:, vmName: i-2-6-VM, vmID: 6, vmIP:
>>>      10.117.40.53, vmMAC:
>>>>> 06:b2:f4:00:00:22, due to There was a failure communicating
>>>      with the
>>>>> plugin.
>>>>> WARN [c.c.h.x.r.w.x.CitrixStartCommandWrapper]
>>>>> (DirectAgent-16:ctx-7c901443) (logid:aab9c320) Catch
>>>      Exception: class
>>>>> com.cloud.utils.exception.CloudRuntimeException due to
>>>>> com.cloud.utils.exception.CloudRuntimeException:
>>>      callHostPlugin failed
>>>>> for cmd: default_network_rules with args secIps: 0:, vmName:
>>>      i-2-6-VM,
>>>>> vmID: 6, vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22, due to
>>>      There was a
>>>>> failure communicating with the plugin.
>>>>> com.cloud.utils.exception.CloudRuntimeException:
>>>      callHostPlugin failed
>>>>> for cmd: default_network_rules with args secIps: 0:, vmName:
>>>      i-2-6-VM,
>>>>> vmID: 6, vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22, due to
>>>      There was a
>>>>> failure communicating with the plugin.
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> callHostPlugin(CitrixResourceBase.java:338)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:188)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.
>>>>> 
>>>      xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> executeRequest(CitrixResourceBase.java:1691)
>>>>> at
>>>      com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(
>>>>> DirectAgentAttache.java:315)
>>>>> 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:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> 
>>>      ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> WARN [c.c.h.x.r.CitrixResourceBase]
>>>      (DirectAgent-16:ctx-7c901443)
>>>>> (logid:aab9c320) Unable to start i-2-6-VM due to
>>>>> com.cloud.utils.exception.CloudRuntimeException:
>>>      callHostPlugin failed
>>>>> for cmd: default_network_rules with args secIps: 0:, vmName:
>>>      i-2-6-VM,
>>>>> vmID: 6, vmIP: 10.117.40.53, vmMAC: 06:b2:f4:00:00:22, due to
>>>      There was a
>>>>> failure communicating with the plugin.
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> callHostPlugin(CitrixResourceBase.java:338)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:188)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.
>>>>> 
>>>      xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> executeRequest(CitrixResourceBase.java:1691)
>>>>> at
>>>      com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(
>>>>> DirectAgentAttache.java:315)
>>>>> 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:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> 
>>>      ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> INFO [o.a.c.e.o.NetworkOrchestrator]
>>>      (Network-Scavenger-1:ctx-2058d5ac)
>>>>> (logid:bf8885a0) NetworkGarbageCollector uses '20' seconds
>>>      for GC interval.
>>>>> WARN [c.c.h.x.r.CitrixResourceBase]
>>>      (DirectAgent-16:ctx-7c901443)
>>>>> (logid:aab9c320) Unable to clean up VBD due to
>>>>> You gave an invalid object reference. The object may have
>>>      recently been
>>>>> deleted. The class parameter gives the type of reference
>>>      given, and the
>>>>> handle parameter echoes the bad value given.
>>>>> at com.xensource.xenapi.Types.checkResponse(Types.java:693)
>>>>> at
>>>      com.xensource.xenapi.Connection.dispatch(Connection.java:395)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$
>>>>> 
>>>      XenServerConnection.dispatch(XenServerConnectionPool.java:457)
>>>>> at com.xensource.xenapi.VBD.unplug(VBD.java:1109)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> handleVmStartFailure(CitrixResourceBase.java:3576)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:210)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.
>>>>> 
>>>      xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> executeRequest(CitrixResourceBase.java:1691)
>>>>> at
>>>      com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(
>>>>> DirectAgentAttache.java:315)
>>>>> 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:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> 
>>>      ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> WARN [c.c.h.x.r.CitrixResourceBase]
>>>      (DirectAgent-16:ctx-7c901443)
>>>>> (logid:aab9c320) Unable to clean up VBD due to
>>>>> You gave an invalid object reference. The object may have
>>>      recently been
>>>>> deleted. The class parameter gives the type of reference
>>>      given, and the
>>>>> handle parameter echoes the bad value given.
>>>>> at com.xensource.xenapi.Types.checkResponse(Types.java:693)
>>>>> at
>>>      com.xensource.xenapi.Connection.dispatch(Connection.java:395)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$
>>>>> 
>>>      XenServerConnection.dispatch(XenServerConnectionPool.java:457)
>>>>> at com.xensource.xenapi.VBD.unplug(VBD.java:1109)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> handleVmStartFailure(CitrixResourceBase.java:3576)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:210)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.
>>>>> 
>>>      xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> executeRequest(CitrixResourceBase.java:1691)
>>>>> at
>>>      com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(
>>>>> DirectAgentAttache.java:315)
>>>>> 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:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> 
>>>      ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> WARN [c.c.h.x.r.CitrixResourceBase]
>>>      (DirectAgent-16:ctx-7c901443)
>>>>> (logid:aab9c320) Unable to cleanup VIF
>>>>> You gave an invalid object reference. The object may have
>>>      recently been
>>>>> deleted. The class parameter gives the type of reference
>>>      given, and the
>>>>> handle parameter echoes the bad value given.
>>>>> at com.xensource.xenapi.Types.checkResponse(Types.java:693)
>>>>> at
>>>      com.xensource.xenapi.Connection.dispatch(Connection.java:395)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$
>>>>> 
>>>      XenServerConnection.dispatch(XenServerConnectionPool.java:457)
>>>>> at com.xensource.xenapi.VIF.unplug(VIF.java:921)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> handleVmStartFailure(CitrixResourceBase.java:3584)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:210)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.
>>>>> 
>>>      CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
>>>>> at com.cloud.hypervisor.xenserver.resource.wrapper.
>>>>> 
>>>      xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
>>>>> at
>>>      com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.
>>>>> executeRequest(CitrixResourceBase.java:1691)
>>>>> at
>>>      com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(
>>>>> DirectAgentAttache.java:315)
>>>>> 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:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> 
>>>      ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$
>>>>> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> INFO [c.c.v.VirtualMachineManagerImpl]
>>>      (Work-Job-Executor-2:ctx-bc104380
>>>>> job-25/job-27 ctx-8c946a5b) (logid:aab9c320) Unable to start
>>>      VM on
>>>>> Host[-2-Routing] due to Unable to start i-2-6-VM due to
>>>>> ERROR [c.c.v.VmWorkJobHandlerProxy]
>>>      (Work-Job-Executor-2:ctx-bc104380
>>>>> job-25/job-27 ctx-8c946a5b) (logid:aab9c320) Invocation
>>>      exception, caused
>>>>> by: com.cloud.exception.InsufficientServerCapacityException:
>>>      Unable to
>>>>> create a deployment for VM[User|i-2-6-VM]Scope=interface
>>>>> com.cloud.dc.DataCenter; id=1
>>>>> INFO [c.c.v.VmWorkJobHandlerProxy]
>>>      (Work-Job-Executor-2:ctx-bc104380
>>>>> job-25/job-27 ctx-8c946a5b) (logid:aab9c320) Rethrow
>>>      exception
>>>>> com.cloud.exception.InsufficientServerCapacityException:
>>>      Unable to create
>>>>> a deployment for VM[User|i-2-6-VM]Scope=interface
>>>>> com.cloud.dc.DataCenter; id=1
>>>>> ERROR [c.c.v.VmWorkJobDispatcher]
>>>      (Work-Job-Executor-2:ctx-bc104380
>>>>> job-25/job-27) (logid:aab9c320) Unable to complete AsyncJobVO
>>>      {id:27,
>>>>> userId: 2, accountId: 2, instanceType: null, instanceId:
>>>      null, cmd:
>>>>> com.cloud.vm.VmWorkStart, cmdInfo:
>>>      rO0ABXNyABhjb20uY2xvdWQudm0uVm
>>>>> 1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2
>>>>> Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAA
>>>>> ljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-
>>>>> AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNp
>>>>> 
>>>      Y2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbE
>>>>> 
>>>      lkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-
>>>>> 
>>>      AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkS
>>>>> 
>>>      gAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAAAAAAAAACAAAAAAAAAAIAAA
>>>>> AAAAAABnQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAAAAAAAAAHBwcH
>>>>> BwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRm
>>>>> FjdG9ySQAJdGhyZXNob2xkeHA_QAAAAAAADHcIAAAAEAAAAAF0AApWbV
>>>>> Bhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
>>>      cmdVersion: 0,
>>>>> status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
>>>      null,
>>>>> initMsid: 52237617797, completeMsid: null, lastUpdated: null,
>>>      lastPolled:
>>>>> null, created: Wed Mar 01 12:51:32 MST 2017}, job origin:25
>>>>> com.cloud.exception.InsufficientServerCapacityException:
>>>      Unable to create
>>>>> a deployment for VM[User|i-2-6-VM]Scope=interface
>>>>> com.cloud.dc.DataCenter; id=1
>>>>> at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(
>>>>> VirtualMachineManagerImpl.java:961)
>>>>> at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(
>>>>> VirtualMachineManagerImpl.java:4661)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>      Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>>> NativeMethodAccessorImpl.java:62)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>>> DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>> at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(
>>>>> VmWorkJobHandlerProxy.java:107)
>>>>> at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(
>>>>> VirtualMachineManagerImpl.java:4822)
>>>>> at com.cloud.vm.VmWorkJobDispatcher.runJob(
>>>>> VmWorkJobDispatcher.java:102)
>>>>> at
>>>      org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.
>>>>> runInContext(AsyncJobManagerImpl.java:554)
>>>>> 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 org.apache.cloudstack.framework.jobs.impl.
>>>>> AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
>>>>> at java.util.concurrent.Executors$RunnableAdapter.
>>>>> call(Executors.java:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> INFO [o.a.c.f.j.i.AsyncJobMonitor]
>>>      (Work-Job-Executor-2:ctx-bc104380
>>>>> job-25/job-27) (logid:aab9c320) Remove job-27 from job
>>>      monitoring
>>>>> WARN [o.a.c.alerts] (API-Job-Executor-1:ctx-f787201d job-25
>>>>> ctx-56356c1a) (logid:aab9c320) alertType:: 8 //
>>>      dataCenterId:: 1 //
>>>>> podId:: 1 // clusterId:: null // message:: Failed to deploy
>>>      Vm with Id: 6,
>>>>> on Host with Id: null
>>>>> ERROR [c.c.a.ApiAsyncJobDispatcher]
>>>      (API-Job-Executor-1:ctx-f787201d
>>>>> job-25) (logid:aab9c320) Unexpected exception while executing
>>>>> org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
>>>>> com.cloud.utils.exception.CloudRuntimeException: Unable to
>>>      start a VM due
>>>>> to insufficient capacity
>>>>> at com.cloud.vm.VirtualMachineManagerImpl.start(
>>>>> VirtualMachineManagerImpl.java:623)
>>>>> at
>>>      org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.
>>>>> deployVirtualMachine(VMEntityManagerImpl.java:242)
>>>>> at org.apache.cloudstack.engine.cloud.entity.api.
>>>>> 
>>>      VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:212)
>>>>> at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(
>>>>> UserVmManagerImpl.java:4084)
>>>>> at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(
>>>>> UserVmManagerImpl.java:3682)
>>>>> at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(
>>>>> UserVmManagerImpl.java:3670)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>      Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>>> NativeMethodAccessorImpl.java:62)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>>> DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>> at org.springframework.aop.support.AopUtils.
>>>>> invokeJoinpointUsingReflection(AopUtils.java:333)
>>>>> at
>>>      org.springframework.aop.framework.ReflectiveMethodInvocation.
>>>>> invokeJoinpoint(ReflectiveMethodInvocation.java:190)
>>>>> at
>>>      org.springframework.aop.framework.ReflectiveMethodInvocation.
>>>>> proceed(ReflectiveMethodInvocation.java:157)
>>>>> at org.apache.cloudstack.network.contrail.management.
>>>>> EventUtils$EventInterceptor.invoke(EventUtils.java:107)
>>>>> at
>>>      org.springframework.aop.framework.ReflectiveMethodInvocation.
>>>>> proceed(ReflectiveMethodInvocation.java:168)
>>>>> at com.cloud.event.ActionEventInterceptor.invoke(
>>>>> ActionEventInterceptor.java:51)
>>>>> at
>>>      org.springframework.aop.framework.ReflectiveMethodInvocation.
>>>>> proceed(ReflectiveMethodInvocation.java:168)
>>>>> at
>>>      org.springframework.aop.interceptor.ExposeInvocationInterceptor.
>>>>> invoke(ExposeInvocationInterceptor.java:92)
>>>>> at
>>>      org.springframework.aop.framework.ReflectiveMethodInvocation.
>>>>> proceed(ReflectiveMethodInvocation.java:179)
>>>>> at org.springframework.aop.framework.JdkDynamicAopProxy.
>>>>> invoke(JdkDynamicAopProxy.java:213)
>>>>> at com.sun.proxy.$Proxy186.startVirtualMachine(Unknown
>>>      Source)
>>>>> at org.apache.cloudstack.api.command.admin.vm.
>>>>> DeployVMCmdByAdmin.execute(DeployVMCmdByAdmin.java:50)
>>>>> at
>>>      com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
>>>>> at com.cloud.api.ApiAsyncJobDispatcher.runJob(
>>>>> ApiAsyncJobDispatcher.java:108)
>>>>> at
>>>      org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.
>>>>> runInContext(AsyncJobManagerImpl.java:554)
>>>>> 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 org.apache.cloudstack.framework.jobs.impl.
>>>>> AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
>>>>> at java.util.concurrent.Executors$RunnableAdapter.
>>>>> call(Executors.java:511)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>> ThreadPoolExecutor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>> ThreadPoolExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:745)
>>>>> Caused by:
>>>      com.cloud.exception.InsufficientServerCapacityException:
>>>>> Unable to create a deployment for
>>>      VM[User|i-2-6-VM]Scope=interface
>>>>> com.cloud.dc.DataCenter; id=1
>>>>> at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(
>>>>> VirtualMachineManagerImpl.java:961)
>>>>> at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(
>>>>> VirtualMachineManagerImpl.java:4661)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>      Method)
>>>>> ... 18 more
>>>>> 
>>>>> On 3/1/17, 8:52 AM, "Pierre-Luc Dion" <pdion891@apache.org>
>>>      wrote:
>>>>> 
>>>>> Do we support centos6 with this 4.10 on jdk8?
>>>>> 
>>>>> Because I did not had much success to install 4.10 jdk8 on
>>>      centos6
>>>>> and it
>>>>> would make more sense to drop support of centos6 so our
>>>      packages would
>>>>> use
>>>>> centos7 with distro packages for tomcat7 and jdk8. Should
>>>      also be the
>>>>> same
>>>>> with ubuntu 16.04 that use jdk8 and tomcat7 by default ?
>>>>> 
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> 
>>>>>> On Wed, Mar 1, 2017 at 9:01 AM, Rene Moser
>>>      <mail@renemoser.net> wrote:
>>>>>> 
>>>>>> Hi
>>>>>> 
>>>>>> While not be directly related to the clodustack java source
>>>      code, any
>>>>>> RPM created using the specs from the repo e.g. from
>>>      packages/centos7
>>>>>> and proceeding an upgrade, will hit CLOUDSTACK-9765, PR
>>>>>> https://github.com/apache/cloudstack/pull/1923 fixes the
>>>      issue.
>>>>>> 
>>>>>> Regards
>>>>>> René
>>>>>> 
>>>>>> 
>>>>>>> On 03/01/2017 02:12 AM, Rajani Karuturi wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> I've created a 4.10.0.0 release, with the following
>>>      artifacts up
>>>>> for a
>>>>>> vote:
>>>>>>> 
>>>>>>> Git Branch and Commit
>>>>>>> SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.
>>>>>> git;a=shortlog;h=refs/heads/4.10.0.0-RC20170301T0634
>>>>>>> Commit:7c1d003b5269b375d87f4f6cfff8a144f0608b67
>>>>>>> <https://git-wip-us.apache.org/repos/asf?p=cloudstack.
>>>>>> git;a=shortlog;h=refs/heads/4.10.0.0-RC20170301T0634Commit:
>>>>>> 7c1d003b5269b375d87f4f6cfff8a144f0608b67>
>>>>>>> 
>>>>>>> Source release (checksums and signatures are available at
>>>      the same
>>>>>>> 
>>>      location):https://dist.apache.org/repos/dist/dev/cloudstack/
>>>>> 4.10.0.0/
>>>>>>> 
>>>>>>> PGP release keys (signed using
>>>>>>> CBB44821):https://dist.apache.org/repos/dist/release/
>>>>> cloudstack/KEYS
>>>>>>> 
>>>>>>> Vote will be open for 72 hours.
>>>>>>> 
>>>>>>> For sanity in tallying the vote, can PMC members please be
>>>      sure to
>>>>>>> indicate "(binding)" with their vote?
>>>>>>> 
>>>>>>> [ ] +1 approve
>>>>>>> [ ] +0 no opinion
>>>>>>> [ ] -1 disapprove (and reason why)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ~Rajani
>>>>>>> http://cloudplatform.accelerite.com/
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>>      rohit.yadav@shapeblue.com
>>>      www.shapeblue.com<http://www.shapeblue.com 
>>>      ( http://www.shapeblue.com<http://www.shapeblue.com )>
>>>      53 Chandos Place, Covent Garden, London WC2N 4HSUK
>>>      @shapeblue
>>> 
>>>      DISCLAIMER
>>>      ==========
>>>      This e-mail may contain privileged and confidential information
>>>      which is the property of Accelerite, a Persistent Systems
>>>      business. It is intended only for the use of the individual or
>>>      entity to which it is addressed. If you are not the intended
>>>      recipient, you are not authorized to read, retain, copy, print,
>>>      distribute or use this message. If you have received this
>>>      communication in error, please notify the sender and delete all
>>>      copies of this message. Accelerite, a Persistent Systems business
>>>      does not accept any liability for virus infected mails.
>>> 
>>>      rohit.yadav@shapeblue.com
>>>      www.shapeblue.com ( http://www.shapeblue.com )
>>>      53 Chandos Place, Covent Garden, London WC2N 4HSUK
>>>      @shapeblue
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 
> 
> 
Mime
View raw message