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.jer...@metaswitch.com
<mailto: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://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
__________________________________________________________________________
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
