[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit fa56d0b3e6b8bf62396a820a84621c9eb8707a42 in cloudstack's branch 
refs/heads/4.9 from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fa56d0b ]

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

In some cases the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

This is also commited in OpenStack:
- https://github.com/projectcalico/felix/issues/40
- https://review.openstack.org/148718
- https://bugzilla.redhat.com/show_bug.cgi?id=910619

Signed-off-by: Wido den Hollander 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit 8b786d1fb2129326426e63d0c11eac717147f091 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b786d1 ]

Merge pull request #1743 from wido/CLOUDSTACK-8326

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VRIn some cases 
the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

Signed-off-by: Wido den Hollander 

* pr/1743:
  CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

Signed-off-by: Rohit Yadav 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8326:


Github user asfgit closed the pull request at:

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


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit 8b786d1fb2129326426e63d0c11eac717147f091 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b786d1 ]

Merge pull request #1743 from wido/CLOUDSTACK-8326

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VRIn some cases 
the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

Signed-off-by: Wido den Hollander 

* pr/1743:
  CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

Signed-off-by: Rohit Yadav 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit 8b786d1fb2129326426e63d0c11eac717147f091 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b786d1 ]

Merge pull request #1743 from wido/CLOUDSTACK-8326

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VRIn some cases 
the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

Signed-off-by: Wido den Hollander 

* pr/1743:
  CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

Signed-off-by: Rohit Yadav 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit 8b786d1fb2129326426e63d0c11eac717147f091 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b786d1 ]

Merge pull request #1743 from wido/CLOUDSTACK-8326

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VRIn some cases 
the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

Signed-off-by: Wido den Hollander 

* pr/1743:
  CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

Signed-off-by: Rohit Yadav 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit 8b786d1fb2129326426e63d0c11eac717147f091 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b786d1 ]

Merge pull request #1743 from wido/CLOUDSTACK-8326

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VRIn some cases 
the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

Signed-off-by: Wido den Hollander 

* pr/1743:
  CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

Signed-off-by: Rohit Yadav 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit 8b786d1fb2129326426e63d0c11eac717147f091 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b786d1 ]

Merge pull request #1743 from wido/CLOUDSTACK-8326

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VRIn some cases 
the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

Signed-off-by: Wido den Hollander 

* pr/1743:
  CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

Signed-off-by: Rohit Yadav 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-8326:
-

Commit fa56d0b3e6b8bf62396a820a84621c9eb8707a42 in cloudstack's branch 
refs/heads/master from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fa56d0b ]

CLOUDSTACK-8326: Always fill UDP checksums in DHCP replies in VR

In some cases the UDP checksums in packets from DHCP servers are
incorrect. This is a problem for some DHCP clients that ignore
packets with bad checksums. This patch inserts an iptables rule
to ensure DHCP servers always send packets with correct checksums.

Due to this bug DHCP offers are sometimes not accepted by Instances.

The end-result without this fix is no connectivity for the Instance
due to the lack of a IPv4 address.

This is also commited in OpenStack:
- https://github.com/projectcalico/felix/issues/40
- https://review.openstack.org/148718
- https://bugzilla.redhat.com/show_bug.cgi?id=910619

Signed-off-by: Wido den Hollander 


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8326:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1743
  
LGTM on code review, merging this based on review and test lgtms. Few 
errors around VPC/VR are known intermittent issues.


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



--
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=15649756#comment-15649756
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@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] [Updated] (CLOUDSTACK-9579) Nuage VSP Plugin :Internal lb vm display page stuck in loading not showing any vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9579:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

>  Nuage VSP Plugin :Internal lb vm display page stuck in loading not showing 
> any vms
> ---
>
> Key: CLOUDSTACK-9579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9579
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> We dont see any internal lb vms inspite there are show in cloudmonkey. Page  
> is stuck in loading. 
> we see in cloudmonkey but UI doesnt show anything
> {noformat}
> [root@acpcloudstackserver-test ~]# cloudmonkey listInternalLoadBalancerVMs
> count = 2
> internalloadbalancervm:
> id = e7873caa-568b-458e-8fa8-e537631ba8d5
> name = b-511-VM
> account = admin
> created = 2016-10-20T11:46:31-0700
> dns1 = 8.8.8.8
> domain = ROOT
> domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
> guestipaddress = 10.1.1.11
> guestmacaddress = 02:00:40:ee:00:07
> guestnetmask = 255.255.255.0
> guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
> hostname = 10.110.1.3
> hypervisor = VMware
> isredundantrouter = False
> linklocalip = 10.110.227.167
> linklocalmacaddress = 02:00:04:52:00:37
> linklocalnetmask = 255.255.0.0
> linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> networkdomain = cs2cloud.internal
> nic:
> id = c21f71ee-de2e-4f9f-9114-745804c22cbf
> broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> gateway = 10.1.1.1
> ipaddress = 10.1.1.11
> isdefault = True
> isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> macaddress = 02:00:40:ee:00:07
> netmask = 255.255.255.0
> networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> networkname = internaltier
> traffictype = Guest
> type = Isolated
> 
> id = 822505c2-26f6-4609-b6fc-7ddb3fbbff61
> gateway = 10.110.6.1
> ipaddress = 10.110.227.167
> isdefault = False
> macaddress = 02:00:04:52:00:37
> netmask = 255.255.0.0
> networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> traffictype = Control
> podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
> redundantstate = UNKNOWN
> requiresupgrade = False
> role = INTERNAL_LB_VM
> serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
> serviceofferingname = System Offering For Internal LB VM
> state = Running
> templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
> version = 4.7.1
> vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
> zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
> zonename = vemzone
> 
> id = 3999be3f-5461-413d-b921-b6a492b04d30
> name = b-509-VM
> account = admin
> created = 2016-10-20T11:40:42-0700
> dns1 = 8.8.8.8
> domain = ROOT
> domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
> guestipaddress = 10.1.1.59
> guestmacaddress = 02:00:7f:fd:00:05
> guestnetmask = 255.255.255.0
> guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
> hostname = 10.110.1.3
> hypervisor = VMware
> isredundantrouter = False
> linklocalip = 10.110.227.240
> linklocalmacaddress = 02:00:6e:72:00:35
> linklocalnetmask = 255.255.0.0
> linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> networkdomain = cs2cloud.internal
> nic:
> id = d72d059a-af68-414e-aad9-e39034c266dc
> broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> gateway = 10.1.1.1
> ipaddress = 10.1.1.59
> isdefault = True
> isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> macaddress = 02:00:7f:fd:00:05
> netmask = 255.255.255.0
> networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> networkname = internaltier
> traffictype = Guest
> type = Isolated
> 
> id = 2c90faec-6183-4550-b93e-920ee8609e1d
> gateway = 10.110.6.1
> ipaddress = 10.110.227.240
> isdefault = False
> macaddress = 02:00:6e:72:00:35
> netmask = 255.255.0.0
> networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> traffictype = Control
> podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
> redundantstate = UNKNOWN
> requiresupgrade = False
> role = INTERNAL_LB_VM
> serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
> serviceofferingname = System Offering For Internal LB VM
> state = Running
> templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
> version = 4.7.1
> vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
> zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
> 

[jira] [Updated] (CLOUDSTACK-9581) Nuage VSP Plugin :Error in logs while concurrently creating 100 vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9581:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

> Nuage VSP Plugin :Error in logs while concurrently creating 100 vms
> ---
>
> Key: CLOUDSTACK-9581
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9581
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> Error in logs while concurrently creating 100 vms. 
> To remove the error we need to update db parameters my.cnf to this to work
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> expected results:
> it should not throw exception and all vms should be created
> actual results:
> it throws unexpected exception and some vms dont start. It is in shutdown 
> state in VMware
> {noformat}
> 0-18 16:18:40,866 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-56:ctx-c49c0b6b job-756) (logid:94f12c66) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1436)
> at 
> org.apache.cloudstack.framework.jobs.dao.AsyncJobJoinMapDaoImpl.joinJob(AsyncJobJoinMapDaoImpl.java:94)
> at sun.reflect.GeneratedMethodAccessor433.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> 
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9578) Nuage VSP Plugin :6 out of 12 internal Lb rules were added to internal LB with same source ip

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9578:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

> Nuage VSP Plugin :6 out of 12 internal Lb rules were added to internal LB 
> with same source ip
> -
>
> Key: CLOUDSTACK-9578
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9578
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> 6 out of 12 internal Lb rules with same source ip were added to internal LB 
> steps to reproduce:
> 1. create 12 rules concurrently with same source ip address
> 2. assign 12 rules to a VM concurrently
> actual results:
> 6 rules are added in haproxy out of 12 
> expected results:
> all 12 rules should be added



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

[jira] [Updated] (CLOUDSTACK-9577) NPE whle deleting internal LB rules concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9577:
---
Summary: NPE whle deleting internal LB rules concurrently  (was: Nuage VSP 
Plugin :NPE whle deleting internal LB rules concurrently)

