[jira] [Created] (CLOUDSTACK-9760) add support for native container orchestration service

[Murali Reddy (JIRA)]

Murali Reddy created CLOUDSTACK-9760:


 Summary: add support for native container orchestration service
 Key: CLOUDSTACK-9760
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9760
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.11.0.0


Container technologies are gaining quite a momentum and changing the way how 
application are traditionally deployed in the public and private clouds. 
Gaining interest in micro services based architecture also fostering adaption 
of container technologies. Like how cloud orchestration platforms enabled 
provisioning of VM's and adjunct services, container orchestration platforms 
like Kubernetes, docker swarm, mesos are emerging to enable orchestration of 
containers. Container orchestration platforms typically can be run any where 
and can be used to provision containers. A popular choice of running containers 
has been running them on the IAAS provisioned VM's. AWS and GCE provides native 
functionality to launch containers abstracting underlying consumption of VM's. 
A container orchestration platform can be provisioned on top of CloudStack 
using develop tools, but they are not out of the box solution. Given the 
momentum of container technologies, miro-services etc it make sense to provide 
a native functionality in CloudStack which is available out-of-the-box for 
users.

FS: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+container+service+functional+specification+and+design+document



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

[jira] [Issue Comment Deleted] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Comment: was deleted

(was: Really need help on this.. will send paypal donation.)

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log, cloudstack.tar, messages
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9359:
-

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9359:


Github user asfgit closed the pull request at:

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


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-676:


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

CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM

This commit implements basic Security Grouping for KVM in
Basic Networking.

It does not implement full Security Grouping yet, but it does:
- Prevent IP-Address source spoofing
- Allow DHCPv6 clients, but disallow DHCPv6 servers
- Disallow Instances to send out Router Advertisements

The Security Grouping allows ICMPv6 packets as described by RFC4890
as they are essential for IPv6 connectivity.

Following RFC4890 it allows:
- Router Solicitations
- Router Advertisements (incoming only)
- Neighbor Advertisements
- Neighbor Solicitations
- Packet Too Big
- Time Exceeded
- Destination Unreachable
- Parameter Problem
- Echo Request

ICMPv6 is a essential part of IPv6, without it connectivity will break or be 
very
unreliable.

For now it allows any UDP and TCP packet to be send in to the Instance which
effectively opens up the firewall completely.

Future commits will implement Security Grouping further which allows 
controlling UDP and TCP
ports for IPv6 like can be done with IPv4.

