incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "edison su" <edison...@citrix.com>
Subject Re: Review Request: fix kvm traffic labels (guest traffic types on multiple networks don't work)
Date Thu, 27 Sep 2012 00:18:28 GMT

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

Ship it!


Ship It!

- edison su


On Sept. 25, 2012, 11:44 p.m., Marcus Sorensen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/7187/
> -----------------------------------------------------------
> 
> (Updated Sept. 25, 2012, 11:44 p.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Description
> -------
> 
> Cloudstack seems to let you create guest traffic types on multiple physical networks.
However, when I try this with KVM I end up always bridging to whatever device is used for
guest.network.device. This pulls the traffic label (NicTO.getName()) and uses that bridge
to ensure that we get on the correct physical network, rather than just always using the guest.network.device.
 
> 
> This also changes the bridge naming scheme from cloudVirBr + vlanid to br + physicalinterface
+ "-" + vlanid. This is because we should be able to support the same vlan numbers per physical
network, and the previous bridge name would not support this and collide.
> 
> 
> Diffs
> -----
> 
>   plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
cf4de09 
>   plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
aadd6dd 
>   scripts/vm/network/vnet/modifyvlan.sh 33d697a 
> 
> Diff: https://reviews.apache.org/r/7187/diff/
> 
> 
> Testing
> -------
> 
> Ran this in our test environment, which is running the latest 4.0 + this patch. Everything
operates as expected, but since I don't have the environment or resources to test this in
every situation I'd hope someone could give this a detailed look over. Regardless, it's a
fairly straightforward fix.
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>


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