Lxd

I sorted out the DHCP issue I saw yesterday. There was a discussion on this topic that was very helpful. There was a checksum problem in the request for an address. The fix was to apply sudo ethtool --offload lxdbr0 tx off to disable checksum offloading on the bridged network in LXD. This site has a nice description of the what that means: Checksum offloading is usually beneficial as it allows the checksum to be calculated (outgoing) or verified (incoming) in hardware at a much faster rate than it could be handled in software.

I was finally able to get FreeBSD installed on LXD: rob@bsd:~ $ uname -a FreeBSD bsd 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 After all of the Ubuntu upgrades, I found that I had done some strange configuration on my LXD system. It’s been a bit since I looked at it and instead of trying to fix it, I just uninstalled (sudo snap remove --purge lxd) and reinstalled. After LXD was installed and configured, I downloaded the FreeBSD 14.

This is a very nice write up about LXD and Multipass by Jon Seager. He’s not exactly neutral as a Canonical employee, but I agree with just about everything he says about LXD. It’s a really nice system for running containers and virtual machines. I haven’t used it much of late, but I found it to be a powerful and flexible. I was concerned that it would lose mometum when one of the principal developers left Canonical and forked the project, but LXD seems to be progressing quite well as does Incus.

Two months ago, I wrote about the LXD fork called Incus that was in the works. The first release of Incus is out and looks interesting. I haven’t installed it yet, but did give it a try online. It is very similar to LXD but has some nice changes. First, the simplification around instances rather than having separate containers and virtual machines is nice. It breaks backwards compatibility but makes things simpler going forward.

I did a little bit more testing with OpenTofu today. This time with LXD. There was a new alpha version of OpenTofu released to fix a bug so I installed that one to keep current. I didn’t encounter the bug although I did use the sensitive variable tag. An init, plan, apply and destroy loop worked flawlessly with the following simple LXD configuration: terraform { required_providers { lxd = { source = "terraform-lxd/lxd" } } } resource "lxd_instance" "tofu1" { name = "tofu1" image = "ubuntu:22.

I haven’t used LXD much recently but it’s a very nice container and virtual machine management system. I’ve done a few things with it in the past and it works really well. I noticed the other day through some web browsing that Canonical was withdrawing LXD from the Linux Container project and would be developing it in-house. I didn’t think anything of it at the time. This piece in The Register outlines why that is.

I tried to follow the documentation to run MicroK8s on LXD. However, it didn’t work because the microk8s nodes (really node since I was just trying on one system) wouldn’t start. I’m not sure of the root cause of that but it was vexing. After a little bit of searching, I found an article on the Ubuntu blog that described running Apache Spark on MicroK8s on Ubuntu Core in the cloud.

I use LXD to create virtual servers on my main system to experiment around with stuff I might not want to install directly. It’s simple, fast and works well. I was curious if I could use it to do the same thing on a cloud server at Hetzner. The only problem was how to access the LXD container from outside. They are assigned IP4 addresses but those aren’t routable. However, the IPv6 address are routable.