Hello Michal,
--
![Architecte réseaux et Sécurité]()
![Network & Security Architect]()
![]()
![]()
![]()
Well, in fact I think this should be vice versa. Docker is using LXCs
but not through libvirt. And as much as I wish they had chosen to have
libvirt backend, they hadn't. I mean, docker is a management application
so in the stack it sits above libvirt. But on the other hand, one could
say that about ESX too, and we have a driver for that.
but not through libvirt. And as much as I wish they had chosen to have
libvirt backend, they hadn't. I mean, docker is a management application
so in the stack it sits above libvirt. But on the other hand, one could
say that about ESX too, and we have a driver for that.
Actually, Libvirt can sit on top of libvirt and use its REST API: cf. architecture.
Interfacing libvirt with docker would be beneficial to both parties, and also to virt-manager if you add some docker management calls into libvirt northbound API.
We do support OvS:
Yes, I know; I have not been clear enough; I meant it seems that OvS management is not offered in libvirt northbound API since we cannot choose the bridge type for each virtual network we create inside virt-manager.
Jean-Christophe Manciot
On Tue, Oct 4, 2016 at 1:48 PM, Michal Privoznik <mprivozn@xxxxxxxxxx> wrote:
On 02.10.2016 15:11, jean-christophe Manciot wrote:
> Hello everyone.
Hi,
Thank you for your points. I often think about this as I'm trying to
promote libvirt on every occasion.
>
> Going straight to the point:
> 1) *add connection type: Docker*
> This should not induce a lot of development since there is already an LXC
> connection type.
Well, in fact I think this should be vice versa. Docker is using LXCs
but not through libvirt. And as much as I wish they had chosen to have
libvirt backend, they hadn't. I mean, docker is a management application
so in the stack it sits above libvirt. But on the other hand, one could
say that about ESX too, and we have a driver for that.
>
> 2) add the ability to *choose the bridge type of any virtual network*:
> - Linux bridge
> + VPP : Cisco has recently open-sourced the virtual switch/router
> <https://wiki.fd.io/view/VPP/What_is_VPP%3F > which it uses with DPDK as a
> core part of some of its commercial virtual products. Its performance
> should be unprecedented as compared to the current Linux bridge or even
> OvS. "VPP is also applicable to many architectures (x86, ARM, and PowerPC)
> and deployment environments (bare metal, VM, container)", according to
> Simon Dredge in FD.io Takes Over VPP and Unites with DPDK to Accelerate NFV
> Data Planes to Outright Nutty Speeds
> <http://www.metaswitch.com/the-switch/fd.io-takes-over- >.vpp
Interesting, haven't known about this one.
> + OvS: not a priority IMHO.
We do support OvS:
<interface type='bridge'>
<source bridge='ovsbr'/>
<virtualport type='openvswitch'/>
</interface>
Michal
Jean-Christophe Manciot
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list