> NPE whle deleting internal LB rules concurrently
> 
>
> Key: CLOUDSTACK-9577
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9577
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> deleting internal Lb rules with different source ip throwing NPE
> teps to reproduce:
> 1. create 12 rules concurrently with different source ip address
> 2. assign 12 rules to a VM concurrently, 12 lb vms should be created
> 3.delete 12 rules concurrently
> actual results:
> NPE while deleting rules
> expected results:
> all rules should be deleted without NPE
> {noformat}
> ava.lang.NullPointerException
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:java.lang.NullPointerException
> java.lang.NullPointerException
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:java.lang.NullPointerException
> 2016-10-20 16:51:31,612 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
> (logid:c55c3a26) Invocation exception, caused by: 
> java.lang.NullPointerException
> 2016-10-20 16:51:31,613 INFO  [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
> (logid:c55c3a26) Rethrow exception java.lang.NullPointerException
> java.lang.NullPointerException
> java.lang.NullPointerException
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:java.lang.NullPointerException
> 2016-10-20 16:51:31,915 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-89:ctx-7fde1f43 job-4701) (logid:c55c3a26) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
> java.lang.NullPointerException
> 2016-10-20 16:51:31,916 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-89:ctx-7fde1f43 job-4701) (logid:c55c3a26) Complete async 
> job-4701, jobStatus: FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
> 2016-10-20 16:51:33,520 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-67:ctx-d7a48e6b job-4703/job-4708 ctx-20982299) 
> (logid:ed374f66) Invocation exception, caused by: 
> java.lang.NullPointerException
> 2016-10-20 16:51:33,522 INFO  [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-67:ctx-d7a48e6b job-4703/job-4708 ctx-20982299) 
> (logid:ed374f66) Rethrow exception java.lang.NullPointerException
> java.lang.NullPointerException
> 2016-10-20 16:51:33,650 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-67:ctx-c2932ca6 job-4703) (logid:ed374f66) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
> java.lang.NullPointerException
> 2016-10-20 16:51:33,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-67:ctx-c2932ca6 job-4703) (logid:ed374f66) Complete async 
> job-4703, jobStatus: FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
> 2016-10-20 16:51:35,512 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-154:ctx-19dc7cab job-4705/job-4710 ctx-acf4b97f) 
> (logid:e48d6bdf) Invocation exception, caused by: 
> java.lang.NullPointerException
> 2016-10-20 16:51:35,514 INFO  [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-154:ctx-19dc7cab job-4705/job-4710 ctx-acf4b97f) 
> (logid:e48d6bdf) Rethrow exception java.lang.NullPointerException
> java.lang.NullPointerException
> 2016-10-20 16:51:35,677 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-9:ctx-698bafa8 job-4705) (logid:e48d6bdf) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9579) Internal lb vm display page stuck in loading not showing any vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9579:
---
Summary: Internal lb vm display page stuck in loading not showing any vms  
(was:  Nuage VSP Plugin :Internal lb vm display page stuck in loading not 
showing any vms)

> Internal lb vm display page stuck in loading not showing any vms
> 
>
> Key: CLOUDSTACK-9579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9579
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> We dont see any internal lb vms inspite there are show in cloudmonkey. Page  
> is stuck in loading. 
> we see in cloudmonkey but UI doesnt show anything
> {noformat}
> [root@acpcloudstackserver-test ~]# cloudmonkey listInternalLoadBalancerVMs
> count = 2
> internalloadbalancervm:
> id = e7873caa-568b-458e-8fa8-e537631ba8d5
> name = b-511-VM
> account = admin
> created = 2016-10-20T11:46:31-0700
> dns1 = 8.8.8.8
> domain = ROOT
> domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
> guestipaddress = 10.1.1.11
> guestmacaddress = 02:00:40:ee:00:07
> guestnetmask = 255.255.255.0
> guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
> hostname = 10.110.1.3
> hypervisor = VMware
> isredundantrouter = False
> linklocalip = 10.110.227.167
> linklocalmacaddress = 02:00:04:52:00:37
> linklocalnetmask = 255.255.0.0
> linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> networkdomain = cs2cloud.internal
> nic:
> id = c21f71ee-de2e-4f9f-9114-745804c22cbf
> broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> gateway = 10.1.1.1
> ipaddress = 10.1.1.11
> isdefault = True
> isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> macaddress = 02:00:40:ee:00:07
> netmask = 255.255.255.0
> networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> networkname = internaltier
> traffictype = Guest
> type = Isolated
> 
> id = 822505c2-26f6-4609-b6fc-7ddb3fbbff61
> gateway = 10.110.6.1
> ipaddress = 10.110.227.167
> isdefault = False
> macaddress = 02:00:04:52:00:37
> netmask = 255.255.0.0
> networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> traffictype = Control
> podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
> redundantstate = UNKNOWN
> requiresupgrade = False
> role = INTERNAL_LB_VM
> serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
> serviceofferingname = System Offering For Internal LB VM
> state = Running
> templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
> version = 4.7.1
> vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
> zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
> zonename = vemzone
> 
> id = 3999be3f-5461-413d-b921-b6a492b04d30
> name = b-509-VM
> account = admin
> created = 2016-10-20T11:40:42-0700
> dns1 = 8.8.8.8
> domain = ROOT
> domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
> guestipaddress = 10.1.1.59
> guestmacaddress = 02:00:7f:fd:00:05
> guestnetmask = 255.255.255.0
> guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
> hostname = 10.110.1.3
> hypervisor = VMware
> isredundantrouter = False
> linklocalip = 10.110.227.240
> linklocalmacaddress = 02:00:6e:72:00:35
> linklocalnetmask = 255.255.0.0
> linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> networkdomain = cs2cloud.internal
> nic:
> id = d72d059a-af68-414e-aad9-e39034c266dc
> broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> gateway = 10.1.1.1
> ipaddress = 10.1.1.59
> isdefault = True
> isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> macaddress = 02:00:7f:fd:00:05
> netmask = 255.255.255.0
> networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> networkname = internaltier
> traffictype = Guest
> type = Isolated
> 
> id = 2c90faec-6183-4550-b93e-920ee8609e1d
> gateway = 10.110.6.1
> ipaddress = 10.110.227.240
> isdefault = False
> macaddress = 02:00:6e:72:00:35
> netmask = 255.255.0.0
> networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> traffictype = Control
> podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
> redundantstate = UNKNOWN
> requiresupgrade = False
> role = INTERNAL_LB_VM
> serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
> serviceofferingname = System Offering For Internal LB VM
> state = Running
> templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
> version = 4.7.1
> vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
> 

[jira] [Updated] (CLOUDSTACK-9579) Internal lb vm display page stuck in loading not showing any vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9579:
---
Description: 
We dont see any internal lb vms inspite there are show in cloudmonkey. Page  is 
stuck in loading. 
we see in cloudmonkey but UI doesnt show anything.This is a generic issue where 
we used Nuage as a Service provider 

{noformat}
[root@acpcloudstackserver-test ~]# cloudmonkey listInternalLoadBalancerVMs
count = 2
internalloadbalancervm:
id = e7873caa-568b-458e-8fa8-e537631ba8d5
name = b-511-VM
account = admin
created = 2016-10-20T11:46:31-0700
dns1 = 8.8.8.8
domain = ROOT
domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
guestipaddress = 10.1.1.11
guestmacaddress = 02:00:40:ee:00:07
guestnetmask = 255.255.255.0
guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
hostname = 10.110.1.3
hypervisor = VMware
isredundantrouter = False
linklocalip = 10.110.227.167
linklocalmacaddress = 02:00:04:52:00:37
linklocalnetmask = 255.255.0.0
linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
networkdomain = cs2cloud.internal
nic:
id = c21f71ee-de2e-4f9f-9114-745804c22cbf
broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
gateway = 10.1.1.1
ipaddress = 10.1.1.11
isdefault = True
isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
macaddress = 02:00:40:ee:00:07
netmask = 255.255.255.0
networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
networkname = internaltier
traffictype = Guest
type = Isolated

id = 822505c2-26f6-4609-b6fc-7ddb3fbbff61
gateway = 10.110.6.1
ipaddress = 10.110.227.167
isdefault = False
macaddress = 02:00:04:52:00:37
netmask = 255.255.0.0
networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
traffictype = Control
podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
redundantstate = UNKNOWN
requiresupgrade = False
role = INTERNAL_LB_VM
serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
serviceofferingname = System Offering For Internal LB VM
state = Running
templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
version = 4.7.1
vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
zonename = vemzone

id = 3999be3f-5461-413d-b921-b6a492b04d30
name = b-509-VM
account = admin
created = 2016-10-20T11:40:42-0700
dns1 = 8.8.8.8
domain = ROOT
domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
guestipaddress = 10.1.1.59
guestmacaddress = 02:00:7f:fd:00:05
guestnetmask = 255.255.255.0
guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
hostname = 10.110.1.3
hypervisor = VMware
isredundantrouter = False
linklocalip = 10.110.227.240
linklocalmacaddress = 02:00:6e:72:00:35
linklocalnetmask = 255.255.0.0
linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
networkdomain = cs2cloud.internal
nic:
id = d72d059a-af68-414e-aad9-e39034c266dc
broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
gateway = 10.1.1.1
ipaddress = 10.1.1.59
isdefault = True
isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
macaddress = 02:00:7f:fd:00:05
netmask = 255.255.255.0
networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
networkname = internaltier
traffictype = Guest
type = Isolated

id = 2c90faec-6183-4550-b93e-920ee8609e1d
gateway = 10.110.6.1
ipaddress = 10.110.227.240
isdefault = False
macaddress = 02:00:6e:72:00:35
netmask = 255.255.0.0
networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
traffictype = Control
podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
redundantstate = UNKNOWN
requiresupgrade = False
role = INTERNAL_LB_VM
serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
serviceofferingname = System Offering For Internal LB VM
state = Running
templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
version = 4.7.1
vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
zonename = vemzone
{noformat}



  was:
We dont see any internal lb vms inspite there are show in cloudmonkey. Page  is 
stuck in loading. 
we see in cloudmonkey but UI doesnt show anything

{noformat}
[root@acpcloudstackserver-test ~]# cloudmonkey listInternalLoadBalancerVMs
count = 2
internalloadbalancervm:
id = e7873caa-568b-458e-8fa8-e537631ba8d5
name = b-511-VM
account = admin
created = 2016-10-20T11:46:31-0700
dns1 = 8.8.8.8
domain = ROOT
domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
guestipaddress = 10.1.1.11
guestmacaddress = 02:00:40:ee:00:07
guestnetmask = 255.255.255.0
guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
hostname = 10.110.1.3
hypervisor = VMware
isredundantrouter = False
linklocalip = 10.110.227.167
linklocalmacaddress = 

