Yeah, I thought the same thing. I think the default configuration of the
mailing list does not send the original mail to the sender.
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
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.
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 te
> 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.
ng.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties
org.apache.catalina.startup.Bootstrap
root 4999 4514 0 17:27 pts/600:00:00 grep 4643
On 16 October 2014 17:16, Marc Leeman wrote:
>
> No:
>
> I killed the p
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
$ 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
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.
>>
>>
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
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 think my mail did not get through, I can't find it in the archives; I've
probably sent it too fast after subscribing
I've started out with cloudstack a couple days ago and I've hit a bit of a
brick wall.
The installation is running on a system that has two network interfaces, a
public one and p
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
I've started out with cloudstack a couple days ago and I've hit a bit of a
brick wall.
The installation is running on a system that has two network interfaces, a
public one and private one (connecting to a local network).
auto eth0
iface eth0 inet manual
auto eth1
iface eth1 inet static
17 matches
Mail list logo
