RE: Functional Specification for the multiple IPs per NIC
Got what I needed. As below called from xenserver, a method 'default_network_rules' in vmops plugin xe host-call-plugin host-uuid=3231a0d3-1e9f-4fea-8c56-a8c3a02ed1b0 plugin=vmops fn=default_network_rules args:vmName=i-2-18-VM args:vmIP=10.147.41.241 args:vmMAC=06:7a:e4:00:00:09 args:vmID=18 Thanks, Jayapal -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Friday, February 15, 2013 9:12 AM To: cloudstack-dev@incubator.apache.org Cc: Anthony Xu Subject: Re: Functional Specification for the multiple IPs per NIC Jayapal, Vmops is a plugin that get instrumented into the xenserver host. You need to invoke the plugin from CirtixResourceBase. Usually the vmops plugin will invoke one of the script that is on that particular host Again copied by cloudstack when that host was added. Anthony, It will be good if you can review the changes Jayapal is going to make to security groups for additional ips. -abhi On 14/02/13 8:13 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Anthony, What is the best way to work on xenserver vmops. I am writing new methods in vmops file for security groups rules for the vm secondary ips. If I add a new method how to call this method from the host. I am not able to call 'vmops methodname args' on the host. Security groups iptables changes for MIPN: --- In security groups in order to allow VM secondary IPs to reach out changing the iptables rules as below. The current rules are comparing the source/destination of the VM ip and allowing only the traffic to/from the VM with VM IP. With MIPN feature VM nic can have multiple IPs. So the iptables rules source/destination ip option is changed to IPSET match. VM ip addresses (primary and secondary) are added to the ipset. Ex: -A i-2-61-def -s 10.147.41.238 -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg With ipset: -A i-2-61-def -m set --set i-2-61 src -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg Also arptables rules for secondary ip addresses are added. Please let me know if you have any comments. Thanks, Jayapal -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, January 30, 2013 9:52 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Jayapal, We should not create multiple APIs for diff outputs, when a param can give you control over output from an existing API. -abhi On 30/01/13 12:58 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 1/29/13 8:23 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ? Yes. Why do we need a listNicSecondaryIps API? Why not just enhance listNics? The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. I think this can be handled with an enhancement separate from this feature. Let us leave the API as is. Thanks, Jayapal -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Monday, January 28, 2013 9:15 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available
RE: Functional Specification for the multiple IPs per NIC
Anthony, What is the best way to work on xenserver vmops. I am writing new methods in vmops file for security groups rules for the vm secondary ips. If I add a new method how to call this method from the host. I am not able to call 'vmops methodname args' on the host. Security groups iptables changes for MIPN: --- In security groups in order to allow VM secondary IPs to reach out changing the iptables rules as below. The current rules are comparing the source/destination of the VM ip and allowing only the traffic to/from the VM with VM IP. With MIPN feature VM nic can have multiple IPs. So the iptables rules source/destination ip option is changed to IPSET match. VM ip addresses (primary and secondary) are added to the ipset. Ex: -A i-2-61-def -s 10.147.41.238 -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg With ipset: -A i-2-61-def -m set --set i-2-61 src -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg Also arptables rules for secondary ip addresses are added. Please let me know if you have any comments. Thanks, Jayapal -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, January 30, 2013 9:52 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Jayapal, We should not create multiple APIs for diff outputs, when a param can give you control over output from an existing API. -abhi On 30/01/13 12:58 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 1/29/13 8:23 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ? Yes. Why do we need a listNicSecondaryIps API? Why not just enhance listNics? The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. I think this can be handled with an enhancement separate from this feature. Let us leave the API as is. Thanks, Jayapal -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Monday, January 28, 2013 9:15 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG- chapter- instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP +a dd res s +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote
Re: Functional Specification for the multiple IPs per NIC
Jayapal, Vmops is a plugin that get instrumented into the xenserver host. You need to invoke the plugin from CirtixResourceBase. Usually the vmops plugin will invoke one of the script that is on that particular host Again copied by cloudstack when that host was added. Anthony, It will be good if you can review the changes Jayapal is going to make to security groups for additional ips. -abhi On 14/02/13 8:13 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Anthony, What is the best way to work on xenserver vmops. I am writing new methods in vmops file for security groups rules for the vm secondary ips. If I add a new method how to call this method from the host. I am not able to call 'vmops methodname args' on the host. Security groups iptables changes for MIPN: --- In security groups in order to allow VM secondary IPs to reach out changing the iptables rules as below. The current rules are comparing the source/destination of the VM ip and allowing only the traffic to/from the VM with VM IP. With MIPN feature VM nic can have multiple IPs. So the iptables rules source/destination ip option is changed to IPSET match. VM ip addresses (primary and secondary) are added to the ipset. Ex: -A i-2-61-def -s 10.147.41.238 -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg With ipset: -A i-2-61-def -m set --set i-2-61 src -m physdev --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg Also arptables rules for secondary ip addresses are added. Please let me know if you have any comments. Thanks, Jayapal -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Wednesday, January 30, 2013 9:52 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Jayapal, We should not create multiple APIs for diff outputs, when a param can give you control over output from an existing API. -abhi On 30/01/13 12:58 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 1/29/13 8:23 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ? Yes. Why do we need a listNicSecondaryIps API? Why not just enhance listNics? The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. I think this can be handled with an enhancement separate from this feature. Let us leave the API as is. Thanks, Jayapal -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Monday, January 28, 2013 9:15 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG- chapter- instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP +a dd res s +per+NIC
RE: Functional Specification for the multiple IPs per NIC
listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ? The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. Thanks, Jayapal -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Monday, January 28, 2013 9:15 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter- instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013
Re: Functional Specification for the multiple IPs per NIC
On 1/29/13 8:23 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ? Yes. Why do we need a listNicSecondaryIps API? Why not just enhance listNics? The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. I think this can be handled with an enhancement separate from this feature. Let us leave the API as is. Thanks, Jayapal -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Monday, January 28, 2013 9:15 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter- instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security
Re: Functional Specification for the multiple IPs per NIC
Jayapal, We should not create multiple APIs for diff outputs, when a param can give you control over output from an existing API. -abhi On 30/01/13 12:58 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: On 1/29/13 8:23 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: listNicIps/listNicSecondaryIps API lists the only the secondary ip addresses . do we need to list the both primary and secondary ip addresses in the list API ? Yes. Why do we need a listNicSecondaryIps API? Why not just enhance listNics? The current load balancing 'assignToLoadBalancerRule' API takes list virtualmachineids argument and configures the LB for primary IP addresses. To configure the LB for secondary ip addresses adding an optional argument to API. The optional argument vmIpaddrs takes the list of ip addresses of the corresponding virtualmachineids vm list parameter. When vmipaddrs is not passed LB is configured for the VMs primary ip addreses. I think this can be handled with an enhancement separate from this feature. Let us leave the API as is. Thanks, Jayapal -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Monday, January 28, 2013 9:15 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter- instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs
RE: Functional Specification for the multiple IPs per NIC
Hi Chiradeep. Thanks for the review comments. I will change API names to 'addIpToNic' and 'removeIpToNic' , update the FS with API names. I will also look into the meta data for secondary ip and include this section in the FS. Regards, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, January 28, 2013 1:05 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter- instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a d dr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please
Re: Functional Specification for the multiple IPs per NIC
I didn't notice the API specification before in the FS. The verb 'associate' is used with the public ip (for static nat), so it will introduce confusion. I prefer add or assign Similarly, 'unassociate' doesn't make any sense Also, why insist on 'secondary' in the API? A nic cannot be created without any ip addresses (at least currently), so I would leave out the 'secondary' part in the API as well. Last, the instance meta-data makes available the primary ip, the secondary ips should be made available as well. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instanceda ta.html#instancedata-data-categories On 1/18/13 3:40 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+addres s +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ad dr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would
RE: Functional Specification for the multiple IPs per NIC
Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ad dr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may
Re: Functional Specification for the multiple IPs per NIC
Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation. -abhi On 18/01/13 4:33 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Update the FS with the below discussions. Please find updated FS below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address +per+NIC Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 12:51 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ad dr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go
Re: Functional Specification for the multiple IPs per NIC
Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+addr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may not be a big deal to reveal the used/unused IPs in isolated network (although it would be hard to show from a large CIDR what is used/available), but we wont even be able to tell him what is used/unused in a shared network - Any thoughts? Hari Kannan -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs
Re: Functional Specification for the multiple IPs per NIC
I hope we consider the case when the ip is removed from the nic while there is a PF rule to that ip. On 1/16/13 9:10 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi Chiradeep, Now the VM NIC will have multiple IPs so for creating PF for secondary ip address we will pass VM id and (optional argument) VM ip address to the API. When VM ip address is passed it checks the whether the ip belongs to the VM or not and configures the PF for the VM IP address. When VM ip address argument is not passed to the API then it works in older way. When VM NIC has NO secondary ip address also we can pass VM id and VM primary ip address to VM ipaddress argument to API to configure PF. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 17, 2013 1:45 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Note also that the createPortForwardingRule API takes a vm id and network id, based on the assumption of a single ip per NIC. This may need an additional parameter of ip (or make the vm id optional). On 1/15/13 9:35 AM, Anthony Xu xuefei...@citrix.com wrote: Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ad dr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may not be a big deal to reveal the used/unused IPs in isolated network (although it would be hard to show from a large CIDR what is used/available), but we wont even be able to tell him what is used/unused in a shared network - Any thoughts? Hari Kannan -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30
RE: Functional Specification for the multiple IPs per NIC
Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.2390.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is-bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may not be a big deal to reveal the used/unused IPs in isolated network (although it would be hard to show from a large CIDR what is used/available), but we wont even be able to tell him what is used/unused in a shared network - Any thoughts? Hari Kannan -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP + a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure
RE: Functional Specification for the multiple IPs per NIC
Thanks for bringing this up, For security group, we may need to handle following things, As you mentioned, Anti-spoofing rules need to be updated, when secondary IP is associate/dissociate to NIC. And Security group rule can base on cidr and it can base on account/security group, For example a security group rule can allow all VMs in another account/security group to access VMs in this security group. In this case, When secondary IP is associate/dissociate to NIC. The related security group rule based on account/security group need to be resent to reflect the IP change in this security group. Anthony -Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Tuesday, January 15, 2013 5:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC Please find the updated FS in below link. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+addr ess+per+NIC I want to discuss the MIPN case for shared networks. I observed VM specific security groups iptables rules in basic zone, in which we are allowing egress traffic from the guest VM primary (dhcp) address only. If we add another IP to the NIC we should update the security groups to allow the egress traffic from the new ip. Example Current rule: It allows traffic from the i-2-3 VM's 10.147.41.239 IP only. 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 --physdev-is- bridged We should update security group rules each time we associate secondary IP to NIC. Please let me know if you have any comments or suggestion for the above . Thanks, Jayapal -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, December 19, 2012 10:59 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC 'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may not be a big deal to reveal the used/unused IPs in isolated network (although it would be hard to show from a large CIDR what is used/available), but we wont even be able to tell him what is used/unused in a shared network - Any thoughts? Hari Kannan -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote
Re: Functional Specification for the multiple IPs per NIC
'morning Hari. I can think of at least one use case where allowing the user to specify the IP would be required - when migrating an IP from one CAP to ACS or from one VM to another. Anyways - I think what the real answer to your question is would be to have a granular security model around the API calls. At that point you could specify what users/groups have the ability to assign specific IPs to a specific instance. So I'd vote to implement for now, and attack a granular api security model sooner rather than later. John On Dec 18, 2012, at 4:15 PM, Hari Kannan hari.kan...@citrix.com wrote: Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may not be a big deal to reveal the used/unused IPs in isolated network (although it would be hard to show from a large CIDR what is used/available), but we wont even be able to tell him what is used/unused in a shared network - Any thoughts? Hari Kannan -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
Sorry, not sure why cloud-init is being clubbed into this feature. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
Replies inline -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) If there is no logical reason, can we have this moved to accommodate whatever size the private subnet is? i.e. CIDR. On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? If you need help on CloudInit let me know, I can usually assist with non-Java tools. On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
-Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, December 18, 2012 10:39 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Sorry, not sure why cloud-init is being clubbed into this feature. I believe it is seen as a way to further automate or complete the multiple IP transaction. Currently the proposal will track IPs in the DB, but the user still has to manually configure everything... status quo. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP +a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
Yes, that is a mere matter of updating the metadata. How the vm wishes to use it is another matter. Concerns such as allow expiration of data, wider variety of data supported are important, but not in this context. Different feature IMO On 12/18/12 10:42 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, December 18, 2012 10:39 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Sorry, not sure why cloud-init is being clubbed into this feature. I believe it is seen as a way to further automate or complete the multiple IP transaction. Currently the proposal will track IPs in the DB, but the user still has to manually configure everything... status quo. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP +a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
-Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, December 18, 2012 10:50 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Yes, that is a mere matter of updating the metadata. How the vm wishes to use it is another matter. Concerns such as allow expiration of data, wider variety of data supported are important, but not in this context. Different feature IMO Ok, I'm starting to see where you're coming from. I'm ok with us pulling the CloudInit stuff back out of this proposal and making that a separate issue. +1 On 12/18/12 10:42 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, December 18, 2012 10:39 AM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC Sorry, not sure why cloud-init is being clubbed into this feature. I believe it is seen as a way to further automate or complete the multiple IP transaction. Currently the proposal will track IPs in the DB, but the user still has to manually configure everything... status quo. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+ IP +a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
cloud-init's (more specifically, user-data) being mentioned because I see an ongoing need of wanting to get instance-specific data into an instance. So, we can tweak meta-data to add support for multi-IP per NIC (MIPN), or we can take a step back and talk through how the metadata side of things could be beefed up before implementing MIPN to minimize future rewriting. The result is better compatibility with AWS, better security, and more standardized functionality going forward. Yes, this is a separate feature than the MIPN by itself. I meant to call that out in my first bullet, apologies. John On Dec 18, 2012, at 10:39 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Sorry, not sure why cloud-init is being clubbed into this feature. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
Well, not quite. The question I might be clearly asking is: Do we build MIPN now with intention to rewrite, or do we update the metadata/user-data code first? On Dec 18, 2012, at 10:58 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: I guess we are all in agreement them :) -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:56 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC cloud-init's (more specifically, user-data) being mentioned because I see an ongoing need of wanting to get instance-specific data into an instance. So, we can tweak meta-data to add support for multi-IP per NIC (MIPN), or we can take a step back and talk through how the metadata side of things could be beefed up before implementing MIPN to minimize future rewriting. The result is better compatibility with AWS, better security, and more standardized functionality going forward. Yes, this is a separate feature than the MIPN by itself. I meant to call that out in my first bullet, apologies. John On Dec 18, 2012, at 10:39 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Sorry, not sure why cloud-init is being clubbed into this feature. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+I P+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
OK, I must have missed something, or made an invalid assumption. I thought the MIPN could be handled by metadata and not need to be re-written. I also figured guest management could be handled separate and make use of the metadata. If it requires a re-write down the road for what we are actively discussing now, then it seems inefficient. Could we not find some sort of hybrid solution, that would allow MIPN to move forward, but not potentially hinder plans for CloudInit/guest management? Thanks -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 11:05 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Well, not quite. The question I might be clearly asking is: Do we build MIPN now with intention to rewrite, or do we update the metadata/user-data code first? On Dec 18, 2012, at 10:58 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: I guess we are all in agreement them :) -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:56 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC cloud-init's (more specifically, user-data) being mentioned because I see an ongoing need of wanting to get instance-specific data into an instance. So, we can tweak meta-data to add support for multi-IP per NIC (MIPN), or we can take a step back and talk through how the metadata side of things could be beefed up before implementing MIPN to minimize future rewriting. The result is better compatibility with AWS, better security, and more standardized functionality going forward. Yes, this is a separate feature than the MIPN by itself. I meant to call that out in my first bullet, apologies. John On Dec 18, 2012, at 10:39 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Sorry, not sure why cloud-init is being clubbed into this feature. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple +I P+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
Concur with Kelcey. Why is this a concern of MIPN? As long as the metadata includes all ips assigned to the nic, cloud-init can be modified at any point in time to take advantage of this metadata. It is like saying AWS maintains cloud-init and changes it in lockstep to any new thing they add to the instance metadata. -Original Message- From: Kelcey Damage (BT) [mailto:kel...@backbonetechnology.com] Sent: Tuesday, December 18, 2012 11:17 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Functional Specification for the multiple IPs per NIC OK, I must have missed something, or made an invalid assumption. I thought the MIPN could be handled by metadata and not need to be re-written. I also figured guest management could be handled separate and make use of the metadata. If it requires a re-write down the road for what we are actively discussing now, then it seems inefficient. Could we not find some sort of hybrid solution, that would allow MIPN to move forward, but not potentially hinder plans for CloudInit/guest management? Thanks -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 11:05 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Well, not quite. The question I might be clearly asking is: Do we build MIPN now with intention to rewrite, or do we update the metadata/user-data code first? On Dec 18, 2012, at 10:58 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: I guess we are all in agreement them :) -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:56 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC cloud-init's (more specifically, user-data) being mentioned because I see an ongoing need of wanting to get instance-specific data into an instance. So, we can tweak meta-data to add support for multi-IP per NIC (MIPN), or we can take a step back and talk through how the metadata side of things could be beefed up before implementing MIPN to minimize future rewriting. The result is better compatibility with AWS, better security, and more standardized functionality going forward. Yes, this is a separate feature than the MIPN by itself. I meant to call that out in my first bullet, apologies. John On Dec 18, 2012, at 10:39 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Sorry, not sure why cloud-init is being clubbed into this feature. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple +I P+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal
Re: Functional Specification for the multiple IPs per NIC
Ya know - thinking it through, Jayapal's feature is purely on the mgmt/IP tracking side, not the domr/instance side. So, I'll back down and say run with that for now, we'll propose the user-data stuff as a separate feature. Sorry for confusion. John On Dec 18, 2012, at 11:16 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: OK, I must have missed something, or made an invalid assumption. I thought the MIPN could be handled by metadata and not need to be re-written. I also figured guest management could be handled separate and make use of the metadata. If it requires a re-write down the road for what we are actively discussing now, then it seems inefficient. Could we not find some sort of hybrid solution, that would allow MIPN to move forward, but not potentially hinder plans for CloudInit/guest management? Thanks -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 11:05 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Well, not quite. The question I might be clearly asking is: Do we build MIPN now with intention to rewrite, or do we update the metadata/user-data code first? On Dec 18, 2012, at 10:58 AM, Kelcey Damage (BT) kel...@backbonetechnology.com wrote: I guess we are all in agreement them :) -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:56 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC cloud-init's (more specifically, user-data) being mentioned because I see an ongoing need of wanting to get instance-specific data into an instance. So, we can tweak meta-data to add support for multi-IP per NIC (MIPN), or we can take a step back and talk through how the metadata side of things could be beefed up before implementing MIPN to minimize future rewriting. The result is better compatibility with AWS, better security, and more standardized functionality going forward. Yes, this is a separate feature than the MIPN by itself. I meant to call that out in my first bullet, apologies. John On Dec 18, 2012, at 10:39 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Sorry, not sure why cloud-init is being clubbed into this feature. The secondary ips can be made available through the usual metadata scheme. On 12/18/12 10:36 AM, John Kinsella j...@stratosec.co wrote: Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple +I P+a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure
RE: Functional Specification for the multiple IPs per NIC
Regarding User can specify the IP address from the guest subnet if not CS picks the IP from the guest subnet comment in the FS I don't see a need to do this - because, it is a shared network, how does he know what is used up and what is not? So, he could go through a sequence of steps only to get an error message back that it is not possible (and keep doing this until success) One possibility is telling him what is available - it may not be a big deal to reveal the used/unused IPs in isolated network (although it would be hard to show from a large CIDR what is used/available), but we wont even be able to tell him what is used/unused in a shared network - Any thoughts? Hari Kannan -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Tuesday, December 18, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Functional Specification for the multiple IPs per NIC Is there any logic behind 30? At some point, we're going to be asked, so I'd like to have a decent answer. :) On the rest of this, I'd like to get some level of consensus on the design. What looks best to me: * Improve UserData/CloudInit support in CloudStack (I'm willing to work on this, consider it important) - allow expiration of data, wider variety of data supported * Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to think through Windows equivalent) * Update the password changing script to use CloudInit Thoughts? Or Jayapal have you already started work on the multi-IP feature? On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Regarding IP limit, it can be made as configurable using global settings and default value will be 30. Thanks, Jayapal -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, December 17, 2012 12:59 PM To: CloudStack DeveloperList Subject: Re: Functional Specification for the multiple IPs per NIC In basic/shared networks the allocation is bounded by what is already used- up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ a dd res s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
RE: Functional Specification for the multiple IPs per NIC
Hi Kelcey,
The question is not whether CS knows this or not - the question is how does a
user know it..
Here is the workflow I envision -
User requests a VM
As part of this, he requests one or more isolated networks
User optionally could add more networks for the VM (multiple nics feature in
Campo)
User acquires guest IPs (new feature)
Specifies the network he wants
Optionally specifies the ip address (or we automatically assign
from the CIDR) - not sure if we need to let him provide an IP - this
is the question
Out of band (manual) he ifconfigs the acquired guest IP on a {VM,NIC}
User can acquire IP (public ip) like he does today
Associate the public IP with the guest IP (CS does the NAT)
release public IP, if acquired
release guest IP, if acquired (cannot release if still mapped to a public IP)
The workflow is similar for shared net
Does it make sense?
Hari
-Original Message-
From: Kelcey Damage (BT) [mailto:kel...@backbonetechnology.com]
Sent: Tuesday, December 18, 2012 4:22 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
All networks in CS shared, isolated, basic track assigned IPs in the database,
so yes, we can know what is in use if provisioned by CS. The key here is to use
the same tables to assign auxiliary IPs at the users request to individual
instances.
The responsibility is still on the VM administrator to take the new IP
provided by CS and configure it in the correct VM.
This is a start, and John and I have been discussing using CloudInit/Guest
management to further automate this process.
-kd
-Original Message-
From: Hari Kannan [mailto:hari.kan...@citrix.com]
Sent: Tuesday, December 18, 2012 4:15 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
Regarding User can specify the IP address from the guest subnet if
not
CS
picks the IP from the guest subnet comment in the FS
I don't see a need to do this - because, it is a shared network, how
does
he
know what is used up and what is not? So, he could go through a
sequence of steps only to get an error message back that it is not
possible (and keep
doing
this until success)
One possibility is telling him what is available - it may not be a big
deal
to
reveal the used/unused IPs in isolated network (although it would be
hard
to
show from a large CIDR what is used/available), but we wont even be
able to tell him what is used/unused in a shared network -
Any thoughts?
Hari Kannan
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Tuesday, December 18, 2012 10:36 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Functional Specification for the multiple IPs per NIC
Is there any logic behind 30? At some point, we're going to be asked,
so
I'd
like to have a decent answer. :)
On the rest of this, I'd like to get some level of consensus on the design.
What
looks best to me:
* Improve UserData/CloudInit support in CloudStack (I'm willing to work
on this, consider it important) - allow expiration of data, wider
variety of
data
supported
* Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to
think through Windows equivalent)
* Update the password changing script to use CloudInit
Thoughts? Or Jayapal have you already started work on the multi-IP feature?
On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com wrote:
Regarding IP limit, it can be made as configurable using global
settings
and
default value will be 30.
Thanks,
Jayapal
-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Monday, December 17, 2012 12:59 PM
To: CloudStack DeveloperList
Subject: Re: Functional Specification for the multiple IPs per NIC
In basic/shared networks the allocation is bounded by what is
already
used- up. To prevent tenants from hogging all the available ips,
there needs to be limits.
On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote:
I'd remove the limitation of having 30 IPs per interface. Modern
OSes can support way more.
Why no support for basic networking? I can see a small hosting
provider with a basic setup wanting to manage web servers...
John
On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com wrote:
Hi All,
Current guest VM by default having one NIC and one IP address
assigned.
If your wants extra IP for the guest VM, there no provision from
the CS.
Using multiple IP address per NIC feature CS can associate IP
address for the NIC, user can take that IP and assign it to the VM.
Please find the FS for the more details.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP
+
a
dd
res
s+per+NIC
Please provide your comments on the FS.
Thanks,
jayapal
Stratosec - Secure Infrastructure
RE: Functional Specification for the multiple IPs per NIC
Kind of yes. In advanced networking the user owns the whole subnet of the
isolated network... so this does not matter.
In shared you are correc its more tricky. The goal I would envision is a
dynamically provided IP that has infinite DHCP lease.
Now we are in the realm of what John was discussing.
The basic spec for MIPN is only to get CS to track the request for
additional private IP, nothing more.
-kd
-Original Message-
From: Hari Kannan [mailto:hari.kan...@citrix.com]
Sent: Tuesday, December 18, 2012 4:32 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
Hi Kelcey,
The question is not whether CS knows this or not - the question is how does
a
user know it..
Here is the workflow I envision -
User requests a VM
As part of this, he requests one or more isolated networks
User
optionally could add more networks for the VM (multiple nics feature in
Campo) User acquires guest IPs (new feature)
Specifies the network he wants
Optionally specifies the ip address (or we automatically
assign from
the CIDR) - not sure if we need to let him provide an IP - this is
the
question Out of band (manual) he ifconfigs the acquired guest IP on a
{VM,NIC} User can acquire IP (public ip) like he does today
Associate the public IP with the guest IP (CS does the NAT)
release
public IP, if acquired release guest IP, if acquired (cannot release if
still
mapped to a public IP)
The workflow is similar for shared net
Does it make sense?
Hari
-Original Message-
From: Kelcey Damage (BT) [mailto:kel...@backbonetechnology.com]
Sent: Tuesday, December 18, 2012 4:22 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
All networks in CS shared, isolated, basic track assigned IPs in the
database, so
yes, we can know what is in use if provisioned by CS. The key here is to
use the
same tables to assign auxiliary IPs at the users request to individual
instances.
The responsibility is still on the VM administrator to take the new IP
provided
by CS and configure it in the correct VM.
This is a start, and John and I have been discussing using CloudInit/Guest
management to further automate this process.
-kd
-Original Message-
From: Hari Kannan [mailto:hari.kan...@citrix.com]
Sent: Tuesday, December 18, 2012 4:15 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
Regarding User can specify the IP address from the guest subnet if
not
CS
picks the IP from the guest subnet comment in the FS
I don't see a need to do this - because, it is a shared network, how
does
he
know what is used up and what is not? So, he could go through a
sequence of steps only to get an error message back that it is not
possible (and keep
doing
this until success)
One possibility is telling him what is available - it may not be a big
deal
to
reveal the used/unused IPs in isolated network (although it would be
hard
to
show from a large CIDR what is used/available), but we wont even be
able to tell him what is used/unused in a shared network -
Any thoughts?
Hari Kannan
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Tuesday, December 18, 2012 10:36 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Functional Specification for the multiple IPs per NIC
Is there any logic behind 30? At some point, we're going to be asked,
so
I'd
like to have a decent answer. :)
On the rest of this, I'd like to get some level of consensus on the
design.
What
looks best to me:
* Improve UserData/CloudInit support in CloudStack (I'm willing to work
on this, consider it important) - allow expiration of data, wider
variety of
data
supported
* Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to
think through Windows equivalent)
* Update the password changing script to use CloudInit
Thoughts? Or Jayapal have you already started work on the multi-IP
feature?
On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com wrote:
Regarding IP limit, it can be made as configurable using global
settings
and
default value will be 30.
Thanks,
Jayapal
-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Monday, December 17, 2012 12:59 PM
To: CloudStack DeveloperList
Subject: Re: Functional Specification for the multiple IPs per NIC
In basic/shared networks the allocation is bounded by what is
already
used- up. To prevent tenants from hogging all the available ips,
there needs to be limits.
On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote:
I'd remove the limitation of having 30 IPs per interface. Modern
OSes can support way more.
Why no support for basic networking? I can see a small hosting
provider with a basic setup wanting to manage web servers...
John
On Dec 14
Re: Functional Specification for the multiple IPs per NIC
I would actually propose that the feature is more on parity with AWS's
'private' ip feature.
The relevant APIs are:
$API_DOCS_URL-AssignPrivateIpAddresses.html
$API_DOCS_URL-UnassignPrivateIpAddresses.html
$API_DOCS_URL-DescribeNetworkInterfaces.html
$API_DOCS_URL-CreateNetworkInterface.html
This kind of ties into [1] and [2] and [3]
As for Hari's question below, you could always modify the listNetwork API
to return the list of available ip addresses. Of course this list is
ephemeral, so you may still fail after choosing one of these addresses.
[1] http://markmail.org/thread/vqoso6p7ttvh7z4c
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-645
[3] http://markmail.org/thread/66b4wzbofggeozgl
On 12/18/12 4:45 PM, Kelcey Damage (BT) kel...@backbonetechnology.com
wrote:
Kind of yes. In advanced networking the user owns the whole subnet of the
isolated network... so this does not matter.
In shared you are correc its more tricky. The goal I would envision is a
dynamically provided IP that has infinite DHCP lease.
Now we are in the realm of what John was discussing.
The basic spec for MIPN is only to get CS to track the request for
additional private IP, nothing more.
-kd
-Original Message-
From: Hari Kannan [mailto:hari.kan...@citrix.com]
Sent: Tuesday, December 18, 2012 4:32 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
Hi Kelcey,
The question is not whether CS knows this or not - the question is how
does
a
user know it..
Here is the workflow I envision -
User requests a VM
As part of this, he requests one or more isolated
networks
User
optionally could add more networks for the VM (multiple nics feature in
Campo) User acquires guest IPs (new feature)
Specifies the network he wants
Optionally specifies the ip address (or we automatically
assign from
the CIDR) - not sure if we need to let him provide an IP - this
is
the
question Out of band (manual) he ifconfigs the acquired guest IP on a
{VM,NIC} User can acquire IP (public ip) like he does today
Associate the public IP with the guest IP (CS does the
NAT)
release
public IP, if acquired release guest IP, if acquired (cannot release if
still
mapped to a public IP)
The workflow is similar for shared net
Does it make sense?
Hari
-Original Message-
From: Kelcey Damage (BT) [mailto:kel...@backbonetechnology.com]
Sent: Tuesday, December 18, 2012 4:22 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
All networks in CS shared, isolated, basic track assigned IPs in the
database, so
yes, we can know what is in use if provisioned by CS. The key here is to
use the
same tables to assign auxiliary IPs at the users request to individual
instances.
The responsibility is still on the VM administrator to take the new IP
provided
by CS and configure it in the correct VM.
This is a start, and John and I have been discussing using
CloudInit/Guest
management to further automate this process.
-kd
-Original Message-
From: Hari Kannan [mailto:hari.kan...@citrix.com]
Sent: Tuesday, December 18, 2012 4:15 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Functional Specification for the multiple IPs per NIC
Regarding User can specify the IP address from the guest subnet if
not
CS
picks the IP from the guest subnet comment in the FS
I don't see a need to do this - because, it is a shared network, how
does
he
know what is used up and what is not? So, he could go through a
sequence of steps only to get an error message back that it is not
possible (and keep
doing
this until success)
One possibility is telling him what is available - it may not be a big
deal
to
reveal the used/unused IPs in isolated network (although it would be
hard
to
show from a large CIDR what is used/available), but we wont even be
able to tell him what is used/unused in a shared network -
Any thoughts?
Hari Kannan
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Tuesday, December 18, 2012 10:36 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Functional Specification for the multiple IPs per NIC
Is there any logic behind 30? At some point, we're going to be asked,
so
I'd
like to have a decent answer. :)
On the rest of this, I'd like to get some level of consensus on the
design.
What
looks best to me:
* Improve UserData/CloudInit support in CloudStack (I'm willing to work
on this, consider it important) - allow expiration of data, wider
variety of
data
supported
* Create the multi-IPs-per-NIC code to get IPs via CloudInit (Need to
think through Windows equivalent)
* Update the password changing script to use CloudInit
Thoughts? Or Jayapal have you already started work on the multi-IP
feature?
On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi
jayapalreddy.ur...@citrix.com wrote:
Regarding IP limit, it can be made
Re: Functional Specification for the multiple IPs per NIC
In basic/shared networks the allocation is bounded by what is already used-up. To prevent tenants from hogging all the available ips, there needs to be limits. On 12/15/12 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+addres s+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
This is a prime example where guest scripts make sense for automating the interface alias creation. I still think I'm missing something however, does this include a new fetch IP API? Also the 30 IP limit seems out of place, when I can go in right now and give any guest VM 256+ interface aliases without restriction. The default isolated network behind any VR is also a /24. Maybe adjust the limit to 256. That way it's more of a logical boundary. Thanks Sent from my iPhone On Dec 15, 2012, at 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
I forgot to add... I second the notion that Basic Networking should be supported. I think this feature targets basic more so anyways. With basics single network, direct public IPs, managing aliases would allow far more flexibility to the platform. Especially any one trying to host an SSL endpoint on a basic network. Sent from my iPhone On Dec 15, 2012, at 11:52 AM, Kelceydamage@bbits kel...@bbits.ca wrote: This is a prime example where guest scripts make sense for automating the interface alias creation. I still think I'm missing something however, does this include a new fetch IP API? Also the 30 IP limit seems out of place, when I can go in right now and give any guest VM 256+ interface aliases without restriction. The default isolated network behind any VR is also a /24. Maybe adjust the limit to 256. That way it's more of a logical boundary. Thanks Sent from my iPhone On Dec 15, 2012, at 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
Good point, there…maybe what we need here is to beef up the password server idea to provide a standardized conduit to get info down to a VM. Similar to EC2's user-data. Data I could see this framework providing: * System passwords * Additional IPs (so need to be able to return data sets, JSON-style maybe?) * Encryption keys * Metadata about the VM (webserver, database, high-availability, master) * What else? One very important piece that's missing is a timeout - need to be able to have the object server provide the object(s) when a VM boots, but should be able to specify for some objects that after X seconds that data should be thrown away. Hugely important for encryption keys (I want to provide key to decryption system at boot, but don't want malicious user to be able to login a week later and easily get that key). So I'd suggest maybe have one spec to update/expand the password server to be an object server, and then Jayapal's multiple-IP spec would integrate with that. Super awesome bonus points: support for fetching/storing said objects in HSM. I've got one vendor in mind who has a sw solution we're looking at, but following a PKCS#11 format would probably be best. John On Dec 15, 2012, at 11:52 AM, Kelceydamage@bbits kel...@bbits.ca wrote: This is a prime example where guest scripts make sense for automating the interface alias creation. I still think I'm missing something however, does this include a new fetch IP API? Also the 30 IP limit seems out of place, when I can go in right now and give any guest VM 256+ interface aliases without restriction. The default isolated network behind any VR is also a /24. Maybe adjust the limit to 256. That way it's more of a logical boundary. Thanks Sent from my iPhone On Dec 15, 2012, at 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
Agreed, this sounds like a good direction to go, and would also fill the role of 'guest agents(VMware tools, etc) as this would handle the standard use cases. +1 I hope more people get in on this discussion. Sent from my iPhone On Dec 15, 2012, at 12:55 PM, John Kinsella j...@stratosec.co wrote: Good point, there…maybe what we need here is to beef up the password server idea to provide a standardized conduit to get info down to a VM. Similar to EC2's user-data. Data I could see this framework providing: * System passwords * Additional IPs (so need to be able to return data sets, JSON-style maybe?) * Encryption keys * Metadata about the VM (webserver, database, high-availability, master) * What else? One very important piece that's missing is a timeout - need to be able to have the object server provide the object(s) when a VM boots, but should be able to specify for some objects that after X seconds that data should be thrown away. Hugely important for encryption keys (I want to provide key to decryption system at boot, but don't want malicious user to be able to login a week later and easily get that key). So I'd suggest maybe have one spec to update/expand the password server to be an object server, and then Jayapal's multiple-IP spec would integrate with that. Super awesome bonus points: support for fetching/storing said objects in HSM. I've got one vendor in mind who has a sw solution we're looking at, but following a PKCS#11 format would probably be best. John On Dec 15, 2012, at 11:52 AM, Kelceydamage@bbits kel...@bbits.ca wrote: This is a prime example where guest scripts make sense for automating the interface alias creation. I still think I'm missing something however, does this include a new fetch IP API? Also the 30 IP limit seems out of place, when I can go in right now and give any guest VM 256+ interface aliases without restriction. The default isolated network behind any VR is also a /24. Maybe adjust the limit to 256. That way it's more of a logical boundary. Thanks Sent from my iPhone On Dec 15, 2012, at 8:38 AM, John Kinsella j...@stratosec.co wrote: I'd remove the limitation of having 30 IPs per interface. Modern OSes can support way more. Why no support for basic networking? I can see a small hosting provider with a basic setup wanting to manage web servers... John On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella Stratosec - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella
Re: Functional Specification for the multiple IPs per NIC
On Sat, Dec 15, 2012 at 3:55 PM, John Kinsella j...@stratosec.co wrote: Good point, there…maybe what we need here is to beef up the password server idea to provide a standardized conduit to get info down to a VM. Similar to EC2's user-data. Data I could see this framework providing: * System passwords * Additional IPs (so need to be able to return data sets, JSON-style maybe?) * Encryption keys * Metadata about the VM (webserver, database, high-availability, master) * What else? One very important piece that's missing is a timeout - need to be able to have the object server provide the object(s) when a VM boots, but should be able to specify for some objects that after X seconds that data should be thrown away. Hugely important for encryption keys (I want to provide key to decryption system at boot, but don't want malicious user to be able to login a week later and easily get that key). So I'd suggest maybe have one spec to update/expand the password server to be an object server, and then Jayapal's multiple-IP spec would integrate with that. Super awesome bonus points: support for fetching/storing said objects in HSM. I've got one vendor in mind who has a sw solution we're looking at, but following a PKCS#11 format would probably be best. In that vein - I'd prefer seeing us do a better job of making cloud-init something usable with CloudStack. I know there is essentially cloud-init support here: https://code.launchpad.net/~lcosmin/cloud-init/cloudstack
Functional Specification for the multiple IPs per NIC
Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal
Re: Functional Specification for the multiple IPs per NIC
Just to be clear, this feature is to simply track multiple IPs in the ui/db correct? There is no mechanism to prevent an existing tenant from creating up aliases on their subnet. So currently users can manually setup all the IPs they want in guest VMs. Sent from my iPhone On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Hi All, Current guest VM by default having one NIC and one IP address assigned. If your wants extra IP for the guest VM, there no provision from the CS. Using multiple IP address per NIC feature CS can associate IP address for the NIC, user can take that IP and assign it to the VM. Please find the FS for the more details. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC Please provide your comments on the FS. Thanks, jayapal
