lxc

List local containers matching a string. Omit the string to list all local containers

$ lxc list [match_string]

$ lxc image list [[remote]:][match_string]

$ lxc init [[remote]:][image] [container]

$ lxc start [[remote]:][container]

$ lxc stop [[remote]:][container]

$ lxc info [[remote]:][container]

$ lxc snapshot [[remote]:][container] [snapshot]

$ lxc exec [[remote]:][container] [command]

lxc [GLOBAL_OPTIONS] <subcommand> [SUBCOMMAND_OPTIONS] [ARGUMENTS]

Common subcommands include: launch, start, stop, delete, list, exec, file, snapshot, image, network, storage, profile, monitor, and many more, each with its own specific options and arguments.

--help
    Displays the help message for the lxc command or a specific subcommand when used with it (e.g., lxc launch --help).

--version
    Shows the LXD client version.

--verbose
    Enables verbose output, showing more details about operations.

--debug
    Enables debug output, providing extensive logging for troubleshooting.

--force-local
    Forces the operation to be performed on the local LXD daemon, overriding any default remote configuration.

--config <path>
    Specifies an alternative client configuration directory to use.

--project <name>
    Specifies the LXD project to operate within. This allows segmenting instances and resources within a single LXD daemon.

--remote <name>
    Specifies the remote LXD server to connect to. This allows managing instances on different LXD deployments.

lxc is the primary command-line client for LXD, a powerful system container and virtual machine manager. It allows users to interact with LXD servers to create, start, stop, delete, and manage Linux containers (LXC) and virtual machines. LXD aims to provide a user experience similar to traditional virtual machines but with the density and performance benefits of containers where applicable.

Through the lxc command, administrators and users can perform a wide array of operations including snapshot management, image publishing, network configuration, storage pool management, and remote server administration. It provides a consistent interface for managing instances whether they are local or on remote LXD servers, making it an essential tool for modern Linux system administration and cloud environments.

LXD Daemon Requirement: lxc is purely a client and requires a running LXD daemon (server) to operate. It cannot function standalone without a daemon to connect to.
Permissions: To interact with the LXD daemon, users typically need to be part of the 'lxd' Unix group or use sudo for privileged operations.
Networking Complexity: Configuring network bridges, NAT, and public IP assignments for containers/VMs can become complex depending on the desired setup and host network environment.
Storage Backends: The performance and features of LXD instances are highly dependent on the chosen storage backend (e.g., ZFS, Btrfs, LVM, Ceph). Improper configuration can lead to performance issues or data loss.
Updates: LXD updates might occasionally require daemon restarts or specific migration steps, especially for significant version changes or underlying database schema changes.

lxc operates on a client-server model. The lxc command is the client that communicates with the LXD daemon (lxd.socket or lxd.service) running in the background. This daemon manages all containers, virtual machines, storage, and networking. This architecture enables local and remote management of LXD servers, allowing a single lxc client to control instances across multiple physical or virtual hosts.

While LXC stands for Linux Containers, modern LXD and the lxc command provide unified management for both system containers (LXC) and full virtual machines. System containers are lightweight, share the host kernel, and are ideal for high density. Virtual machines run their own kernel, providing stronger isolation and compatibility with various operating systems. This dual capability makes lxc a highly versatile tool for different virtualization and isolation needs.

lxc provides robust image management capabilities. Users can publish instances as new images, allowing for quick replication of specific setups or creation of custom base images. It also enables pulling images from various sources (e.g., official LXD image servers like images.linuxcontainers.org, custom remote servers, or local tarballs) to launch new instances rapidly and consistently.

LXC (Linux Containers), the underlying container technology, emerged around 2008, leveraging Linux kernel features like namespaces and cgroups for process isolation.

LXD was developed by Canonical and first introduced in 2014. It was designed as a 'hypervisor' or management layer specifically for LXC containers, providing a daemonized service with a REST API, improved security, and a much more user-friendly experience compared to the raw lxc- tools. The lxc command-line tool serves as the primary client for interacting with this LXD daemon.

Over time, LXD has significantly evolved, notably adding support for full virtual machines alongside containers in 2018, making it a versatile tool for managing various types of instances from a single, unified interface.

lxc-create(1), docker(1), virsh(1), systemd-nspawn(1), chroot(1)