Regardless of the egress filtering (which can't be done yet) it will always 
allow outbound DNS
to port 53 over UDP or TCP.

Signed-off-by: Wido den Hollander 


> Firewall / ACL support for ipv6
> ---
>
> Key: CLOUDSTACK-676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Chiradeep Vittal
>Assignee: Wido den Hollander
> Fix For: Future
>
>
> An ability to specify a firewall / ACL rule set for a subnet which has 
> instances with ipv6 addresses. The implementation can be at the VR level, at 
> the hypervisor level or in an external firewall



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1700 from wido/ipv6-basic-networking

CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very 
basic IPv6 to Basic Networking. The main goal of this PR is that the API 
returns a valid IPv6 address over which the Instance is reachable.

The GUI will show the IPv6 address after deployment of the Instance.

![screenshot from 2016-10-03 16 34 
56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png)

If the table VLAN has a proper IPv6 CIDR configured the 
DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will 
obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862

In this case the _vlan_ table contained:

mysql> select * from vlan \G
*** 1. row ***
 id: 1
   uuid: 90e0716c-5261-4992-bb9d-0afd3006f476
vlan_id: vlan://untagged
   vlan_gateway: 172.16.0.1
   vlan_netmask: 255.255.255.0
description: 172.16.0.10-172.16.0.250
  vlan_type: DirectAttached
 data_center_id: 1
 network_id: 204
physical_network_id: 200
ip6_gateway: 2001:980:7936:112::1
   ip6_cidr: 2001:980:7936:112::/64
  ip6_range: NULL
removed: NULL
created: 2016-07-19 20:39:41
1 row in set (0.00 sec)

mysql>

It will then log:

2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1
2016-10-04 11:42:45,009 INFO  [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 
using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e

The template has to be configured accordingly:
- No IPv6 Privacy Extensions
- Use SLAAC
- Follow RFC4862

This is also described in: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking

The next steps after this will be:
- Security Grouping to prevent IPv6 Address Spoofing
- Security Grouping to filter ICMP, UDP and TCP traffic

* pr/1700:
  CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking
  CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM
  CLOUDSTACK-9359: IPv6 for Basic Networking with KVM

Signed-off-by: Rajani Karuturi 


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-9359: IPv6 for Basic Networking with KVM

This commit adds the initial functionality for IPv6 in Basic Networking.

When a valid IPv6 CIDR is configured for the POD/VLAN the 
DirectPodBasedNetworkGuru
will use the EUI-64 calculation to calculate the IPv6 Address the Instance will 
obtain.

For this it is required that the physical routers in the Layer 2 network 
(POD/VLAN) send out
Router Advertisements with the same subnet as configured in CloudStack.

A example subnet could be 2001:db8::/64

Using radvd a Linux Router could send out Router Advertisements using this 
configuration:

  interface eth0
  {

MinRtrAdvInterval 5;
MaxRtrAdvInterval 60;
AdvSendAdvert on;
AdvOtherConfigFlag off;
IgnoreIfMissing off;

prefix 2001:db8::/64 {
};

RDNSS 2001:db8:::53 {
};
  };

A Instance with MAC Address 06:7a:88:00:00:8b will obtain IPv6 address 
2001:db8:100::47a:88ff:fe00:8b

Both Windows, Linux and FreeBSD use the same calculation for their IPv6 
Addresses, this is specified
in RFC4862 (IPv6 Stateless Address Autoconfiguration).

Under Linux it is mandatory that IPv6 Privacy Extensions are disabled:

$ sysctl -w net.ipv6.conf.all.use_tempaddr=0

Windows should be configured to use the MAC Address as the identifier for the 
EUI-64/SLAAC calculation.

$ netsh interface ipv6 set privacy state=disabled store=persistent
$ netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

The IPv6 address is stored in the 'nics' table and is then returned by the API 
and will be shown in the UI.

Searching for a conflicting IPv6 Address it NOT required as each IPv6 address 
is based on the MAC Address
of the Instance and therefor unique.

Security Grouping has not been implemented yet and will follow in a upcoming 
commit.

Signed-off-by: Wido den Hollander 


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-676:


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

Merge pull request #1700 from wido/ipv6-basic-networking

CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very 
basic IPv6 to Basic Networking. The main goal of this PR is that the API 
returns a valid IPv6 address over which the Instance is reachable.

The GUI will show the IPv6 address after deployment of the Instance.

![screenshot from 2016-10-03 16 34 
56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png)

If the table VLAN has a proper IPv6 CIDR configured the 
DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will 
obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862

In this case the _vlan_ table contained:

mysql> select * from vlan \G
*** 1. row ***
 id: 1
   uuid: 90e0716c-5261-4992-bb9d-0afd3006f476
vlan_id: vlan://untagged
   vlan_gateway: 172.16.0.1
   vlan_netmask: 255.255.255.0
description: 172.16.0.10-172.16.0.250
  vlan_type: DirectAttached
 data_center_id: 1
 network_id: 204
physical_network_id: 200
ip6_gateway: 2001:980:7936:112::1
   ip6_cidr: 2001:980:7936:112::/64
  ip6_range: NULL
removed: NULL
created: 2016-07-19 20:39:41
1 row in set (0.00 sec)

mysql>

It will then log:

2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1
2016-10-04 11:42:45,009 INFO  [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 
using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e

The template has to be configured accordingly:
- No IPv6 Privacy Extensions
- Use SLAAC
- Follow RFC4862

This is also described in: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking

The next steps after this will be:
- Security Grouping to prevent IPv6 Address Spoofing
- Security Grouping to filter ICMP, UDP and TCP traffic

* pr/1700:
  CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking
  CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM
  CLOUDSTACK-9359: IPv6 for Basic Networking with KVM

Signed-off-by: Rajani Karuturi 


> Firewall / ACL support for ipv6
> ---
>
> Key: CLOUDSTACK-676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Chiradeep Vittal
>Assignee: Wido den Hollander
> Fix For: Future
>
>
> An ability to specify a firewall / ACL rule set for a subnet which has 
> instances with ipv6 addresses. The implementation can be at the VR level, at 
> the hypervisor level or in an external firewall



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

[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-676:


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

CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking

This commit implements Ingress and Egress filtering for IPv6 in
Basic Networking.

It allows for opening and closing ports just as can be done with IPv4.

Rules have to be specified twice, once for IPv4 and once for IPv6, for
example:

- 22 until 22: 0.0.0.0/0
- 22 until 22: ::/0

Egress filtering works the same as with IPv4. When no rule is applied all
traffic is allowed. Otherwise only the specified traffic (with DNS being
the exception) is allowed.

Signed-off-by: Wido den Hollander 


> Firewall / ACL support for ipv6
> ---
>
> Key: CLOUDSTACK-676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Chiradeep Vittal
>Assignee: Wido den Hollander
> Fix For: Future
>
>
> An ability to specify a firewall / ACL rule set for a subnet which has 
> instances with ipv6 addresses. The implementation can be at the VR level, at 
> the hypervisor level or in an external firewall



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

[jira] [Commented] (CLOUDSTACK-676) Firewall / ACL support for ipv6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-676:


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

Merge pull request #1700 from wido/ipv6-basic-networking

CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very 
basic IPv6 to Basic Networking. The main goal of this PR is that the API 
returns a valid IPv6 address over which the Instance is reachable.

The GUI will show the IPv6 address after deployment of the Instance.

![screenshot from 2016-10-03 16 34 
56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png)

If the table VLAN has a proper IPv6 CIDR configured the 
DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will 
obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862

In this case the _vlan_ table contained:

mysql> select * from vlan \G
*** 1. row ***
 id: 1
   uuid: 90e0716c-5261-4992-bb9d-0afd3006f476
vlan_id: vlan://untagged
   vlan_gateway: 172.16.0.1
   vlan_netmask: 255.255.255.0
description: 172.16.0.10-172.16.0.250
  vlan_type: DirectAttached
 data_center_id: 1
 network_id: 204
physical_network_id: 200
ip6_gateway: 2001:980:7936:112::1
   ip6_cidr: 2001:980:7936:112::/64
  ip6_range: NULL
removed: NULL
created: 2016-07-19 20:39:41
1 row in set (0.00 sec)

mysql>

It will then log:

2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1
2016-10-04 11:42:45,009 INFO  [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 
using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e

The template has to be configured accordingly:
- No IPv6 Privacy Extensions
- Use SLAAC
- Follow RFC4862

This is also described in: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking

The next steps after this will be:
- Security Grouping to prevent IPv6 Address Spoofing
- Security Grouping to filter ICMP, UDP and TCP traffic

* pr/1700:
  CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking
  CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM
  CLOUDSTACK-9359: IPv6 for Basic Networking with KVM

Signed-off-by: Rajani Karuturi 


> Firewall / ACL support for ipv6
> ---
>
> Key: CLOUDSTACK-676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-676
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Chiradeep Vittal
>Assignee: Wido den Hollander
> Fix For: Future
>
>
> An ability to specify a firewall / ACL rule set for a subnet which has 
> instances with ipv6 addresses. The implementation can be at the VR level, at 
> the hypervisor level or in an external firewall



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1700 from wido/ipv6-basic-networking

CLOUDSTACK-9359: IPv6 for Basic NetworkingThis PR is a proposal for adding very 
basic IPv6 to Basic Networking. The main goal of this PR is that the API 
returns a valid IPv6 address over which the Instance is reachable.

The GUI will show the IPv6 address after deployment of the Instance.

![screenshot from 2016-10-03 16 34 
56](https://cloud.githubusercontent.com/assets/326786/19070024/b06d2de6-8a29-11e6-8fe7-4902e2801ada.png)

If the table VLAN has a proper IPv6 CIDR configured the 
DirectPodBasedNetworkGuru will calculate the IPv6 Address the Instance will 
obtain using EUI-64 and SLAAC: https://tools.ietf.org/search/rfc4862

In this case the _vlan_ table contained:

mysql> select * from vlan \G
*** 1. row ***
 id: 1
   uuid: 90e0716c-5261-4992-bb9d-0afd3006f476
vlan_id: vlan://untagged
   vlan_gateway: 172.16.0.1
   vlan_netmask: 255.255.255.0
description: 172.16.0.10-172.16.0.250
  vlan_type: DirectAttached
 data_center_id: 1
 network_id: 204
physical_network_id: 200
ip6_gateway: 2001:980:7936:112::1
   ip6_cidr: 2001:980:7936:112::/64
  ip6_range: NULL
removed: NULL
created: 2016-07-19 20:39:41
1 row in set (0.00 sec)

mysql>

It will then log:

2016-10-04 11:42:44,998 DEBUG [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Found IPv6 CIDR 2001:980:7936:112::/64 for VLAN 1
2016-10-04 11:42:45,009 INFO  [c.c.n.g.DirectPodBasedNetworkGuru] 
(Work-Job-Executor-1:ctx-1975ec54 job-186/job-187 ctx-0d967d88) 
(logid:275c4961) Calculated IPv6 address 2001:980:7936:112:4ba:80ff:fe00:e9 
using EUI-64 for NIC 6a05deab-b5d9-4116-80da-c94b48333e5e

The template has to be configured accordingly:
- No IPv6 Privacy Extensions
- Use SLAAC
- Follow RFC4862

This is also described in: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking

The next steps after this will be:
- Security Grouping to prevent IPv6 Address Spoofing
- Security Grouping to filter ICMP, UDP and TCP traffic

* pr/1700:
  CLOUDSTACK-676: IPv6 In -and Egress filtering for Basic Networking
  CLOUDSTACK-676: IPv6 Basic Security Grouping for KVM
  CLOUDSTACK-9359: IPv6 for Basic Networking with KVM

Signed-off-by: Rajani Karuturi 


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9359:
-

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1700
  
LGTM. Test results are good. I am merging this now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9359:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1700
  
LGTM. Test results are good. I am merging this now.


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9619:
-

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



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

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9619:


Github user asfgit closed the pull request at:

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


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



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

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1749 from mike-tutkowski/archived_snapshots

CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few 
issues in #1600 (which was recently merged to master for 4.10).

In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. 
In one such scenario, the source snapshot in question is coming from secondary 
storage (when we are creating a new volume on managed storage from a snapshot 
of ours thats on secondary storage).

This usually worked in the regression tests due to a bit of "luck": We retrieve 
the ID of the snapshot (which is on secondary storage) and then try to pull out 
its StorageVO object (which is for primary storage). If you happen to have a 
primary storage that matches the ID (which is the ID of a secondary storage), 
then getSnapshotDetails populates its Map with inapplicable 
data (that is later ignored) and you dont easily see a problem. However, if you 
dont have a primary storage that matches that ID (which I didnt today because I 
had removed that primary storage), then a NullPointerException is thrown.

I have fixed that issue by skipping getSnapshotDetails if the source is coming 
from secondary storage.

While fixing that, I noticed a couple more problems:

1)   We can invoke grantAccess on a snapshot thats actually on secondary 
storage (this doesnt amount to much because the VolumeServiceImpl ignores the 
call when its not for a primary-storage driver).
2)   We can invoke revokeAccess on a snapshot thats actually on secondary 
storage (this doesnt amount to much because the VolumeServiceImpl ignores the 
call when its not for a primary-storage driver).

I have corrected those issues, as well.

I then came across one more problem:
 When using a SAN snapshot and copying it to secondary storage or 
creating a new managed-storage volume from a snapshot of ours on secondary 
storage, we attach to the SR in the XenServer code, but detach from it in the 
StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
code to perform an SR detach). Since we know to detach from the SR after the 
copy is done, we should detach from the SR in the XenServer code (without that 
code having to be explicitly called from outside of the XenServer logic).

I went ahead and changed that, as well.

JIRA Ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-9619

* pr/1749:
  CLOUDSTACK-9619: Updates for SAN-assisted snapshots

Signed-off-by: Rajani Karuturi 


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a 

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF subversion and git services (JIRA)]

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

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

Commit 06806a6523d4c5b46a0345ad62171ed26e843bb8 in cloudstack's branch 
refs/heads/master from [~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06806a6 ]

CLOUDSTACK-9619: Updates for SAN-assisted snapshots


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



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

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1749 from mike-tutkowski/archived_snapshots

CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few 
issues in #1600 (which was recently merged to master for 4.10).

In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. 
In one such scenario, the source snapshot in question is coming from secondary 
storage (when we are creating a new volume on managed storage from a snapshot 
of ours thats on secondary storage).

This usually worked in the regression tests due to a bit of "luck": We retrieve 
the ID of the snapshot (which is on secondary storage) and then try to pull out 
its StorageVO object (which is for primary storage). If you happen to have a 
primary storage that matches the ID (which is the ID of a secondary storage), 
then getSnapshotDetails populates its Map with inapplicable 
data (that is later ignored) and you dont easily see a problem. However, if you 
dont have a primary storage that matches that ID (which I didnt today because I 
had removed that primary storage), then a NullPointerException is thrown.

I have fixed that issue by skipping getSnapshotDetails if the source is coming 
from secondary storage.

While fixing that, I noticed a couple more problems:

1)   We can invoke grantAccess on a snapshot thats actually on secondary 
storage (this doesnt amount to much because the VolumeServiceImpl ignores the 
call when its not for a primary-storage driver).
2)   We can invoke revokeAccess on a snapshot thats actually on secondary 
storage (this doesnt amount to much because the VolumeServiceImpl ignores the 
call when its not for a primary-storage driver).

I have corrected those issues, as well.

I then came across one more problem:
 When using a SAN snapshot and copying it to secondary storage or 
creating a new managed-storage volume from a snapshot of ours on secondary 
storage, we attach to the SR in the XenServer code, but detach from it in the 
StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
code to perform an SR detach). Since we know to detach from the SR after the 
copy is done, we should detach from the SR in the XenServer code (without that 
code having to be explicitly called from outside of the XenServer logic).

