Thank you! I first created a zone without sec groups and noticed that there was no way. I recreated with SG enabled and tried but maybe I missed something, I will try again now that I'm sure it should work and that I read the article.
2013/3/1 Clayton Weise <cwe...@iswest.net> > 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 > -- Andrea Ottonello