[jira] [Updated] (CLOUDSTACK-9580) Unexpected exception while deleting vms concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9580:
---
Summary: Unexpected exception while deleting vms concurrently  (was: Nuage 
VSP Plugin :Unexpected exception while deleting vms concurrently)

> Unexpected exception while deleting vms concurrently
> 
>
> Key: CLOUDSTACK-9580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9580
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> Unexpected exception while deleting 100 vms concurrently .This is a generic 
> issue where we used Nuage as a Service provider 
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> 2. delete 100 vms in that network with expunge=true
> expected results:
> it should not throw exception and all vms should be deleted
> actual results:
> it throws unexpected exception and some vms dont start are stuck in expunging 
> state
> {noformat}
> 2016-10-19 15:39:08,277 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-14:ctx-86f2f5c3 job-4153) (logid:fbe038ed) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin
> com.cloud.utils.exception.CloudRuntimeException: Failed to expunge vm 
> VM[User|i-2-405-VM]
> at 
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2532)
> at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:107)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy199.destroyVm(Unknown Source)
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9578) 6 out of 12 internal Lb rules were added to internal LB with same source ip

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9578:
---
Summary: 6 out of 12 internal Lb rules were added to internal LB with same 
source ip  (was: Nuage VSP Plugin :6 out of 12 internal Lb rules were added to 
internal LB with same source ip)

> 6 out of 12 internal Lb rules were added to internal LB with same source ip
> ---
>
> Key: CLOUDSTACK-9578
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9578
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> 6 out of 12 internal Lb rules with same source ip were added to internal LB 
> steps to reproduce:
> 1. create 12 rules concurrently with same source ip address
> 2. assign 12 rules to a VM concurrently
> actual results:
> 6 rules are added in haproxy out of 12 
> expected results:
> all 12 rules should be added



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

[jira] [Updated] (CLOUDSTACK-9578) 6 out of 12 internal Lb rules were added to internal LB with same source ip

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9578:
---
Description: 
6 out of 12 internal Lb rules with same source ip were added to internal LB 
.This is a generic issue where we used Nuage as a Service provider 

steps to reproduce:
1. create 12 rules concurrently with same source ip address
2. assign 12 rules to a VM concurrently
actual results:
6 rules are added in haproxy out of 12 
expected results:
all 12 rules should be added

  was:
6 out of 12 internal Lb rules with same source ip were added to internal LB 

steps to reproduce:
1. create 12 rules concurrently with same source ip address
2. assign 12 rules to a VM concurrently
actual results:
6 rules are added in haproxy out of 12 
expected results:
all 12 rules should be added


> 6 out of 12 internal Lb rules were added to internal LB with same source ip
> ---
>
> Key: CLOUDSTACK-9578
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9578
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> 6 out of 12 internal Lb rules with same source ip were added to internal LB 
> .This is a generic issue where we used Nuage as a Service provider 
> steps to reproduce:
> 1. create 12 rules concurrently with same source ip address
> 2. assign 12 rules to a VM concurrently
> actual results:
> 6 rules are added in haproxy out of 12 
> expected results:
> all 12 rules should be added



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

[jira] [Updated] (CLOUDSTACK-9577) NPE whle deleting internal LB rules concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9577:
---
Description: 
deleting internal Lb rules with different source ip throwing NPE. This is a 
generic issue where we used Nuage as a Service provider 

teps to reproduce:
1. create 12 rules concurrently with different source ip address
2. assign 12 rules to a VM concurrently, 12 lb vms should be created
3.delete 12 rules concurrently
actual results:
NPE while deleting rules
expected results:
all rules should be deleted without NPE

{noformat}
ava.lang.NullPointerException
com.cloud.utils.exception.CloudRuntimeException: Failed to update 
state:java.lang.NullPointerException
java.lang.NullPointerException
com.cloud.utils.exception.CloudRuntimeException: Failed to update 
state:java.lang.NullPointerException
2016-10-20 16:51:31,612 ERROR [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
(logid:c55c3a26) Invocation exception, caused by: java.lang.NullPointerException
2016-10-20 16:51:31,613 INFO  [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
(logid:c55c3a26) Rethrow exception java.lang.NullPointerException
java.lang.NullPointerException
java.lang.NullPointerException
com.cloud.utils.exception.CloudRuntimeException: Failed to update 
state:java.lang.NullPointerException
2016-10-20 16:51:31,915 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-89:ctx-7fde1f43 job-4701) (logid:c55c3a26) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
java.lang.NullPointerException
2016-10-20 16:51:31,916 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-89:ctx-7fde1f43 job-4701) (logid:c55c3a26) Complete async 
job-4701, jobStatus: FAILED, resultCode: 530, result: 
org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
2016-10-20 16:51:33,520 ERROR [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-67:ctx-d7a48e6b job-4703/job-4708 ctx-20982299) 
(logid:ed374f66) Invocation exception, caused by: java.lang.NullPointerException
2016-10-20 16:51:33,522 INFO  [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-67:ctx-d7a48e6b job-4703/job-4708 ctx-20982299) 
(logid:ed374f66) Rethrow exception java.lang.NullPointerException
java.lang.NullPointerException
2016-10-20 16:51:33,650 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-67:ctx-c2932ca6 job-4703) (logid:ed374f66) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
java.lang.NullPointerException
2016-10-20 16:51:33,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-67:ctx-c2932ca6 job-4703) (logid:ed374f66) Complete async 
job-4703, jobStatus: FAILED, resultCode: 530, result: 
org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
2016-10-20 16:51:35,512 ERROR [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-154:ctx-19dc7cab job-4705/job-4710 ctx-acf4b97f) 
(logid:e48d6bdf) Invocation exception, caused by: java.lang.NullPointerException
2016-10-20 16:51:35,514 INFO  [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-154:ctx-19dc7cab job-4705/job-4710 ctx-acf4b97f) 
(logid:e48d6bdf) Rethrow exception java.lang.NullPointerException
java.lang.NullPointerException
2016-10-20 16:51:35,677 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-9:ctx-698bafa8 job-4705) (logid:e48d6bdf) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd

{noformat}

  was:
deleting internal Lb rules with different source ip throwing NPE

teps to reproduce:
1. create 12 rules concurrently with different source ip address
2. assign 12 rules to a VM concurrently, 12 lb vms should be created
3.delete 12 rules concurrently
actual results:
NPE while deleting rules
expected results:
all rules should be deleted without NPE

{noformat}
ava.lang.NullPointerException
com.cloud.utils.exception.CloudRuntimeException: Failed to update 
state:java.lang.NullPointerException
java.lang.NullPointerException
com.cloud.utils.exception.CloudRuntimeException: Failed to update 
state:java.lang.NullPointerException
2016-10-20 16:51:31,612 ERROR [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
(logid:c55c3a26) Invocation exception, caused by: java.lang.NullPointerException
2016-10-20 16:51:31,613 INFO  [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
(logid:c55c3a26) Rethrow exception java.lang.NullPointerException
java.lang.NullPointerException
java.lang.NullPointerException
com.cloud.utils.exception.CloudRuntimeException: Failed to update 
state:java.lang.NullPointerException
2016-10-20 16:51:31,915 ERROR 

[jira] [Updated] (CLOUDSTACK-9582) Null pointer exceptions while deleting network concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9582:
---
Description: 
This is a generic issue where we used NUageService provider 
steps to reproduce
1. create 100 isolated networks, create vms in 1 network
2. delete 100 networks
expected results:
it should not throw null pointer exception and network should get deleted

actual results:
it throws null pointer exception and networks get deleted
{noformat}
2016-10-17 14:39:56,647 ERROR [c.c.a.ApiServer] (catalina-exec-15:ctx-3c0a08c5 
ctx-031f80e3) (logid:9760f183) unhandled exception executing api command: 
[Ljava.lang.String;@7edf9d68
java.lang.NullPointerException
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.convertNetworkToNetworkProfile(NetworkOrchestrator.java:2847)
at com.cloud.api.ApiDBUtils.getNetworkProfile(ApiDBUtils.java:1224)
at 
com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:1995)
at 
org.apache.cloudstack.api.command.admin.network.ListNetworksCmdByAdmin.execute(ListNetworksCmdByAdmin.java:44)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:707)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:538)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:297)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
2016-10-17 14:39:56,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(API-Job-Executor-96:ctx-b2805859 job-113 ctx-1c0dfe04) (logid:64f9073a) 
Successfully cleaned up firewallRules rules for network id=392

{noformat}

  was:

steps to reproduce
1. create 100 isolated networks, create vms in 1 network
2. delete 100 networks
expected results:
it should not throw null pointer exception and network should get deleted

actual results:
it throws null pointer exception and networks get deleted
{noformat}
2016-10-17 14:39:56,647 ERROR [c.c.a.ApiServer] (catalina-exec-15:ctx-3c0a08c5 
ctx-031f80e3) (logid:9760f183) unhandled exception executing api command: 
[Ljava.lang.String;@7edf9d68
java.lang.NullPointerException
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.convertNetworkToNetworkProfile(NetworkOrchestrator.java:2847)
at com.cloud.api.ApiDBUtils.getNetworkProfile(ApiDBUtils.java:1224)
 

[jira] [Updated] (CLOUDSTACK-9580) Nuage VSP Plugin :Unexpected exception while deleting vms concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9580:
---
Description: 
Unexpected exception while deleting 100 vms concurrently .This is a generic 
issue where we used Nuage as a Service provider 
steps to reproduce
1. create 1 isolated networks, create 100 vms in the network
2. delete 100 vms in that network with expunge=true

expected results:
it should not throw exception and all vms should be deleted
actual results:
it throws unexpected exception and some vms dont start are stuck in expunging 
state


{noformat}
2016-10-19 15:39:08,277 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-14:ctx-86f2f5c3 job-4153) (logid:fbe038ed) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin
com.cloud.utils.exception.CloudRuntimeException: Failed to expunge vm 
VM[User|i-2-405-VM]
at com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2532)
at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:107)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy199.destroyVm(Unknown Source)


