Just some final feedback on the setup I had.
I have an installation up and running since about a week ago. A number of
remarks I got from Sebastien allowed me to put things in perspective
(especially when trying to get the network configured). All in all, a
pretty standard configuration seems to b
> I cleared the database and re-did the installation and all seems to be
> > working now.
> >
> > Thanks for the help.
> >
> > It seems that something must have been off during the initial install.
>
> Hi Marc, I was at the guy at the booth :)
>
Yeah, thank you; you were very patient. Thank you
On Oct 17, 2014, at 11:01 AM, Marc Leeman wrote:
> I cleared the database and re-did the installation and all seems to be
> working now.
>
> Thanks for the help.
>
> It seems that something must have been off during the initial install.
Hi Marc, I was at the guy at the booth :)
In my angst
I cleared the database and re-did the installation and all seems to be
working now.
Thanks for the help.
It seems that something must have been off during the initial install.
ok, then I'd re-init the db and try again, Keeping Pauls remark in mind. I
usually mess up my ip space and find myself stuck in a mess. Paul didn't
you post a sample layout somewhere?
On Fri, Oct 17, 2014 at 10:38 AM, Marc Leeman wrote:
> On 16 October 2014 17:53, Daan Hoogland wrote:
>
> > On
On 16 October 2014 17:53, Daan Hoogland wrote:
> On Thu, Oct 16, 2014 at 5:33 PM, Marc Leeman
> wrote:
>
> > Is there some inconsistency in the database?
> >
> This might well be. To check this look at mshost and mshost_peer.
>
> Are you upgrading? Is this a test setup?
>
>
>
It is my first setu
Hi Marc,
I'm not sure if this is adding to your issues, but the section of your network
config where you send traffic for 172.16.0.0/16 to 172.16.8.1
doesn't look right to my eye, as traffic for your local subnet 172.16.8.0/24
would also get sent to that gateway.
address 172.16.8.7
net
On Thu, Oct 16, 2014 at 5:33 PM, Marc Leeman wrote:
> Is there some inconsistency in the database?
>
This might well be. To check this look at mshost and mshost_peer.
Are you upgrading? Is this a test setup?
Daan
btw
On Thu, Oct 16, 2014 at 5:46 PM, Daan Hoogland
wrote:
> no, this is restoring an instance AFAICT
>
> On Thu, Oct 16, 2014 at 5:43 PM, Marc Leeman
> wrote:
>
>> > Try to restore your system:
>
> this was part of the log!
Not an advice
--
Daan
no, this is restoring an instance AFAICT
On Thu, Oct 16, 2014 at 5:43 PM, Marc Leeman wrote:
> > Try to restore your system:
> >
>
>
>
> You are talking about this procedure right?
>
>
> https://support.getcloudservices.com/entries/21982811-CloudStack-Restore-Cloud-Server
>
--
Daan
> Try to restore your system:
>
You are talking about this procedure right?
https://support.getcloudservices.com/entries/21982811-CloudStack-Restore-Cloud-Server
Is there some inconsistency in the database?
At the end of the stack dump:
2014-10-16 17:27:36,912 INFO [c.c.c.ClusterManagerImpl] (main:null)
Detected that another management node with the same IP 172.16.8.7 is
considered as running in DB, however it is not pingable, we will continue
cluster in
> configure your system:
> Checking KVM...[Failed]
> Please enable KVM on this machine
I opened a bug on this one: there is a packaging problem: a dependency is
missing on cpu_utils. We got that one figured out too :-) The script is
using kvm-ok at some point.
I don't see a mention of cloud0 in the log. It might come from within the
agent itself trying to restore some defaults after a reset or delete.
I do note some other perculiar thing:
Around the following log fragment a lot of nulls are in the file. Also the
meassage is not filling one with hope: n
The port is being started by the manager. The error is happening during the
restart of the management server
2014-10-16 17:27:36,909 ERROR [c.c.c.ClusterManagerImpl] (main:null) Unable
to ping management server at 172.16.8.7:9090 due to ConnectException
java.net.ConnectException: Connection refuse
No:
I killed the process at the boot the day before yesterday (thanks to the
cloudstack guys that I made to miss the boot crawl): there was indeed a
problem with that; NO vsm were starting.
After killing the old stuck programs; we got further and after downloading
the svm images manually with the
Ok, let us know if this solves your issue.
Op 16 okt. 2014 17:07 schreef "Marc Leeman" :
> $ sudo netstat -tulpn |grep 9090
> tcp6 0 0 :::9090 :::*
> LISTEN 32427/jsvc.exec
>
> That is cloudstack.
>
> But then I thought of it; I asked someone on the cloudstack stand
$ sudo netstat -tulpn |grep 9090
tcp6 0 0 :::9090 :::*
LISTEN 32427/jsvc.exec
That is cloudstack.
But then I thought of it; I asked someone on the cloudstack stand at
Dusseldorf; and the 4.0 was upgraded to 4.3. It seems that there was
something wrong with the pack
Marc from your logs it seems like there is a port conflict on your host.
Can you check on that? port 9090
first I see
2014-10-14 17:25:54,181 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server (host id : 1) is being started at 172.16.8.7:9090
2014-10-14 17:25:54,186 INFO [c.c.c.Clust
On 16 October 2014 16:10, Daan Hoogland wrote:
>
>> My eye is not much more trained at this table but I'll have a peek in the
>> code. It seems to e that cloudstack should be configuring the bridge
>> instead of the cloud0 device. I have no idea if this is a config err of
>> yours or a bug.
>>
>>
My eye is not much more trained at this table but I'll have a peek in the
code. It seems to e that cloudstack should be configuring the bridge
instead of the cloud0 device. I have no idea if this is a config err of
yours or a bug.
My assuptions:
you are using kvm as hypervisor
you are running vers
yes.
But there must be something in the configuration that causes problems. I
haven't played around too much with bridging.
If I delete the route to cloud0 and replace it to the cloudbr0, I can
access the LL devices on the network; after resetting the cloudstack
manager; I cannot. It seems to my
Marc,
The only difference I see is de vice cloudbr0 becoming cloud0, in the third
line. Am I correct?
On Thu, Oct 16, 2014 at 3:28 PM, Marc Leeman wrote:
>
> OK, there is something off here:
>
> This is my routing table where I can ping another physical host with an
> link-local address
>
> r
OK, there is something off here:
This is my routing table where I can ping another physical host with an
link-local address
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
0.0.0.0 10.158.231.1 0.0.0.0 UG0
I've managed to get link local working my modifying the routing (disable
the fw atm too).
/sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
0.0.0.0 10.158.231.1 0.0.0.0 UG0 00 eth1
150.158.231.0
25 matches
Mail list logo
