Is this functionality useful for OpenVZ? Do people need the ability todo this? Why/when is it necessary for me to be able to add eth0 to abridge remotely? I don't quite (yet) understand the usefulness of this feature. Youwould still be very limited in what you can change with the network ifyou are remote, right? That's why I don't quite understand the benefitof this feature. How are you planning to use it? When I set up myOpenVZ systems, I like to get the overall network/bridge configurationperfect so that I don't need to make major changes when I am remote. Again, I am not an expert so I am asking purely for my own curiosity.I support the idea of making networking more flexible, but I do notsee this particular step addressed by the patch as a common need. Thatmay be due to my own lack of understanding. I am a big fan of OpenVZ though, so if it helps OpenVZ in some way,I'd like to know about it :) -Daniel On Tue, May 12, 2009 at 12:19 AM, Cyrill Gorcunov <gorcunov@xxxxxxxxxx> wrote:> On 5/12/09, Daniel Robbins <drobbins@xxxxxxxxxx> wrote:>> Note: I am not a bridge guru but I'm interested in understanding this>> new functionality better. What is the larger benefit of this feature?>> Does this make it possible to configure a bridge setup on a remote>> system without losing connectivity? I can't do many kinds of network>> changes remotely without risking losing connectivity (ie. changing IP>> address, messing with routing, etc. -- it would be likely that you'd>> lose network connectivity :) ) Therefore, I don't know if this is a>> benefit unless it is needed for a particular application. Is this>> useful for OpenVZ in some way?>>>> Regards,>>>> Daniel>>> Hi Daniel,>> The idea was exactly you described, ie have an ability to configure> remote system as bridge. There was an example how to use it in the> pach (last patch in series). Say we have remote system with eth0 set> up and running. So we may sign in into this system remotely. If we> have to confugure bridge on such a system (that even eth0 has to be> the bridge port) we connect to this system via eth0 then add bridge> br0 and run it via ifconfig br0 up, turn on via_phys_dev feature and> evetually add eth0 as a bridge port. We will have small delay in> session until port get forwarding state but after we could continue> work remotely on the system without reconfiguring routing table. Even> ssh session being used during configuration will continue operate. So> except a delay no session interrupt. I hope, need a good testing ;)>>> On Mon, May 11, 2009 at 5:46 AM, Cyrill Gorcunov <gorcunov@xxxxxxxxxx>>> wrote:>>> Hi,>>>>>> here is RFC for new via_phys_dev bridge feature.>>> In short -- it allows to use some bridge port as>>> bridge itself with already configured routing table.>>>>>> More details with example you may found in patches.>>>>>> Please review. Any (including _complains_) comments are>>> highly appreciated!>>>>>> The series is on top of current -net-next-2.6>>>>>> | commit ed9b58bc443a1210b5be1ded6421b17e015bf985>>> | Author Richard Genoud <richard.genoud@xxxxxxxxx>>>> | Date Sat May 9 06:59:16 2009 +0000>>>>>> Cyrill>>> _______________________________________________>>> Bridge mailing list>>> Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx>>> https://lists.linux-foundation.org/mailman/listinfo/bridge>>>>>>_______________________________________________Bridge mailing listBridge@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/bridge