{noformat}

  was:
Unexpected exception while deleting 100 vms concurrently
steps to reproduce
1. create 1 isolated networks, create 100 vms in the network
2. delete 100 vms in that network with expunge=true

expected results:
it should not throw exception and all vms should be deleted
actual results:
it throws unexpected exception and some vms dont start are stuck in expunging 
state


{noformat}
2016-10-19 15:39:08,277 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-14:ctx-86f2f5c3 job-4153) (logid:fbe038ed) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin
com.cloud.utils.exception.CloudRuntimeException: Failed to expunge vm 
VM[User|i-2-405-VM]
at com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2532)
at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:107)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy199.destroyVm(Unknown Source)


{noformat}


> Nuage VSP Plugin :Unexpected exception while deleting vms concurrently
> --
>
> Key: CLOUDSTACK-9580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9580
> 

[jira] [Updated] (CLOUDSTACK-9581) Error in logs while concurrently creating 100 vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9581:
---
Description: 
This is a generic issue where we used Nuage as a Service provider 
Error in logs while concurrently creating 100 vms. 
To remove the error we need to update db parameters my.cnf to this to work

steps to reproduce
1. create 1 isolated networks, create 100 vms in the network

expected results:
it should not throw exception and all vms should be created
actual results:
it throws unexpected exception and some vms dont start. It is in shutdown state 
in VMware

{noformat}
0-18 16:18:40,866 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-56:ctx-c49c0b6b job-756) (logid:94f12c66) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1436)
at 
org.apache.cloudstack.framework.jobs.dao.AsyncJobJoinMapDaoImpl.joinJob(AsyncJobJoinMapDaoImpl.java:94)
at sun.reflect.GeneratedMethodAccessor433.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)


{noformat}

  was:
Error in logs while concurrently creating 100 vms. 
To remove the error we need to update db parameters my.cnf to this to work

steps to reproduce
1. create 1 isolated networks, create 100 vms in the network

expected results:
it should not throw exception and all vms should be created
actual results:
it throws unexpected exception and some vms dont start. It is in shutdown state 
in VMware

{noformat}
0-18 16:18:40,866 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-56:ctx-c49c0b6b job-756) (logid:94f12c66) Unexpected 
exception while executing 
org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1436)
at 
org.apache.cloudstack.framework.jobs.dao.AsyncJobJoinMapDaoImpl.joinJob(AsyncJobJoinMapDaoImpl.java:94)
at sun.reflect.GeneratedMethodAccessor433.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)


{noformat}


> Error in logs while concurrently creating 100 vms
> -
>
> Key: CLOUDSTACK-9581
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9581
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> This is a generic issue where we used Nuage as a Service provider 
> Error in logs while concurrently creating 100 vms. 
> To remove the error we need to update db parameters my.cnf to this to work
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> expected results:
> it should not throw exception and all vms should be created
> actual results:
> it throws unexpected exception and some vms dont start. It is in shutdown 
> state in VMware
> {noformat}
> 0-18 16:18:40,866 ERROR 

[jira] [Updated] (CLOUDSTACK-9581) Error in logs while concurrently creating 100 vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9581:
---
Summary: Error in logs while concurrently creating 100 vms  (was: Nuage VSP 
Plugin :Error in logs while concurrently creating 100 vms)

> Error in logs while concurrently creating 100 vms
> -
>
> Key: CLOUDSTACK-9581
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9581
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> Error in logs while concurrently creating 100 vms. 
> To remove the error we need to update db parameters my.cnf to this to work
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> expected results:
> it should not throw exception and all vms should be created
> actual results:
> it throws unexpected exception and some vms dont start. It is in shutdown 
> state in VMware
> {noformat}
> 0-18 16:18:40,866 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-56:ctx-c49c0b6b job-756) (logid:94f12c66) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1436)
> at 
> org.apache.cloudstack.framework.jobs.dao.AsyncJobJoinMapDaoImpl.joinJob(AsyncJobJoinMapDaoImpl.java:94)
> at sun.reflect.GeneratedMethodAccessor433.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> 
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9582) Null pointer exceptions while deleting network concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9582:
---
Summary: Null pointer exceptions while deleting network concurrently  (was: 
Nuage VSP Plugin :null pointer exceptions while deleting network concurrently)

> Null pointer exceptions while deleting network concurrently
> ---
>
> Key: CLOUDSTACK-9582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9582
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> steps to reproduce
> 1. create 100 isolated networks, create vms in 1 network
> 2. delete 100 networks
> expected results:
> it should not throw null pointer exception and network should get deleted
> actual results:
> it throws null pointer exception and networks get deleted
> {noformat}
> 2016-10-17 14:39:56,647 ERROR [c.c.a.ApiServer] 
> (catalina-exec-15:ctx-3c0a08c5 ctx-031f80e3) (logid:9760f183) unhandled 
> exception executing api command: [Ljava.lang.String;@7edf9d68
> java.lang.NullPointerException
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.convertNetworkToNetworkProfile(NetworkOrchestrator.java:2847)
>   at com.cloud.api.ApiDBUtils.getNetworkProfile(ApiDBUtils.java:1224)
>   at 
> com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:1995)
>   at 
> org.apache.cloudstack.api.command.admin.network.ListNetworksCmdByAdmin.execute(ListNetworksCmdByAdmin.java:44)
>   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132)
>   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:707)
>   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:538)
>   at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:297)
>   at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
>   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>   at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Thread.java:745)
> 2016-10-17 14:39:56,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-96:ctx-b2805859 job-113 ctx-1c0dfe04) (logid:64f9073a) 
> Successfully cleaned up firewallRules rules for network id=392
> {noformat}



--

[jira] [Updated] (CLOUDSTACK-9582) Nuage VSP Plugin :null pointer exceptions while deleting network concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9582:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

> Nuage VSP Plugin :null pointer exceptions while deleting network concurrently
> -
>
> Key: CLOUDSTACK-9582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9582
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> steps to reproduce
> 1. create 100 isolated networks, create vms in 1 network
> 2. delete 100 networks
> expected results:
> it should not throw null pointer exception and network should get deleted
> actual results:
> it throws null pointer exception and networks get deleted
> {noformat}
> 2016-10-17 14:39:56,647 ERROR [c.c.a.ApiServer] 
> (catalina-exec-15:ctx-3c0a08c5 ctx-031f80e3) (logid:9760f183) unhandled 
> exception executing api command: [Ljava.lang.String;@7edf9d68
> java.lang.NullPointerException
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.convertNetworkToNetworkProfile(NetworkOrchestrator.java:2847)
>   at com.cloud.api.ApiDBUtils.getNetworkProfile(ApiDBUtils.java:1224)
>   at 
> com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:1995)
>   at 
> org.apache.cloudstack.api.command.admin.network.ListNetworksCmdByAdmin.execute(ListNetworksCmdByAdmin.java:44)
>   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132)
>   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:707)
>   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:538)
>   at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:297)
>   at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
>   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>   at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Thread.java:745)
> 2016-10-17 14:39:56,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-96:ctx-b2805859 job-113 ctx-1c0dfe04) (logid:64f9073a) 
> Successfully cleaned up firewallRules rules for network id=392
> {noformat}



--
This message was sent by Atlassian JIRA

[jira] [Updated] (CLOUDSTACK-9580) Nuage VSP Plugin :Unexpected exception while deleting vms concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9580:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

> Nuage VSP Plugin :Unexpected exception while deleting vms concurrently
> --
>
> Key: CLOUDSTACK-9580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9580
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> Unexpected exception while deleting 100 vms concurrently
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> 2. delete 100 vms in that network with expunge=true
> expected results:
> it should not throw exception and all vms should be deleted
> actual results:
> it throws unexpected exception and some vms dont start are stuck in expunging 
> state
> {noformat}
> 2016-10-19 15:39:08,277 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-14:ctx-86f2f5c3 job-4153) (logid:fbe038ed) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin
> com.cloud.utils.exception.CloudRuntimeException: Failed to expunge vm 
> VM[User|i-2-405-VM]
> at 
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2532)
> at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:107)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy199.destroyVm(Unknown Source)
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9577) Nuage VSP Plugin :NPE whle deleting internal LB rules concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9577:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

