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