Software Virtualisation with LXD in Linux for Private Hosting via Cloudflare

Posted: 26/04/2026/Under: Hosting, Networking/By: mirage

Use LXD to run virtual linux images more compact than Docker and Oracle Virtualbox

In our project we will host a nextcloud service for a private dropbox like service using cloudflare tunnel (Other alternatives using ngrok etc.)

First install LXD

sudo apt install lxd lxd-client

Message during the end of LXD installation

LXD has been installed. You must run `sudo lxd init` to
perform the initial configuration of LXD.
Be sure to add user(s) to the lxd group, then have them
logout and back in to properly setup their access.

If you want to see what images are  available (like a specific architecture or a “cloud” version), use the list command:

Bash

lxc image list images: 
lxc image list images: | grep -i "debian"

The launch command both downloads the image and starts the container in one go.

Bash

lxc launch images:debian/13 my-sandbox

Breaking down the name:

  • images:: The remote server where LXD looks for templates.

  • debian/13: The distribution and version (you can also use ubuntu/22.04, alpine/3.18, etc.).

  • my-sandbox: The name you choose for your container.

Summary of Lifecycle Commands

Action Command
Start lxc start my-sandbox
Stop lxc stop my-sandbox
Restart lxc restart my-sandbox
List all lxc list
Delete lxc delete my-sandbox --force

Resource Limiting (Optional but Recommended)

Since you are likely working on a headless setup where resources matter, you can limit the container’s footprint immediately after creation:

Bash

# Limit to 512MB of RAM
lxc config set my-sandbox limits.memory 512MB

# Limit to 1 CPU core
lxc config set my-sandbox limits.cpu 1

Copying Files

To move files between your host machine and the sandbox:

# Host to Container
lxc file push ./index.html my-sandbox/var/www/html/

# Container to Host
lxc file pull my-sandbox/etc/apache2/apache2.conf ./backup-configs/

Once the container is launched, it is running “detached” in the background. Use these commands to manage it:

Execute a Command

To run a command inside the container without entering it:

Bash

lxc exec my-sandbox -- apt update

Get an Interactive Shell

This is like “SSHing” into your sandbox. You will get a root prompt inside the container:

lxc exec my-sandbox -- bash

Network Errors
i can ping from my-sandbox to google 8.8.8.8 but unable to update apt

The Quick Fix: Manually Set DNS

The fastest way to test this is to force a DNS server inside the container.

  1. Enter the container:

  2. Edit the resolv.conf file:
echo "nameserver 8.8.8.8" > /etc/resolv.conf

3. The Permanent Fix (LXD Level)

Editing /etc/resolv.conf manually is often overwritten by the system. To fix this permanently for your sandbox, you should tell the LXD bridge to provide a specific DNS server via DHCP.

Run this on your host machine:

lxc network set lxdbr0 ipv4.address 10.0.3.1/24
lxc network set lxdbr0 ipv4.nat true
lxc network set lxdbr0 dns.domain sandbox
lxc network set lxdbr0 raw.dnsmasq "dhcp-option=6,8.8.8.8,8.8.4.4"

Note: Replace lxdbr0 if you named your bridge something else during lxd init.

Backing up an LXD container

Backing up an LXD container is straightforward, and you have a few different ways to do it depending on whether you want a quick snapshot, a portable tarball file, or a full clone.

Here is a breakdown of the three best methods to back up your LXD containers.

Method 1: Create an Exported Backup File (Best for Disaster Recovery)

This method compresses the container into a single .tar.gz file that you can download, move to an external drive, or restore on a completely different server.

  1. Stop the container (Optional, but highly recommended to ensure data consistency):

    Bash

    lxc stop my-container

  2. Export the container to a backup file:

Bash

   lxc export my-container /path/to/backups/my-container-backup.tar.gz

  1. Restart your container (if you stopped it):

    Bash

    lxc start my-container

💡 How to Restore: If your server crashes, you can restore this exact container using:

lxc import /path/to/backups/my-container-backup.tar.gz

Method 2: Take a Snapshot (Best for Quick, Local Backups)

Snapshots are perfect right before you make a risky change (like a major software update). They are instant and stored locally inside LXD.

  1. Take a snapshot:

    Bash

    lxc snapshot my-container snapshot-name

    (If you don’t provide a name, LXD will automatically name it snap0, snap1, etc.)

  2. View your snapshots to confirm it worked:

Bash

   lxc info my-container

💡 How to Restore: If the update breaks your container, roll it back instantly using:

lxc restore my-container snapshot-name

Method 3: Publish as a Custom Image (Best for Templating)

If you’ve configured a container perfectly and want to use it as a base template to spin up new containers, turn it into an image.

  1. Stop the container:

Bash

   lxc stop my-container

  1. Publish it to your local image store:

Bash

   lxc publish my-container --alias my-custom-template

💡 How to Restore/Launch: You can now spin up brand new, identical containers using your template:

lxc launch my-custom-template new-container

Summary: Which one should you use?

Method Best Used For Portability Command
Export Off-site backups, server migrations 🟢 High (Creates a file) lxc export
Snapshot Quick safety nets before updates 🔴 Low (Stored inside LXD) lxc snapshot
Publish Creating reusable blueprints/templates 🟡 Medium (Local image store) lxc publish

 

 

Copying and Moving Detailed explanation:

https://share.google/aimode/B5ZxFXZTenHsoYu0N
facebookShare on Facebook
TwitterTweet
FollowFollow us
PinterestSave

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Comments