On 04/29/2011 12:13 PM, Paolo Smiraglia wrote:
Hi to everyone!
Sorry for the latency of the response but me and my team we are noticed
that the TVD argument can not be treated only with a few lines in some
mails. In order to avoid any possible misunderstanding, we decided to
produce a little report (just four pages with images) that describes our
project. Technical details are not treated in the report. You can
download the report by using the link
http://dl.dropbox.com/u/824617/tvd_in_libvirt.pdf
Our idea is to start the discussion about Libvirt TVD implementation
using as starting point the report.
As already mentioned in previous mail, we think that the first step for
the implementation of the TVD is to make possible the 'tunnel' modeling
in Libvirt.
Considering the report, what do you think about our tunnel modeling
idea? It's right or some changes are needed?
Paolo,
Did you see my recent email titled "RFC: disconnecting guest/domain
interface config from host config":
https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html
We both want to expand the usage of <network>, so we'd do well to avoid
stepping on each others' toes! :-)
I'm wondering how the <sectunnel> element would fit in with network
types that were not "bridge". I'm also curious about your work with
openvswitch, because one of the potentials I can see as a result of
expanding the usage of <network> is that openvswitch could be supported
directly by libvirt by defining a new <network type='openvswitch'> (I
mention that in one of the followup messages.
Also I'm still curious about my questions in my earlier response to you:
https://www.redhat.com/archives/libvir-list/2011-April/msg00589.html
in particular:
1) does the network on each host always have a <forward ...> element for
forwarding local traffic directly out to the public network? or
alternately, is it possible to force a network on one host to send all
traffic over the L2-over-L3 tunnel to a network on another machine, and
from there out to the public network? It seems that, in this case, there
would be no default route for the systems on the former network (in the
case of no forwarding on a libvirt network, no default route is sent in
the dhcp response - maybe that needs to be configurable...)
2) Is there an exact 1:1 correspondence between network and tunnel (or
perhaps there may be multiple tunnels for a network, but those tunnels
are not used by any other network on the same host)? If so, perhaps your
project could be simplified by just putting the tunnel config as a
subelement of <network>, rather than referencing it - this way you would
avoid the need for the extra APIs to define/undefine/etc sectunnel.
3) Are your tunnels always L2, or do you have provision for setting up
L3 tunnels? (Perhaps that could be done by allowing multiple <forward>
elements, and having a <forward> that specified a tunnel rather than a
physical interface, as well as a list of routes as subelements? This,
along with a sectunnel subelement should be enough info to setup a
secure L3 tunnel which would be used for the specified routes, right?
(BTW, after thinking about it some more, I think I agree that <network>
is the right place to implement this, rather than a virInterface (host)
based <interface> (although that would also be useful, totally separate
from libvirt)).
It seems we can gain a lot from each other! I'm hoping to have my
expansion of the network config completed by the end of June at latest,
but your work may enable/force me to hurry it a bit more than that :-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list