> Nuage VSP Plugin :NPE whle deleting internal LB rules concurrently
> --
>
> Key: CLOUDSTACK-9577
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9577
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> deleting internal Lb rules with different source ip throwing NPE
> teps to reproduce:
> 1. create 12 rules concurrently with different source ip address
> 2. assign 12 rules to a VM concurrently, 12 lb vms should be created
> 3.delete 12 rules concurrently
> actual results:
> NPE while deleting rules
> expected results:
> all rules should be deleted without NPE
> {noformat}
> ava.lang.NullPointerException
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:java.lang.NullPointerException
> java.lang.NullPointerException
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:java.lang.NullPointerException
> 2016-10-20 16:51:31,612 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
> (logid:c55c3a26) Invocation exception, caused by: 
> java.lang.NullPointerException
> 2016-10-20 16:51:31,613 INFO  [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-63:ctx-c2e57461 job-4701/job-4706 ctx-a45e175b) 
> (logid:c55c3a26) Rethrow exception java.lang.NullPointerException
> java.lang.NullPointerException
> java.lang.NullPointerException
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:java.lang.NullPointerException
> 2016-10-20 16:51:31,915 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-89:ctx-7fde1f43 job-4701) (logid:c55c3a26) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
> java.lang.NullPointerException
> 2016-10-20 16:51:31,916 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-89:ctx-7fde1f43 job-4701) (logid:c55c3a26) Complete async 
> job-4701, jobStatus: FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
> 2016-10-20 16:51:33,520 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-67:ctx-d7a48e6b job-4703/job-4708 ctx-20982299) 
> (logid:ed374f66) Invocation exception, caused by: 
> java.lang.NullPointerException
> 2016-10-20 16:51:33,522 INFO  [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-67:ctx-d7a48e6b job-4703/job-4708 ctx-20982299) 
> (logid:ed374f66) Rethrow exception java.lang.NullPointerException
> java.lang.NullPointerException
> 2016-10-20 16:51:33,650 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-67:ctx-c2932ca6 job-4703) (logid:ed374f66) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
> java.lang.NullPointerException
> 2016-10-20 16:51:33,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-67:ctx-c2932ca6 job-4703) (logid:ed374f66) Complete async 
> job-4703, jobStatus: FAILED, resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
> 2016-10-20 16:51:35,512 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-154:ctx-19dc7cab job-4705/job-4710 ctx-acf4b97f) 
> (logid:e48d6bdf) Invocation exception, caused by: 
> java.lang.NullPointerException
> 2016-10-20 16:51:35,514 INFO  [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-154:ctx-19dc7cab job-4705/job-4710 ctx-acf4b97f) 
> (logid:e48d6bdf) Rethrow exception java.lang.NullPointerException
> java.lang.NullPointerException
> 2016-10-20 16:51:35,677 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-9:ctx-698bafa8 job-4705) (logid:e48d6bdf) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.DeleteApplicationLoadBalancerCmd
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9576) Nuage VSP Plugin : NPE while creating vpctier with wrong domain template name

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9576:
---
Affects Version/s: (was: 4.7.1)
   (was: 4.7.0)

> Nuage VSP Plugin : NPE while creating vpctier with wrong domain template name
> -
>
> Key: CLOUDSTACK-9576
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9576
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: esx 5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> NPE while creating vpctier with wrong domain template name in VPC Domain 
> Template testcases
> Global setting
> nuagevsp.vpc.domaintemplate.name -> Defines if NuageVsp plugin needs to use 
> pre created Domain Template configured in VSP for VPCs
> steps to reproduce:
> 1. provide invalid domain name in "nuagevsp.vpc.domaintemplate.name" global 
> setting
> 2. create vpc tier
> actual results:
> null pointer exception and no UI error thrown
> expected results:
> there should be no null pointer exception and a proper UI error should be 
> thrown
> {noformat}
> 2016-10-25 16:57:29,463 ERROR [c.c.n.g.NuageVspGuestNetworkGuru] 
> (catalina-exec-2:ctx-f105f25a ctx-56e75cb8) (logid:91261740) 
> ImplementNetworkVspCommand for network 9a4aad29-5c0e-4e82-845f-dd9f29dad721 
> failed on Nuage VSD 10.110.9.6
> 2016-10-25 16:57:29,463 ERROR [c.c.n.g.NuageVspGuestNetworkGuru] 
> (catalina-exec-2:ctx-f105f25a ctx-56e75cb8) (logid:91261740) Exception: 
> net.nuage.vsp.acs.client.exception.NuageVspException
> Message: Preconfigured DomainTemplate 'c5f1741d-8584-4cb3-a3b5-ce0785f06d65' 
> could not be found. Please remove the VPC Tier before trying again.
> Stack: net.nuage.vsp.acs.client.exception.NuageVspException: Preconfigured 
> DomainTemplate 'c5f1741d-8584-4cb3-a3b5-ce0785f06d65' could not be found. 
> Please remove the VPC Tier before trying again.
> at 
> net.nuage.vsp.acs.client.api.impl.NuageVspApiClientImpl.createNetworkConfigurationWithDefaultACLs(NuageVspApiClientImpl.java:435)
> at 
> net.nuage.vsp.acs.client.api.impl.NuageVspGuruClientImpl.implement(NuageVspGuruClientImpl.java:37)
> at 
> com.cloud.network.resource.NuageVspResource.executeRequest(NuageVspResource.java:347)
> at 
> com.cloud.network.resource.NuageVspResource.executeRequest(NuageVspResource.java:287)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2016-10-25 16:57:29,463 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (catalina-exec-2:ctx-f105f25a ctx-56e75cb8) (logid:91261740) Cleaning up 
> because we're unable to implement the network Ntwk[494|Guest|56]
> 2016-10-25 16:57:29,646 ERROR [c.c.a.ApiServer] (catalina-exec-2:ctx-f105f25a 
> ctx-56e75cb8) (logid:91261740) unhandled exception executing api command: 
> [Ljava.lang.String;@2feea6ba
> java.lang.NullPointerException
> at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:1033)
> at 
> com.cloud.network.NetworkServiceImpl.createGuestNetwork(NetworkServiceImpl.java:1334)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at 

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
Trillian test result (tid-304)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 35528 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1677-t304-vmware-55u3.zip
Test completed. 46 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_vpc_site2site_vpn | `Error` | 522.07 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | `Error` | 728.32 | test_vpc_vpn.py
ContextSuite context=TestSnapshotRootDisk>:teardown | `Error` | 107.07 | 
test_snapshots.py
test_01_vpc_remote_access_vpn | Success | 171.77 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 432.31 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 784.13 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 707.64 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1590.28 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 719.87 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 700.00 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1381.15 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 31.01 | test_volumes.py
test_06_download_detached_volume | Success | 60.55 | test_volumes.py
test_05_detach_volume | Success | 100.22 | test_volumes.py
test_04_delete_attached_volume | Success | 20.24 | test_volumes.py
test_03_download_attached_volume | Success | 25.34 | test_volumes.py
test_02_attach_volume | Success | 53.78 | test_volumes.py
test_01_create_volume | Success | 450.26 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.18 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 199.07 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 126.08 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 129.25 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 233.47 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.82 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.27 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 76.28 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.15 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.14 | test_vm_life_cycle.py
test_02_start_vm | Success | 20.23 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.14 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 276.83 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.06 | test_templates.py
test_04_extract_template | Success | 20.29 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.15 | test_templates.py
test_01_create_template | Success | 100.78 | test_templates.py
test_10_destroy_cpvm | Success | 266.98 | test_ssvm.py
test_09_destroy_ssvm | Success | 204.38 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.55 | test_ssvm.py
test_07_reboot_ssvm | Success | 159.15 | test_ssvm.py
test_06_stop_cpvm | Success | 201.92 | test_ssvm.py
test_05_stop_ssvm | Success | 479.23 | test_ssvm.py
test_04_cpvm_internals | Success | 1.23 | test_ssvm.py
test_03_ssvm_internals | Success | 3.98 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py
test_01_snapshot_root_disk | Success | 61.38 | test_snapshots.py
test_04_change_offering_small | Success | 91.83 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py
test_01_create_service_offering | Success | 0.11 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.12 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py
test_09_reboot_router | Success | 125.82 | test_routers.py
test_08_start_router | Success | 100.69 | test_routers.py

[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=15648758#comment-15648758
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user syed commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
LGTM as well. Thanks for the fix @murali-reddy 


> 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-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8326:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1743
  
LGTM !


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Updated] (CLOUDSTACK-9580) Nuage VSP Plugin :Unexpected exception while deleting vms concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9580:
---
Affects Version/s: 4.7.0
   4.7.1

> Nuage VSP Plugin :Unexpected exception while deleting vms concurrently
> --
>
> Key: CLOUDSTACK-9580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9580
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.0, 4.7.1
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> Unexpected exception while deleting 100 vms concurrently
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> 2. delete 100 vms in that network with expunge=true
> expected results:
> it should not throw exception and all vms should be deleted
> actual results:
> it throws unexpected exception and some vms dont start are stuck in expunging 
> state
> {noformat}
> 2016-10-19 15:39:08,277 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-14:ctx-86f2f5c3 job-4153) (logid:fbe038ed) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin
> com.cloud.utils.exception.CloudRuntimeException: Failed to expunge vm 
> VM[User|i-2-405-VM]
> at 
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2532)
> at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:107)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy199.destroyVm(Unknown Source)
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9579) Nuage VSP Plugin :Internal lb vm display page stuck in loading not showing any vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9579:
---
Affects Version/s: 4.7.0
   4.7.1

