date:20160829

RE: Incorrect details for private Nic

2016-08-29 Thread Simon Weller

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 [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

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] (main:null) (logid:) id is
2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

[root@node1 ~]# service cloudstack-agent status
cloudstack-agent dead but subsys locked


Thanks for your help so far, do you have any other suggestions? The next
thing I was going to try was downgrading to 4.8 and trying that version.

On 30 August 2016 at 00:40, Simon Weller  wrote:

> 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-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 10:08AM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> 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
> changed back):
>
>
> [root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
> 2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
>
> 2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Agent started
> 2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Implementation Version is 4.9.0
> 2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> agent.properties found at /etc/cloudstack/agent/agent.properties
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: guest.network.device
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: workers
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: private.network.device
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: port
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: resource
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: pod
> 2016-08-30 00:07:29,915

Re: Incorrect details for private Nic

2016-08-29 Thread John Cenile

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] (main:null) (logid:) id is
2016-08-30 12:28:50,924 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,932 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 12:28:50,935 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 12:28:50,935 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

[root@node1 ~]# service cloudstack-agent status
cloudstack-agent dead but subsys locked


Thanks for your help so far, do you have any other suggestions? The next
thing I was going to try was downgrading to 4.8 and trying that version.

On 30 August 2016 at 00:40, Simon Weller  wrote:

> 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-
> From: John Cenile [jcenile1...@gmail.com]
> Received: Monday, 29 Aug 2016, 10:08AM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: Re: Incorrect details for private Nic
>
> 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
> changed back):
>
>
> [root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
> 2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: eth0.200
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
>
> 2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Agent started
> 2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Implementation Version is 4.9.0
> 2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> agent.properties found at /etc/cloudstack/agent/agent.properties
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: guest.network.device
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: workers
> 2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: private.network.device
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: port
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: resource
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: pod
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: zone
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: guid
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: hypervisor.type
> 2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found

RE: Incorrect details for private Nic

2016-08-29 Thread Simon Weller

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-
From: John Cenile [jcenile1...@gmail.com]
Received: Monday, 29 Aug 2016, 10:08AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

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
changed back):


[root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource



2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Agent started
2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Implementation Version is 4.9.0
2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
agent.properties found at /etc/cloudstack/agent/agent.properties
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guest.network.device
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: workers
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: private.network.device
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: port
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: resource
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: pod
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: zone
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guid
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: hypervisor.type
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: cluster
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: public.network.device
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: local.storage.uuid
2016-08-30 00:07:29,916 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: domr.scripts.dir
2016-08-30 00:07:29,916 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: host
2016-08-30 00:07:29,916 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to using properties file for storage
2016-08-30 00:07:29,918 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to the constant time backoff algorithm
2016-08-30 00:07:29,935 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-08-30 00:07:29,951 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Using default Java settings for IPv6 preference for agent connection
2016-08-30 00:07:29,951 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:07:29,959 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:07:29,964 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:07:30,020 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 00:07:30,021 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 00:07:30,028 DEBUG [cloud.resource.ServerResourceBase]

Re: Incorrect details for private Nic

2016-08-29 Thread John Cenile

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
changed back):


[root@node1 ~]# tail -f /var/log/cloudstack/agent/agent.log
2016-08-30 00:06:34,789 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:06:34,798 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:06:34,803 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:06:34,853 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 00:06:34,853 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: eth0.200
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,856 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:06:34,859 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 00:06:34,859 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource



2016-08-30 00:07:29,905 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Agent started
2016-08-30 00:07:29,907 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Implementation Version is 4.9.0
2016-08-30 00:07:29,909 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
agent.properties found at /etc/cloudstack/agent/agent.properties
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guest.network.device
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: workers
2016-08-30 00:07:29,914 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: private.network.device
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: port
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: resource
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: pod
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: zone
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guid
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: hypervisor.type
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: cluster
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: public.network.device
2016-08-30 00:07:29,915 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: local.storage.uuid
2016-08-30 00:07:29,916 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: domr.scripts.dir
2016-08-30 00:07:29,916 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: host
2016-08-30 00:07:29,916 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to using properties file for storage
2016-08-30 00:07:29,918 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to the constant time backoff algorithm
2016-08-30 00:07:29,935 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-08-30 00:07:29,951 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Using default Java settings for IPv6 preference for agent connection
2016-08-30 00:07:29,951 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-30 00:07:29,959 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-30 00:07:29,964 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-30 00:07:30,020 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-30 00:07:30,021 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 00:07:30,028 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-30 00:07:30,029 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:07:30,029 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-30 00:07:30,031 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-30 00:07:30,032

