With security groups enabled, you should be able to go into the network and make the changes required. You can find instructions here:
http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/Installation_Guide/security-groups.html If that's not available then your network isn't using security groups. I've seen this happen before where security groups _should_ be disabled but aren't because of a global setting called "network.securitygroups.defaultadding" which is true by default. That throws all instances into the default security group, which (by default) blocks all traffic except for established traffic. The problem though is if the network offering chosen doesn't support security groups, it still seems to throw them in there anyway which means all traffic to an instance is blocked with no way to actually _change_ that since security groups aren't enabled. It's one of the weird ways that CloudStack will screw itself into the ground without knowing that little piece of knowledge... -----Original Message----- From: Andrea Ottonello [mailto:aottone...@gmail.com] Sent: Friday, March 1, 2013 9:16 AM To: cloudstack-users@incubator.apache.org Subject: Re: How the vm<->vm communicate each other? Hallo Clayton a little question on scenario I Basic: could you please tell me how can I permit traffic between VMs? I would like to permit VMs to "talk" with each other. From what you say, default for Basic is that every machine only allows outgoing traffic and answers to its requests. And actually I tried unsuccessfully to ping from a VM to another... Thank you. 2013/3/1 Clayton Weise <cwe...@iswest.net> > Wang, I replied to your question on LinkedIn as well. I'll respond to > each of your questions as they relate to both basic AND advanced networks: > > > Scenario I : > > All VMs belong to one account in the same vlan deploy to the same host. > > Basic network: All VMs belong to one account but they each have separate > security group rules (a set of rules for each instance). Unlike > Amazon/Eucalyptus there is no private network with NAT going on in a basic > network. In a basic network public ip addresses are assigned _directly_ to > the VM. Each VM has its own security group rules, which by default, only > allow established traffic. The virtual router does not route, it only > provides DHCP and DNS services. > > Advanced network: VMs belonging to one account and one network (accounts > can have more than one network) are all on the same VLAN or SDN group and > no filtering is done between them (all traffic between VMs in the same > network is permitted). Only established traffic is permitted and anything > else must be mapped through via NAT. In advanced networks, all traffic > routes through the virtual router (NAT). > > Scenario II: > > VMs in the same vlan deploy to the same host but belong to different > > accouts. > > Basic network: Same as above -- _Every_ VM has its own security rules. It > does not matter which account owns them, by default all traffic that is not > established from the instance is blocked. > > Advanced network: This scenario is impossible in advanced networks. Two > accounts cannot have VMs on the same VLAN. In advanced networking each > account would have separate networks and separate VLANs. > > > Scenario III: > > VMs in different vlan deploy to the same host and belong to same account. > > Basic network: I believe this is possible in basic networking if two > different public subnets had different VLAN tags. The same security group > rules would apply as previously stated. Only established traffic would be > permitted unless a security group rule permitted otherwise. No inherent > trust exists just because they belong to the same account. > > Advanced network: With a VPC enabled, inter-vlan routing can be permitted. > By default only established traffic is permitted and the two VLANs cannot > communicate to each other. But rules can be enabled which will allow the > different VLANs to communicate with one-another on specific ports and > protocols. Without VPCs, traffic from one VLAN would NAT out through a > public IP address to talk to the public IP address of another VLAN and > through that other virtual router. If you're familiar with Amazon EC2 and > Eucalyptus, this is exactly the same way that they operate. > > > Scenario IV: > > All VMs belong to one account in the same vlan deploy to the different > > hosts. > > Basic network: Same as Scenario I, assuming your switch supports VLAN > tagging and allows the traffic across. > > Advanced networking: Same as Scenario I, assuming your switch supports > VLAN tagging and allows the traffic across. > > -----Original Message----- > From: Wang Fei [mailto:pytho...@gmail.com] > Sent: Thursday, February 28, 2013 6:31 PM > To: Bryan Whitehead > Cc: cloudstack-users@incubator.apache.org > Subject: Re: How the vm<->vm communicate each other? > > What if scenario 1 in basic network? > > It have to support security group to isolate resource belong to different > accounts. > > in that way VMs have to communicate with VR! > > is that correct? > > > > > ---- > best regards > > > On Fri, Mar 1, 2013 at 9:09 AM, Bryan Whitehead <dri...@megahappy.net > >wrote: > > > As long as VM's are in the same vlan all VM's can communicate. Account > > settings or where the VM's are running should be irrelevant Your > switches > > should support tagging and should be setup in trunk mode or some other > vlan > > access mode. > > > > > > > > On Thu, Feb 28, 2013 at 4:35 AM, Wang Fei <pytho...@gmail.com> wrote: > > > >> Scenario I : > >> All VMs belong to one account in the same vlan deploy to the same host. > >> > >> Scenario II: > >> VMs in the same vlan deploy to the same host but belong to different > >> accouts. > >> > >> > >> Scenario III: > >> VMs in different vlan deploy to the same host and belong to same > account. > >> > >> Scenario IV: > >> All VMs belong to one account in the same vlan deploy to the different > >> hosts. > >> > >> > >> > >> ---- > >> best regards > >> > > > > > -- Andrea Ottonello