I went ahead and changed that, as well.

JIRA Ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-9619

* pr/1749:
  CLOUDSTACK-9619: Updates for SAN-assisted snapshots

Signed-off-by: Rajani Karuturi 


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a 

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1749 from mike-tutkowski/archived_snapshots

CLOUDSTACK-9619: Updates for SAN-assisted snapshotsThis PR is to address a few 
issues in #1600 (which was recently merged to master for 4.10).

In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. 
In one such scenario, the source snapshot in question is coming from secondary 
storage (when we are creating a new volume on managed storage from a snapshot 
of ours thats on secondary storage).

This usually worked in the regression tests due to a bit of "luck": We retrieve 
the ID of the snapshot (which is on secondary storage) and then try to pull out 
its StorageVO object (which is for primary storage). If you happen to have a 
primary storage that matches the ID (which is the ID of a secondary storage), 
then getSnapshotDetails populates its Map with inapplicable 
data (that is later ignored) and you dont easily see a problem. However, if you 
dont have a primary storage that matches that ID (which I didnt today because I 
had removed that primary storage), then a NullPointerException is thrown.

I have fixed that issue by skipping getSnapshotDetails if the source is coming 
from secondary storage.

While fixing that, I noticed a couple more problems:

1)   We can invoke grantAccess on a snapshot thats actually on secondary 
storage (this doesnt amount to much because the VolumeServiceImpl ignores the 
call when its not for a primary-storage driver).
2)   We can invoke revokeAccess on a snapshot thats actually on secondary 
storage (this doesnt amount to much because the VolumeServiceImpl ignores the 
call when its not for a primary-storage driver).

