[jira] [Created] (CLOUDSTACK-9592) Empty responses from site to site connection status are not handled propertly

[subhash yedugundla (JIRA)]

subhash yedugundla created CLOUDSTACK-9592:
--

 Summary: Empty responses from site to site connection status are 
not handled propertly
 Key: CLOUDSTACK-9592
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9592
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.8.0
 Environment: Any Hypervisor
Reporter: subhash yedugundla
 Fix For: 4.8.1


vpn connection status gives responses like the below sometimes

Processing: { Ans: , MgmtId: 7203499016310, via: 1(10.147.28.37), Ver: v1, 
Flags: 110, 
[{"com.cloud.agent.api.CheckS2SVpnConnectionsAnswer":{"ipToConnected":{},"ipToDetail":{},"details":"","result":true,"wait":0}}]
 }
2016-09-27 08:52:19,211 DEBUG [c.c.a.t.Request] 
(RouterStatusMonitor-1:ctx-c20f391d) (logid:c217239d) Seq 
1-2315413158421863581: Received: { Ans: , MgmtId: 7203499016310, via: 
1(10.147.28.37), Ver: v1, Flags: 110,
{ CheckS2SVpnConnectionsAnswer }

In the above scenario, the bug in the processing of this response assumes the 
connection is disconnected even though it is not disconnected and there would 
be two consecutive alerts in logs as well as emails even though there is not 
actual disconnection and reconnection

Site-to-site Vpn Connection XYZ-VPN on router r-197-VM(id: 197) just switch 
from Disconnected to Connected
Site-to-site Vpn Connection to D1 site to site VPN on router r-372-VM(id: 372) 
just switch from Connected to Disconnected




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[John Burwell (JIRA)]

John Burwell created CLOUDSTACK-9591:


 Summary: VMware dvSwitch Requires a Dummy, Standard vSwitch
 Key: CLOUDSTACK-9591
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VMware
Affects Versions: 4.9.0, 4.8.0, 4.7.1, 4.7.0, 4.6.2
Reporter: John Burwell
Priority: Minor


When using the VMware dvSwitch, templates fail to register and VMs with the 
following secondary storage error:

createImportSpec error: Host did not have any virtual network defined.

Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15655167#comment-15655167
 ] 

Sven Vogel commented on CLOUDSTACK-9590:


i upload the management-server.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-9590:
---
Attachment: management-server.zip

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log, management-server.zip
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9405) listDomains API call takes an extremely long time to respond

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654880#comment-15654880
 ] 

Wei Zhou commented on CLOUDSTACK-9405:
--

I will add new parameter "details" in listDomainCmd, which is similar to 
listhosts
https://cloudstack.apache.org/api/apidocs-4.9/apis/listHosts.html