>  Nuage VSP Plugin :Internal lb vm display page stuck in loading not showing 
> any vms
> ---
>
> Key: CLOUDSTACK-9579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9579
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.0, 4.7.1
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> We dont see any internal lb vms inspite there are show in cloudmonkey. Page  
> is stuck in loading. 
> we see in cloudmonkey but UI doesnt show anything
> {noformat}
> [root@acpcloudstackserver-test ~]# cloudmonkey listInternalLoadBalancerVMs
> count = 2
> internalloadbalancervm:
> id = e7873caa-568b-458e-8fa8-e537631ba8d5
> name = b-511-VM
> account = admin
> created = 2016-10-20T11:46:31-0700
> dns1 = 8.8.8.8
> domain = ROOT
> domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
> guestipaddress = 10.1.1.11
> guestmacaddress = 02:00:40:ee:00:07
> guestnetmask = 255.255.255.0
> guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
> hostname = 10.110.1.3
> hypervisor = VMware
> isredundantrouter = False
> linklocalip = 10.110.227.167
> linklocalmacaddress = 02:00:04:52:00:37
> linklocalnetmask = 255.255.0.0
> linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> networkdomain = cs2cloud.internal
> nic:
> id = c21f71ee-de2e-4f9f-9114-745804c22cbf
> broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> gateway = 10.1.1.1
> ipaddress = 10.1.1.11
> isdefault = True
> isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> macaddress = 02:00:40:ee:00:07
> netmask = 255.255.255.0
> networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> networkname = internaltier
> traffictype = Guest
> type = Isolated
> 
> id = 822505c2-26f6-4609-b6fc-7ddb3fbbff61
> gateway = 10.110.6.1
> ipaddress = 10.110.227.167
> isdefault = False
> macaddress = 02:00:04:52:00:37
> netmask = 255.255.0.0
> networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> traffictype = Control
> podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
> redundantstate = UNKNOWN
> requiresupgrade = False
> role = INTERNAL_LB_VM
> serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
> serviceofferingname = System Offering For Internal LB VM
> state = Running
> templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
> version = 4.7.1
> vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
> zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
> zonename = vemzone
> 
> id = 3999be3f-5461-413d-b921-b6a492b04d30
> name = b-509-VM
> account = admin
> created = 2016-10-20T11:40:42-0700
> dns1 = 8.8.8.8
> domain = ROOT
> domainid = 3b7ec87c-94a7-11e6-85f5-0cc47a06e0fc
> guestipaddress = 10.1.1.59
> guestmacaddress = 02:00:7f:fd:00:05
> guestnetmask = 255.255.255.0
> guestnetworkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> hostid = 358dac83-7bea-4e78-9ca0-2328d40d18fc
> hostname = 10.110.1.3
> hypervisor = VMware
> isredundantrouter = False
> linklocalip = 10.110.227.240
> linklocalmacaddress = 02:00:6e:72:00:35
> linklocalnetmask = 255.255.0.0
> linklocalnetworkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> networkdomain = cs2cloud.internal
> nic:
> id = d72d059a-af68-414e-aad9-e39034c266dc
> broadcasturi = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> gateway = 10.1.1.1
> ipaddress = 10.1.1.59
> isdefault = True
> isolationuri = vsp://063a1b14-18ec-472f-b4fe-9faa15d2d637/10.1.1.2
> macaddress = 02:00:7f:fd:00:05
> netmask = 255.255.255.0
> networkid = 063a1b14-18ec-472f-b4fe-9faa15d2d637
> networkname = internaltier
> traffictype = Guest
> type = Isolated
> 
> id = 2c90faec-6183-4550-b93e-920ee8609e1d
> gateway = 10.110.6.1
> ipaddress = 10.110.227.240
> isdefault = False
> macaddress = 02:00:6e:72:00:35
> netmask = 255.255.0.0
> networkid = 69dfc258-d4ac-4d12-9277-2dc7eb78bf9b
> traffictype = Control
> podid = bdbf3325-7b28-4fc5-851e-f3b26db52d4a
> redundantstate = UNKNOWN
> requiresupgrade = False
> role = INTERNAL_LB_VM
> serviceofferingid = aaad943d-7803-4f03-b4bd-94a0356af66f
> serviceofferingname = System Offering For Internal LB VM
> state = Running
> templateid = 3bae4eda-94a7-11e6-85f5-0cc47a06e0fc
> version = 4.7.1
> vpcid = d4326d33-056a-42c2-829e-b8ffaa655957
> zoneid = 33b85c8e-4d37-4c63-b672-0be1b91eddfe
> zonename = 

[jira] [Updated] (CLOUDSTACK-9582) Nuage VSP Plugin :null pointer exceptions while deleting network concurrently

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9582:
---
Affects Version/s: 4.7.0
   4.7.1

> Nuage VSP Plugin :null pointer exceptions while deleting network concurrently
> -
>
> Key: CLOUDSTACK-9582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9582
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.0, 4.7.1
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> steps to reproduce
> 1. create 100 isolated networks, create vms in 1 network
> 2. delete 100 networks
> expected results:
> it should not throw null pointer exception and network should get deleted
> actual results:
> it throws null pointer exception and networks get deleted
> {noformat}
> 2016-10-17 14:39:56,647 ERROR [c.c.a.ApiServer] 
> (catalina-exec-15:ctx-3c0a08c5 ctx-031f80e3) (logid:9760f183) unhandled 
> exception executing api command: [Ljava.lang.String;@7edf9d68
> java.lang.NullPointerException
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.convertNetworkToNetworkProfile(NetworkOrchestrator.java:2847)
>   at com.cloud.api.ApiDBUtils.getNetworkProfile(ApiDBUtils.java:1224)
>   at 
> com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:1995)
>   at 
> org.apache.cloudstack.api.command.admin.network.ListNetworksCmdByAdmin.execute(ListNetworksCmdByAdmin.java:44)
>   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132)
>   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:707)
>   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:538)
>   at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:297)
>   at com.cloud.api.ApiServlet$1.run(ApiServlet.java:129)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:126)
>   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>   at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Thread.java:745)
> 2016-10-17 14:39:56,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (API-Job-Executor-96:ctx-b2805859 job-113 ctx-1c0dfe04) (logid:64f9073a) 
> Successfully cleaned up firewallRules rules for network id=392
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9581) Nuage VSP Plugin :Error in logs while concurrently creating 100 vms

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9581:
---
Affects Version/s: 4.7.0
   4.7.1

> Nuage VSP Plugin :Error in logs while concurrently creating 100 vms
> ---
>
> Key: CLOUDSTACK-9581
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9581
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.0, 4.7.1
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> Error in logs while concurrently creating 100 vms. 
> To remove the error we need to update db parameters my.cnf to this to work
> steps to reproduce
> 1. create 1 isolated networks, create 100 vms in the network
> expected results:
> it should not throw exception and all vms should be created
> actual results:
> it throws unexpected exception and some vms dont start. It is in shutdown 
> state in VMware
> {noformat}
> 0-18 16:18:40,866 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-56:ctx-c49c0b6b job-756) (logid:94f12c66) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1436)
> at 
> org.apache.cloudstack.framework.jobs.dao.AsyncJobJoinMapDaoImpl.joinJob(AsyncJobJoinMapDaoImpl.java:94)
> at sun.reflect.GeneratedMethodAccessor433.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> 
> {noformat}



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

[jira] [Updated] (CLOUDSTACK-9578) Nuage VSP Plugin :6 out of 12 internal Lb rules were added to internal LB with same source ip

[Bhavin (JIRA)]

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

Bhavin updated CLOUDSTACK-9578:
---
Affects Version/s: 4.7.0
   4.7.1

> Nuage VSP Plugin :6 out of 12 internal Lb rules were added to internal LB 
> with same source ip
> -
>
> Key: CLOUDSTACK-9578
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9578
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.7.0, 4.7.1
> Environment: esx-5.5
>Reporter: Bhavin
>  Labels: controller, management, network, server
>
> 6 out of 12 internal Lb rules with same source ip were added to internal LB 
> steps to reproduce:
> 1. create 12 rules concurrently with same source ip address
> 2. assign 12 rules to a VM concurrently
> actual results:
> 6 rules are added in haproxy out of 12 
> expected results:
> all 12 rules should be added



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

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1735
  
@jburwell sure, will work on it


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8326:


Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1743
  
Good suggestion @ustcweizhou, done that!


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1735
  
@nvazquez could you please add a Marvin test to verify this fix?


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



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

