Lxd Development Teams

Research Date: 2026-02-18
Topic: Using LXD for development team infrastructure

Executive Summary

This research evaluates using LXD (Linux Container Daemon) to provide isolated development environments for development teams. The analysis covers container configuration, Docker-in-LXD support, VS Code Remote SSH access, Ansible automation, and migration capabilities.

Findings

1. LXD Container Nesting for Docker Support

Finding: Docker can run inside unprivileged LXD containers using security.nesting=true without requiring privileged mode ¹².

Verification: Canonical’s LXD documentation and community discussions confirm that security.nesting=true enables container nesting for unprivileged containers. Additional configuration options like security.syscalls.intercept.mknod=true and security.syscalls.intercept.setxattr=true may be required for full Docker functionality ²³.

Implication: Development teams can run Docker and devcontainers inside LXD containers while maintaining security through unprivileged operation.

2. Docker Storage Driver Requirements in LXD

Finding: The vfs storage driver is not strictly required for Docker-in-LXD; fuse-overlayfs and modern kernel overlay2 support provide alternatives ⁴⁵⁶.

Verification:

• Docker’s official documentation states vfs is “intended for testing purposes” with “poor performance” and “not generally recommended for production use” ⁴.
• fuse-overlayfs enables overlay filesystem in userspace without root permissions, suitable for unprivileged containers ⁵⁶.
• Modern kernels (5.11+) support overlay2 in rootless mode, and recent LXC/LXD versions with ZFS backing can use overlay2 directly ⁶⁷.

Implication: The blanket recommendation to use vfs is outdated. Teams should prefer fuse-overlayfs or native overlay2 when available for significantly better performance.

3. Live Migration Capabilities

Finding: Live migration (zero-downtime migration) is supported for LXD virtual machines but requires stopping containers before migration ⁸⁹¹⁰.

Verification:

• Official LXD documentation: “When migrating a container, you must stop it first. When migrating a virtual machine, you must either enable Live migration or stop it first” ⁸.
• VM live migration requires migration.stateful=true and sufficient size.state allocation ⁸.
• Experimental CRIU-based container live migration exists but requires privileged containers and has significant limitations ⁹¹⁰.

Implication: Development teams requiring migration without downtime must use LXD virtual machines, not containers.

4. SSH Access Methods

Finding: LXD supports multiple SSH access patterns: proxy devices for port forwarding and bridged networking for direct IP access ¹¹¹².

Verification:

• Proxy devices (proxy device type) forward host ports to container ports ¹¹.
• Bridged networking attaches containers directly to physical networks, allowing DHCP-assigned IPs ¹².
• Default lxdbr0 is IPv6 link-local only and requires configuration for SSH access ¹¹.

Implication: Proxy devices are simpler for multi-developer scenarios where each container needs unique SSH ports; bridged networking suits environments requiring direct LAN access.

5. Ansible LXD Module Support

Finding: Ansible provides official community.general.lxd_container module for LXD container management ¹³.

Verification:

• The module supports creating, starting, stopping, and deleting containers and VMs ¹³.
• Configuration options include security.nesting, resource limits, and device attachments ¹³.
• The module requires community.general collection installation ¹³.

Implication: Infrastructure-as-code automation for LXD development environments is well-supported through standard Ansible tooling.

6. Security Considerations

Finding: Unprivileged LXD containers provide strong isolation while supporting nested containers through security.nesting ¹¹⁴.

Verification:

• Canonical recommends unprivileged containers for security, with security.nesting=true for Docker support ¹.
• Privileged containers bypass security controls and should be avoided ¹⁴.
• Resource limits (limits.memory, limits.cpu, limits.disk) prevent resource exhaustion ¹⁵.

Implication: Development environments should use unprivileged containers with appropriate nesting and resource limits.

Recommendations

References

Configuration Examples

The following configuration examples are derived from official documentation and verified sources. They demonstrate practical implementation of the findings above.

Example 1: Creating Developer Containers with Nesting

Create an unprivileged container with nesting enabled for Docker support ¹¹⁵:

1
2
3
4
5
6
7
8

# Create container with nesting enabled
lxc launch ubuntu:24.04 dev-1 \
  -c security.nesting=true \
  -c limits.memory=8GB \
  -c limits.cpu=4

# Alternative: specify configuration at launch
lxc launch ubuntu:24.04 dev-1 --config=user.user-data="$(cat cloud-init.yaml)"

Verified: The -c flag sets configuration options at launch time. security.nesting=true enables nested containers for Docker support ¹¹⁵.

Example 2: Resource Limits Configuration

Configure resource limits for development containers ¹⁵:

1
2
3
4
5
6
7

# Set memory and CPU limits
lxc config set dev-1 limits.memory 8GB
lxc config set dev-1 limits.cpu 4
lxc config set dev-1 limits.disk 100GB

# View current configuration
lxc config show dev-1

Verified: Resource limits prevent container resource exhaustion. Options include limits.memory, limits.cpu, limits.disk, and limits.processes ¹⁵.

Example 3: SSH Access via Proxy Device

Forward host port 2222 to container port 22 for SSH access ¹¹¹⁶:

1
2
3
4

# Add proxy device for SSH forwarding
lxc config device add dev-1 ssh-proxy proxy \
  listen=tcp:0.0.0.0:2222 \
  connect=tcp:127.0.0.1:22

Verified: Proxy devices forward traffic from host listeners to container endpoints. The listen address is on the host, connect address is inside the container ¹¹¹⁶.

Example 4: Running Commands in Containers

Execute commands inside containers using lxc exec ¹⁷:

1
2
3
4
5
6
7
8

# Run single command
lxc exec dev-1 -- apt update

# Get interactive shell
lxc exec dev-1 -- bash

# Run command as specific user
lxc exec dev-1 -- su - developer -c "whoami"

Verified: lxc exec executes commands directly in the instance. For interactive sessions, both stdin and stdout must be terminals ¹⁷.

Example 5: Ansible LXD Container Creation

Create and manage containers with Ansible ¹³¹⁸:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

- name: Create developer container
  community.general.lxd_container:
    name: dev-1
    state: started
    source:
      type: image
      mode: pull
      alias: "24.04"
    config:
      security.nesting: "true"
      limits.memory: "8GB"
      limits.cpu: "4"
    devices:
      root:
        path: /
        pool: default
        size: 100GB
        type: disk

Verified: The community.general.lxd_container module supports full container lifecycle management. Configuration options match LXD CLI options ¹³¹⁸.

Reference URLs

Revision History

Research completed: 2026-02-18
Repository: https://git.home.luguber.info/claw/research
Issue: https://git.home.luguber.info/claw/research/issues/4