I have corrected those issues, as well.

I then came across one more problem:
 When using a SAN snapshot and copying it to secondary storage or 
creating a new managed-storage volume from a snapshot of ours on secondary 
storage, we attach to the SR in the XenServer code, but detach from it in the 
StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
code to perform an SR detach). Since we know to detach from the SR after the 
copy is done, we should detach from the SR in the XenServer code (without that 
code having to be explicitly called from outside of the XenServer logic).

I went ahead and changed that, as well.

JIRA Ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-9619

* pr/1749:
  CLOUDSTACK-9619: Updates for SAN-assisted snapshots

Signed-off-by: Rajani Karuturi 


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a 

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9619:
-

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1749
  
LGTM. From the discussion, looks like the test failures are unrelated to 
this PR. merging this now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



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

[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9619:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1749
  
LGTM. From the discussion, looks like the test failures are unrelated to 
this PR. merging this now.


> Fixes for PR 1600
> -
>
> Key: CLOUDSTACK-9619
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call 
> getSnapshotDetails. In one such scenario, the source snapshot in question is 
> coming from secondary storage (when we are creating a new volume on managed 
> storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We 
> retrieve the ID of the snapshot (which is on secondary storage) and then try 
> to pull out its StorageVO object (which is for primary storage). If you 
> happen to have a primary storage that matches the ID (which is the ID of a 
> secondary storage), then getSnapshotDetails populates its Map 
> with inapplicable data (that is later ignored) and you don’t easily see a 
> problem. However, if you don’t have a primary storage that matches that ID 
> (which I didn’t today because I had removed that primary storage), then a 
> NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is 
> coming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary 
> storage (this doesn’t amount to much because the VolumeServiceImpl ignores 
> the call when it’s not for a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a 
> new managed-storage volume from a snapshot of ours on secondary storage, we 
> attach to the SR in the XenServer code, but detach from it in the 
> StorageSystemDataMotionStrategy code (by sending a message to the XenServer 
> code to perform an SR detach). Since we know to detach from the SR after the 
> copy is done, we should detach from the SR in the XenServer code (without 
> that code having to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9729:


Github user asfgit closed the pull request at:

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


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9729:
-

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1904 from fmaximus/bugfix/CLOUDSTACK-9729

CLOUDSTACK-9729: Use latest Nuage client.CloudStack root pom change to use 
Amazon WS 11.1.16
caused our client to fail, as it was depending on classes,
which are not not present anymore.
Latest client version uses Gson instead.

BUG-ID: CLOUDSTACK-9729
Bugfix-for: master

* pr/1904:
  Use latest Nuage client.

Signed-off-by: Rajani Karuturi 


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1904 from fmaximus/bugfix/CLOUDSTACK-9729

CLOUDSTACK-9729: Use latest Nuage client.CloudStack root pom change to use 
Amazon WS 11.1.16
caused our client to fail, as it was depending on classes,
which are not not present anymore.
Latest client version uses Gson instead.

BUG-ID: CLOUDSTACK-9729
Bugfix-for: master

* pr/1904:
  Use latest Nuage client.

Signed-off-by: Rajani Karuturi 


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1904 from fmaximus/bugfix/CLOUDSTACK-9729

CLOUDSTACK-9729: Use latest Nuage client.CloudStack root pom change to use 
Amazon WS 11.1.16
caused our client to fail, as it was depending on classes,
which are not not present anymore.
Latest client version uses Gson instead.

BUG-ID: CLOUDSTACK-9729
Bugfix-for: master

* pr/1904:
  Use latest Nuage client.

Signed-off-by: Rajani Karuturi 


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Comment Edited] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael edited comment on CLOUDSTACK-9759 at 1/26/17 11:44 PM:
---

Really need help on this.. will send paypal donation.


was (Author: mabarkdoll):
Really need help on this.. well send paypal donation.

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log, cloudstack.tar, messages
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Commented] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael commented on CLOUDSTACK-9759:
-

Really need help on this.. well send paypal donation.

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log, cloudstack.tar, messages
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9729:
-

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1904
  
LGTM merging now


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9729:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1904
  
LGTM merging now


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-8672:
-

Github user nitin-maharana commented on the issue:

https://github.com/apache/cloudstack/pull/1859
  
Sure @rajesh-battala, will look at that.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> NCC Integration with CloudStack
> ---
>
> Key: CLOUDSTACK-8672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.6.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: Future
>
>




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

[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8672:


Github user nitin-maharana commented on the issue:

https://github.com/apache/cloudstack/pull/1859
  
Sure @rajesh-battala, will look at that.


> NCC Integration with CloudStack
> ---
>
> Key: CLOUDSTACK-8672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.6.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: Future
>
>




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

[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Attachment: cloudstack.tar

cloudstack.tar added contains all of /etc/cloudstack from VPC VR

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log, cloudstack.tar, messages
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Attachment: messages

VPC VR /var/log/messages

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log, messages
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Comment Edited] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael edited comment on CLOUDSTACK-9759 at 1/26/17 6:34 PM:
--

VPC VR /var/log/messages added


was (Author: mabarkdoll):
VPC VR /var/log/messages

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log, messages
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Remaining Estimate: (was: 24h)
 Original Estimate: (was: 24h)

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log
>
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Updated] (CLOUDSTACK-9759) VPC VR ips.json ethNone instead of eth1

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Summary: VPC VR ips.json ethNone instead of eth1  (was: VPC VR not 
obtaining ip address)

> VPC VR ips.json ethNone instead of eth1
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Updated] (CLOUDSTACK-9759) VPC VR not obtaining ip address

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Priority: Critical  (was: Major)

> VPC VR not obtaining ip address
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
>Priority: Critical
> Attachments: cloud.log
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Commented] (CLOUDSTACK-9759) VPC VR not obtaining ip address

