[lxc-users] Current state of LXC as it relates to VoIP / realtime transcoding
Greetings, first post to the list. I’ve been doing some initial research, started with docker and also LXC by way of Proxmox (which I use for virtualization). Basically, I’m looking at rolling out Freeswitch for a whole bunch of my customers in an automated fashion, and using containers, whether via docker, LXD or proxmox is an attractive platform for this. But everywhere I’ve raised the idea, IRC/forums etc, people are saying that Linux containers are still not really suitable for this, unless security is significantly compromised by allowing container processes to access features of the kernel that they normally would not be able to, in order to have a clocking mechanism that is reliable enough for real-time transcoding etc, and this also means the solution is not portable, as it presupposes that these escalated privileges will be available in all deployment environments. Anyone have more specifics on this, is LXD any better/worse for this application than other containerization platforms, etc? Thanks much! Kevin Long smime.p7s Description: S/MIME cryptographic signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Current state of LXC as it relates to VoIP / realtime transcoding
Quoting Kevin Long (kevin.l...@haloprivacy.com): > > Greetings, first post to the list. > > I’ve been doing some initial research, started with docker and also LXC by > way of Proxmox (which I use for virtualization). > > Basically, I’m looking at rolling out Freeswitch for a whole bunch of my > customers in an automated fashion, and using containers, whether via docker, > LXD or proxmox is an attractive platform for this. > > But everywhere I’ve raised the idea, IRC/forums etc, people are saying that > Linux containers are still not really suitable for this, unless security is > significantly compromised by allowing container processes to access features > of the kernel that they normally would not be able to, in order to have a > clocking mechanism that is reliable enough for real-time transcoding etc, > and this also means the solution is not portable, as it presupposes that > these escalated privileges will be available in all deployment environments. > > > Anyone have more specifics on this, is LXD any better/worse for this > application than other containerization platforms, etc? Can you give us some more details on what hardware you need the containers to be able to use? In general it'll depend on the kernel and the hardware drivers (in the kernel), and whether you want to just delegate them to one container at a time or actually virtualize them (i.e. handing a network card to multiple containers). ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Current state of LXC as it relates to VoIP / realtime transcoding
Kevin Long wrote: Greetings, first post to the list. I’ve been doing some initial research, started with docker and also LXC by way of Proxmox (which I use for virtualization). Basically, I’m looking at rolling out Freeswitch for a whole bunch of my customers in an automated fashion, and using containers, whether via docker, LXD or proxmox is an attractive platform for this. But everywhere I’ve raised the idea, IRC/forums etc, people are saying that Linux containers are still not really suitable for this, unless security is significantly compromised by allowing container processes to access features of the kernel that they normally would not be able to, in order to have a clocking mechanism that is reliable enough for real-time transcoding etc, and this also means the solution is not portable, as it presupposes that these escalated privileges will be available in all deployment environments. Anyone have more specifics on this, is LXD any better/worse for this application than other containerization platforms, etc? Thanks much! Kevin Long Good rules for transcoding... More slower cores better than less faster cores. So 40 slow cores better than 8 fast cores. Even better, building boxes around Intel's 60 core CPUs will be even better. Trick for realtime transcoding is to keep processes pinned to a CPU, reduce context switching (when CPUs service many processes). Also, target reducing all other processes. In other words, strip down your OS to run your bootable kernel + only freeswitch. If you must use containers, using something like a BusyBox container + Freeswitch, with no other processes running. Containers based on BusyBox or Alpine will like produce far less context switching, then say an Ubuntu based container. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
