[libvirt] 2 major proposals to enhance libvirt and its attractivity among developers & users

[jean-christophe Manciot]

Hello Michal,

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.

Actually, Libvirt can sit on top of libvirt and use its *REST API:*
cf. *architecture
<https://docs.docker.com/engine/understanding-docker/>*.
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*

*[image: Architecte réseaux et Sécurité]
<https://learningnetwork.cisco.com/people/manciot.jeanchristophe/content>
*[image:
Network & Security Architect]
<https://fr.linkedin.com/in/jeanchristophemanciot/en>
<https://twitter.com/jc_manciot>
<https://plus.google.com/u/0/+jeanchristopheManciot-IT/posts>

On Tue, Oct 4, 2016 at 1:48 PM, Michal Privoznik <mprivozn at redhat.com>
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*

*[image: Architecte réseaux et Sécurité]
<https://learningnetwork.cisco.com/people/manciot.jeanchristophe/content>
*[image:
Network & Security Architect]
<https://fr.linkedin.com/in/jeanchristophemanciot/en>
<https://twitter.com/jc_manciot>
<https://plus.google.com/u/0/+jeanchristopheManciot-IT/posts>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161005/40fed972/attachment-0001.htm>