[openstack-dev] [nova] vif type libvirt-network
ijw.ubuntu at cack.org.uk
Wed Jun 10 20:07:02 UTC 2015
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
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
On 10 June 2015 at 12:16, Neil Jerram <Neil.Jerram at 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 . This
>> blueprint would make the macvtap-vif blueprint  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. 
>>  https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
>>  https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
>>  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
> <forward mode="route"\>
> <interface type='network'>
> <source network='xyx'/>
> would provide the connectivity that my Calico project wants to set up 
> - i.e. where all data to and from VMs is routed on the compute host -
> instead of
> <interface type='ethernet'>
> Do you happen to know how data gets routed _to_ a VM, in the
> type='network' case?
>  http://docs.projectcalico.org/en/latest/home.html
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev