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

2015-06-12 Thread Ian Wells
On 11 June 2015 at 02:37, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Do you happen to know how data gets routed _to_ a VM, in the type='network' case? Neil, sorry no. Haven't played around with that, yet. But from reading the libvirt man, it looks good. It's saying Guest network

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

2015-06-12 Thread Andreas Scheuring
But I still need to figure out more details about device renaming and what other side effects might come with it. Device renaming might not be a good idea in the macvtap context, as the interface used could also be used with by other applications that might insist on a fixed device name. It's

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

2015-06-11 Thread Andreas Scheuring
Ian, Neil, thanks for your input! There may be a set of races you need to deal with, too - what happens if Nova starts a VM attached to a Neutron network binding that has yet to be set up? Neutron doesn't (well, technically, shouldn't be expected to) do things instantaneously on a call,

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

2015-06-11 Thread Andreas Scheuring
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

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

2015-06-11 Thread Daniel P. Berrange
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

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

2015-06-11 Thread Daniel P. Berrange
On Wed, Jun 10, 2015 at 04:47:41PM +0200, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with

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

2015-06-11 Thread Daniel P. Berrange
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,

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

2015-06-11 Thread Andreas Scheuring
Daniel, thanks a lot for your input! Please see my novel below ;) 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

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

2015-06-10 Thread Neil Jerram
On 10/06/15 15:47, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything

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

2015-06-10 Thread Neil Jerram
Hi Ian, Thanks for your reply! On 10/06/15 21:07, Ian Wells wrote: I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage 0) and tear it down when you're done with it (usage

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

2015-06-10 Thread Ian Wells
I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage 0) and tear it down when you're done with it (usage 1). There may be a set of races you need to deal with, too - what