> 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! :-) Referring to the options listed in the link posted above, I agree about the Options 3. Moreover, according to the posted XML network examples, I imagine a network definition like: <network type='tunneled'> <name>red-network</name> <tunnel type='ipsec'> <!-- here all elements to define an ipsec tunnel --> </tunnel> </network> or <network type='tunneled'> <name>red-network</name> <tunnel name='ipsectun0' /> </network> but the second example requires the definition (XML, API, ect) of element <tunnel ...> > I'm wondering how the <sectunnel> element would fit in with network > types that were not "bridge". [...] Sorry, but I don't understand what do you want to say... ;-) > [...] 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. I used Open vSwitch to isolate the traffic (by using VLAN tagging) into the tunnel. Moreover, I'm valuating to define a Libvirt hook that will allow the dynamic configuration of Open vSwitch. See you, Paolo -- PAOLO SMIRAGLIA Department of Control and Computer Engineering Polytechnic University of Turin Email: paolo.smiraglia@xxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list