[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1745
  
@rhtyd we have the following failures in the blueoraguntan vmware run that 
were fixed as part of #1692:

* `test_CreateTemplateWithDuplicateName`
* `test_01_create_template`
* `ContextSuite context=TestTemplates>:setup`

Do we have an explanation for these failures?


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user nvazquez commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1735#discussion_r87001105
  
--- Diff: server/src/com/cloud/api/ApiResponseHelper.java ---
@@ -526,16 +529,18 @@ public static DataStoreRole getDataStoreRole(Snapshot 
snapshot, SnapshotDataStor
 }
 
 long storagePoolId = snapshotStore.getDataStoreId();
-DataStore dataStore = dataStoreMgr.getDataStore(storagePoolId, 
DataStoreRole.Primary);
+if (! 
snapshotStore.getState().equals(ObjectInDataStoreStateMachine.State.Destroyed)){
--- End diff --

Done, thanks @rhtyd 


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



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

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1735
  
@ustcweizhou Not necessary. The issue affects removal of primary storage DS 
where there are snapshot copies. After that the snapshot could remain on 
secondary storage. 


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



--
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=15647474#comment-15647474
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

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


> 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=15647424#comment-15647424
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
LGTM


> 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=15647396#comment-15647396
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@rhtyd 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=15647395#comment-15647395
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@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=15647378#comment-15647378
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@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=15647377#comment-15647377
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@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=15647354#comment-15647354
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

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


> 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-9071) stats.output.uri stops the server from starting if the uri is malformed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9071:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1673
  
@jburwell failures are redundant VPC related being tracked CLOUDSTACK-9541


> stats.output.uri stops the server from starting if the uri is malformed
> ---
>
> Key: CLOUDSTACK-9071
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Carles Figuerola
>
> After inputting a malformed uri (was missing the graphite://) and restarting 
> the management service, the application stops at:
> 2015-11-17 11:06:42,861 INFO  [c.c.s.StatsCollector] 
> (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol 
> for external statistics. No statistics will be send.
> No more logs are output and tomcat is up but serving a completely blank page.
> When the uri has this form: (graphite://metrics.dev.company.net:2013), the 
> end result is very similar to the previous one
> (also, the last word should be "sent")



--
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=15647280#comment-15647280
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@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=15647279#comment-15647279
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1750
  
@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=15647277#comment-15647277
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


GitHub user murali-reddy opened a pull request:

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

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


ensuring for both vpc and non vpc vr, both localhost and hostname is 
resolved to 127.0.0.1

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/1750.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 #1750


commit 0ac2539dfc50d5502d733aabbaf5fa6148aee4ca
Author: Murali Reddy 
Date:   2016-11-08T11:20:41Z

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

ensuring for both vpc and non vpc vr, both localhost and hostname is 
resolved to 127.0.0.1




> 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-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[Murali Reddy (JIRA)]

Murali Reddy created CLOUDSTACK-9583:


 Summary: 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-9500) VR configuration not clean properly after Public IP release

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user blueorangutan commented on the issue:

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


> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



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

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been 
kicked to run smoke tests


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response Received: 
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8) 
> 

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@blueorangutan test centos7 vmware-55u3


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response Received: 
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Processing:  { Ans: , MgmtId: 
> 

[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user rhtyd commented on the issue:

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


> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



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

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@rhtyd unsupported parameters provided. Supported mgmt server os are: 
`centos6, centos7, ubuntu`. Supported hypervisors are: `kvm-centos6, 
kvm-centos7, kvm-ubuntu, xenserver-65sp1, xenserver-62sp1, vmware-60u2, 
vmware-55u3, vmware-51u1, vmware-50u1`


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) 

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

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


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user rhtyd commented on the issue:

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


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@blueorangutan test centos7 vmware55u3


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response Received: 
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Processing:  { Ans: , MgmtId: 
> 

[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user blueorangutan commented on the issue:

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


> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-150


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8326:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1743
  
@rhtyd @wido I would suggest one more change: move line 378-380 after line 
360.


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-9561) After domain/account deletion, snapshot taken by the domain/account remains undeleted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9561:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1737
  
Packaging result: ✔centos6 ✖centos7 ✔debian. JID-148


> After domain/account deletion, snapshot taken by the domain/account remains 
> undeleted
> -
>
> Key: CLOUDSTACK-9561
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9561
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> While deleting the UserAccount Cleanup for the removed VMs/volumes are not 
> happening. For the removed VMs, snapshots doesn't get cleaned. Only for 
> volumes in ready state the cleanup happens.



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

[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user rhtyd commented on the issue:

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


> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove 
> configuration of the public IP on the VR configs 
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on 
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on 
> the old VR is not pignable but the switches arp table get updated every time 
> the previous VR have configuration changes.



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

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user rhtyd commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1726#discussion_r86956330
  
--- Diff: server/src/com/cloud/storage/StorageManagerImpl.java ---
@@ -2199,15 +2199,20 @@ public void cleanupDownloadUrls(){
 if(downloadUrlCurrentAgeInSecs < 
_downloadUrlExpirationInterval){  // URL hasnt expired yet
 continue;
 }
-
-s_logger.debug("Removing download url " + 
volumeOnImageStore.getExtractUrl() + " for volume id " + 
volumeOnImageStore.getVolumeId());
+long volumeId = volumeOnImageStore.getVolumeId();
+s_logger.debug("Removing download url " + 
volumeOnImageStore.getExtractUrl() + " for volume id " + volumeId);
 
 // Remove it from image store
 ImageStoreEntity secStore = (ImageStoreEntity) 
_dataStoreMgr.getDataStore(volumeOnImageStore.getDataStoreId(), 
DataStoreRole.Image);
 
secStore.deleteExtractUrl(volumeOnImageStore.getInstallPath(), 
volumeOnImageStore.getExtractUrl(), Upload.Type.VOLUME);
 
 // Now expunge it from DB since this entry was created 
only for download purpose
 _volumeStoreDao.expunge(volumeOnImageStore.getId());
+Volume volume = _volumeDao.findById(volumeId);
+if (volume != null && volume.getState() == 
Volume.State.Expunged)
+{
+_volumeDao.remove(volumeId);
+}
--- End diff --

@yvsubhash can you reply to @ustcweizhou 's comment above ^^ ?


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

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


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user blueorangutan commented on the issue:

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


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response Received: 
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8) 
> 

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user rhtyd commented on the issue:

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


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user rhtyd commented on the issue:

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


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response Received: 
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Processing:  { Ans: , MgmtId: 
> 345051581208, 

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user rhtyd commented on the issue:

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


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9183:
-

Commit 0279ac20e46cbbc7f699dc41eafbe31fe0c4797b in cloudstack's branch 
refs/heads/4.8 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0279ac2 ]

Merge pull request #1744 from greenqloud/4.7

CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

* pr/1744:
  CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

Signed-off-by: Rohit Yadav 


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9183:
-

Commit 0279ac20e46cbbc7f699dc41eafbe31fe0c4797b in cloudstack's branch 
refs/heads/4.7 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0279ac2 ]

Merge pull request #1744 from greenqloud/4.7

CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

* pr/1744:
  CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

Signed-off-by: Rohit Yadav 


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9183:


Github user asfgit closed the pull request at:

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


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9183:
-

Commit 0279ac20e46cbbc7f699dc41eafbe31fe0c4797b in cloudstack's branch 
refs/heads/4.7 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0279ac2 ]

Merge pull request #1744 from greenqloud/4.7

CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

* pr/1744:
  CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

Signed-off-by: Rohit Yadav 


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9183:
-

Commit 0279ac20e46cbbc7f699dc41eafbe31fe0c4797b in cloudstack's branch 
refs/heads/4.8 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0279ac2 ]

Merge pull request #1744 from greenqloud/4.7

CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

* pr/1744:
  CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

Signed-off-by: Rohit Yadav 


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9544:
-

Commit 0f89a8939fa618aa516523f21933fc7cabfe8a3a in cloudstack's branch 
refs/heads/4.8 from [~marcaurele]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f89a89 ]

CLOUDSTACK-9544: Check access on account trying to generate user API keys

This fixes CVE-2016-6813

Signed-off-by: Marc-Aurèle Brothier 
Signed-off-by: Rohit Yadav 
(cherry picked from commit 158497d68a92ab1e1f864a77371ea1de5c4dc5bb)
Signed-off-by: Rohit Yadav 


> Account API keys vulnerability in Cloudstack with possible privileges 
> escalation
> 
>
> Key: CLOUDSTACK-9544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: John Kinsella
>Assignee: Rohit Yadav
> Fix For: 4.8.1.1, 4.9.0.1, 4.5.2.2
>
> Attachments: fix_api_keys.patch
>
>
> Reported by Marc-Aurèle Brothier to security@:
> Hello,
> I don't know if you would consider this as a vulnerabilities but I think it 
> is one. Currently in all Cloudstack version, any user having access to the 
> API can regenerate API keys for all user except the system one with ID=1, 
> with the assumptions that he knows the UUID of the user. With the 
> consideration that user knows another user UUID from a privilege domain, the 
> attacker can change the api key of that user and then get the same access 
> since he will receive the new key and secret in the API response for that 
> privileged user. Therefore he can create a privilege account for himself 
> after that call. From there, it's open bar ;-) It's the description of the 
> worst case scenario.
> Other cases would be to access to other accounts data/vm and invalidate api 
> keys.
> I think it is a vulnerability since the user UUID is not something supposed 
> to be kept secret, and having the knowledge of this single uuid let you 
> access to the ROOT domain pretty easily.
> Human description to reproduce the case:
> Search for a user in the ROOT domain and admin account of your cloudstack 
> installation, and get the ID of a user, but not the admin one, or create a 
> new user in this account.
> Create or use another user from a different account/domain that does not have 
> any privileged access, a normal account. Then using the secretkey and apikey 
> from the normal user, issue a registerUserKeys id= and 
> see that you're getting a new pair of api & secret key.
> The patch is pretty simple and attached to this email, 3 lines to change in 
> one class to check the access of the account caller on the account associated 
> to the user uuid in the request. The patch has been done on the file version 
> on the master branch, and should be very easily back ported to all version 
> since the code hasn't changed much in this method.
> I haven't open any PR or bug of course to relate this finding. We will patch 
> our own cloudstack version (the repo having this fix is private) today, 
> that's all.
> Let me know if you have any questions or for the follow up.
> Kind regards,



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9183:
-

Commit 0279ac20e46cbbc7f699dc41eafbe31fe0c4797b in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0279ac2 ]

Merge pull request #1744 from greenqloud/4.7

CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

* pr/1744:
  CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

Signed-off-by: Rohit Yadav 


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9544:
-

Commit 0f89a8939fa618aa516523f21933fc7cabfe8a3a in cloudstack's branch 
refs/heads/4.9 from [~marcaurele]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f89a89 ]

CLOUDSTACK-9544: Check access on account trying to generate user API keys

This fixes CVE-2016-6813

Signed-off-by: Marc-Aurèle Brothier 
Signed-off-by: Rohit Yadav 
(cherry picked from commit 158497d68a92ab1e1f864a77371ea1de5c4dc5bb)
Signed-off-by: Rohit Yadav 


> Account API keys vulnerability in Cloudstack with possible privileges 
> escalation
> 
>
> Key: CLOUDSTACK-9544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: John Kinsella
>Assignee: Rohit Yadav
> Fix For: 4.8.1.1, 4.9.0.1, 4.5.2.2
>
> Attachments: fix_api_keys.patch
>
>
> Reported by Marc-Aurèle Brothier to security@:
> Hello,
> I don't know if you would consider this as a vulnerabilities but I think it 
> is one. Currently in all Cloudstack version, any user having access to the 
> API can regenerate API keys for all user except the system one with ID=1, 
> with the assumptions that he knows the UUID of the user. With the 
> consideration that user knows another user UUID from a privilege domain, the 
> attacker can change the api key of that user and then get the same access 
> since he will receive the new key and secret in the API response for that 
> privileged user. Therefore he can create a privilege account for himself 
> after that call. From there, it's open bar ;-) It's the description of the 
> worst case scenario.
> Other cases would be to access to other accounts data/vm and invalidate api 
> keys.
> I think it is a vulnerability since the user UUID is not something supposed 
> to be kept secret, and having the knowledge of this single uuid let you 
> access to the ROOT domain pretty easily.
> Human description to reproduce the case:
> Search for a user in the ROOT domain and admin account of your cloudstack 
> installation, and get the ID of a user, but not the admin one, or create a 
> new user in this account.
> Create or use another user from a different account/domain that does not have 
> any privileged access, a normal account. Then using the secretkey and apikey 
> from the normal user, issue a registerUserKeys id= and 
> see that you're getting a new pair of api & secret key.
> The patch is pretty simple and attached to this email, 3 lines to change in 
> one class to check the access of the account caller on the account associated 
> to the user uuid in the request. The patch has been done on the file version 
> on the master branch, and should be very easily back ported to all version 
> since the code hasn't changed much in this method.
> I haven't open any PR or bug of course to relate this finding. We will patch 
> our own cloudstack version (the repo having this fix is private) today, 
> that's all.
> Let me know if you have any questions or for the follow up.
> Kind regards,



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9183:
-