[Michael (JIRA)]

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

Michael commented on CLOUDSTACK-9759:
-

Please let me know, if you need more logs.  ip addr on the VR only shows the 
link-local without modifying (/etc/cloudstack/ips.json) and restarting the VR.

My understanding is the management server sends the json to the host and the 
host delivers the ips.json to the VR.  Can I check something to see why ethNone 
is being passed instead of eth1 at some point?

> VPC VR not obtaining ip address
> ---
>
> Key: CLOUDSTACK-9759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
> for guest and public
>Reporter: Michael
> Attachments: cloud.log
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Cloudstack deployment with advanced networking.
> My VPC VR is incorrectly be assigned ethNone inside 
> (/etc/cloudstack/ips.json) for my eth1 public network interface.  If I edit 
> /etc/cloudstack/ips.json and change both occurrences of ethNone to eth1 and 
> restart the VPC then the network works for isolated guest networks attached 
> to the VPC VR and the VR itself.  (note: this issue only occurs with the VPC 
> VR not with guest network or guest shared networks).
> Here is the contents of /etc/cloudstack/ips.json
> root@r31-VM# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.1.203/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.1.203",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": true,
> "broadcast": "10.1.1.255",
> "cidr": "10.1.1.1/24",
> "device": "eth2",
> "gateway": "10.1.1.1",
> "netmask": "255.255.255.0",
> "network": "10.1.1.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.1.1.1",
> "size": "24",
> "source_nat": false
> }
> ],
> "ethNone": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "ethNone",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> "id": "ips"
> }
> After modifying the file ethNone to eth1 then the VPC VR has internet via 
> Public network vlan 165 trunked that bridges to cloudbr1.
> "eth1": [
> {
> "add": true,
> "broadcast": "10.100.71.255",
> "cidr": "10.100.66.3/21",
> "device": "eth1",
> "first_i_p": false,
> "gateway": "10.100.71.254",
> "netmask": "255.255.248.0",
> "network": "10.100.64.0/21",
> "new_nic": false,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "10.100.66.3",
> "size": "21",
> "source_nat": true,
> "vif_mac_address": "06:56:74:00:06:2c"
> }
> ],
> Public network details:
> gateway 10.100.71.254 
> ip range: 10.100.66.1 - 10.100.67.254
> Netmask: 255.255.248.0 /21
> eth1 on VPC VR is the Public network interface
> Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
> computer.
> I'm also attaching the /var/log/cloud.log from the VPC VR
> Note: I restarted the VR several times attempting other 
> /etc/network/interfaces changes before I read on how the VPC VR runs scripts 
> to configure the nics, but the final restart had the reflected changes that 
> causes things to work.
> Cloudstack is using KVM hypervisor.



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

