[openstack-dev] [nova] vif type libvirt-network

Daniel P. Berrange berrange at redhat.com
Thu Jun 11 15:15:07 UTC 2015


On Thu, Jun 11, 2015 at 03:02:13PM +0100, Daniel P. Berrange wrote:
> On Thu, Jun 11, 2015 at 12:54:54PM +0200, Andreas Scheuring wrote:
> > 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?
> 
> I could have sworn I've previously reviewed patches which dealt with
> NIC device naming changes across migration, but I can't find them
> now. Did you ever submit patches which tried to fix this, or am I
> perhaps thinking of someone elses.
> 
> I understand the difficulty in getting the information across to
> the right place, but I thought I remembered seeing a solution ot
> that. Failing that though, the other option is to rename the ethernet
> devices when assigning them to a guest, so they have a stable name
> across hosts.

I wasn't imaginging it - this spec about SRIOV live migration deals
with exactly the scenario you describe with macvtap

https://review.openstack.org/#/c/136077/9/specs/liberty/approved/sriov-live-migration.rst


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



More information about the OpenStack-dev mailing list