Commit 0279ac20e46cbbc7f699dc41eafbe31fe0c4797b in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0279ac2 ]

Merge pull request #1744 from greenqloud/4.7

CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

* pr/1744:
  CLOUDSTACK-9183: bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
directory

Signed-off-by: Rohit Yadav 


> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9544:
-

Commit 0f89a8939fa618aa516523f21933fc7cabfe8a3a in cloudstack's branch 
refs/heads/master from [~marcaurele]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f89a89 ]

CLOUDSTACK-9544: Check access on account trying to generate user API keys

This fixes CVE-2016-6813

Signed-off-by: Marc-Aurèle Brothier 
Signed-off-by: Rohit Yadav 
(cherry picked from commit 158497d68a92ab1e1f864a77371ea1de5c4dc5bb)
Signed-off-by: Rohit Yadav 


> Account API keys vulnerability in Cloudstack with possible privileges 
> escalation
> 
>
> Key: CLOUDSTACK-9544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: John Kinsella
>Assignee: Rohit Yadav
> Fix For: 4.8.1.1, 4.9.0.1, 4.5.2.2
>
> Attachments: fix_api_keys.patch
>
>
> Reported by Marc-Aurèle Brothier to security@:
> Hello,
> I don't know if you would consider this as a vulnerabilities but I think it 
> is one. Currently in all Cloudstack version, any user having access to the 
> API can regenerate API keys for all user except the system one with ID=1, 
> with the assumptions that he knows the UUID of the user. With the 
> consideration that user knows another user UUID from a privilege domain, the 
> attacker can change the api key of that user and then get the same access 
> since he will receive the new key and secret in the API response for that 
> privileged user. Therefore he can create a privilege account for himself 
> after that call. From there, it's open bar ;-) It's the description of the 
> worst case scenario.
> Other cases would be to access to other accounts data/vm and invalidate api 
> keys.
> I think it is a vulnerability since the user UUID is not something supposed 
> to be kept secret, and having the knowledge of this single uuid let you 
> access to the ROOT domain pretty easily.
> Human description to reproduce the case:
> Search for a user in the ROOT domain and admin account of your cloudstack 
> installation, and get the ID of a user, but not the admin one, or create a 
> new user in this account.
> Create or use another user from a different account/domain that does not have 
> any privileged access, a normal account. Then using the secretkey and apikey 
> from the normal user, issue a registerUserKeys id= and 
> see that you're getting a new pair of api & secret key.
> The patch is pretty simple and attached to this email, 3 lines to change in 
> one class to check the access of the account caller on the account associated 
> to the user uuid in the request. The patch has been done on the file version 
> on the master branch, and should be very easily back ported to all version 
> since the code hasn't changed much in this method.
> I haven't open any PR or bug of course to relate this finding. We will patch 
> our own cloudstack version (the repo having this fix is private) today, 
> that's all.
> Let me know if you have any questions or for the follow up.
> Kind regards,



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

[jira] [Commented] (CLOUDSTACK-9561) After domain/account deletion, snapshot taken by the domain/account remains undeleted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9561:


Github user blueorangutan commented on the issue:

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


> After domain/account deletion, snapshot taken by the domain/account remains 
> undeleted
> -
>
> Key: CLOUDSTACK-9561
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9561
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> While deleting the UserAccount Cleanup for the removed VMs/volumes are not 
> happening. For the removed VMs, snapshots doesn't get cleaned. Only for 
> volumes in ready state the cleanup happens.



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

[jira] [Commented] (CLOUDSTACK-9561) After domain/account deletion, snapshot taken by the domain/account remains undeleted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9561:


Github user rhtyd commented on the issue:

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


> After domain/account deletion, snapshot taken by the domain/account remains 
> undeleted
> -
>
> Key: CLOUDSTACK-9561
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9561
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> While deleting the UserAccount Cleanup for the removed VMs/volumes are not 
> happening. For the removed VMs, snapshots doesn't get cleaned. Only for 
> volumes in ready state the cleanup happens.



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

[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9183:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1744
  
Merging this based on git history changes found in 6477bd8
Several test failures are not related to the changes, but because marvin 
test fixes were not merged on 4.7 branch. Going ahead with the merge, since 
this only adds a delete file.



> CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
> ---
>
> Key: CLOUDSTACK-9183
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
> Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS
>Reporter: Milamber
>  Labels: kvm, systemvm
>
> On my 4.7.0 RC1 test environment, I've this warning message:
> 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts 
> from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or 
> directory
> I don't find this bash script anywhere (on management node, host node and 
> inside the VR)
> I find theses references to this script inside:
> public static final String ROUTER_ALERTS = "getRouterAlerts.sh";
> ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java
> ExecutionResult result = _vrDeployer.executeInVR(routerIp, 
> VRScripts.ROUTER_ALERTS, args);
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
>  



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

[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1745
  
LGTM. Reviews -- @karuturi @jburwell @murali-reddy and others ?


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1735
  
if the data store is deleted, the snapshot should be removed as well, right?


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



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

[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8326:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1743
  
@ustcweizhou @The-Loeki do we have LGTM from you guys on this? Thanks.

LGTM.


> Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP 
> Debian Wheezy specific
> ---
>
> Key: CLOUDSTACK-8326
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Virtual Router
>Affects Versions: 4.3.2
> Environment: Ubuntu 12.04.5 for Host
> Debian Squeeze for VR
>Reporter: Ivan A Kudryavtsev
>Assignee: Wido den Hollander
> Fix For: Future, 4.10.0.0, 4.9.2.0
>
>
> I've found bug in DHCP component of VR 4.3.2. The bug is completely described 
> at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217
> DHCP responses with bad checksum. As a result, dhcp client unable to get 
> lease: "dhcpd: 5 bad udp checksums in 5 packets"
> Hotfix is:
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM 
> --checksum-fill
> on VR.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 6f609e6946e5099c09f649f26da5ef2a2103d889 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f609e6 ]

Merge pull request #1713 from wido/CLOUDSTACK-9552

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic NetworkingAllow DNS 
queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander w...@widodh.nl

* pr/1713:
  CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Signed-off-by: Rohit Yadav 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 8ea75f1a85b53908f97a6397637ecb346b821387 in cloudstack's branch 
refs/heads/4.9 from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8ea75f1 ]

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Allow DNS queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 8ea75f1a85b53908f97a6397637ecb346b821387 in cloudstack's branch 
refs/heads/master from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8ea75f1 ]

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Allow DNS queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 6f609e6946e5099c09f649f26da5ef2a2103d889 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f609e6 ]

Merge pull request #1713 from wido/CLOUDSTACK-9552

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic NetworkingAllow DNS 
queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander w...@widodh.nl

* pr/1713:
  CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Signed-off-by: Rohit Yadav 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 6f609e6946e5099c09f649f26da5ef2a2103d889 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f609e6 ]

Merge pull request #1713 from wido/CLOUDSTACK-9552

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic NetworkingAllow DNS 
queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander w...@widodh.nl

* pr/1713:
  CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Signed-off-by: Rohit Yadav 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9552:


Github user asfgit closed the pull request at:

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


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 6f609e6946e5099c09f649f26da5ef2a2103d889 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f609e6 ]

Merge pull request #1713 from wido/CLOUDSTACK-9552

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic NetworkingAllow DNS 
queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander w...@widodh.nl

* pr/1713:
  CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Signed-off-by: Rohit Yadav 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 6f609e6946e5099c09f649f26da5ef2a2103d889 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f609e6 ]

Merge pull request #1713 from wido/CLOUDSTACK-9552

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic NetworkingAllow DNS 
queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander w...@widodh.nl

* pr/1713:
  CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Signed-off-by: Rohit Yadav 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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

[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-9552:
-

Commit 6f609e6946e5099c09f649f26da5ef2a2103d889 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f609e6 ]

Merge pull request #1713 from wido/CLOUDSTACK-9552

CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic NetworkingAllow DNS 
queries over TCP when egress filtering is configured.

When using DNSSEC more and more queries are done over TCP and this
requires 53/TCP to be allowed.

Signed-off-by: Wido den Hollander w...@widodh.nl

* pr/1713:
  CLOUDSTACK-9552: Allow egress TCP/53 implicitly in Basic Networking

Signed-off-by: Rohit Yadav 


> KVM Security Groups do not allow DNS over TCP egress
> 
>
> Key: CLOUDSTACK-9552
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.8.0, 4.9.0
> Environment: KVM Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: dns, dnssec, security-groups
> Fix For: Future
>
>
> When egress filtering is configured all outbound traffic is blocked unless 
> configured otherwise.
> With the exception that UDP/53 DNS is allowed implicitly by the Security 
> Groups.
> Many DNS responses are larger then 4k, with DNSSEC for example and require 
> TCP to be allowed.
> The Security Groups should also allow TCP/53 when egress filtering is 
> configured.



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