<div dir="ltr">On 20 January 2014 10:13, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
With such an architecture, we wouldn't have to tell neutron about<br>
vif_security or vif_type when it creates a port. When Neutron get<br>
called with port_create, it should only return the tap created.<br></blockquote><div><br></div><div>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'.<br>


<br></div>I don't know if such a proposal is reasonable since I can't find good<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
informations about the ability of libvirt to use an already created<br>
tap, when it creates a VM. It seem to be usable with KVM.<br>
But I would love to have feedback of the communnity on this<br>
architecture. May be it has already been discussed on the ML, so<br>
please give me the pointer.<br></blockquote><div><br></div>libvirt will attach to many things, but I'm damned if I can work out if it will attach to a tap, either.  <br><br>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).<br>


</div><div class="gmail_quote">-- <br></div><div class="gmail_quote">Ian.<br></div></div></div>