----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7187/#review11763 -----------------------------------------------------------
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java <https://reviews.apache.org/r/7187/#comment25317> There is a problem, if we change the bridge name schema, then upgrade from 3.0.x to 4.0 will not work unless stop/start all the VMs, which is unpractical. Need to maintain backward compatibility here: based on pifname and vlanId, search the system, if there is a bridge created for this vlanId on this pif already, then we use the existing name. Otherwise, use the new name schema. - edison su On Sept. 20, 2012, 4:58 p.m., Marcus Sorensen wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/7187/ > ----------------------------------------------------------- > > (Updated Sept. 20, 2012, 4:58 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 > 65742d8 > 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 > >
