6:49 p.m.
Hi Daniel. Thanks for the reply. All comments are inline.
On Thu, Mar 24, 2011 at 06:44:05PM +0100, Paolo Smiraglia wrote:
> Hi guys...
>
> I need an opinion from the Libvirt community about the development of
> a new possible Libvirt feature: the Trusted Virtual Domains (TVD).
> Conceptually, a TVD can be compared to a mix of Virtual Private
> Network (VPN) and Virtual LAN (VLAN).
>
> My idea is to define a new Libvirt entity called "tvd" which contains
> the information about domains and hosts belonging to the same TVD.
> Below is showed a possible XML definition of tvd entity:
>
> <tvd name='tvd1.mycloud' uuid='...'>
> <host ip='10.0.0.1' hostname='node1.example.com'>
> <domain name='guest1' uuid='...' />
> <domain name='guest27' uuid='...' />
> </host>
> <host ip='10.0.0.2' hostname='node2.example.com'>
> <domain name='guest12' uuid='...' />
> <domain name='guest2' uuid='...' />
> </host>
> </tvd>
>
> With the informations contained in the tvd XML definition, Libvirt may
> be able to automatically setup, for example, an IPSec tunnel between
> node1.example.com and node2.example.com, and VLAN between guest1,
> guest2,guest12 and guest27.
One core thing to remember is that libvirt's view of the "world"
is restricted to the single host running libvirt. The XML mentioned
above seems to be predicated on a network-wide view of the world.
In my example I consider the presence of super-host that knows "everything
about everyone". You can see this super-host as the FrontEnd node in Opennebula
cloud.
The second thing is that the guest XML describes the connection of
a virtual machine to the host network. This mapping above would
appear to imply some duplication of information.
The TVD definition should be considered not as property of domains, but a
property of the host.
> In my opinion, this feature may be really useful in a cloud
computing scenario.
>
> And you? What about it? It is a crazy idea? ;-)
I would like to see some form of VPN/IPSec support in libvirt. There
are many questions about just where it would be best to slot it into
libvirt.
We have what we call a 'virtual network' in libvirt, which is basically
an standalone bridge device, to which guests are connected. This bridge
device has no physical NIC enslaved. Thus guests can talk to each other,
or the host. It can only be made to allow routing (with optional NAT)
to the LAN. One idea would thus be to provide a mode where it would
integrate with IPSec instad of routing direct to the LAN, using
network-2-network IPsec connections.
We also have a set of APIs for managing physical network interface
configuration (virsh iface-XXXX). This allows for bridges, bonding
and VLANs to be configured. We might want to integrate IPSec at that
point for host-2-host or network-2-network IPsec connections.
A third possibility, is that we have considered is to create a set
of APIs to represent a 'virtual switch'. This would be a defining
logical networks & ports to which guests can connect - a higher level
API over the physical network interface APIs we already have. We could
put some kind of IPSec capability in here.
I don't not enough about IPSec yet to know which is most useful / best.
I think that the security features should be transparent for the domains. For
example, considering a cloud computing scenario, informations about the
backbone network must be invisible.
Could you explain a bit about the kind of network interface
configuration
/ network architecture you imagine with your example above ?
A TVD is composed of several domains hosted on a different hosts. All traffic
between the domains belonging to the same TVD is tagged like a VLAN. Protection
and authentication of the traffic between two domains running on a
different host
is provided by IPSec.
All hosts belonging to the TVD share the same tvd definition. Using
the information
stored in the XML file is easily for the host, for example using a
libvirt hook, to
establish an IPSec channel and VLAN configuration on the virtual switch.
IPSec channel can be established using the host ip addresses stored in
the XML file.
The VLAN setup consists in to configure the ports (the domain's tap interface)
connected to the virtual switch (a bridge which support a VLAN tagging) with the
TVD id (corresponding to the VLAN id).
As you can see, all settings are host-side and not domain-side.
IIUC, it sounds like you'd create a IPSec host-to-host link
beween the
2 IP addresses, and then somehow run multiple VLANs above it. So you
can have multiple independant secure networks across the two hosts.
Yes, you're right!
Does this expand easily to > 2 hosts ?
To expand the configuration I immagine a message system between super-node
and all the hosts belonging to the TVD. For example:
There are two hosts (A,B) which composing a TVD. The super-node deploy a new
domain on a third host (C). The new deployed domain must be a member of the TVD.
The super-node generate a new xml definition of the TVD and send it to all hosts
belonging to the TVD. A and B will recive a 'TVDUpdate' message, and C recive
a 'TVDNew' message. All messages include the new tvd xml definition.
I hope I was clear. If you need more information give me a whistle! ;-)
Bests,
Paolo
--
PAOLO SMIRAGLIA
http://portale.isf.polito.it/paolo-smiraglia