Open Stack

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

Good point.  Andreas, how do you think the timing of the Nova and 
Neutron parts will work?

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

Consider data that's arriving at a local VM, and has come from a VM on 
another compute host.

   VM ----- Host A ------------- Host B ----- VM
10.0.0.1                                  10.0.0.2

In Host B's routing table there is a rule like this:

10.0.0.2/32 dev tap12345-CD

where tap12345-CD is the TAP interface towards the VM.  Does that answer 
your question, and would that be possible with a libvirt network?

Thanks,
	Neil


> --
> Ian.
>
>
> On 10 June 2015 at 12:16, Neil Jerram <Neil.Jerram at metaswitch.com
> <mailto: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 [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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>