<div dir="ltr"><div><div>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).<br><br>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.<br><br></div>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?<br>-- <br></div>Ian.<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 June 2015 at 12:16, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/06/15 15:47, Andreas Scheuring wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel, Neil and others,<br>
<br>
I was thinking about introducing libvirt-network as a new vif type to<br>
nova. It can be used when Neutron prepares a libvirt network for<br>
attaching guests.<br>
<br>
Would you see any general concerns with such an approach? Anything that<br>
I need to consider with libvirt networks in addition? Maybe I should<br>
mention one thing due to the discussion this morning: No plug/unplug<br>
behavior would required.<br>
<br>
Any feedback is welcome!<br>
<br>
<br>
I added a blueprint and wrote a spec with more details [1]. This<br>
blueprint would make the macvtap-vif blueprint [2] dispensable.<br>
<br>
The neutron code exploiting this libvirt network vif type will land on<br>
stackforge. It will manage macvtap backed libvirt networks --> offer<br>
guest attachments via macvtap. [3]<br>
<br>
<br>
<br>
[1] <a href="https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif" target="_blank">https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif</a><br>
[2] <a href="https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif" target="_blank">https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif</a><br>
[3] <a href="https://launchpad.net/networking-macvtap" target="_blank">https://launchpad.net/networking-macvtap</a><br>
(I'm still waiting for the repo to be approved, so for now I only have a<br>
launchpad project to ref to).<br>
</blockquote>
<br></span>
Thanks, Andreas, this looks interesting.  I wonder if<br>
<br>
<network><br>
  <name>xyz</name><br>
  <forward mode="route"\><br>
  ...<br>
</network><br>
<br>
<domain><br>
  ...<br>
  <interface type='network'><br>
    <source network='xyx'/><br>
  </interface><br>
  ...<br>
</domain><br>
<br>
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<br>
<br>
<domain><br>
  ...<br>
  <interface type='ethernet'><br>
    ...<br>
  </interface><br>
  ...<br>
</domain><br>
<br>
Do you happen to know how data gets routed _to_ a VM, in the type='network' case?<br>
<br>
Regards,<br>
        Neil<br>
<br>
<br>
[1] <a href="http://docs.projectcalico.org/en/latest/home.html" target="_blank">http://docs.projectcalico.org/en/latest/home.html</a><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>