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