[openstack-dev] [nova] vif type libvirt-network
scheuran at linux.vnet.ibm.com
Thu Jun 11 10:54:54 UTC 2015
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
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  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
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. 
> 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!
More information about the OpenStack-dev