Sorry, I wasn't clear...I meant change your interfaces by removing the vlans so
the bridges show just the interface name.
Simon Weller/ENA
(615) 312-6068
-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 8:32PM
To: users@cloudstack.apache.org [us
Unfortunately that didn't fix it either, it looks like they just change
straight back to "cloudbr0":
[root@node1 ~]# tail -n 3 /etc/cloudstack/agent/agent.properties
private.network.device=eth0
public.network.device=eth0
guest.network.device=eth0
2016-08-30 12:28:50,924 INFO [cloud.agent.Agent
I'd suspect changing the sub ints to native ports will fix this as well. That
might be a better approach so you don't have to mess with the traffic labels
Traveling today, so if my responses are a bit slow, it's because I'm on a plane.
Simon Weller/ENA
(615) 312-6068
-Original Message-
I just tried this, unfortunately that didn't solve it. I was under the
impression that the master replaced the interface names in that file with
cloudbr0 / cloudbr1? When I check the file again, those interface names are
back.
Here are the logs (notice on the second attempt, the interface names
ch
Can you edit /etc/cloudstack/agent.properties and try changing the interfaces
from cloudbr0 to your sub int, e.g. eth0.200
Simon Weller/ENA
(615) 312-6068
-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 7:28AM
To: users@cloudstack.apache.org [
On 29 August 2016 at 22:16, Simon Weller wrote:
> So, my guess here is that the agent doesn't like the fact you have a sub
> interface plugged into the bridge. This is an advanced network zone,
> correct?
I haven't actually got that far, but I'm aiming for the Basic network zone.
The guide on C
So, my guess here is that the agent doesn't like the fact you have a sub
interface plugged into the bridge. This is an advanced network zone, correct?
Simon Weller/ENA
(615) 312-6068
-Original Message-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 7:08AM
To: us
On 29 August 2016 at 21:57, Simon Weller wrote:
> Can you post the output of brctl show?
bridge name bridge id STP enabled interfaces
cloud0 8000. no
cloudbr08000.bcaec529ec9a yes eth0.200
cloudbr1
Can you post the output of brctl show?
Also, what are your kvm traffic labels set to? Do you have multiple physical
networks configured in mgmt?
Simon Weller/ENA
(615) 312-6068
-Original Message-
From: Pierre-Luc Dion [pd...@cloudops.com]
Received: Monday, 29 Aug 2016, 6:06AM
To: users@
On 29 August 2016 at 21:06, Pierre-Luc Dion wrote:
>
> Does the management server can ssh on the kvm server?
Yes it can.
[root@master ~]# ssh 10.1.1.2
root@10.1.1.2's password:
Last login: Mon Aug 29 21:44:20 2016 from master
[root@node1 ~]#
On 29 August 2016 at 21:06, Pierre-Luc Dion wrote:
In my experience, the error your reporting normally indicates that the agent
can't figure out the interface names for some reason. Can you place the agent
in debug mode and post the output?
You can enable agent debugging by running the following command: sed -i
's/INFO/DEBUG/g' /etc/cloudstack/
I presume the kvm node is a different one than the management server, has a
basic tests:
Does the management server can ssh on the kvm server?
Does the kvm server can tcp connect on the mgt server port 8250?
On Aug 29, 2016 03:52, "John Cenile" wrote:
> Hi all,
>
> I'm trying to set up a test
Have you try to destroy and re-create SSVM?
-Original Message-
From: uabstarn...@gmail.com [mailto:uabstarn...@gmail.com] On Behalf Of
Mindaugas Milinavicius
Sent: Monday, August 29, 2016 5:57 PM
To: users@cloudstack.apache.org
Subject: Re: Reconnect secondary storage NFS
Yes, did not he
Looks like fixed, strange story, but only after reconfigure eth port in
management server, i get it up.
1) If you destroy the SSVM, CS will create it again from DB values. Wait
for some time,
2) For disconnected SSVMs, stopping and starting cloud service on SSVM from
command line helps.
--
Makrand
On Mon, Aug 29, 2016 at 3:26 PM, Mindaugas Milinavičius <
mindau...@clustspace.com> wrote:
> Yes, d
Yes, did not helped.
Have you tried to restart ACS management?
-Original Message-
From: uabstarn...@gmail.com [mailto:uabstarn...@gmail.com] On Behalf Of
Mindaugas Milinavicius
Sent: Monday, August 29, 2016 5:32 PM
To: users@cloudstack.apache.org
Subject: Re: Reconnect secondary storage NFS
Yes, i can ping,
Yes, i can ping, and i see mounted storage on managemed server:)
Problem is SSVM is disconnected from secondary storage, reboot didnot
helped, i tryed to destroy and now have no idea how to run it again:)) It's
not starting up manually:)
MM,
This may sound very noobish, but can you ping NFS server from cloudstack
server?
Also, try recreating the SSVM etc. SSVM is responsible for all secondary
stuff.
--
Makrand
On Mon, Aug 29, 2016 at 2:23 PM, Mindaugas Milinavičius <
mindau...@clustspace.com> wrote:
> Hello,
>
> Today, serv
Hello,
Today, server, where is secondary storage, was turned off for 10min. After
it come back, cloudstack can't see secondary storage with templates and ISO
files.
Tryed to search how to reconnect - but did not found anything.
Any solution?
Virtualization: Xen
Secondary Storage: NFS
Hi all,
I'm trying to set up a test CloudStack installation, using two very basic
CentOS 6.8 servers (I previously tried with CentOS 7, but ran into the same
issue, so now I'm trying CentOS 6).
Basically I can get (almost) everything working, except for the *Add
host* stage,
where I get the error
Here is the structure of disk_offering_view in 4.8.0
+---+-+--+-+-+---+
| Field | Type| Null | Key | Default | Extra |
+---+-+--+-+-+---+
| id
22 matches
Mail list logo