RE: Incorrect details for private Nic

2016-08-29 Thread Simon Weller

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 [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

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 CloudStack's website actually recommends this set up (having a
VLAN interface plugged into the bridge).

For a testing setup, that will never have production servers on it, how
would you recommend setting up the interfaces? Just an eth0 -> cloudbr0 and
eth1 -> cloudbr1?

Re: Incorrect details for private Nic

2016-08-29 Thread John Cenile

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 CloudStack's website actually recommends this set up (having a
VLAN interface plugged into the bridge).

For a testing setup, that will never have production servers on it, how
would you recommend setting up the interfaces? Just an eth0 -> cloudbr0 and
eth1 -> cloudbr1?

RE: Incorrect details for private Nic

2016-08-29 Thread Simon Weller

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: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

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
cloudbr18000.bcaec529ec9a   yes eth0.300
virbr0  8000.5254001fbe67   yes virbr0-nic

On 29 August 2016 at 21:57, Simon Weller  wrote:

> Also, what are your kvm traffic labels set to? Do you have multiple
> physical networks configured in mgmt?

I haven't actually changed these, so I *assume* these are the default of
cloudbr0 and cloudbr1? No, I only have one physical network configured on
the management server.

Re: Incorrect details for private Nic

2016-08-29 Thread John Cenile

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:

> Does the kvm server can tcp connect on the mgt server port 8250?

Yes it can:

