Thanks! I got the system VM up and running again on XenServer.
On 3/8/17, 12:40 PM, "Sergey Levitskiy" <sergey.levits...@autodesk.com> wrote:
1. I think PR1991 that was merged today will resolve it
2. What are your settings for hypervisor.list and
system.vm.default.hypervisor ? In some settings disabling cluster doesn’t have
an intended affect. You might try unmanage your vmware cluster and re-try. I
think one of the settings above can control where your router will end up.
Thanks,
Sergey
On 3/8/17, 11:30 AM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:
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.levits...@autodesk.com> wrote:
>
> Thanks, Mike. BTW issue with storage tags will be addressed shortly
>
> On 3/8/17, 12:24 AM, "Tutkowski, Mike" <mike.tutkow...@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.tutkow...@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.tutkow...@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.levits...@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.tutkow...@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.levits...@autodesk.com> wrote:
>>>
>>> Is VM has an VMsnaphsot? Is VM in Stopped state?
>>>
>>> On 3/6/17, 10:32 PM, "Tutkowski, Mike" <mike.tutkow...@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" <raj...@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
(raj...@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.ya...@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....@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.ya...@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.tutkow...@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.tutkow...@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
>>> <pd...@cloudops.com> wrote:
>>>>
>>>> Hi Mike,
>>>> Try vm with at least 512MB for memory.
>>>>
>>>>> On Mar 1, 2017 15:01, "Tutkowski, Mike"
>>> <mike.tutkow...@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" <pdion...@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
>>> <m...@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.ya...@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.ya...@shapeblue.com
>>> www.shapeblue.com ( http://www.shapeblue.com )
>>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
>>> @shapeblue
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
