Open Stack

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.


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 :|