By default, LXD Virtual Machines do not preallocate their memory up to the limits.memory set. Instead, they allocate up to the maximum memory has needed during its lifetime, but they do not give back memory to the host system after it is freed, ballooning devices notwithstanding.

So, because the memory isn't given back to the host, why not preallocate the memory used by the VM? This way it is easier to reason about if you have enough memory in your system, instead of trying to think about "uuhh I do have 10240 megabytes free, but one of my VMs has a 6144 megabytes limit, and currently they are using 2048 megabytes, so actually we have 6144 megabytes free".

First, you need to shutdown your virtual machine...

lxc stop test-memoryalloc

Now, if you haven't already, let's set the memory limit for the virtual machine...

lxc config set test-memoryalloc limits.memory 8GB

And then we add QEMU's -mem-prealloc parameter to the VM!

lxc config set test-memoryalloc raw.qemu "\-mem-prealloc"

That's it! If you check how much memory the QEMU process for the test-memoryalloc virtual machine is using, you'll see that it will be using ~8GB.

And yes, you need to add the \ before the dash, because if you don't, LXD will complain about Error: unknown shorthand flag: 'm' in -mem-prealloc.

If you want to remove the -mem-prealloc parameter, you can remove it by using lxc config unset.

lxc config unset test-memoryalloc raw.qemu

---

If you have a dedicated server with OVHcloud, you can purchase additional IPs, also known as "Fallback IPs", for your server. Because I have enough resources on my dedicated servers, I wanted to give/rent VPSes for my friends for them to use for their own projects, but I wanted to give them the real VPS experience, with a real external public IP that they can connect and use.

So I figured out how to bind an external IP to your LXD container/LXD VM! Although there are several online tutorials discussing this process, none of them worked for me until I stumbled upon this semi-unrelated OVHcloud guide that helped me go in the right direction.

---

Even though I stopped using Proxmox on my dedicated servers, there were still some stateful containers that I needed to host that couldn't be hosted via Docker, such as "VPSes" that I give out to my friends for them to host their own stuff.

Enter LXD: A virtual machine and system containers manager developed by Canonical. LXD is included in all Ubuntu Server 20.04 (and newer versions), and can be easily set up by using the lxd init command. Just like how Proxmox can manage LXC containers, LXD can also manage LXC containers. Despite their similar names, LXD is not a "successor" to LXC; rather, it is a management tool for LXC containers. They do know that this is very confusing.

Keep in mind that LXD does not provide a GUI like Proxmox. If you prefer managing your containers through a GUI, you may find LXD less appealing. But for me? I rarely used Proxmox's GUI anyway and always managed my containers via the terminal.

Peter Shaw has already written an excellent tutorial on this topic, and his tutorial rocks! But I wanted to write my own tutorial with my own findings and discoveries, such as how to fix network issues after migrating the container, since that was left out from his tutorial because "it is a little beyond the scope of this article, that’s a topic for another post."

The source server is running Proxmox 7.1-12, the target server is running Ubuntu Server 22.04. The LXC container we plan to migrate is running Ubuntu 22.04.

---