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 >> > >
