On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote: > It seems the main reason for your new proposal is to deal with > the fact that on migration, you need to specify a different > NIC name in the XML. This is not particularly difficult - Nova > already has code for dealing with pdating the XML - the _update_xml > method in nova.virt.libvirt.driver just needs extending to cover > that.
Right, that's why I considered the libvirt network vif type. I also considered to use direct macvtap attachments exploiting the xml-modify feature you just mentioned. My big problem in this case is, that the domain.xml contains the physical eth interface name which will be used as source for the macvtap. Only neutron agent knows about that. It's configured in his interface_mappings. On vif_binding, neutron serves nova the eth interface name via the vif data. That's working fine - I already implemented a prototype for that which was working greatly - as long you not do live Migration. During pre-livemigration on the target host I would need to figure out which interface should be used and give this information back to the source via the pre migration data. But therefore nova needs to talk to my new neutron agent. I don't think that such a shortcut is a good approach. I'm not aware of any similar thing from other drivers. The poor alternative I see would be to duplicate the interface_mapping config to nova, but that's also not a proper approach. I also had a look at the sriov macvtap live migration blueprint [4] but the situation there is slightly different, as nova knows about all pci devices that can be used. No interaction with neutron would be needed. I also thought on jumping on this boat somehow, but the sriov macvtap support is too tightly coupled to pci. I want a general purpose macvtap driver that doesn't care about vendor specifics, but working with any ethernet device... Do you have any ideas how to achieve this? > > The neutron code exploiting this libvirt network vif type will land on > > stackforge. It will manage macvtap backed libvirt networks --> offer > > guest attachments via macvtap. [3] > > Who / what will actally be talking to libvirt to create/update the > network XML setup. Will that be part of the vif driver too. The plan was that the new macvtap-neutron agent will talk to libvirt and set up the network. My plan was not to include such function in the vif driver. But as I learned from Neil and Ian, this does not work, as there's no guarantee that neutron has set up the network before nova defined the instance. So I would need some pluging in the network-vif use case. And here I have the same problem, that nova needs to know the eth interface name for setting up the network... I also played around with just creating the network and adding an interface later on. But on a libvirt network without interfaces I cannot start a guest... Any input is welcome! Thanks! [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap [4] https://blueprints.launchpad.net/nova/+spec/sriov-live-migration -- Andreas (irc: scheuran) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev