Re: [Xen-devel] [DRAFT 1] XenSock protocol design document

[Stefano Stabellini <stefano@xxxxxxxxxxx>]

On Fri, 8 Jul 2016, David Vrabel wrote:
> On 08/07/16 12:23, Stefano Stabellini wrote:
> > 
> > XenSocks provides the following benefits:
> > * guest networking works out of the box with VPNs, wireless networks and
> >   any other complex configurations on the host
> 
> Only in the trivial case where the host only has one external network.

Which is the most common case and the one we care about the most.


> Otherwise, you are going to have to have some sort of configuration to
> keep guest traffic isolated from the management or storage network (for
> example).

I admit I don't think I understand your example, please add more
details.

In any case how would you achieve this benefit with netfront/netback?


> > * guest services listen on ports bound directly to the backend domain IP
> >   addresses
> 
> I think this could be done with SDN but I'm no expert on this area.

Maybe. But a simple Google search didn't turn up anything useful on
this. The solution used by Docker to achieve this is very expensive in
terms of resources.

In fact even if you are right, these are complex and expensive solutions
you are talking about. It would likely require some sort of address and
port translation. XenSock is a simple solution and the best way to solve
this problem. I don't want to configure an SDN, iptables and whatnot
just to have guest ports bound on the host. More complexity one
introduces, the more difficult becomes handling security and
maintenance. Performance suffers too.


> > * localhost becomes a secure namespace for intra-VMs communications
> 
> I presume you mean "inter-VM" communication here?

Yes, I meant inter-VM, sorry for the confusion.


> This is already achievable with a private bridged network for VMs on a
> host.

Wouldn't that require one more virtual interface per VM?


> > * full visibility of the guest behavior on the backend domain, allowing
> >   for inexpensive filtering and manipulation of any guest calls
> 
> There's many existing solutions in this space for networking.

One the most important points of this work is that users don't need to
use those "existing solutions in this space for networking". They are
expensive (both in terms of money and performance) and suboptimal. They
are never going to have the level of visibility and control that we
could have with XenSock.


> > * excellent performance
> 
> netback/netfront is pretty good now and further improvements to them
> would have wider benefits.
 
You are saying that one could achieve the same benefits of XenSock with:

netfront/netback + some zero configuration tool for netfront/netback +
SDN + a network based application firewall + one more virtual interface
per VM

I feel confortable in stating that XenSock is far better than a
combination of 4 or 5 complex moving pieces.

I admit that Citrix XenServer won't directly benefit from XenSock, at
least not in the short term. But the Xen Community is much wider than
XenServer. People have already pointed out to me why this would be
useful for them.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel