I am thinking of moving my dedicated server to LXD (a variant of LXC). One reason is that I can run LXD on several different environments where I can run Ubuntu: * On a dedicated server. * On an Amazon EC2 instance. * On my home machine, running Ubuntu desktop. * On a cheap Ubuntu 16.04 Openstack KVM VPS. I find the VPS option very usuful, however tricky because of the tight disk space. I can have a few containers on my VPS. I can move containers between the VPS and another LXD server. I can run a container OS that I need on my VPS that is not offered as a choice by my VPS provider, but is available as an LXD template. And perhaps I can replace the dedicated server with a few cheaper VPSs. I have tried doing all these with OpenVZ in the past. I couldn't get it to run anywhere, except on the dedicated server or on a dedicated home machine (or dual boot). Now it seems that I cannot run OpenVZ 7.0.0 on any of the above infrastructure. I have installed OpenVZ 7.0.0 on my home machine, as a dual boot, but I'm not using it, since I use my desktop OS and I cannot use both at the same time. In the past I tried installing OpenVZ on several desktop distributions, but I couldn't find one that worked. It seemed to work on Linux Mint 17, but when I ran a Java IDE, it crashed. There are other pros and cons to using LXD vs OpenVZ, but the versatility of installation seems to be the deciding factor for me. LXD is Ubiquitous, if you are willing to run Ubuntu (which I am). If I could easily move containers between OpenVZ and LXD, I could use both. Here's some food for thought for an OpenVZ feature: compatibility with LXD and perhaps with other container technologies. Create an LXD template from an OpenVZ container. Or an OpenVZ container from an LXD template. Why not?
I migrated to LXD, several months ago, and I like it. I have about 30 running containers on my dedicated server, for personal or non-profit use, websites etc. I use containers with the ZFS filesystem, which allows me to take instant snapshots and copies. It takes 10 seconds to make a test copy of a full ubuntu container and start it. I often have one container per project (website, etc.) so I can easily experiment with it, make snapshots, temporary test copies, revert to the last snapshot, etc. I use two container templates, the official ubuntu 16.04 and the latest Alpine. Alpine is very small. I use it for pound, static websites, git, certbot, and backup containers. I use a single external IP address for all the containers on my host, just like I did with OpenVZ. I use shorewall to redirect various ports to different containers. I redirect a separate port to SSH for each container. I also redirect the HTTP and HTTPS ports to a pound container that proxies requests to various containers according to the Host header (using SNI for HTTPS). I also use LXD on a home computer, a VPS and an Amazon nano (!) instance. On the VPS I use containers with the ext4 filesystem, running one Ubuntu and two Alpine containers in a total of 10G disk. I tried using ZFS backed-up by flat files but it was tricky and I unexpectedly ran out of disk space. I also tried using ZFS on an add-on filesystem to the VPS. It was good for temporary migrating my OpenVZ containers, but the add-on filesystem performed much worse (with ZFS) than the root filesystem. I also use LXD on a home computer, and on an Amazon nano instance (running just a backup Alpine container). I like the LXD client, "lxc", which allows me to do all LXD operations remotely, from my desktop. My LXD containers are not as isolated as the OpenVZ containers. When I do "df" on an LXD container I also see the host lxd filesystem and when I run "top" I see the host RAM. ZFS allows me to set disk quotas for each container. I think I could also limit the RAM for a container. But I don't bother with limits, since I administer all my containers. I am grateful to OpenVZ for introducing me to containers, and to LXD for giving me more flexibility and ease of use.
votsalo wrote on Sat, 18 March 2017 10:09 My LXD containers are not as isolated as the OpenVZ containers. When I do "df" on an LXD container I also see the host lxd filesystem and when I run "top" I see the host RAM. That's a deal breaker for me. I suspect it would be for a lot of people wanting to use it commercially. Using it for personal use is a completely different thing. I hope they plan to address that. If not then I will definitely be using OVZ 7.
I think I am running lxd from the 'stable' channel already. Have you changed anything in your release policy?
Are there any control panels for LXD? For hosting purposes? OVZ has Solus and Virtualizor. Neither support LXD. Proxmox is not suitable and it does not yet support LXD either.
I don't know if there are control panels for LXD, but if there are control panels for LXC, then I don't think they need to support LXD. I assume that a control panel would have its own interface, just like Proxmox had its own command line interface, which could be used in place of the vz tools. Doesn't Proxmox support some sort of LXC containers? LXD is a newer and better command-line interface to the same facilities supported with LXC. It is similar to vzlist + vzctl. LXD and LXC containers are managed differently. You cannot mix LXD and LXC commands for the same containers. LXD does not see the containers of LXC and vice versa. The client command for LXD is called "lxc", while client commands for LXC are multiple executables with the prefix "lxc-" (somewhat confusing). My use case is managing containers for my own use. I use the LXD command line, and I was using the OpenVZ command line. My initial reason for switching from OpenVZ was the difficulty of installing OpenVZ 7. It was practically impossible, except on a dedicated machine to which I had physical access. Now I use LXD on all my computers, desktops and cloud. I run LXD commands on my desktop to manage remote containers. I have containers on my desktop. It's easy, so why not? It's even possible to run GUI programs with working video and audio in a desktop container (with some additional configuration to link the display and the sound with the host).
You cannot use LXC for hosting. It is not secure for that purpose. Only for internal use behind a firewall where the ability to break out of individual containers is not a security problem. So for corporate use where you need to keep the logic separate and the only people accessing things are administrators. I repeat. You cannot use LXC for hosting. The primary use of OVZ is for hosting. So LXC is not a replacement for OVZ. LXD is but it's still not as secure or stable
By hosting do you mean creating VPSs or hosting plans? I see that VPS providers are moving away from OpenVZ and moving to KVM. For example OVH discontinued its OpenVZ VPS series and replaced it with OpenStack KVM. What stability or security issues have you seen with LXD? Have you tried submitting a bug report? Having used both, I consider LXD more stable than OpenVZ. I spent many hours trying to use OpenVZ alongside my desktop, even changing OS to Debian or CentOS, and my system kept crashing. I know this is not the intended usage of OpenVZ, but LXD manages just fine. LXD maintains Alpine images, which are very useful for tiny containers. If you install apache2 on Alpine, the whole system is about 15 MiB. There has been an explosion of container technologies lately, and I don't know which will be the winner. We don't hear much from LXD, as this recent articles mentions: https://containerjournal.com/2018/01/12/whats-the-status-of- lxd-canonicals-container-hypervisor/ I just tried RKT today, which is more like Docker. But here's a list of related technologies: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.htm l systemd-nspawn seems interesting. Could that be used for hosting plans? The primary use of OpenVZ may be "hosting", but the technology is also driven by new use cases.
votsalo wrote on Mon, 19 February 2018 14:35 By hosting do you mean creating VPSs or hosting plans? I see that VPS providers are moving away from OpenVZ and moving to KVM. For example OVH discontinued its OpenVZ VPS series and replaced it with OpenStack KVM. What stability or security issues have you seen with LXD? Have you tried submitting a bug report? Having used both, I consider LXD more stable than OpenVZ. I spent many hours trying to use OpenVZ alongside my desktop, even changing OS to Debian or CentOS, and my system kept crashing. I know this is not the intended usage of OpenVZ, but LXD manages just fine. LXD maintains Alpine images, which are very useful for tiny containers. If you install apache2 on Alpine, the whole system is about 15 MiB. There has been an explosion of container technologies lately, and I don't know which will be the winner. We don't hear much from LXD, as this recent articles mentions: https://containerjournal.com/2018/01/12/whats-the-status-of- lxd-canonicals-container-hypervisor/ I just tried RKT today, which is more like Docker. But here's a list of related technologies: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.htm l systemd-nspawn seems interesting. Could that be used for hosting plans? The primary use of OpenVZ may be "hosting", but the technology is also driven by new use cases. LXC/D containers are not as isolated as OpenVZ. You can also use KVM with OpenVZ 7 so why use KVM only when you can have both? Providers are using KVM because that is the only sure thing right now. Because you can also do that with OpenVZ 7 it seems like a no brainer to me. My only issue is that they require you to install their custom openvz-iso OS or convert an existing CE7 install. I think that was a mistake.
votsalo wrote on Mon, 19 February 2018 15:35 Having used both, I consider LXD more stable than OpenVZ. I spent many hours trying to use OpenVZ alongside my desktop, even changing OS to Debian or CentOS, and my system kept crashing. I know this is not the intended usage of OpenVZ, but LXD manages just fine. It's not the intended usage, nor should the experience on one desktop system be considered representative, IMHO. Who knows what made your system crash... We've been using OpenVZ (up to OpenVZ 7) for roughly a decade on literally dozens of nodes (enterprise grade hardware and using CentOS or Scientific Linux) and thousands of VMs of all kinds and in my experience, it's completely stable and rock solid. Can't vouch for OpenVZ 7 though, as we haven't started using it in production. The OpenVZ 6 node and CentOS 7 VMs scenario works well for us. Not to mention OpenVZ 6 node and CentOS 6 VMs, that goes without saying. We've also been successfully using KVM alongside OpenVZ 6. A couple of rough edges here and there, but the combo has been used live for a long time and it's completely doable.
I've done a lot of testing with lxc and lxd, and while it has made a lot of progress, for my use cases openvz is the best available platform. I've had strange issues over the years with lxc containers, and as a result, they've all been moved to openvz 7, with no further issues. Originally I used only the containers in openvz, but now am using the VMs more and more, when I need a full OS install. YMMV, of course. To each his own, and it's great that the open source community offers choice. Jake