[jira] [Updated] (CLOUDSTACK-9759) VPC VR not obtaining ip address

[Michael (JIRA)]

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

Michael updated CLOUDSTACK-9759:

Description: 
Cloudstack deployment with advanced networking.

My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) 
for my eth1 public network interface.  If I edit /etc/cloudstack/ips.json and 
change both occurrences of ethNone to eth1 and restart the VPC then the network 
works for isolated guest networks attached to the VPC VR and the VR itself.  
(note: this issue only occurs with the VPC VR not with guest network or guest 
shared networks).

Here is the contents of /etc/cloudstack/ips.json

root@r31-VM# cat /etc/cloudstack/ips.json
{
"eth0": [
{
"add": true,
"broadcast": "169.254.255.255",
"cidr": "169.254.1.203/16",
"device": "eth0",
"gateway": "None",
"netmask": "255.255.0.0",
"network": "169.254.0.0/16",
"nic_dev_id": "0",
"nw_type": "control",
"one_to_one_nat": false,
"public_ip": "169.254.1.203",
"size": "16",
"source_nat": false
}
],
"eth2": [
{
"add": true,
"broadcast": "10.1.1.255",
"cidr": "10.1.1.1/24",
"device": "eth2",
"gateway": "10.1.1.1",
"netmask": "255.255.255.0",
"network": "10.1.1.0/24",
"nic_dev_id": "2",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.1.1.1",
"size": "24",
"source_nat": false
}
],
"ethNone": [
{
"add": true,
"broadcast": "10.100.71.255",
"cidr": "10.100.66.3/21",
"device": "ethNone",
"first_i_p": false,
"gateway": "10.100.71.254",
"netmask": "255.255.248.0",
"network": "10.100.64.0/21",
"new_nic": false,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "10.100.66.3",
"size": "21",
"source_nat": true,
"vif_mac_address": "06:56:74:00:06:2c"
}
],
"id": "ips"
}

