Can OVN be installed/used in LXD containers (ie System containers not Process containers)?

[bmullan]

I see the documentation referring to using OVN in Kubernetes or Docker containers (which are process type containers).

But do you happen to know if it can/could be used in LXD containers (https://linuxcontainers.org).

LXD (not LXC) containers are "system" containers in that they run a complete Linux OS (CentOS, Debian, Alpine, Ubuntu, Oracle, Gentoo, etc). Like Docker they share the Host's Kernel though.

I don't have any problem using VxLAN or OVS with LXD containers.

But I'd like to know if anyone has any knowledge about using OVN with LXD?

Thanks Brian

[shettyg]

My quick read of LXD ecosystem is that you can attach a veth device to OVS bridge. From there, OVN can easily use it. But it does not look like there is a clean inbuilt multi-host story in LXD or a network plugin interface to integrate cleanly with LXD command lines.

So you will have to build in-house integration scripts.

[bmullan]

Yes, its easy to use veth with LXD and a bridge.

LXD allows you to orchestrate/manage both local and remote Servers/Hosts that have LXD installed on them and configured to allow network access to the LXD Daemon on that local/remote Server/Host.

In my use of LXD I have LXD servers on AWS, Digital Ocean & Hetzner clouds as well as here locally and orchestrate/manage them from here.

I currently use a full-Mesh auto-learning VPN to interconnect the 10.x.x.x network LXD containers running on all of these local/remote Server/Hosts.

However, I recently retired from 20 years at Cisco Systems and my last 3 years there were with their SDN leadership consulting team where I worked with OpenDayLight (ODL), VxLAN etc.

Now that I'm retired my projects involve LXD containers.

I'd like to find a solution beyond my current mesh VPN which would include a more SDN type overlay-networking environment with a Controller, OVS/VxLAN etc so the local/Remote LXD container orchestration/management could be more easily setup for Multi-Tenant etc use-cases.

The LXD REST API is documented here: https://linuxcontainers.org/lxd/rest-api/

A general introduction is found here: https://linuxcontainers.org/lxd/introduction/

LXD Design

The core of LXD is a privileged daemon which exposes a REST API over a local unix socket as well as over the network (if enabled). LXD containers are all "un-privileged" by default.

_Clients, such as the LXC command line tool provided with LXD itself then do everything through that REST API.

It means that whether you're talking to your local host or a remote server, everything works the same way._

Features

Some of the biggest features of LXD are:

• Secure by design (unprivileged containers, resource restrictions and much more)
• Scalable (from containers on your laptop to thousand of compute nodes)
• Intuitive (simple, clear API and crisp command line experience)
• Image based (with a wide variety of Linux distributions published daily)
• Support for Cross-host container and image transfer (including live migration with CRIU)
• Advanced resource control (cpu, memory, network I/O, block I/O, disk usage and kernel resources)
• Device passthrough (USB, GPU, unix character and block devices, NICs, disks and paths)
• Network management (bridge creation and configuration, cross-host tunnels, ...)
• Storage management (support for multiple storage backends, storage pools and storage volumes)