On 20 January 2014 10:13, Mathieu Rohon <mathieu.ro...@gmail.com> wrote:
> With such an architecture, we wouldn't have to tell neutron about > vif_security or vif_type when it creates a port. When Neutron get > called with port_create, it should only return the tap created. > Not entirely true. Not every libvirt port is a tap; if you're doing things with PCI passthrough attachment you want different libvirt configuration (and, in this instance, also different Xen and everything else configuration), and you still need vif_type to distinguish. You just don't need 101 values for 'this is a *special and unique* sort of software bridge'. I don't know if such a proposal is reasonable since I can't find good > informations about the ability of libvirt to use an already created > tap, when it creates a VM. It seem to be usable with KVM. > But I would love to have feedback of the communnity on this > architecture. May be it has already been discussed on the ML, so > please give me the pointer. > libvirt will attach to many things, but I'm damned if I can work out if it will attach to a tap, either. To my mind, it would make that much more sense if Neutron created, networked and firewalled a tap and returned it completely set up (versus now, where the VM can start with a half-configured set of separation and firewall rules that get patched up asynchronously). -- Ian.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