[root@node1 ~]# nc -z 10.1.1.1 8250
Connection to 10.1.1.1 8250 port [tcp/*] succeeded!

On 29 August 2016 at 21:33, Simon Weller  wrote:

> Can you place the agent in debug mode and post the output?

Sure, here's the log output:

2016-08-29 21:50:18,650 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Agent started
2016-08-29 21:50:18,653 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Implementation Version is 4.9.0
2016-08-29 21:50:18,654 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
agent.properties found at /etc/cloudstack/agent/agent.properties
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guest.network.device
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: workers
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: private.network.device
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: port
2016-08-29 21:50:18,660 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: resource
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: pod
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: zone
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: guid
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: hypervisor.type
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: cluster
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: public.network.device
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: local.storage.uuid
2016-08-29 21:50:18,661 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: domr.scripts.dir
2016-08-29 21:50:18,662 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: host
2016-08-29 21:50:18,662 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to using properties file for storage
2016-08-29 21:50:18,664 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to the constant time backoff algorithm
2016-08-29 21:50:18,681 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-08-29 21:50:18,697 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Using default Java settings for IPv6 preference for agent connection
2016-08-29 21:50:18,697 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-29 21:50:18,706 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-29 21:50:18,712 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-29 21:50:18,768 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-29 21:50:18,769 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-29 21:50:18,776 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-29 21:50:18,777 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-29 21:50:18,777 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-29 21:50:18,780 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-29 21:50:18,780 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource

RE: Incorrect details for private Nic

2016-08-29 Thread Simon Weller

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/agent/log4j-cloud.xml

- Si

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: Pierre-Luc Dion [pd...@cloudops.com]
Received: Monday, 29 Aug 2016, 6:06AM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: Re: Incorrect details for private Nic

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 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 "Incorrect details for private Nic during
> initialization of ServerResourceBase" in the agent.log.
>
> I haven't edited the agent.properties file manually at all, I have followed
> the KVM agent configuration guide
>  9/hypervisor/kvm.html>
> perfectly as far as I can tell, as well as the Management Node
> configuration guide
>  9/management-server/index.html>
> .
>
> I have cloudbr0 and cloudbr1 bridge interfaces set up, as well as eth0
> which is the actual IP I'm connecting to.
>
> The only other thread I can find where someone had this issue, they ended
> up downgrading the agent, does that mean this is a known issue with 4.9? (
> https://www.mail-archive.com/users@cloudstack.apache.org/msg20717.html)
>
> Does anyone have any idea why I'm getting these errors? If there's any
> other logs / config files you need, please let me know.
>
> Thanks in advance.
>
> *Cloudstack Management: *4.9.0.1.el6
>
> *Cloudstack Agent:* 4.9.0.1.el6
>
> *Agent logs*
>
> [root@node1 ~]# tail -n 15 /var/log/cloudstack/agent/agent.log
> 2016-08-29 17:18:08,572 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: host
> 2016-08-29 17:18:08,572 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to using properties file for storage
> 2016-08-29 17:18:08,574 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to the constant time backoff algorithm
> 2016-08-29 17:18:08,591 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
> log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
> 2016-08-29 17:18:08,606 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Using default Java settings for IPv6 preference for agent connection
> 2016-08-29 17:18:08,607 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-29 17:18:08,615 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-29 17:18:08,620 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-29 17:18:08,670 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-29 17:18:08,670 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,673 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,676 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-29 17:18:08,677 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
> Agent properties
>
> [root@node1 ~]# cat /etc/cloudstack/agent/agent.properties | sed -e
> '/^#/d'
> | sed -e '/^$/d'
> guid=b02788c7-20fc-30cd-a391-f2abaf002019
> resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
> workers=5
> host=10.1.1.1
> port=8250
> cluster=1
> pod=1
> zone=1
> local.storage.uuid=525850bd-64fa-4eba-89e1-c0af4fb49621
> domr.scripts.dir=scripts/network/domr/kvm
> hypervisor.type=kvm
> private.network.device=cloudbr0
> public.network.device=cloudbr0
> guest.network.device=cloudbr0
>
>
> *Master ifconfig output*
>
> [root@master ~]# ifconfig
> eth0  Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
>   inet addr:10.1.1.1  Bcast:10.1.1.255 Mask:255.255.255.0
>   UP BROADCAST

Re: Incorrect details for private Nic

2016-08-29 Thread Pierre-Luc Dion

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 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 "Incorrect details for private Nic during
> initialization of ServerResourceBase" in the agent.log.
>
> I haven't edited the agent.properties file manually at all, I have followed
> the KVM agent configuration guide
>  9/hypervisor/kvm.html>
> perfectly as far as I can tell, as well as the Management Node
> configuration guide
>  9/management-server/index.html>
> .
>
> I have cloudbr0 and cloudbr1 bridge interfaces set up, as well as eth0
> which is the actual IP I'm connecting to.
>
> The only other thread I can find where someone had this issue, they ended
> up downgrading the agent, does that mean this is a known issue with 4.9? (
> https://www.mail-archive.com/users@cloudstack.apache.org/msg20717.html)
>
> Does anyone have any idea why I'm getting these errors? If there's any
> other logs / config files you need, please let me know.
>
> Thanks in advance.
>
> *Cloudstack Management: *4.9.0.1.el6
>
> *Cloudstack Agent:* 4.9.0.1.el6
>
> *Agent logs*
>
> [root@node1 ~]# tail -n 15 /var/log/cloudstack/agent/agent.log
> 2016-08-29 17:18:08,572 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Found property: host
> 2016-08-29 17:18:08,572 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to using properties file for storage
> 2016-08-29 17:18:08,574 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Defaulting to the constant time backoff algorithm
> 2016-08-29 17:18:08,591 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
> log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
> 2016-08-29 17:18:08,606 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
> Using default Java settings for IPv6 preference for agent connection
> 2016-08-29 17:18:08,607 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
> Checking to see if agent.pid exists.
> 2016-08-29 17:18:08,615 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Executing: bash -c echo $PPID
> 2016-08-29 17:18:08,620 DEBUG [cloud.utils.ProcessUtil] (main:null)
> (logid:) Execution is successful.
> 2016-08-29 17:18:08,670 INFO  [cloud.agent.Agent] (main:null) (logid:) id
> is
> 2016-08-29 17:18:08,670 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,673 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: cloudbr0
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Retrieving network interface: null
> 2016-08-29 17:18:08,676 WARN  [cloud.resource.ServerResourceBase]
> (main:null) (logid:) Incorrect details for private Nic during
> initialization of ServerResourceBase
> 2016-08-29 17:18:08,677 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
> Unable to start agent: Unable to configure LibvirtComputingResource
>
>
> Agent properties
>
> [root@node1 ~]# cat /etc/cloudstack/agent/agent.properties | sed -e
> '/^#/d'
> | sed -e '/^$/d'
> guid=b02788c7-20fc-30cd-a391-f2abaf002019
> resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
> workers=5
> host=10.1.1.1
> port=8250
> cluster=1
> pod=1
> zone=1
> local.storage.uuid=525850bd-64fa-4eba-89e1-c0af4fb49621
> domr.scripts.dir=scripts/network/domr/kvm
> hypervisor.type=kvm
> private.network.device=cloudbr0
> public.network.device=cloudbr0
> guest.network.device=cloudbr0
>
>
> *Master ifconfig output*
>
> [root@master ~]# ifconfig
> eth0  Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
>   inet addr:10.1.1.1  Bcast:10.1.1.255 Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:350162 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:135250 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:342643150 (326.7 MiB)  TX bytes:12230569 (11.6 MiB)
>   Interrupt:18 Memory:fbce-fbd0
>
>
> *Agent ifconfig output*
>
> [root@node1 ~]# ifconfig
> cloud0Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
>   inet addr:169.254.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500

RE: Reconnect secondary storage NFS

2016-08-29 Thread Mohd Zainal Abidin Rabani

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 helped.

Re: Reconnect secondary storage NFS

2016-08-29 Thread Mindaugas Milinavičius

Looks like fixed, strange story, but only after reconfigure eth port in
management server, i get it up.

Re: Reconnect secondary storage NFS

2016-08-29 Thread Makrand

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, did not helped.
>

Re: Reconnect secondary storage NFS

2016-08-29 Thread Mindaugas Milinavičius

Yes, did not helped.

RE: Reconnect secondary storage NFS

2016-08-29 Thread Mohd Zainal Abidin Rabani

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, 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:)

Re: Reconnect secondary storage NFS

2016-08-29 Thread Mindaugas Milinavičius

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:)

Re: Reconnect secondary storage NFS

2016-08-29 Thread Makrand

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, 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
>

Reconnect secondary storage NFS

2016-08-29 Thread Mindaugas Milinavičius

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

Incorrect details for private Nic

2016-08-29 Thread John Cenile

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 "Incorrect details for private Nic during
initialization of ServerResourceBase" in the agent.log.

I haven't edited the agent.properties file manually at all, I have followed
the KVM agent configuration guide

perfectly as far as I can tell, as well as the Management Node
configuration guide

.

I have cloudbr0 and cloudbr1 bridge interfaces set up, as well as eth0
which is the actual IP I'm connecting to.

The only other thread I can find where someone had this issue, they ended
up downgrading the agent, does that mean this is a known issue with 4.9? (
https://www.mail-archive.com/users@cloudstack.apache.org/msg20717.html)

Does anyone have any idea why I'm getting these errors? If there's any
other logs / config files you need, please let me know.

Thanks in advance.

*Cloudstack Management: *4.9.0.1.el6

*Cloudstack Agent:* 4.9.0.1.el6

*Agent logs*

[root@node1 ~]# tail -n 15 /var/log/cloudstack/agent/agent.log
2016-08-29 17:18:08,572 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Found property: host
2016-08-29 17:18:08,572 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to using properties file for storage
2016-08-29 17:18:08,574 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Defaulting to the constant time backoff algorithm
2016-08-29 17:18:08,591 INFO  [cloud.utils.LogUtils] (main:null) (logid:)
log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2016-08-29 17:18:08,606 INFO  [cloud.agent.AgentShell] (main:null) (logid:)
Using default Java settings for IPv6 preference for agent connection
2016-08-29 17:18:08,607 DEBUG [cloud.agent.AgentShell] (main:null) (logid:)
Checking to see if agent.pid exists.
2016-08-29 17:18:08,615 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Executing: bash -c echo $PPID
2016-08-29 17:18:08,620 DEBUG [cloud.utils.ProcessUtil] (main:null)
(logid:) Execution is successful.
2016-08-29 17:18:08,670 INFO  [cloud.agent.Agent] (main:null) (logid:) id is
2016-08-29 17:18:08,670 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-29 17:18:08,673 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: cloudbr0
2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-29 17:18:08,674 DEBUG [cloud.resource.ServerResourceBase]
(main:null) (logid:) Retrieving network interface: null
2016-08-29 17:18:08,676 WARN  [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during
initialization of ServerResourceBase
2016-08-29 17:18:08,677 ERROR [cloud.agent.AgentShell] (main:null) (logid:)
Unable to start agent: Unable to configure LibvirtComputingResource


Agent properties

[root@node1 ~]# cat /etc/cloudstack/agent/agent.properties | sed -e '/^#/d'
| sed -e '/^$/d'
guid=b02788c7-20fc-30cd-a391-f2abaf002019
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
workers=5
host=10.1.1.1
port=8250
cluster=1
pod=1
zone=1
local.storage.uuid=525850bd-64fa-4eba-89e1-c0af4fb49621
domr.scripts.dir=scripts/network/domr/kvm
hypervisor.type=kvm
private.network.device=cloudbr0
public.network.device=cloudbr0
guest.network.device=cloudbr0


*Master ifconfig output*

[root@master ~]# ifconfig
eth0  Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
  inet addr:10.1.1.1  Bcast:10.1.1.255 Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:350162 errors:0 dropped:0 overruns:0 frame:0
  TX packets:135250 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:342643150 (326.7 MiB)  TX bytes:12230569 (11.6 MiB)
  Interrupt:18 Memory:fbce-fbd0


*Agent ifconfig output*

[root@node1 ~]# ifconfig
cloud0Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
  inet addr:169.254.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 b)  TX bytes:648 (648.0 b)

cloudbr0  Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0

Re: KVM disk cache option has no effect

2016-08-29 Thread (IMIS) Enzo Bettini


Here is the structure of disk_offering_view in 4.8.0

+---+-+--+-+-+---+
| Field | Type| Null | Key | Default | Extra |
+---+-+--+-+-+---+
| id| bigint(20) unsigned | NO   | | 0 |   |
| uuid  | varchar(40) | YES  | | NULL |   |
| name  | varchar(255)| NO   | | NULL |   |
| display_text  | varchar(4096)   | YES  | | NULL |   |
| provisioning_type | varchar(32) | NO   | | thin |   |
| disk_size | bigint(20) unsigned | NO   | | NULL |   |
| min_iops  | bigint(20) unsigned | YES  | | NULL |   |
| max_iops  | bigint(20) unsigned | YES  | | NULL |   |
| created   | datetime| YES  | | NULL |   |
| tags  | varchar(4096)   | YES  | | NULL |   |
| customized| tinyint(1) unsigned | NO   | | 0 |   |
| customized_iops   | tinyint(1) unsigned | YES  | | NULL |   |
| removed   | datetime| YES  | | NULL |   |
| use_local_storage | tinyint(1) unsigned | NO   | | 0 |   |
| system_use| tinyint(1) unsigned | NO   | | 0 |   |
| hv_ss_reserve | int(32) unsigned| YES  | | NULL |   |
| bytes_read_rate   | bigint(20)  | YES  | | NULL |   |
| bytes_write_rate  | bigint(20)  | YES  | | NULL |   |
| iops_read_rate| bigint(20)  | YES  | | NULL |   |
| iops_write_rate   | bigint(20)  | YES  | | NULL |   |
| cache_mode| varchar(16) | YES  | | none |   |
| sort_key  | int(32) | NO   | | 0 |   |
| type  | varchar(32) | YES  | | NULL |   |
| display_offering  | tinyint(1)  | NO   | | 1 |   |
| domain_id | bigint(20) unsigned | YES  | | 0 |   |
| domain_uuid   | varchar(40) | YES  | | NULL |   |
| domain_name   | varchar(255)| YES  | | NULL |   |
| domain_path   | varchar(255)| YES  | | NULL |   |
+---+-+--+-+-+---+

On 29/08/2016 08:48, Yuriy Karpel wrote:

No table disk_offerings_view in 4.7.1. There is a table disk_offering with
this structure:

MariaDB [cloud]> SHOW COLUMNS FROM disk_offering;
+---+-+--+-+-++
| Field | Type| Null | Key | Default | Extra
|
+---+-+--+-+-++
| id| bigint(20) unsigned | NO   | PRI | NULL|
auto_increment |
| domain_id | bigint(20) unsigned | YES  | | NULL|
|
| name  | varchar(255)| NO   | | NULL|
|
| uuid  | varchar(40) | YES  | UNI | NULL|
|
| display_text  | varchar(4096)   | YES  | | NULL|
|
| disk_size | bigint(20) unsigned | NO   | | NULL|
|
| type  | varchar(32) | YES  | | NULL|
|
| tags  | varchar(4096)   | YES  | | NULL|
|
| recreatable   | tinyint(1) unsigned | NO   | | 0   |
|
| use_local_storage | tinyint(1) unsigned | NO   | | 0   |
|
| unique_name   | varchar(32) | YES  | UNI | NULL|
|
| system_use| tinyint(1) unsigned | NO   | | 0   |
|
| customized| tinyint(1) unsigned | NO   | | 0   |
|
| removed   | datetime| YES  | MUL | NULL|
|
| created   | datetime| YES  | | NULL|
|
| sort_key  | int(32) | NO   | | 0   |
|
| display_offering  | tinyint(1)  | NO   | | 1   |
|
| customized_iops   | tinyint(1) unsigned | YES  | | NULL|
|
| min_iops  | bigint(20) unsigned | YES  | | NULL|
|
| max_iops  | bigint(20) unsigned | YES  | | NULL|
|
| bytes_read_rate   | bigint(20)  | YES  | | NULL|
|
| bytes_write_rate  | bigint(20)  | YES  | | NULL|
|
| iops_read_rate| bigint(20)  | YES  | | NULL|
|
| iops_write_rate   | bigint(20)  | YES  | | NULL|
|
| state | char(40)| NO   | | Active  |
|
| hv_ss_reserve | int(32) unsigned| YES  | | NULL|
|
| cache_mode| varchar(16) | YES  | | none|
|
| provisioning_type | varchar(32) | NO   | | thin|
|

Re: KVM disk cache option has no effect

2016-08-29 Thread Yuriy Karpel

No table disk_offerings_view in 4.7.1. There is a table disk_offering with
this structure:

MariaDB [cloud]> SHOW COLUMNS FROM disk_offering;
+---+-+--+-+-++
| Field | Type| Null | Key | Default | Extra
   |
+---+-+--+-+-++
| id| bigint(20) unsigned | NO   | PRI | NULL|
auto_increment |
| domain_id | bigint(20) unsigned | YES  | | NULL|
   |
| name  | varchar(255)| NO   | | NULL|
   |
| uuid  | varchar(40) | YES  | UNI | NULL|
   |
| display_text  | varchar(4096)   | YES  | | NULL|
   |
| disk_size | bigint(20) unsigned | NO   | | NULL|
   |
| type  | varchar(32) | YES  | | NULL|
   |
| tags  | varchar(4096)   | YES  | | NULL|
   |
| recreatable   | tinyint(1) unsigned | NO   | | 0   |
   |
| use_local_storage | tinyint(1) unsigned | NO   | | 0   |
   |
| unique_name   | varchar(32) | YES  | UNI | NULL|
   |
| system_use| tinyint(1) unsigned | NO   | | 0   |
   |
| customized| tinyint(1) unsigned | NO   | | 0   |
   |
| removed   | datetime| YES  | MUL | NULL|
   |
| created   | datetime| YES  | | NULL|
   |
| sort_key  | int(32) | NO   | | 0   |
   |
| display_offering  | tinyint(1)  | NO   | | 1   |
   |
| customized_iops   | tinyint(1) unsigned | YES  | | NULL|
   |
| min_iops  | bigint(20) unsigned | YES  | | NULL|
   |
| max_iops  | bigint(20) unsigned | YES  | | NULL|
   |
| bytes_read_rate   | bigint(20)  | YES  | | NULL|
   |
| bytes_write_rate  | bigint(20)  | YES  | | NULL|
   |
| iops_read_rate| bigint(20)  | YES  | | NULL|
   |
| iops_write_rate   | bigint(20)  | YES  | | NULL|
   |
| state | char(40)| NO   | | Active  |
   |
| hv_ss_reserve | int(32) unsigned| YES  | | NULL|
   |
| cache_mode| varchar(16) | YES  | | none|
   |
| provisioning_type | varchar(32) | NO   | | thin|
   |
+---+-+--+-+-++
28 rows in set (0.00 sec)



| 151 | 4 | test_cache| a6c0b591-0ca7-4938-91f4-8ed961f490b6 | test_cache
 |  0 | Disk | NULL |  0 |  0 | NULL  |  0 |  1 | NULL | 2016-08-25
06:35:07 | 0 |1 | NULL | NULL | NULL |  NULL |  NULL | NULL | NULL
| Active   | NULL |writeback | thin  |


Can you show the structure of the table disk_offerings_view?


2016-08-25 15:06 GMT+03:00 Andrija Panic :

> Example (2 volumes on RBD,1 volume on NFS) - 4.5.1, Ubutnu 14.04
>
> 
>   
>   
> 
>   
>name='cold-storage/d8e3ee4a-c238-4afe-81b2-e06a0e19655e'>
> 
>   
>   
>   
> 41943040
> 20971520
> 100
> 100
>   
>   
>function='0x0'/>
> 
> 
>   
>   
> 
>   
>name='cold-storage/39a571d4-9b78-4a10-aa9e-8caa86dbb53a'>
> 
>   
>   
>   
> 125829120
> 125829120
> 1000
> 1000
>   
>   
>function='0x0'/>
> 
> 
>   
>file='/mnt/14d3778f-b635-3edb-b60e-d4eb917c/39e0f94a-
> 4454-47a2-b73e-2105f6838142'/>
>   
>   
> 125829120
> 125829120
> 1000
> 1000
>   
>   
>
> On 25 August 2016 at 14:02, Andrija Panic  wrote:
>
> > Guys, I', on 4.5.1, Ubuntu 14.04, and when I edit this field in
> > disk_offerings_view, it does work, and  ps aux | grep qemu clearly shows
> > cache=writeback
> >
> > so this might be broken later, and would be good to understand when
> > exactly, since we plan upgrade soon to 4.8 release...
> >
> > cheers
> >
> > On 25 August 2016 at 11:09, Andrei Mikhailovsky
>  > > wrote:
> >
> >> I've experimented by using virsh and virtual-manager gui app. The acs
> gui
> >> settings make no difference to the cache settings. I am surprised it has
> >> not been working for ages and no one actually fixed it.
> >>
> >> Cheers
> >>
> >> - Original Message -
> >> > From: "(IMIS) Enzo Bettini" 
> >> > To: "users" 
> >> > Sent: Wednesday, 24 August, 2016 09:24:50
> >> > Subject: Re: KVM disk cache option has no effect
> >>
> >> > Hi Andrei,
> >> >
> >> > How did you get around this? Did you manually update the VM
> >> > configuration using virsh edit?
> >> >
> >> >

RE: Incorrect details for private Nic

Re: Incorrect details for private Nic

RE: Incorrect details for private Nic

Re: Incorrect details for private Nic

RE: Incorrect details for private Nic

Re: Incorrect details for private Nic

RE: Incorrect details for private Nic

Re: Incorrect details for private Nic

RE: Incorrect details for private Nic

Re: Incorrect details for private Nic

RE: Reconnect secondary storage NFS

Re: Reconnect secondary storage NFS

Re: Reconnect secondary storage NFS

Re: Reconnect secondary storage NFS

RE: Reconnect secondary storage NFS

Re: Reconnect secondary storage NFS

Re: Reconnect secondary storage NFS

Reconnect secondary storage NFS

Incorrect details for private Nic

Re: KVM disk cache option has no effect

Re: KVM disk cache option has no effect

21 matches

Site Navigation

Mail list logo

Footer information