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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list