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 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, even binding, or you get into the realm
of distributed system failure case analysis.

Neil, are you trying to route to the host - where this will work, because a
libvirt network is L2 - or to the VM - where this won't, for the same
reason?
-- 
Ian.


On 10 June 2015 at 12:16, Neil Jerram <neil.jer...@metaswitch.com> wrote:

> 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 that
>> I need to consider with libvirt networks in addition? Maybe I should
>> mention one thing due to the discussion this morning: No plug/unplug
>> behavior would required.
>>
>> Any feedback is welcome!
>>
>>
>> I added a blueprint and wrote a spec with more details [1]. This
>> blueprint would make the macvtap-vif blueprint [2] dispensable.
>>
>> 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. [3]
>>
>>
>>
>> [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
>> [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
>> [3] https://launchpad.net/networking-macvtap
>> (I'm still waiting for the repo to be approved, so for now I only have a
>> launchpad project to ref to).
>>
>
> Thanks, Andreas, this looks interesting.  I wonder if
>
> <network>
>   <name>xyz</name>
>   <forward mode="route"\>
>   ...
> </network>
>
> <domain>
>   ...
>   <interface type='network'>
>     <source network='xyx'/>
>   </interface>
>   ...
> </domain>
>
> would provide the connectivity that my Calico project wants to set up [1]
> - i.e. where all data to and from VMs is routed on the compute host -
> instead of
>
> <domain>
>   ...
>   <interface type='ethernet'>
>     ...
>   </interface>
>   ...
> </domain>
>
> Do you happen to know how data gets routed _to_ a VM, in the
> type='network' case?
>
> Regards,
>         Neil
>
>
> [1] http://docs.projectcalico.org/en/latest/home.html
>
>
> __________________________________________________________________________
> 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
>
__________________________________________________________________________
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

Reply via email to