The condidated value are all,resource and min
If you want to listDomains without resource limitation/count, you can use 
listDomains with details=min (this is also used in ui/scripts/*js, but not 
implemented)

> listDomains API call takes an extremely long time to respond
> 
>
> Key: CLOUDSTACK-9405
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9405
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: performance
>
> We recently upgraded from Cloudstack 4.5.2 to Cloudstack 4.8.0. Since this 
> update, the listDomains API call has started taking an extremely long time to 
> respond. This has caused issues with our services that rely on this API call. 
> Initially they simply timed out until we increased the thresholds. Now we 
> have processes that used to take a few seconds taking many minutes.
> This is so problematic for us that our organisation has put a halt on further 
> updates of Cloudstack 4.5.2 installations. If reversing the update of zones 
> already on 4.8.0 was feasible, we would have reverted back to 4.5.2.
> Here is a table of the times we're seeing:
> ||CS Version||Domain Count||API Response Time||
> |4.5.2|251|~3s|
> |4.8.0|182|~26s|
> |4.8.0|<10|<1s|
> This small data sample indicates that the response time for zones with a 
> larger amount of domains is significantly worse after the update to 4.8.0. 
> Zones with few domains aren't able to reproduce this issue.
> I recall a bug being resolved recently that concerned reducing the response 
> time for list* API calls. I also recall [~remibergsma] resolving a bug 
> concerning the sorting of the listDomains response. Is it possible that these 
> issues are connected?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654860#comment-15654860
 ] 

Wei Zhou commented on CLOUDSTACK-9590:
--

no.

Can you paste the management logs just before 2016-11-10 13:23:06 ?


> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654266#comment-15654266
 ] 

Sven Vogel commented on CLOUDSTACK-9590:


ip upload the agent.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654195#comment-15654195
 ] 

Sven Vogel commented on CLOUDSTACK-9590:


i dont see anything like an error. you?

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-9590:
---
Attachment: agent.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: agent.log, cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654132#comment-15654132
 ] 

Wei Zhou commented on CLOUDSTACK-9590:
--

any error in agent.log near 2016-11-10 13:23:06 ?

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654097#comment-15654097
 ] 

Sven Vogel commented on CLOUDSTACK-9590:


Hi Wei,

thanks for answer.

when you look the startup it looks good. the agent starts and host are very 
long in alert mode.

what could be the problem?

thanks

Sven

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sven Vogel updated CLOUDSTACK-9590:
---
Attachment: cloudstack-startup.log

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
> Attachments: cloudstack-startup.log
>
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654040#comment-15654040
 ] 

Wei Zhou commented on CLOUDSTACK-9590:
--

any error in /var/log/cloudstack/agent/agent.log ?

> KVM + CentOS 7.2 + Agent in Alert State for long time
> -
>
> Key: CLOUDSTACK-9590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.9.0
> Environment: entOS Linux release 7.2.1511 (Core)
> cloudstack-agent-4.9.0-1.el7.centos.x86_64
>Reporter: Sven Vogel
>
> Hi,
> When i add a new host to cloudstack management server it take some time to 
> get host out from alert state.
> 1. i add the host and host add not possible
> 2. values are correct set to agent.properties, restart cloustack agent
> 3. agent says connected to server
> 4. management server says "alert"
> management-server.log
> 2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
> state = Enabled, Agent event = AgentDisconnected, Host
> id = 51, name = kvm02.oscloud.local]
> 2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
> of to disconnect
> 2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
> connection: com.cloud.exception.Connection
> Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51
> is there any way to speed up the alert state? is it normal that it take so 
> long?
> thanks
> Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9590) KVM + CentOS 7.2 + Agent in Alert State for long time

[Sven Vogel (JIRA)]

Sven Vogel created CLOUDSTACK-9590:
--

 Summary: KVM + CentOS 7.2 + Agent in Alert State for long time
 Key: CLOUDSTACK-9590
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9590
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: cloudstack-agent
Affects Versions: 4.9.0
 Environment: entOS Linux release 7.2.1511 (Core)
cloudstack-agent-4.9.0-1.el7.centos.x86_64
Reporter: Sven Vogel


Hi,

When i add a new host to cloudstack management server it take some time to get 
host out from alert state.

1. i add the host and host add not possible
2. values are correct set to agent.properties, restart cloustack agent
3. agent says connected to server
4. management server says "alert"

management-server.log

2016-11-10 13:23:06,783 DEBUG [c.c.h.Status] 
(AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Transition:[Resource 
state = Enabled, Agent event = AgentDisconnected, Host
id = 51, name = kvm02.oscloud.local]
2016-11-10 13:23:06,798 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
(AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Notifying other nodes 
of to disconnect
2016-11-10 13:23:06,806 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-49:ctx-c3b72839) (logid:5a86e1fb) Failed to handle host 
connection: com.cloud.exception.Connection
Exception: Unable to get an answer to the CheckNetworkCommand from agent: 51

is there any way to speed up the alert state? is it normal that it take so long?

thanks

Sven



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9589) vmName entries from host_details table for the VM's whose state is Expunging should be deleted during upgrade from older versions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653925#comment-15653925
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9589:


GitHub user yvsubhash opened a pull request:

https://github.com/apache/cloudstack/pull/1759

CLOUDSTACK-9589 vmName entries from host_details table for the VM's w…

CLOUDSTACK-9589 vmName entries from host_details table for the VM's whose 
state is Expunging should be deleted during upgrade from older versions

Having vmName entries for VMs in 'expunging' states would cause with 
deploying VMs with matching host tags fail. So removing them during upgrade

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-9589

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1759.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1759


commit 45114ec507692d9ca6cb9b4564db474da5f1b76a
Author: subhash_y 
Date:   2016-11-10T12:23:21Z

CLOUDSTACK-9589 vmName entries from host_details table for the VM's whose 
state is Expunging should be deleted during upgrade from older versions




> vmName entries from host_details table for the VM's whose state is Expunging 
> should be deleted during upgrade from older versions
> -
>
> Key: CLOUDSTACK-9589
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9589
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Baremetal
>Affects Versions: 4.4.4
> Environment: Baremetal zone
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Having vmName entries for VMs in 'expunging' states would cause with 
> deploying VMs with matching host tags fail. So removing them during upgrade



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9589) vmName entries from host_details table for the VM's whose state is Expunging should be deleted during upgrade from older versions

[subhash yedugundla (JIRA)]

subhash yedugundla created CLOUDSTACK-9589:
--

 Summary: vmName entries from host_details table for the VM's whose 
state is Expunging should be deleted during upgrade from older versions
 Key: CLOUDSTACK-9589
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9589
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Baremetal
Affects Versions: 4.4.4
 Environment: Baremetal zone
Reporter: subhash yedugundla
 Fix For: 4.8.1


Having vmName entries for VMs in 'expunging' states would cause with deploying 
VMs with matching host tags fail. So removing them during upgrade



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653881#comment-15653881
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9401:


Github user krissterckx commented on the issue:

https://github.com/apache/cloudstack/pull/1578
  
@jburwell @rhtyd 
I would appreciate your feedback.
 
This PR is pending from early June, and we have more PR's pending. 

Thanks,
Cheers

Kris Sterckx
Nuage Networks


> Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
> -
>
> Key: CLOUDSTACK-9401
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9401
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> Supporting Internal Dns by using Dns service provider as Virtual Router but 
> Dhcp provider will be NuageVsp. The idea is here is to keep using Internal 
> Dns service of cloudstack when network provider is some other vendor.
> A sample network offering will be like below one:-
> Service   Provider
> DHCP NuageVsp
> DNSVirtualRouter/VpcVirtualRouter
> UserDataVirtualRouter/VpcVirtualRouter
> Virtual Networking   NuageVsp
> SourceNat   NuageVsp
> StaticNat NuageVsp
> NetworkAcl/FirewallNuageVsp
> Testrun:-
> Verify InternalDns on Isolated Network ... === TestName: 
> test_01_Isolated_Network_with_zone | Status : SUCCESS ===
> ok
> Verify InternalDns on Isolated Network with ping by hostname ... === 
> TestName: test_02_Isolated_Network | Status : SUCCESS ===
> ok
> Verify update NetworkDomain for InternalDns on Isolated Network ... === 
> TestName: test_03_Update_Network_with_Domain | Status : SUCCESS ===
> ok
> Verify update NetworkDomain for InternalDns on Isolated Network with ping VM 
> ... === TestName: test_04_Update_Network_with_Domain | Status : SUCCESS ===
> ok
> Verify InternalDns on VPC Network ... === TestName: 
> test_05_VPC_Network_With_InternalDns | Status : SUCCESS ===
> ok
> Verify InternalDns on VPC Network by ping with hostname ... === TestName: 
> test_06_VPC_Network_With_InternalDns | Status : SUCCESS ===
> ok
> --
> Ran 6 tests in 5736.562s
> OK
> cloudstack$ pep8 --max-line-length=150 test_internal_dns.py
> cloudstack$  pyflakes test_internal_dns.py
> cloudstack$



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653794#comment-15653794
 ] 

Wei Zhou edited comment on CLOUDSTACK-9017 at 11/10/16 11:16 AM:
-

[~dagsonstebo] [~sudharmaj] 
could you please test the following change to fix the issues 
(1) default route is not set correctly if vm  has multiple nics on networks or 
vpc tiers.
(2) ip cannot be fetched if vm has multiple nics on multiple tiers in the same 
vpc.

{code}
diff --git a/systemvm/patches/debian/config/etc/vpcdnsmasq.conf 
b/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
index d46d623..41767ed 100644
--- a/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
+++ b/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
@@ -460,3 +460,5 @@ log-facility=/var/log/dnsmasq.log
 # Include a another lot of configuration options.
 #conf-file=/etc/dnsmasq.more.conf
 conf-dir=/etc/dnsmasq.d
+
+dhcp-optsfile=/etc/dhcpopts.txt
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py 
b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
index f4cff6f..95d2eff 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
@@ -24,6 +24,7 @@ from cs.CsFile import CsFile
 LEASES = "/var/lib/misc/dnsmasq.leases"
 DHCP_HOSTS = "/etc/dhcphosts.txt"
 CLOUD_CONF = "/etc/dnsmasq.d/cloud.conf"
+DHCP_OPTS = "/etc/dhcpopts.txt"


 class CsDhcp(CsDataBag):
@@ -36,8 +37,10 @@ class CsDhcp(CsDataBag):
 self.preseed()
 self.cloud = CsFile(DHCP_HOSTS)
 self.conf = CsFile(CLOUD_CONF)
+self.opts = CsFile(DHCP_OPTS)

 self.cloud.repopulate()
+self.opts.repopulate()

 for item in self.dbag:
 if item == "id":
@@ -52,6 +55,7 @@ class CsDhcp(CsDataBag):

 self.conf.commit()
 self.cloud.commit()
+self.opts.commit()

 # We restart DNSMASQ every time the configure.py is called in order to 
avoid lease problems.
 if not self.cl.is_redundant() or self.cl.is_master():
@@ -123,9 +127,15 @@ class CsDhcp(CsDataBag):

 def add(self, entry):
 self.add_host(entry['ipv4_adress'], entry['host_name'])
-self.cloud.add("%s,%s,%s,infinite" % (entry['mac_address'],
-  entry['ipv4_adress'],
-  entry['host_name']))
+if entry['default_entry'] == True:
+self.cloud.add("%s,%s,%s,infinite" % (entry['mac_address'], 
entry['ipv4_adress'], entry['host_name']))
+else:
+tag = entry['ipv4_adress'].replace(".","_")
+self.opts.add("%s,3" % tag)
+self.opts.add("%s,6" % tag)
+self.opts.add("%s,15" % tag)
+self.cloud.add("%s,set:%s,%s,%s,infinite" % (entry['mac_address'], 
tag, entry['ipv4_adress'], entry['host_name']))
+
 i = IPAddress(entry['ipv4_adress'])
 # Calculate the device
 for v in self.devinfo:
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py 
b/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py
index d9f30e5..254bcb5 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py
@@ -21,7 +21,7 @@ from netaddr import *

 def merge(dbag, data):

-search(dbag, data['host_name'])
+search(dbag, data['host_name'], data['default_gateway'])
 # A duplicate ip address wil clobber the old value
 # This seems desirable 
 if "add" in data and data['add'] is False and \
@@ -34,7 +34,7 @@ def merge(dbag, data):
 return dbag


-def search(dbag, name):
+def search(dbag, name, gateway):
 """
 Dirty hack because CS does not deprovision hosts
 """
@@ -42,8 +42,8 @@ def search(dbag, name):
 for o in dbag:
 if o == 'id':
 continue
-print "%s %s" % (dbag[o]['host_name'], name)
-if dbag[o]['host_name'] == name:
+print "%s %s %s" % (dbag[o]['host_name'], name, gateway)
+if dbag[o]['host_name'] == name and dbag[o]['default_gateway'] == 
gateway:
 hosts.append(o)
 for o in hosts:
 del(dbag[o])
{code}

if the change cannot be applied (by git am or patch import), please change the 
files manually.

potenial issue: if vpc tier is removed , there might be some configuration left 
in vr (not used any more).


was (Author: weizhou):
[~dagsonstebo] [~sudharmaj] 
could you please testing the following change to fix the issues 
(1) default route is not correctly if vm  has multiple nics on networks or vpc 
tiers.
(2) ip cannot be fetched if vm has multiple nics on multiple tiers in the same 
vpc.

{code}
diff --git a/systemvm/patches/debian/config/etc/vpcdnsmasq.conf 
b/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
index d46d623..41767ed 100644
--- 

[jira] [Commented] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653794#comment-15653794
 ] 

Wei Zhou commented on CLOUDSTACK-9017:
--

[~dagsonstebo] [~sudharmaj] 
could you please testing the following change to fix the issues 
(1) default route is not correctly if vm  has multiple nics on networks or vpc 
tiers.
(2) ip cannot be fetched if vm has multiple nics on multiple tiers in the same 
vpc.

{code}
diff --git a/systemvm/patches/debian/config/etc/vpcdnsmasq.conf 
b/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
index d46d623..41767ed 100644
--- a/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
+++ b/systemvm/patches/debian/config/etc/vpcdnsmasq.conf
@@ -460,3 +460,5 @@ log-facility=/var/log/dnsmasq.log
 # Include a another lot of configuration options.
 #conf-file=/etc/dnsmasq.more.conf
 conf-dir=/etc/dnsmasq.d
+
+dhcp-optsfile=/etc/dhcpopts.txt
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py 
b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
index f4cff6f..95d2eff 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/cs/CsDhcp.py
@@ -24,6 +24,7 @@ from cs.CsFile import CsFile
 LEASES = "/var/lib/misc/dnsmasq.leases"
 DHCP_HOSTS = "/etc/dhcphosts.txt"
 CLOUD_CONF = "/etc/dnsmasq.d/cloud.conf"
+DHCP_OPTS = "/etc/dhcpopts.txt"


 class CsDhcp(CsDataBag):
@@ -36,8 +37,10 @@ class CsDhcp(CsDataBag):
 self.preseed()
 self.cloud = CsFile(DHCP_HOSTS)
 self.conf = CsFile(CLOUD_CONF)
+self.opts = CsFile(DHCP_OPTS)

 self.cloud.repopulate()
+self.opts.repopulate()

 for item in self.dbag:
 if item == "id":
@@ -52,6 +55,7 @@ class CsDhcp(CsDataBag):

 self.conf.commit()
 self.cloud.commit()
+self.opts.commit()

 # We restart DNSMASQ every time the configure.py is called in order to 
avoid lease problems.
 if not self.cl.is_redundant() or self.cl.is_master():
@@ -123,9 +127,15 @@ class CsDhcp(CsDataBag):

 def add(self, entry):
 self.add_host(entry['ipv4_adress'], entry['host_name'])
-self.cloud.add("%s,%s,%s,infinite" % (entry['mac_address'],
-  entry['ipv4_adress'],
-  entry['host_name']))
+if entry['default_entry'] == True:
+self.cloud.add("%s,%s,%s,infinite" % (entry['mac_address'], 
entry['ipv4_adress'], entry['host_name']))
+else:
+tag = entry['ipv4_adress'].replace(".","_")
+self.opts.add("%s,3" % tag)
+self.opts.add("%s,6" % tag)
+self.opts.add("%s,15" % tag)
+self.cloud.add("%s,set:%s,%s,%s,infinite" % (entry['mac_address'], 
tag, entry['ipv4_adress'], entry['host_name']))
+
 i = IPAddress(entry['ipv4_adress'])
 # Calculate the device
 for v in self.devinfo:
diff --git a/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py 
b/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py
index d9f30e5..254bcb5 100755
--- a/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py
+++ b/systemvm/patches/debian/config/opt/cloud/bin/cs_dhcp.py
@@ -21,7 +21,7 @@ from netaddr import *

 def merge(dbag, data):

-search(dbag, data['host_name'])
+search(dbag, data['host_name'], data['default_gateway'])
 # A duplicate ip address wil clobber the old value
 # This seems desirable 
 if "add" in data and data['add'] is False and \
@@ -34,7 +34,7 @@ def merge(dbag, data):
 return dbag


-def search(dbag, name):
+def search(dbag, name, gateway):
 """
 Dirty hack because CS does not deprovision hosts
 """
@@ -42,8 +42,8 @@ def search(dbag, name):
 for o in dbag:
 if o == 'id':
 continue
-print "%s %s" % (dbag[o]['host_name'], name)
-if dbag[o]['host_name'] == name:
+print "%s %s %s" % (dbag[o]['host_name'], name, gateway)
+if dbag[o]['host_name'] == name and dbag[o]['default_gateway'] == 
gateway:
 hosts.append(o)
 for o in hosts:
 del(dbag[o])
{code}

if the change cannot be applied (by git am or patch import), please change the 
files manually.

potenial issue: if vpc tier is removed , there might be some configuration left 
in vr (not used any more).

> VPC VR DHCP broken for multihomed guest VMs
> ---
>
> Key: CLOUDSTACK-9017
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9017
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.9.0
> Environment: CloudStack 4.5.2, XenServer 

[jira] [Commented] (CLOUDSTACK-8288) Deleting Instance deletes unrelated snapshots

[Martin Emrich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653791#comment-15653791
 ] 

Martin Emrich commented on CLOUDSTACK-8288:
---

I just stumbled over this old issue. As no one else encountered it, I suspect 
it to be a Layer 8 problem, so it could be closed

> Deleting Instance deletes unrelated snapshots
> -
>
> Key: CLOUDSTACK-8288
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8288
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.4.2
> Environment: XenServer 6.2
>Reporter: Martin Emrich
> Attachments: management-server.log
>
>
> After deleting two instances, the snapshots on two other instances 
> disappeared (first in state "Expunging", then gone.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Dag Sonstebo (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653763#comment-15653763
 ] 

Dag Sonstebo commented on CLOUDSTACK-9017:
--

+1 - issue has been reproduced in 4.5, 4.6 as well as 4.9. Ticket affected 
versions updated accordingly.

> VPC VR DHCP broken for multihomed guest VMs
> ---
>
> Key: CLOUDSTACK-9017
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9017
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.9.0
> Environment: CloudStack 4.5.2, XenServer back end.
>Reporter: Dag Sonstebo
>  Labels: systemvm, virtualrouter, vpc
>
> Bug: VPC VR DHCP broken for multihomed guest VMs
> Affected version: CloudStack 4.5.2 only tested
> Summary: When attaching a guest VM to more than one VPC tier DHCP will only 
> work for the last NIC to be added. This is according to end user new 
> behaviour after the CS4.5.2 upgrade.
> Workarounds:
> 1) Only use single NICs on VPC connected VMs and configure L3 routing and 
> ACLs to handle traffic between tiers.
> 2) Configure additional tier NICs with the static IP addresses reported by 
> CloudStack.
>   
> 
> Steps to recreate:
> 1) Create a VPC with two tiers, in this case
>   - VPC on 10.3.0.0/16
>   - Tier 1 on 10.3.1.0/24
>   - Tier 2 on 10.3.2.0/24
> 2) Create a new VM attached to tier 1 only. This will cause a new entry to be 
> written to /etc/dhcphosts.txt on the VPC VR:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:21:fd:00:08,set:10_3_1_162,10.3.1.162,BatVM2,infinite
> root@r-20-VM:~#
> When the VM starts up the following is displayed in /var/log/dnsmasq.log when 
> the VM requests it's IP address:
> Oct 30 15:50:12 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPOFFER(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPACK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 BatVM2
> The following is displayed in the dnsmasq leases file:
> root@r-20-VM:~# cat /var/lib/misc/dnsmasq.leases 
> 0 02:00:21:fd:00:08 10.3.1.162 BatVM2 *
> And the following in the cloud DHCP configuration file:
> root@r-20-VM:~# cat /etc/dnsmasq.d/cloud.conf 
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-range=interface:eth3,set:interface-eth3,10.3.2.1,static
> dhcp-option=tag:interface-eth3,15,batvpc.net
> dhcp-range=interface:eth2,set:interface-eth2,10.3.1.1,static
> dhcp-option=tag:interface-eth2,15,batvpc.net
> root@r-20-VM:~# 
> 3) Checking the VM locally IP configuration will show DHCP lease in place for 
> eth0.
> 4) Add a new NIC to the VM, attached to Tier 2.   This results in the 
> following entries in the dnsmasq log:
> Oct 30 16:23:02 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2.batvpc.net to the 
> DHCP lease of 10.3.1.162 because the name exists in /etc/hosts with address 
> 10.3.2.111
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2 to the DHCP lease 
> of 10.3.1.162 because the name exists in /etc/hosts with address 10.3.2.111
> In other words the Tier 2 address has taken precedence over the initial Tier 
> 1 address.
> The /etc/dhcphosts.txt file has now lost the Tier 1 entry and now contains:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:26:94:00:06,set:10_3_2_111,10.3.2.111,BatVM2,infinite
> 5) When restarting the VM it will fail to get a DHCP lease on eth0.
> Note: in some cases it will reuse the old lease which is cached in the local 
> leases database - note this IP lease does not come from the VPC VR.
> The dnsmasq log will now display the following:
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPNAK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 address not available
> Oct 30 16:30:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:30:58 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:13 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:22 

[jira] [Commented] (CLOUDSTACK-9017) VPC VR DHCP broken for multihomed guest VMs

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653758#comment-15653758
 ] 

Wei Zhou commented on CLOUDSTACK-9017:
--

this issue exists on 4.6 and later as well.

> VPC VR DHCP broken for multihomed guest VMs
> ---
>
> Key: CLOUDSTACK-9017
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9017
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.4.4, 4.5.2, 4.6.0, 4.6.1, 4.6.2, 4.7.0, 4.9.0
> Environment: CloudStack 4.5.2, XenServer back end.
>Reporter: Dag Sonstebo
>  Labels: systemvm, virtualrouter, vpc
>
> Bug: VPC VR DHCP broken for multihomed guest VMs
> Affected version: CloudStack 4.5.2 only tested
> Summary: When attaching a guest VM to more than one VPC tier DHCP will only 
> work for the last NIC to be added. This is according to end user new 
> behaviour after the CS4.5.2 upgrade.
> Workarounds:
> 1) Only use single NICs on VPC connected VMs and configure L3 routing and 
> ACLs to handle traffic between tiers.
> 2) Configure additional tier NICs with the static IP addresses reported by 
> CloudStack.
>   
> 
> Steps to recreate:
> 1) Create a VPC with two tiers, in this case
>   - VPC on 10.3.0.0/16
>   - Tier 1 on 10.3.1.0/24
>   - Tier 2 on 10.3.2.0/24
> 2) Create a new VM attached to tier 1 only. This will cause a new entry to be 
> written to /etc/dhcphosts.txt on the VPC VR:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:21:fd:00:08,set:10_3_1_162,10.3.1.162,BatVM2,infinite
> root@r-20-VM:~#
> When the VM starts up the following is displayed in /var/log/dnsmasq.log when 
> the VM requests it's IP address:
> Oct 30 15:50:12 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 15:50:12 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPOFFER(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 15:50:44 dnsmasq-dhcp[8246]: DHCPACK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 BatVM2
> The following is displayed in the dnsmasq leases file:
> root@r-20-VM:~# cat /var/lib/misc/dnsmasq.leases 
> 0 02:00:21:fd:00:08 10.3.1.162 BatVM2 *
> And the following in the cloud DHCP configuration file:
> root@r-20-VM:~# cat /etc/dnsmasq.d/cloud.conf 
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-range=interface:eth3,set:interface-eth3,10.3.2.1,static
> dhcp-option=tag:interface-eth3,15,batvpc.net
> dhcp-range=interface:eth2,set:interface-eth2,10.3.1.1,static
> dhcp-option=tag:interface-eth2,15,batvpc.net
> root@r-20-VM:~# 
> 3) Checking the VM locally IP configuration will show DHCP lease in place for 
> eth0.
> 4) Add a new NIC to the VM, attached to Tier 2.   This results in the 
> following entries in the dnsmasq log:
> Oct 30 16:23:02 dnsmasq[8246]: read /etc/hosts - 7 addresses
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcphosts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: read /etc/dhcpopts.txt
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2.batvpc.net to the 
> DHCP lease of 10.3.1.162 because the name exists in /etc/hosts with address 
> 10.3.2.111
> Oct 30 16:23:02 dnsmasq-dhcp[8246]: not giving name BatVM2 to the DHCP lease 
> of 10.3.1.162 because the name exists in /etc/hosts with address 10.3.2.111
> In other words the Tier 2 address has taken precedence over the initial Tier 
> 1 address.
> The /etc/dhcphosts.txt file has now lost the Tier 1 entry and now contains:
> root@r-20-VM:~# cat /etc/dhcphosts.txt 
> 02:00:26:94:00:06,set:10_3_2_111,10.3.2.111,BatVM2,infinite
> 5) When restarting the VM it will fail to get a DHCP lease on eth0.
> Note: in some cases it will reuse the old lease which is cached in the local 
> leases database - note this IP lease does not come from the VPC VR.
> The dnsmasq log will now display the following:
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPREQUEST(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 
> Oct 30 16:30:36 dnsmasq-dhcp[8246]: DHCPNAK(eth2) 10.3.1.162 
> 02:00:21:fd:00:08 address not available
> Oct 30 16:30:44 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:30:58 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:13 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address available
> Oct 30 16:31:22 dnsmasq-dhcp[8246]: DHCPDISCOVER(eth2) 02:00:21:fd:00:08 no 
> address 

[jira] [Commented] (CLOUDSTACK-9588) Add Load Balancer functionality in Network page is redundant.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653639#comment-15653639
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9588:


GitHub user nitin-maharana opened a pull request:

https://github.com/apache/cloudstack/pull/1758

CLOUDSTACK-9588: Add Load Balancer functionality in Network page is 
Redundant.

Steps to Reproduce:
Network -> Select any network -> Observer Add Load Balancer tab
The "Add Load Balancer" functionality is redundant.
The above is used to create LB rule without any public IP.


Resolution:
There exist similar functionality in Network -> Any Network -> Details Tab 
-> View IP Addresses -> Any public IP -> Configuration Tab -> Observe Load 
Balancing.
The above is used to create LB rule with a public IP. This is a more 
convenient way of creating LB rule as the IP is involved.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nitin-maharana/CloudStack-Nitin 
CloudStack-Nitin-4.9

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1758.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1758


commit 49844e626bdf5788508186b7f037c46442e3a5b4
Author: Nitin Kumar Maharana 
Date:   2016-11-10T09:57:52Z

CLOUDSTACK-9588: Add Load Balancer functionality in Network page is 
redundant.
The "Add Load Balancer" functionality is redundant.
The above is used to create LB rule without any public IP.
This commit removes the tab from network page.




> Add Load Balancer functionality in Network page is redundant.
> -
>
> Key: CLOUDSTACK-9588
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9588
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Steps to Reproduce:
> Network -> Select any network -> Observer Add Load Balancer tab
> The "Add Load Balancer" functionality is redundant.
> The above is used to create LB rule without any public IP.
> Resolution:
> There exist similar functionality in Network -> Any Network -> Details Tab -> 
> View IP Addresses -> Any public IP -> Configuration Tab -> Observe Load 
> Balancing.
> The above is used to create LB rule with a public IP. This is a more 
> convenient way of creating LB rule as the IP is involved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653484#comment-15653484
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1757
  
@murali-reddy a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653482#comment-15653482
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1757
  
@blueorangutan test


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653453#comment-15653453
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1757
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-160


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9588) Add Load Balancer functionality in Network page is redundant.

[Nitin Kumar Maharana (JIRA)]

Nitin Kumar Maharana created CLOUDSTACK-9588:


 Summary: Add Load Balancer functionality in Network page is 
redundant.
 Key: CLOUDSTACK-9588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Kumar Maharana


Steps to Reproduce:
Network -> Select any network -> Observer Add Load Balancer tab
The "Add Load Balancer" functionality is redundant.
The above is used to create LB rule without any public IP.

Resolution:
There exist similar functionality in Network -> Any Network -> Details Tab -> 
View IP Addresses -> Any public IP -> Configuration Tab -> Observe Load 
Balancing.
The above is used to create LB rule with a public IP. This is a more convenient 
way of creating LB rule as the IP is involved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9587) Add Load Balancer functionality in Network page is redundant.

[Nitin Kumar Maharana (JIRA)]

Nitin Kumar Maharana created CLOUDSTACK-9587:


 Summary: Add Load Balancer functionality in Network page is 
redundant.
 Key: CLOUDSTACK-9587
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9587
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Kumar Maharana


Steps to Reproduce:
Network -> Select any network -> Observer Add Load Balancer tab
The "Add Load Balancer" functionality is redundant.
The above is used to create LB rule without any public IP.

Resolution:
There exist similar functionality in Network -> Any Network -> Details Tab -> 
View IP Addresses -> Any public IP -> Configuration Tab -> Observe Load 
Balancing.

The above is used to create LB rule with a public IP. This is a more convenient 
way of creating LB rule as the IP is involved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653387#comment-15653387
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1757
  
@murali-reddy a Jenkins job has been kicked to build packages. I'll keep 
you posted as I make progress.


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653385#comment-15653385
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1757
  
@blueorangutan package


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653377#comment-15653377
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
opened #1757 targeting 4.8 so closed this PR


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653375#comment-15653375
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


GitHub user murali-reddy opened a pull request:

https://github.com/apache/cloudstack/pull/1757

CLOUDSTACK-9583: VR: In CsDhcp.py preseed both hostaname and localhost to 
resolve to 127.0.0.1



The VR executes a ip route flush command as part of configurations. This 
command performs a
DNS lookup on the VR hostname. Since the VR does not have a DNS entry, the 
ip command would
wait 5 seconds before timing out and executing the flush operation. This 
fix adds the VR
hostname to /etc/hosts mapped to 127.0.0.1 to answer the DNS lookup – 
reducing the
execution time.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/murali-reddy/cloudstack vr_dhcp_entries

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1757.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1757


commit 4c4696e5e43a870b7504dfde735bc3afd04a843e
Author: Murali Reddy 
Date:   2016-11-10T07:55:22Z

CLOUDSTACK-9583: VR: In CsDhcp.py preseed both hostaname and localhost to 
resolve to 127.0.0.1

The VR executes a ip route flush command as part of configurations. This 
command performs a
DNS lookup on the VR hostname. Since the VR does not have a DNS entry, the 
ip command would
wait 5 seconds before timing out and executing the flush operation. This 
fix adds the VR
hostname to /etc/hosts mapped to 127.0.0.1 to answer the DNS lookup – 
reducing the
execution time.




> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9562) Linux Guest VM get wrong default route when there are multiple Nic with a nic with vpc

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653370#comment-15653370
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9562:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1736
  
@SudharmaJain  I can reproduce this issue sometimes, but I donot think this 
PR can fix the issue.
Because the file /etc/dhcpopts.txt is not used after VR refactoring in 
cloudstack 4.6.
The issue (default route on non-default nic) also exists on networks (not 
only vpc tiers). 
We need to fix it 


> Linux Guest VM get wrong default route when there are multiple Nic with a nic 
> with vpc
> --
>
> Key: CLOUDSTACK-9562
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9562
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> REPRO STEPS
> ==
> 1. Log as admin, create a VM CentOSx64 integrate with default network 
> "Admin-Network" (gateway is 10.1.1.1)
> 2. Create a VPC "TestVpc" and inside network named "TechNet" (gateway is 
> 10.0.0.1)
> 3. Add VPC network to VM as NIC 2
> 4. Reboot VM and examine VM default VR changed to VPC default gateway



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)