gt;
> >
> >
> >
> > -Original Message-
> > From: Jevgeni Zolotarjov [mailto:j.zolotar...@gmail.com]
> > Sent: 09 February 2018 16:34
> > To: users@cloudstack.apache.org
> > Subject: Re: cloudstack-management fails to start after upgrade 4.10
hapeblue.com
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
> >
> >
> >
> >
> > -----Original Message-
> > From: Jevgeni Zolotarjov [mailto:j.zolotar...@gmail.com]
> > Sent: 09 February 2018 16:19
> > To: users@cloudstack.
ry 2018 16:34
To: users@cloudstack.apache.org
Subject: Re: cloudstack-management fails to start after upgrade 4.10 -> 4.11
destroyed virtual router
it got recreated.
On NOW. My VMs start!!!
All IPs got changed, but I can manage with that.
Thank you for your support
On Fri, Feb 9, 2018 at
lotar...@gmail.com]
> Sent: 09 February 2018 16:19
> To: users@cloudstack.apache.org
> Subject: Re: cloudstack-management fails to start after upgrade 4.10 ->
> 4.11
>
> I destroyed system VMs and they got recreated automatically.
> They are running. I can verify that by
> virsh list -
en, London WC2N 4HSUK
@shapeblue
-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: 09 February 2018 16:21
To: users@cloudstack.apache.org
Subject: RE: cloudstack-management fails to start after upgrade 4.10 -> 4.11
Have you done the same for the virtual r
arjov [mailto:j.zolotar...@gmail.com]
Sent: 09 February 2018 16:19
To: users@cloudstack.apache.org
Subject: Re: cloudstack-management fails to start after upgrade 4.10 -> 4.11
I destroyed system VMs and they got recreated automatically.
They are running. I can verify that by
virsh list --all
and
I can s
today
> > > into https://pastebin.com (or similar) to share with us.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > paul.an.
eni Zolotarjov [mailto:j.zolotar...@gmail.com]
> Sent: 09 February 2018 15:55
> To: users@cloudstack.apache.org
> Subject: Re: cloudstack-management fails to start after upgrade 4.10 ->
> 4.11
>
> Destroyed VMs? No. Definitely not.
>
> At least I can see them all under web console
HSUK
@shapeblue
-Original Message-
From: Jevgeni Zolotarjov [mailto:j.zolotar...@gmail.com]
Sent: 09 February 2018 15:55
To: users@cloudstack.apache.org
Subject: Re: cloudstack-management fails to start after upgrade 4.10 -> 4.11
Destroyed VMs? No. Definitely not.
At least I can s
today
>> into
>> > https://pastebin.com (or similar) to share with us.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > paul.an...@shapeblue.com
>> > www.shapeblue.com
&
os Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
> > -Original Message-
> > From: Jevgeni Zolotarjov [mailto:j.zolotar...@gmail.com]
> > Sent: 09 February 2018 15:31
> > To: users@cloudstack.apache.org
> > Subject
andos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Jevgeni Zolotarjov [mailto:j.zolotar...@gmail.com]
> Sent: 09 February 2018 15:31
> To: users@cloudstack.apache.org
> Subject: Re: cloudstack-management fails to s
al Message-
From: Jevgeni Zolotarjov [mailto:j.zolotar...@gmail.com]
Sent: 09 February 2018 15:31
To: users@cloudstack.apache.org
Subject: Re: cloudstack-management fails to start after upgrade 4.10 -> 4.11
the same result
[root@mtl1-apphst03 management]# virsh list --al
the same result
[root@mtl1-apphst03 management]# virsh list --all
IdName State
1 v-1-VM running
2 s-2-VM running
On Fri, Feb 9, 2018 at 5:28 PM, Daan Hoo
so try
# virsh list --all
On Fri, Feb 9, 2018 at 4:27 PM, Jevgeni Zolotarjov
wrote:
> I guess, these are system VMs.
> none of my own created instances can start.
> IdName State
>
> 1 v-1-VM
I guess, these are system VMs.
none of my own created instances can start.
IdName State
1 v-1-VM running
2 s-2-VM running
virsh start 3> gives error
error:
On Fri, Feb 9, 2018 at 3:58 PM, Jevgeni Zolotarjov
wrote:
> * how to start instance with virsh?
>
ah, usually something like
# virsh start
or
# virsh start <number>
> * starting in debugger? I would rather not do it :)
>
ok, i expected as much. It will slow our solution process unfortunatel
* how to start instance with virsh?
* starting in debugger? I would rather not do it :)
* this is the log around GetHostStatsAnswer
2018-02-09 14:05:30,274 DEBUG [c.c.s.StatsCollector]
(StatsCollector-4:ctx-167407f0) (logid:0c470e95) HostStatsCollector is
running...
2018-02-09 14:05:30,322 DEBUG
and with cloudstack (and mysql) running locally, right?
So my next step would be to stop cloudstack and see if you can start the
image with virsh?
Cloudstack thinks for some reason the host is not a suitable target. I have
no clue why that is from your log. You can start cloudstack in a debugger
bu
t; > is
> > > > not
> > > > >>> > used, so not failing upgrade
> > > > >>> > 2018-02-09 09:38:05,494 DEBUG [c.c.u.d.Upgrade41000to41100]
> > > > (main:null)
> > > > >>> > (logid:) Upda
at
> > > >>> > com.cloud.upgrade.dao.Upgrade41000to41100.performDataMigration(
> > > >>> > Upgrade41000to41100.java:71)
> > > >>> > at
> > > >>> > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(
> > >
> > >>> > org.springframework.context.support.DefaultLifecycleProcesso
> > >>> r.access$200(
> > >>> > DefaultLifecycleProcessor.java:52)
> > >>> > at
> > >>> > org.springframework.context.support.Def
initionSet$2.with(DefaultModuleDefinitionSet.
> java:122)
> >>> > at
> >>> > org.apache.cloudstack.spring.module.model.impl.DefaultModule
> >>> DefinitionSet.
> >>> > withModule(DefaultModuleDefinitionSet.java:245)
> >>
> at
>>> > org.apache.cloudstack.spring.module.factory.CloudStackSpring
>>> Context.init(
>>> > CloudStackSpringContext.java:71)
>>> > at
>>> > org.apache.cloudstack.spring.module.factory.CloudStackSpring
>>&g
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(
>> > ContextHandler.java:890)
>> > at
>> > org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(
>> > ServletContextHandler.java:532)
>> >
gt; startContext(ContextHandler.java:853)
> > at
> > org.eclipse.jetty.servlet.ServletContextHandler.startContext(
> > ServletContextHandler.java:344)
> > at
> > org.eclipse.jetty.webapp.WebAppContext.startWebapp(
> > WebAppContext.java
g.eclipse.jetty.server.handler.ContextHandler.
> doStart(ContextHandler.java:785)
>
>
>
> On Fri, Feb 9, 2018 at 11:42 AM, Daan Hoogland
> wrote:
>
> > before you continue Jevgeni,
> >
> > Do you have a good backup and is no-one able to access this inst
Jevgeni, the error shows that the MS is not able to find the 4.11 system
template. Did you seed the 4.11 KVM system template?
Best,
Raja
Engineering, Accelerite,
2055, Laurelwood Road, Santa Clara, CA, 95054
www.accelerite.com
On 2/9/18, 3:15 PM, "Jevgeni Zolotarjov" wrote:
Unable to
tarjov
> > Sent: Friday, February 9, 2018 10:59:27 AM
> > To: users@cloudstack.apache.org
> > Subject: Re: cloudstack-management fails to start after upgrade 4.10 ->
> > 4.11
> >
> > I dropped the column. But then another error like this appeared
> >
> &
00to41100.sql:
>
>
> From: Jevgeni Zolotarjov
> Sent: Friday, February 9, 2018 10:59:27 AM
> To: users@cloudstack.apache.org
> Subject: Re: cloudstack-management fails to start after upgrade 4.10 ->
> 4.11
>
> I dropped the column. Bu
engine/schema/resources/META-INF/db/schema-41000to41100.sql:
From: Jevgeni Zolotarjov
Sent: Friday, February 9, 2018 10:59:27 AM
To: users@cloudstack.apache.org
Subject: Re: cloudstack-management fails to start after upgrade 4.10 -> 4.11
I dropped the col
I dropped the column. But then another error like this appeared
Please advise, where are the DB update script located? so I can manually
inspect that.
On Fri, Feb 9, 2018 at 10:29 AM, Ernie Janse van Rensburg <
ernie.jvrensb...@shapeblue.com> wrote:
> Hi Jevgeni
>
>
> It looks like there was a d
Hi Jevgeni
It looks like there was a database error during the upgrade process.
A SQL script that is trying to add a column 'for_vpc' to the TABLE
'cloud.network_offerings' but the column already exists, for some reason, so it
fails because mysql does not allow 2 columns with the same name in
Jevgeni,
It looks like the db upgrade went wrong. You'll have to restore a backup,
or be very savvy about what you do next.
For some reason the new column, 'for_vpc' was already defined. The
management server saw that the db was version 4.10 and self is 4.11. It
then starts the run the required up
34 matches
Mail list logo