After modifying the file ethNone to eth1 then the VPC VR has internet via 
Public network vlan 165 trunked that bridges to cloudbr1.

"eth1": [
{
"add": true,
"broadcast": "10.100.71.255",
"cidr": "10.100.66.3/21",
"device": "eth1",
"first_i_p": false,
"gateway": "10.100.71.254",
"netmask": "255.255.248.0",
"network": "10.100.64.0/21",
"new_nic": false,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "10.100.66.3",
"size": "21",
"source_nat": true,
"vif_mac_address": "06:56:74:00:06:2c"
}
],


Public network details:
gateway 10.100.71.254 
ip range: 10.100.66.1 - 10.100.67.254
Netmask: 255.255.248.0 /21

eth1 on VPC VR is the Public network interface

Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
computer.

I'm also attaching the /var/log/cloud.log from the VPC VR

Note: I restarted the VR several times attempting other /etc/network/interfaces 
changes before I read on how the VPC VR runs scripts to configure the nics, but 
the final restart had the reflected changes that causes things to work.

Cloudstack is using KVM hypervisor.


  was:
Cloudstack deployment with advanced networking.

My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) 
for my eth1 public network interface.  If I edit /etc/cloudstack/ips.json and 
change both occurrences of ethNone to eth1 and restart the VPC then the network 
works for isolated guest networks attached to the VPC VR and the VR itself.  
(note: this issue only occurs with the VPC VR not with guest network or guest 
shared networks).

Here is the contents of /etc/cloudstack/ips.json

