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
