Re: KVM Agent Error: Incorrect details for private Nic
Excellent, glad you got it up and running.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 11/01/2019, 16:13, "Daniel Farrar" wrote:
This set me straight, much appreciated! Was over-complicating my demo
setup, got rid of all vlans for Public and Management networks while leaving
Guest networks with a VLAN range. No issues now.
Daniel Farrar
-Original Message-
From: Dag Sonstebo
Sent: Thursday, January 10, 2019 11:42 AM
To: users@cloudstack.apache.org
Subject: Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel,
Yes makes sense and this is your simplest setup. Just remembered I updated
this blog post a couple of months back - it should see you right
https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 10/01/2019, 16:37, "Daniel Farrar"
wrote:
Thank you Dag, this looks very likely to be the case. I was able to
find a scenario yesterday that brought the service up by setting eno1.8 type to
Ethernet, disabling eno1.8, restarting the agent service, then re-enabling
eno1.8 as type Vlan. My intended design was to create a 2 NIC bond (for now
just single NIC eno1 for troubleshooting), create subinterfaces (ex eno1.8 for
vlan8), and assign each subinterface to a cloudstack service. I will try
letting Cloudstack take care of all vlans and remove the subinterface, pointing
cloudbr0 directly to eno1 or bond.
Daniel Farrar
-Original Message-
From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com]
Sent: Wednesday, January 9, 2019 10:38 AM
To: users@cloudstack.apache.org
Subject: Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel,
My initial guess without deep diving into this is your NIC naming. The
CloudStack agent looks for the interface (bond / NIC / team) which supports
cloudbr0 - and I think maybe in your case it can't find it due to the dotted
naming "eno1.8" when it probably expects some conventional like "eno16777984".
Is there a reason you've named it like this? This would normally point
to a VLAN setup (whereas cloudbr0 needs to be trunked in an advanced zone).
If not can you rename it?
Code for this is somewhere around here I think:
https://github.com/apache/cloudstack/blob/c565db2cf2ab5fdbd2fba65409928dfa7c5f2d25/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1312
Developers - please correct me if I'm wrong.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 09/01/2019, 14:08, "Daniel Farrar"
wrote:
Hello! Wanted to see if anyone else has ran into this issue or if
you can point me in the right direction...
I have 2 KVM CloudStack-agents version 4.11.2 running Centos7 that
are not able to start the cloudstack-agent service if the agent.propreties file
specifies the variable "private.network.device=cloudbr0". This is
automatically added to the config file when the agent connects to the server,
if the private network is commented out the service is able to start up but any
system VMs are unable to connect to the network. This environment was working
with my original 2 KVM agents, but after deleting the hosts and rebuilding with
identical network config I've ran into this issue. I have logs and configs
below, any ideas what is wrong? This is a dev proof of concept environment, so
I can rebuild if needed. Thank you for your time!
2019-01-07 15:36:10,257 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Agent started
2019-01-07 15:36:10,259 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Implementation Version is 4.11.2.0
2019-01-07 15:36:10,260 INFO [cloud.agent.AgentShell] (main:null)
(logid:) agent.properties found at /etc/cloudstack/agent/agent.properties
2019-01-07 15:36:10,271 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Defaulting to using properties file for storage
2019-01-07 15:36:10,272 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Defaulting to the constant time backoff algorithm
2019-01-07 15:36:10,282 INFO [cloud.utils.LogUtils] (main:null)
(logid:) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2019-01-07 15:36:10,293 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Using default Java settings for IPv6 preference for agent connection
2019-01-07 15:36:10,384 INFO [cloud.agent.Agent] (main:null)
(logid:) id is 15
2019
RE: KVM Agent Error: Incorrect details for private Nic
This set me straight, much appreciated! Was over-complicating my demo setup,
got rid of all vlans for Public and Management networks while leaving Guest
networks with a VLAN range. No issues now.
Daniel Farrar
-Original Message-
From: Dag Sonstebo
Sent: Thursday, January 10, 2019 11:42 AM
To: users@cloudstack.apache.org
Subject: Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel,
Yes makes sense and this is your simplest setup. Just remembered I updated this
blog post a couple of months back - it should see you right
https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 10/01/2019, 16:37, "Daniel Farrar" wrote:
Thank you Dag, this looks very likely to be the case. I was able to find a
scenario yesterday that brought the service up by setting eno1.8 type to
Ethernet, disabling eno1.8, restarting the agent service, then re-enabling
eno1.8 as type Vlan. My intended design was to create a 2 NIC bond (for now
just single NIC eno1 for troubleshooting), create subinterfaces (ex eno1.8 for
vlan8), and assign each subinterface to a cloudstack service. I will try
letting Cloudstack take care of all vlans and remove the subinterface, pointing
cloudbr0 directly to eno1 or bond.
Daniel Farrar
-Original Message-
From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com]
Sent: Wednesday, January 9, 2019 10:38 AM
To: users@cloudstack.apache.org
Subject: Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel,
My initial guess without deep diving into this is your NIC naming. The
CloudStack agent looks for the interface (bond / NIC / team) which supports
cloudbr0 - and I think maybe in your case it can't find it due to the dotted
naming "eno1.8" when it probably expects some conventional like "eno16777984".
Is there a reason you've named it like this? This would normally point to a
VLAN setup (whereas cloudbr0 needs to be trunked in an advanced zone).
If not can you rename it?
Code for this is somewhere around here I think:
https://github.com/apache/cloudstack/blob/c565db2cf2ab5fdbd2fba65409928dfa7c5f2d25/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1312
Developers - please correct me if I'm wrong.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 09/01/2019, 14:08, "Daniel Farrar"
wrote:
Hello! Wanted to see if anyone else has ran into this issue or if you
can point me in the right direction...
I have 2 KVM CloudStack-agents version 4.11.2 running Centos7 that are
not able to start the cloudstack-agent service if the agent.propreties file
specifies the variable "private.network.device=cloudbr0". This is
automatically added to the config file when the agent connects to the server,
if the private network is commented out the service is able to start up but any
system VMs are unable to connect to the network. This environment was working
with my original 2 KVM agents, but after deleting the hosts and rebuilding with
identical network config I've ran into this issue. I have logs and configs
below, any ideas what is wrong? This is a dev proof of concept environment, so
I can rebuild if needed. Thank you for your time!
2019-01-07 15:36:10,257 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Agent started
2019-01-07 15:36:10,259 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Implementation Version is 4.11.2.0
2019-01-07 15:36:10,260 INFO [cloud.agent.AgentShell] (main:null)
(logid:) agent.properties found at /etc/cloudstack/agent/agent.properties
2019-01-07 15:36:10,271 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Defaulting to using properties file for storage
2019-01-07 15:36:10,272 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Defaulting to the constant time backoff algorithm
2019-01-07 15:36:10,282 INFO [cloud.utils.LogUtils] (main:null)
(logid:) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2019-01-07 15:36:10,293 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Using default Java settings for IPv6 preference for agent connection
2019-01-07 15:36:10,384 INFO [cloud.agent.Agent] (main:null) (logid:)
id is 15
2019-01-07 15:36:10,387 WARN [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during initialization of
ServerResourceBase
2019-01-07 15:36:10,387 ERROR [cloud.agent.AgentShell] (main:null)
(logid:) Unable to start agent: Unable to configure LibvirtComputingResource
This occurs on version 4.11.1 and 4.11.2, and I've seen other threads
with this i
Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel,
Yes makes sense and this is your simplest setup. Just remembered I updated this
blog post a couple of months back - it should see you right
https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 10/01/2019, 16:37, "Daniel Farrar" wrote:
Thank you Dag, this looks very likely to be the case. I was able to find a
scenario yesterday that brought the service up by setting eno1.8 type to
Ethernet, disabling eno1.8, restarting the agent service, then re-enabling
eno1.8 as type Vlan. My intended design was to create a 2 NIC bond (for now
just single NIC eno1 for troubleshooting), create subinterfaces (ex eno1.8 for
vlan8), and assign each subinterface to a cloudstack service. I will try
letting Cloudstack take care of all vlans and remove the subinterface, pointing
cloudbr0 directly to eno1 or bond.
Daniel Farrar
-Original Message-
From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com]
Sent: Wednesday, January 9, 2019 10:38 AM
To: users@cloudstack.apache.org
Subject: Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel,
My initial guess without deep diving into this is your NIC naming. The
CloudStack agent looks for the interface (bond / NIC / team) which supports
cloudbr0 - and I think maybe in your case it can't find it due to the dotted
naming "eno1.8" when it probably expects some conventional like "eno16777984".
Is there a reason you've named it like this? This would normally point to a
VLAN setup (whereas cloudbr0 needs to be trunked in an advanced zone).
If not can you rename it?
Code for this is somewhere around here I think:
https://github.com/apache/cloudstack/blob/c565db2cf2ab5fdbd2fba65409928dfa7c5f2d25/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1312
Developers - please correct me if I'm wrong.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 09/01/2019, 14:08, "Daniel Farrar"
wrote:
Hello! Wanted to see if anyone else has ran into this issue or if you
can point me in the right direction...
I have 2 KVM CloudStack-agents version 4.11.2 running Centos7 that are
not able to start the cloudstack-agent service if the agent.propreties file
specifies the variable "private.network.device=cloudbr0". This is
automatically added to the config file when the agent connects to the server,
if the private network is commented out the service is able to start up but any
system VMs are unable to connect to the network. This environment was working
with my original 2 KVM agents, but after deleting the hosts and rebuilding with
identical network config I've ran into this issue. I have logs and configs
below, any ideas what is wrong? This is a dev proof of concept environment, so
I can rebuild if needed. Thank you for your time!
2019-01-07 15:36:10,257 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Agent started
2019-01-07 15:36:10,259 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Implementation Version is 4.11.2.0
2019-01-07 15:36:10,260 INFO [cloud.agent.AgentShell] (main:null)
(logid:) agent.properties found at /etc/cloudstack/agent/agent.properties
2019-01-07 15:36:10,271 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Defaulting to using properties file for storage
2019-01-07 15:36:10,272 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Defaulting to the constant time backoff algorithm
2019-01-07 15:36:10,282 INFO [cloud.utils.LogUtils] (main:null)
(logid:) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
2019-01-07 15:36:10,293 INFO [cloud.agent.AgentShell] (main:null)
(logid:) Using default Java settings for IPv6 preference for agent connection
2019-01-07 15:36:10,384 INFO [cloud.agent.Agent] (main:null) (logid:)
id is 15
2019-01-07 15:36:10,387 WARN [cloud.resource.ServerResourceBase]
(main:null) (logid:) Incorrect details for private Nic during initialization of
ServerResourceBase
2019-01-07 15:36:10,387 ERROR [cloud.agent.AgentShell] (main:null)
(logid:) Unable to start agent: Unable to configure LibvirtComputingResource
This occurs on version 4.11.1 and 4.11.2, and I've seen other threads
with this issue on earlier versions that reported downgrading the agent fixed
this issue.
NIC CONFIGURATION:
ifcfg-cloudbr0
DEVICE=cloudbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes
Ifcfg-eno1.8
HWADDR=XX:XX:XX:XX:XX:XX
RE: KVM Agent Error: Incorrect details for private Nic
Thank you Dag, this looks very likely to be the case. I was able to find a scenario yesterday that brought the service up by setting eno1.8 type to Ethernet, disabling eno1.8, restarting the agent service, then re-enabling eno1.8 as type Vlan. My intended design was to create a 2 NIC bond (for now just single NIC eno1 for troubleshooting), create subinterfaces (ex eno1.8 for vlan8), and assign each subinterface to a cloudstack service. I will try letting Cloudstack take care of all vlans and remove the subinterface, pointing cloudbr0 directly to eno1 or bond. Daniel Farrar -Original Message- From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com] Sent: Wednesday, January 9, 2019 10:38 AM To: users@cloudstack.apache.org Subject: Re: KVM Agent Error: Incorrect details for private Nic Hi Daniel, My initial guess without deep diving into this is your NIC naming. The CloudStack agent looks for the interface (bond / NIC / team) which supports cloudbr0 - and I think maybe in your case it can't find it due to the dotted naming "eno1.8" when it probably expects some conventional like "eno16777984". Is there a reason you've named it like this? This would normally point to a VLAN setup (whereas cloudbr0 needs to be trunked in an advanced zone). If not can you rename it? Code for this is somewhere around here I think: https://github.com/apache/cloudstack/blob/c565db2cf2ab5fdbd2fba65409928dfa7c5f2d25/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1312 Developers - please correct me if I'm wrong. Regards, Dag Sonstebo Cloud Architect ShapeBlue On 09/01/2019, 14:08, "Daniel Farrar" wrote: Hello! Wanted to see if anyone else has ran into this issue or if you can point me in the right direction... I have 2 KVM CloudStack-agents version 4.11.2 running Centos7 that are not able to start the cloudstack-agent service if the agent.propreties file specifies the variable "private.network.device=cloudbr0". This is automatically added to the config file when the agent connects to the server, if the private network is commented out the service is able to start up but any system VMs are unable to connect to the network. This environment was working with my original 2 KVM agents, but after deleting the hosts and rebuilding with identical network config I've ran into this issue. I have logs and configs below, any ideas what is wrong? This is a dev proof of concept environment, so I can rebuild if needed. Thank you for your time! 2019-01-07 15:36:10,257 INFO [cloud.agent.AgentShell] (main:null) (logid:) Agent started 2019-01-07 15:36:10,259 INFO [cloud.agent.AgentShell] (main:null) (logid:) Implementation Version is 4.11.2.0 2019-01-07 15:36:10,260 INFO [cloud.agent.AgentShell] (main:null) (logid:) agent.properties found at /etc/cloudstack/agent/agent.properties 2019-01-07 15:36:10,271 INFO [cloud.agent.AgentShell] (main:null) (logid:) Defaulting to using properties file for storage 2019-01-07 15:36:10,272 INFO [cloud.agent.AgentShell] (main:null) (logid:) Defaulting to the constant time backoff algorithm 2019-01-07 15:36:10,282 INFO [cloud.utils.LogUtils] (main:null) (logid:) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml 2019-01-07 15:36:10,293 INFO [cloud.agent.AgentShell] (main:null) (logid:) Using default Java settings for IPv6 preference for agent connection 2019-01-07 15:36:10,384 INFO [cloud.agent.Agent] (main:null) (logid:) id is 15 2019-01-07 15:36:10,387 WARN [cloud.resource.ServerResourceBase] (main:null) (logid:) Incorrect details for private Nic during initialization of ServerResourceBase 2019-01-07 15:36:10,387 ERROR [cloud.agent.AgentShell] (main:null) (logid:) Unable to start agent: Unable to configure LibvirtComputingResource This occurs on version 4.11.1 and 4.11.2, and I've seen other threads with this issue on earlier versions that reported downgrading the agent fixed this issue. NIC CONFIGURATION: ifcfg-cloudbr0 DEVICE=cloudbr0 TYPE=Bridge ONBOOT=yes BOOTPROTO=none IPV6INIT=no IPV6_AUTOCONF=no DELAY=5 STP=yes Ifcfg-eno1.8 HWADDR=XX:XX:XX:XX:XX:XX DEVICE=eno1.8 ONBOOT=yes HOTPLUG=no BOOTPROTO=none TYPE=Vlan VLAN=yes BRIDGE=cloudbr0 cloudbr0: flags=4163 mtu 1500 ether txqueuelen 1000 (Ethernet) RX packets 2368 bytes 116316 (113.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3 bytes 270 (270.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eno1.8: flags=4163 mtu 1500 ether txqueuelen 1000 (Ethernet) RX packets 3159 bytes 163465 (159.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0
Re: KVM Agent Error: Incorrect details for private Nic
Hi Daniel, My initial guess without deep diving into this is your NIC naming. The CloudStack agent looks for the interface (bond / NIC / team) which supports cloudbr0 - and I think maybe in your case it can't find it due to the dotted naming "eno1.8" when it probably expects some conventional like "eno16777984". Is there a reason you've named it like this? This would normally point to a VLAN setup (whereas cloudbr0 needs to be trunked in an advanced zone). If not can you rename it? Code for this is somewhere around here I think: https://github.com/apache/cloudstack/blob/c565db2cf2ab5fdbd2fba65409928dfa7c5f2d25/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1312 Developers - please correct me if I'm wrong. Regards, Dag Sonstebo Cloud Architect ShapeBlue On 09/01/2019, 14:08, "Daniel Farrar" wrote: Hello! Wanted to see if anyone else has ran into this issue or if you can point me in the right direction... I have 2 KVM CloudStack-agents version 4.11.2 running Centos7 that are not able to start the cloudstack-agent service if the agent.propreties file specifies the variable "private.network.device=cloudbr0". This is automatically added to the config file when the agent connects to the server, if the private network is commented out the service is able to start up but any system VMs are unable to connect to the network. This environment was working with my original 2 KVM agents, but after deleting the hosts and rebuilding with identical network config I've ran into this issue. I have logs and configs below, any ideas what is wrong? This is a dev proof of concept environment, so I can rebuild if needed. Thank you for your time! 2019-01-07 15:36:10,257 INFO [cloud.agent.AgentShell] (main:null) (logid:) Agent started 2019-01-07 15:36:10,259 INFO [cloud.agent.AgentShell] (main:null) (logid:) Implementation Version is 4.11.2.0 2019-01-07 15:36:10,260 INFO [cloud.agent.AgentShell] (main:null) (logid:) agent.properties found at /etc/cloudstack/agent/agent.properties 2019-01-07 15:36:10,271 INFO [cloud.agent.AgentShell] (main:null) (logid:) Defaulting to using properties file for storage 2019-01-07 15:36:10,272 INFO [cloud.agent.AgentShell] (main:null) (logid:) Defaulting to the constant time backoff algorithm 2019-01-07 15:36:10,282 INFO [cloud.utils.LogUtils] (main:null) (logid:) log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml 2019-01-07 15:36:10,293 INFO [cloud.agent.AgentShell] (main:null) (logid:) Using default Java settings for IPv6 preference for agent connection 2019-01-07 15:36:10,384 INFO [cloud.agent.Agent] (main:null) (logid:) id is 15 2019-01-07 15:36:10,387 WARN [cloud.resource.ServerResourceBase] (main:null) (logid:) Incorrect details for private Nic during initialization of ServerResourceBase 2019-01-07 15:36:10,387 ERROR [cloud.agent.AgentShell] (main:null) (logid:) Unable to start agent: Unable to configure LibvirtComputingResource This occurs on version 4.11.1 and 4.11.2, and I've seen other threads with this issue on earlier versions that reported downgrading the agent fixed this issue. NIC CONFIGURATION: ifcfg-cloudbr0 DEVICE=cloudbr0 TYPE=Bridge ONBOOT=yes BOOTPROTO=none IPV6INIT=no IPV6_AUTOCONF=no DELAY=5 STP=yes Ifcfg-eno1.8 HWADDR=XX:XX:XX:XX:XX:XX DEVICE=eno1.8 ONBOOT=yes HOTPLUG=no BOOTPROTO=none TYPE=Vlan VLAN=yes BRIDGE=cloudbr0 cloudbr0: flags=4163 mtu 1500 ether txqueuelen 1000 (Ethernet) RX packets 2368 bytes 116316 (113.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3 bytes 270 (270.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eno1.8: flags=4163 mtu 1500 ether txqueuelen 1000 (Ethernet) RX packets 3159 bytes 163465 (159.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1752 bytes 91924 (89.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 brctl show bridge name bridge id STP enabled interfaces cloud0 8000.fe00a9fe00fc no vnet0 vnet3 cloudbr08000.64510630b869 yes eno1.8 vnet2 vnet5 cloudbr18000.64510630b869 yes eno1.7 vnet1 vnet4 virbr0 8000.525400b79d7d yes virbr0-nic Agent.properties file networks:
