Hi Tomasz, A few points to note, and this might make things clearer:
* The gateway initialization happens in a separate driver (I am referring to the part of the code which you did not find), please take a look at the QuantumLinuxBridgeInterfaceDriver class inside: nova/network/linux_net.py * For the reboot scenario that you mention, I did not say that the tap devices are created in the agent, I mentioned that only the bridge is created. The tap devices are created in the VIF driver. That part of the code needs to execute when the VM is being revived. * As for your suggestion on using the interface type bridge, that would work only if plug is called only once in the lifetime of a VM. Quantum tries to support semantics beyond that; one should be able to plug a VIF into a port, may be unplug at a later time, plug into a port on a separate network, and so on. One way to achieve this is by using the interface type ethernet (and that's where the agent comes into play, hence it's required). Thanks, ~Sumit. > -----Original Message----- > From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net > [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On > Behalf Of Tomasz Paszkowski > Sent: Wednesday, March 21, 2012 12:13 AM > To: netstack@lists.launchpad.net > Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available > > Hi, > > Comments inline > > On Wed, Mar 21, 2012 at 12:18 AM, Sumit Naiksatam (snaiksat) > <snaik...@cisco.com> wrote: > > > > Hi Tomasz, > > > > > > > > Thanks for your note. I am not sure I completely understand the > problems you are facing. Please note that the patch you have referred > to introduces the VIF-driver for Quantum's Linux Bridge plugin. The > behavior of this is slightly different from the VIF driver that is used > within Nova for plugging into a Linux bridge (when using a VLAN- > NetworkManager). More responses inline. > > VIF driver for Quantum's Linux bridge is already introduced in master: > > ubuntu@vm-builder-2:~/build/nova/nova- > 2012.1+git201203162209/nova/virt/libvirt$ > grep Quantum * > vif.py:class QuantumLinuxBridgeVIFDriver(vif.VIFDriver): > vif.py: """VIF driver for Linux Bridge when running Quantum.""" > vif.py: > linux_net.QuantumLinuxBridgeInterfaceDriver.create_tap_dev(dev) > ubuntu@vm-builder-2:~/build/nova/nova- > 2012.1+git201203162209/nova/network$ > grep Quantum * > linux_net.py:# plugs interfaces using Linux Bridge when using > QuantumManager > linux_net.py:class > QuantumLinuxBridgeInterfaceDriver(LinuxNetInterfaceDriver): > linux_net.py: > QuantumLinuxBridgeInterfaceDriver.create_tap_dev(dev, mac_address) > > > > > > > > > > Thanks, > > > > ~Sumit. > > > > > > > > From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net > [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On > Behalf Of Tomasz Paszkowski > > Sent: Tuesday, March 20, 2012 2:54 PM > > To: netstack@lists.launchpad.net > > > > > > Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available > > > > > > > > > > > > as I wrote in bug report related to linux bridge and quantum in nova > this code is broken in few places: > > > > > > > > 1) tap devices for instances are set up (ip link set up) by > quantum during creation and this is stoping libvirt from changing mac > address of this interface which is breaking vm startup > > > > > > > > <Sumit> We have not seen issues with the VM startup. Could you kindly > be a little more specific as to which MAC address needs to change, and > is not getting changed?</Sumit> > > > Hi, > > Default template for libvirt for ethernet type interface is: > > #for $nic in $nics > #if $vif_type == 'ethernet' > <interface type='ethernet'> > <target dev='${nic.name}' /> > <mac address='${nic.mac_address}' /> > <script path='${nic.script}' /> > > If we pass mac address within domain configuration libvirt is trying > to set mac address on specified interface and this operation fails > because it can't be performed on up interface (interface is beeing put > up from nova code). This error stop libvirt from starting vm. Patch > from http://paste.openstack.org/show/10976/ prevents setting this > interface up. > > > Op > > > > > > > > 2) nova-network is not initializing bridge devices on startup > and l3 interfaces > > > > > > > > > > > > <Sumit> Did you run the Quantum Linux Bridge agent? The agent does > this work, and it only happens when the first VM comes up on that > network. </Sumit> > > > I can't find any code in linuxbridge_quantum_agent.py which is > handling this. That's why I have modified code in init_host function > nova/network/quantum/manager.py to do this. > > > > 3) machine running instances after reboot is loosing all bridges > and tap devices and there is no code which recreates this. > > > > > > > > <Sumit> I have not tested this, but again, if you were running the > Quantum Linux Bridge agent, the bridges should get created again. The > tap devices are created in the VIF driver, so that only happens when > Nova calls "plug" on VM start-up. </Sumit> > > No, tap devices are not created by this agent. Take a look at code > from linuxbridge_quantum_agent.py: > > def add_tap_interface(self, network_id, vlan_id, tap_device_name): > """ > If a VIF has been plugged into a network, this function will > add the corresponding tap device to the relevant bridge > """ > if not tap_device_name: > return False > > if not self.device_exists(tap_device_name): > LOG.debug("Tap device: %s does not exist on this host, > skipped" % > tap_device_name) > return False > > As you can see if the tap interface dosen't already exists function > returns :-) > > > > > > > > > > > > problem 1 and 2 is resolved by code changes in nova and problem nr. 3 > is addressed by adapting interface type bridge with quantum linux > bridge integration. > > > > > > > > patches are on launchpad https://bugs.launchpad.net/nova/+bug/941794 > > > > > > > > > > > > At the end in my opinion we don't need an agent for linux bridge > integration. > > > > > > > > <Sumit> As I mentioned earlier, in order to fully support the Quantum > attach/detach interface semantics, the interface-type has to be set to > "ethernet" (so that tap devices can be used, and be added to the bridge > only when attach is called, and vice versa), and the agent has to be > run so that the per-host configuration is done correctly. So the agent > is needed. Of course, if there are any issues, those need to be > fixed.</Sumit> > > Im my opinion for linux bridge integration with quantum we can easily > use > interface type 'bridge' in libvirt. This solves problem with tap > devices after reboot and frees agent from plugging/unplugging > interfaces. Amount of code needed to be changed to achive > this is small: http://paste.openstack.org/show/10977/. We need also to > add <target dev='${nic.name}' /> statment to bridge section in > libvirt.xml.template but this is only requires to be mentioned within > README file. > > -- > Tomasz Paszkowski > SS7, Asterisk, SAN, Datacenter, Cloud Computing > +48500166299 > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
