cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Sorensen" <shadow...@gmail.com>
Subject Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix
Date Tue, 29 Oct 2013 21:01:00 GMT


> On Oct. 29, 2013, 6:26 p.m., Marcus Sorensen wrote:
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
line 164
> > <https://reviews.apache.org/r/15014/diff/3/?file=373389#file373389line164>
> >
> >     It is indeed traffic label if one exists. _pifs contains map "trafficLabel =>
physical nic", but also contains the general keys 'private' (for guest traffic type) and 'public'
(for public traffic type) for default values. If you prefer we can change the variable name
to "pifKey" in order to reduce confusion.
> >     
> >     If we pull the "_pifs.get(trafficLabel)" out of here, we have to add several
lines or a new method just prior to every point where createVnetBr is called to see if we
can get a nic, then check for physical interface if no mapping was found to pass it as nic.
 I'm ok with doing a new method if you feel strongly that this needs to be split out. It would
be better if it were within createVnetBr or wrapped createVnetBr so that one doesn't have
to remember to call it every time prior to createVnetBr.
> 
> Yoshikazu Nojima wrote:
>     Previous comment is just a comment, not a strong one. Changing the 2nd param name
to "pifKey" seems better for me.

Ok, I'll make that change and commit it.


- Marcus


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15014/#review27710
-----------------------------------------------------------


On Oct. 29, 2013, 5:51 p.m., Marcus Sorensen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> -----------------------------------------------------------
> 
> (Updated Oct. 29, 2013, 5:51 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
>     https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> -------
> 
> 1) vxlan will use bridge scheme 'brvx-<vni>'. Multiple physical networks can host
guest traffic type with vxlan isolation, so long as they don't use the same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is not found.
Normally we take traffic label name, find the matching bridge, then resolve that to a physical
interface. Then we create guest bridges on that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs for review.
> 
> 
> Diffs
> -----
> 
>   plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
f945b74 
>   plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> -------
> 
> I created two physical networks hosting guest traffic, one as a vlan isolation type,
the other a vxlan isolation type. The vlan isolation type has traffic label 'cloudbr0', on
physical eth0, and the vxlan has traffic label 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, just not
the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name	bridge id		STP enabled	interfaces
> breth0-3905		8000.000c29d82947	no		eth0.3905
> 							vnet8
> brvx-1213043		8000.a6e6026f7fbb	no		vnet9
> 							vxlan1213043
> brvx-1589169		8000.663d4e875e78	no		vnet10
> 							vxlan1589169
> cloud0		8000.fe00a9fe0069	no		vnet0
> 							vnet2
> 							vnet3
> cloudbr0		8000.000c29d82947	no		eth0
> 							vnet4
> 							vnet6
> cloudbr1		8000.000c29d82951	no		eth1
> 							vnet1
> 							vnet5
> 							vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master
brvx-1213043 state UNKNOWN mode DEFAULT group default
>     vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 ageing 300
> 59: vxlan1589169: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master
brvx-1589169 state UNKNOWN mode DEFAULT group default
>     vxlan id 1589169 group 239.24.63.177 dev eth2 port 32768 61000 ttl 10 ageing 300
> 62: vxlan1638510: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master
brvx-1638510 state UNKNOWN mode DEFAULT group default
>     vxlan id 1638510 group 239.25.0.110 dev eth2 port 32768 61000 ttl 10 ageing 300
> root@devcloud-kvm-u:~/cloudstack# ip route show
> default via 192.168.100.1 dev cloudbr1  metric 100
> 169.254.0.0/16 dev cloud0  proto kernel  scope link  src 169.254.0.1
> 172.17.10.0/24 dev cloudbr0  proto kernel  scope link  src 172.17.10.10
> 192.168.100.0/24 dev cloudbr1  proto kernel  scope link  src 192.168.100.10
> 239.18.130.115 dev eth2  scope link
> 239.24.63.177 dev eth2  scope link
> 239.25.0.110 dev eth2  scope link
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message