root@r31-VM# cat /etc/cloudstack/ips.json
{
"eth0": [
{
"add": true,
"broadcast": "169.254.255.255",
"cidr": "169.254.1.203/16",
"device": "eth0",
"gateway": "None",
"netmask": "255.255.0.0",
"network": "169.254.0.0/16",
"nic_dev_id": "0",
"nw_type": "control",
"one_to_one_nat": false,
"public_ip": "169.254.1.203",
"size": "16",
"source_nat": false
}
],
"eth2": [
{
"add": true,
"broadcast": "10.1.1.255",
"cidr": "10.1.1.1/24",
"device": "eth2",
"gateway": "10.1.1.1",
"netmask": "255.255.255.0",
"network": "10.1.1.0/24",
"nic_dev_id": 

[jira] [Created] (CLOUDSTACK-9759) VPC VR not obtaining ip address

[Michael (JIRA)]

Michael created CLOUDSTACK-9759:
---

 Summary: VPC VR not obtaining ip address
 Key: CLOUDSTACK-9759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.9.2.0
 Environment: Centos 6.8, CloudStack 4.9.2.0 advanced networking vlans 
for guest and public
Reporter: Michael
 Attachments: cloud.log

Cloudstack deployment with advanced networking.

My VPC VR is incorrectly be assigned ethNone inside (/etc/cloudstack/ips.json) 
for my eth1 public network interface.  If I edit /etc/cloudstack/ips.json and 
change both occurrences of ethNone to eth1 and restart the VPC then the network 
works for isolated guest networks attached to the VPC VR and the VR itself.  
(note: this issue only occurs with the VPC VR not with guest network or guest 
shared networks).

Here is the contents of /etc/cloudstack/ips.json

root@r31-VM# cat /etc/cloudstack/ips.json
{
"eth0": [
{
"add": true,
"broadcast": "169.254.255.255",
"cidr": "169.254.1.203/16",
"device": "eth0",
"gateway": "None",
"netmask": "255.255.0.0",
"network": "169.254.0.0/16",
"nic_dev_id": "0",
"nw_type": "control",
"one_to_one_nat": false,
"public_ip": "169.254.1.203",
"size": "16",
"source_nat": false
}
],
"eth2": [
{
"add": true,
"broadcast": "10.1.1.255",
"cidr": "10.1.1.1/24",
"device": "eth2",
"gateway": "10.1.1.1",
"netmask": "255.255.255.0",
"network": "10.1.1.0/24",
"nic_dev_id": "2",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.1.1.1",
"size": "24",
"source_nat": false
}
],
"ethNone": [
{
"add": true,
"broadcast": "10.100.71.255",
"cidr": "10.100.66.3/21",
"device": "ethNone",
"first_i_p": false,
"gateway": "10.100.71.254",
"netmask": "255.255.248.0",
"network": "10.100.64.0/21",
"new_nic": false,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "10.100.66.3",
"size": "21",
"source_nat": true,
"vif_mac_address": "06:56:74:00:06:2c"
}
],
"id": "ips"
}

After modifying the file ethNone to eth1 then the VPC VR has internet via 
Public network vlan 165 trunked that bridges to cloudbr1.

"eth1": [
{
"add": true,
"broadcast": "10.100.71.255",
"cidr": "10.100.66.3/21",
"device": "eth1",
"first_i_p": false,
"gateway": "10.100.71.254",
"netmask": "255.255.248.0",
"network": "10.100.64.0/21",
"new_nic": false,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "10.100.66.3",
"size": "21",
"source_nat": true,
"vif_mac_address": "06:56:74:00:06:2c"
}
],


Public network details:
gateway 10.100.71.254 
ip range: 10.100.66.1 - 10.100.67.254
Netmask: 255.255.248.0 /21

eth1 on VPC VR is the Public network interface

Guest network uses vlan's 300-500 that are trunked into cloudbr1 on the host 
computer.

I'm also attaching the /var/log/cloud.log from the VPC VR

Note: I restarted the VR several times attempting other /etc/network/interfaces 
changes before I read on how the VPC VR runs scripts to configure the nics, but 
the final restart had the reflected changes that causes things to work.




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

[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8672:


Github user rajesh-battala commented on the issue:

https://github.com/apache/cloudstack/pull/1859
  
@nitin-maharana @sowmyakrishn  Can you please check why CI tests are 
failing?


> NCC Integration with CloudStack
> ---
>
> Key: CLOUDSTACK-8672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.6.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: Future
>
>




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

[jira] [Commented] (CLOUDSTACK-8672) NCC Integration with CloudStack

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-8672:
-

Github user rajesh-battala commented on the issue:

https://github.com/apache/cloudstack/pull/1859
  
@nitin-maharana @sowmyakrishn  Can you please check why CI tests are 
failing?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> NCC Integration with CloudStack
> ---
>
> Key: CLOUDSTACK-8672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.6.0
>Reporter: Rajesh Battala
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: Future
>
>




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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9359:
-

Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1700
  
I rebased the code against master and it is compiling with Java 8 and 
passing all tests.

```[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 8:59.691s (Wall Clock)
[INFO] Finished at: Thu Jan 26 15:45:36 CET 2017
[INFO] Final Memory: 105M/1555M
[INFO] 
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9462:
-

Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1916
  
Good point to remove Ubuntu 12.04 in 4.10.

I didn't notice this is for 4.9. Not really paid attention to it.

I personally dislike the moving of the control file while building the deps 
though. Don't see another way however.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1916
  
Good point to remove Ubuntu 12.04 in 4.10.

I didn't notice this is for 4.9. Not really paid attention to it.

I personally dislike the moving of the control file while building the deps 
though. Don't see another way however.


> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9359:


Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1700
  
I rebased the code against master and it is compiling with Java 8 and 
passing all tests.

```[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 8:59.691s (Wall Clock)
[INFO] Finished at: Thu Jan 26 15:45:36 CET 2017
[INFO] Final Memory: 105M/1555M
[INFO] 
```


> Return ip6address in Basic Networking
> -
>
> Key: CLOUDSTACK-9359
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
> Environment: CloudStack Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: api, basic-networking, ipv6
> Fix For: Future
>
>
> In Basic Networking Instances will obtain their IPv6 address using SLAAC 
> (Stateless Autoconfiguration) as described in the Wiki: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> When a ip6cidr is configured and is a /64 we can calculate the IPv6 address 
> an Instance will obtain.
> There is no need to store a IPv6 address in the database with the /64 subnet 
> (ip6cidr) and the MAC address we can calculate the address using EUI-64:
> "A 64-bit interface identifier is most commonly derived from its 48-bit MAC 
> address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by 
> inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is 
> used to form an IPv6 address it is modified:[1] the meaning of the 
> Universal/Local bit (the 7th most significant bit of the EUI-64, starting 
> from 1) is inverted, so that a 1 now means Universal. To create an IPv6 
> address with the network prefix 2001:db8:1:2::/64 it yields the address 
> 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) 
> bit inverted to a 1, because the MAC address is universally unique)."
> The API should return this address in the ip6address field for a NIC in Basic 
> Networking.
> End-Users can use this, but it can also be used internally by Security 
> Grouping to program rules.



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