VPS에서 Incus 시스템 컨테이너 설정 및 운영 가이드

Incus 시스템 컨테이너란 무엇인가

VPS에서 사용하는 Incus 시스템 컨테이너는 단순히 파일 시스템이 연결된 단일 프로세스가 아니라, 고유한 init 시스템과 사용자 계정을 갖춘 완전한 머신을 제공합니다. 컨테이너는 부팅 시 PID 1로 init을 실행하며 systemctl에 응답합니다. 호스트의 커널을 공유하므로 가상 머신(VM)과는 다릅니다. 하지만 커널 상위의 모든 동작은 가상 머신과 동일하게 작동합니다.

Incus는 Linux Containers 프로젝트 산하에서 관리되는 LXD의 커뮤니티 포크입니다. 클라이언트 명령어는 incus입니다. --vm 옵션을 전달하면 QEMU를 통해 실제 가상 머신을 실행할 수도 있지만, 대부분의 사용자가 Incus를 설치하는 주된 이유는 시스템 컨테이너 때문이며, 이 가이드의 나머지 부분도 이를 다룹니다.

Docker 비교가 오해를 불러일으키는 이유

Docker는 하나의 프로세스를 패키징합니다. Incus는 하나의 운영 체제를 패키징합니다. Incus 문서에서는 이 차이를 다음과 같이 명확히 설명합니다. "애플리케이션 컨테이너(예: Docker)는 단일 프로세스나 애플리케이션을 패키징합니다. 반면 시스템 컨테이너는 호스트나 가상 머신에서 실행하는 것과 유사한 전체 운영 체제를 시뮬레이션합니다."

이러한 차이는 매일 해당 도구를 사용하는 방식에 영향을 미칩니다.

• Docker 이미지에는 init 시스템이 없으므로 내부에서 systemctl를 실행하면 실패합니다. Incus 컨테이너는 init 시스템을 실행하므로 서버에서와 동일하게 서비스와 타이머가 작동합니다.
• Docker 컨테이너는 Dockerfile을 통해 파괴하고 다시 빌드하도록 설계되었습니다. Incus 컨테이너는 유지 관리하고 패치하며 스냅샷을 생성하도록 설계되었습니다.
• Docker 이미지는 레지스트리로 푸시하는 빌드 결과물입니다. Incus 인스턴스는 스토리지 풀의 디스크 상태이며, incus export을 사용하여 이동합니다.
• Docker는 워크로드를 격리합니다. Incus는 머신을 격리하므로 하나의 컨테이너 안에 여러 워크로드와 여러 사용자 계정을 담을 수 있습니다.

Incus 시스템 컨테이너 내부에서 Docker를 실행할 수는 있습니다. 하지만 Docker 애플리케이션 컨테이너 내부에서 Incus를 실행하지는 않습니다. 컨테이너당 하나의 프로세스를 실행하고 이미지 빌드 단계를 거치는 방식을 원한다면, 먼저 VPS에서의 Podman 및 Docker 비교 문서를 읽어보시기 바랍니다. 공유 커널 대신 워크로드별로 별도의 커널을 원한다면, 반대 방향의 기술인 VPS에서의 Firecracker microVM을 확인하십시오.

Incus를 VPS 내부에서 실행할 수 있습니까?

VPS의 가상화 유형과 커널에 따라 다르므로 설치 전에 두 가지를 모두 확인해야 합니다. 제공업체의 마케팅 페이지 내용을 그대로 믿지 마십시오. 서버에서 다음 네 가지 명령을 실행하십시오.

systemd-detect-virt
uname -r
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers

systemd-detect-virt 명령이 kvm 또는 qemu을 출력한다면, 해당 VPS는 자체 커널을 사용하는 가상 머신입니다. 이 경우 Incus가 하드웨어에서와 동일하게 동작하므로 설정이 간단합니다. lxc, lxc-libvirt 또는 openvz가 출력된다면, 해당 VPS는 제공업체의 커널을 공유하는 컨테이너입니다. 그 내부에서 실행되는 Incus 컨테이너는 중첩(nested) 컨테이너가 되며, 이는 제공업체가 해당 기능을 활성화한 경우에만 작동합니다. 설정이 사용자가 제어할 수 없는 호스트에 있으므로 내부에서 직접 활성화할 수 없습니다.

stat -fc %T /sys/fs/cgroup 명령은 cgroup2fs을 출력해야 합니다. 다른 결과가 나온다면 해당 서버는 cgroup(control group) v1 또는 하이브리드 레이아웃을 사용 중인 것이며, 이는 현재 Incus가 지원하지 않는 환경입니다.

cat /sys/fs/cgroup/cgroup.controllers 명령은 사용자에게 위임된 제어 그룹 컨트롤러 목록을 보여줍니다. Incus 문서에서는 blkio, cpuset, devices, freezer, memory 및 pids이 필수라고 명시합니다. 중첩된 VPS에서는 제공업체가 제한적으로 권한을 부여하기 때문에 KVM 기반 VPS보다 이 목록이 짧은 경우가 많습니다. 해당 파일에 없는 컨트롤러는 Incus가 사용할 수 없으며, 따라서 해당 컨트롤러에 의존하는 인스턴스 제한 기능도 사용할 수 없습니다.

커널 버전은 과거보다 더 중요해졌습니다. 2026년 8월 기준으로 Incus 문서는 업스트림에서 유지 관리하는 두 가지 브랜치에 대해 서로 다른 최소 요구 사항을 제시합니다. 6.0 LTS(장기 지원) 브랜치는 "최소 지원 커널 버전은 5.4입니다"라고 명시합니다. 현재 안정화 브랜치는 "최소 지원 커널 버전은 6.12입니다"라고 명시합니다. Ubuntu 24.04는 자체 저장소에 6.0 LTS 시리즈를 패키징하여 6.8 커널과 함께 제공하며, 이는 지원되는 조합입니다. 업스트림 저장소에서 현재 안정화 빌드를 설치하여 동일한 6.8 커널에서 실행하면 문서화된 최소 요구 사항 미만이 되므로, 저장소를 선택하기 전에 uname -r를 읽어보십시오.

컨테이너가 아닌 전체 가상 머신을 실행하는 것이 목표라면 제약 조건이 다르며 더 까다롭습니다. VPS가 /dev/kvm을 노출할 수 있는지 여부는 VPS에서의 중첩 가상화를 참조하고, 하드웨어를 직접 소유한 경우라면 임대 VPS에서의 Proxmox 사용을 참조하십시오.

Ubuntu 또는 Debian에 Incus 설치하기

Debian 13 및 Ubuntu 24.04 이상 버전은 자체 저장소에서 Incus를 제공합니다.

sudo apt update
sudo apt install -y incus

Debian에서는 incus-base 명령으로 가상 머신 기능을 제외한 컨테이너 지원만 설치할 수 있습니다. Ubuntu에서는 --vm 인스턴스도 사용하려면 qemu-system를 추가하십시오.

배포판이 제공하는 버전보다 최신 릴리스가 필요한 경우, 업스트림 패키지는 pkgs.zabbly.com에서 제공합니다. 아래 명령은 프로젝트 공식 저장소의 README를 따릅니다.

sudo apt update && sudo apt install -y curl
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
sudo apt-get update
sudo apt-get install -y incus

그런 다음 사용자에게 데몬 소켓에 대한 접근 권한을 부여하십시오.

sudo usermod -aG incus-admin "$USER"
newgrp incus-admin
incus info

incus info 명령으로 서버 설정을 출력할 수 있다면 소켓이 정상적으로 작동하는 것입니다. 권한 오류가 발생한다면 그룹 변경 사항이 현재 셸에 적용되지 않은 것이며, newgrp incus-admin 명령으로 현재 셸에 즉시 적용하거나 새로 로그인하여 해결할 수 있습니다. incus-admin 그룹 멤버십은 호스트의 root 권한과 동일하게 취급해야 합니다. 해당 소켓에 접근하면 root 권한으로 실행되는 데몬을 완전히 제어할 수 있기 때문입니다. 일부 배포판은 제한된 사용자 접근을 위해 별도의 incus 그룹을 생성하기도 합니다.

이제 데몬을 초기화하십시오.

sudo incus admin init

incus admin init --minimal를 사용하기보다 질문에 직접 답변하십시오. 최소 설치 경로를 선택하면 dir 스토리지 드라이버가 설정되며, 다음 섹션에서 이 선택이 미치는 영향에 대해 다룹니다.

컨테이너를 실행하여 정상 작동하는지 확인하십시오.

incus launch images:debian/13 web
incus list
incus exec web -- bash

incus list 명령을 실행하면 incusbr0 서브넷의 IPv4 주소를 가진 RUNNING 상태의 web가 표시되어야 합니다. 주소가 할당되지 않았다면 DHCP(Dynamic Host Configuration Protocol)가 완료되지 않은 것이며, 이는 네트워킹 섹션에서 다룹니다. 시작에 실패한 컨테이너는 incus info web --show-log에 실패 원인을 출력하며, 데몬 수준의 오류는 sudo journalctl -u incus -n 50에 기록됩니다. systemd-detect-virt 명령의 결과가 lxc 또는 openvz인 VPS 환경에서는, 이 실행 테스트를 통해 중첩 가상화(nesting) 사용 가능 여부를 확실히 확인할 수 있습니다.

기본 스토리지 백엔드가 중요한 이유

스토리지 백엔드는 스냅샷을 즉시 생성할지, 아니면 컨테이너 디스크 전체를 복사할지를 결정합니다. 이는 설치 시점에 선택해야 하며, 나중에 변경하려면 큰 비용이 드는 유일한 설정입니다.

Incus는 dir, btrfs, lvm, zfs, Ceph 및 여러 원격 드라이버를 지원합니다. 단일 디스크 VPS 환경에서 실질적인 선택지는 dir와 btrfs 사이입니다.

dir 드라이버는 각 컨테이너를 /var/lib/incus 하위의 일반 파일과 디렉터리로 유지합니다. Incus는 이 드라이버가 공유 블록을 참조하는 대신 모든 이미지를 압축 해제하고 실제로 복사해야 하므로 "다른 모든 드라이버보다 훨씬 느리다"고 명시합니다. 4 GiB 컨테이너의 스냅샷을 생성하면 4 GiB를 기록해야 하며 cp -a만큼의 시간이 소요됩니다. 디스크 할당량(quota)은 파일 시스템 수준에서 프로젝트 할당량이 활성화된 ext4 또는 XFS에서만 작동하는데, 대부분의 VPS 이미지에서는 기본적으로 활성화되어 있지 않으므로 dir 풀의 디스크 제한은 종종 아무런 효과가 없습니다.

btrfs 및 zfs은 쓰기 시 복사(copy-on-write) 방식을 사용하므로, 스냅샷은 생성 이후 변경된 블록만 기록합니다. Incus는 이 두 가지를 권장 백엔드로 지정합니다. 스냅샷은 거의 즉시 생성됩니다. 디스크 할당량은 파일 시스템 자체의 할당량 지원 기능을 통해 작동합니다.

대부분의 VPS 플랜은 여유 파티션이 없는 단일 디스크를 제공하므로, 풀을 루프 파일(loop file)에 배치해야 합니다. source=를 지정하지 않으면 Incus가 이를 자동으로 처리합니다.

sudo apt install -y btrfs-progs
incus storage create fast btrfs size=30GiB
incus profile device set default root pool=fast
incus launch images:debian/13 web2 -s fast

size=이 없으면 루프 기반 풀은 여유 디스크 공간의 20%를 차지하며, 최소 5 GiB에서 최대 30 GiB로 제한됩니다. 이 값을 의도적으로 설정하십시오. 루프 파일은 루트 파일 시스템상의 파일이므로, 풀과 호스트는 동일한 여유 공간을 공유합니다. 즉, 풀이 가득 차면 호스트의 디스크도 가득 차게 됩니다.

Debian 및 Ubuntu에서 ZFS는 커널 내장 모듈이 아닌 DKMS 모듈로 제공되므로, 커널이 업그레이드될 때마다 다시 빌드되며 빌드 과정에서 실패할 수 있습니다. 매일 관리하기 어려운 서버라면, 두 가지 중 유지보수 부담이 적은 btrfs를 선택하는 것이 좋습니다.

세 가지 네트워킹 모드와 각 모드의 노출 범위

incus admin init는 incusbr0라는 관리형 브리지를 생성하고 모든 새 인스턴스를 이 브리지에 연결합니다. 이는 컨테이너를 연결하는 세 가지 방법 중 하나이며, 나머지 두 가지 방법은 첫 번째 방법이 컨테이너를 NAT(네트워크 주소 변환) 뒤에 숨기기 때문에 존재합니다.

관리형 브리지(Managed bridge). incusbr0은 사설 서브넷을 할당받습니다. 호스트는 해당 서브넷의 첫 번째 주소를 점유하여 게이트웨이 역할을 수행하며, Incus는 그 위에서 DHCP와 DNS(도메인 네임 시스템)를 실행합니다. 아웃바운드 트래픽은 소스 NAT가 적용된 상태로 호스트의 공인 주소를 통해 나갑니다. 사용자가 별도로 설정하지 않는 한 외부에서 컨테이너로 접근할 수 없습니다. 포트를 전달하려면 프록시 장치를 사용하십시오.

incus config device add web http proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80 nat=true

nat=true은 별도의 사용자 공간 연결을 거치는 프록시 방식 대신 netfilter 규칙을 사용하여 전달하므로, 클라이언트의 실제 주소가 컨테이너 로그에 그대로 남습니다. Incus는 호스트가 인스턴스의 게이트웨이인 경우에만 이 모드를 지원하며, 이는 정확히 incusbr0의 경우에 해당합니다.

macvlan. 컨테이너는 호스트의 물리적 네트워크에서 고유한 MAC(미디어 접근 제어) 주소를 할당받습니다. 대부분의 VPS 플랫폼에서는 가상 스위치 포트가 VM의 MAC 주소에 고정되어 있어 다른 MAC 주소에서 오는 프레임을 차단하므로 이 방식이 실패합니다. 작동하는 환경에서도 주의해야 할 두 번째 제한 사항이 있습니다. Incus 문서에 따르면 "macvlan 장치는 상호 간이나 외부와는 통신할 수 있지만, 부모 장치와는 통신할 수 없습니다." 즉, 인스턴스가 호스트와 직접 통신해야 하는 경우에는 macvlan을 사용할 수 없습니다.

라우팅(Routed). 이 모드는 일반적으로 추가 주소를 제공하는 VPS에서 작동합니다. Incus 문서에 따르면 이 장치는 "호스트와 인스턴스를 연결하는 가상 장치 쌍을 생성하고, 정적 경로와 프록시 ARP/NDP 항목을 설정하여 인스턴스가 지정된 부모 인터페이스의 네트워크에 참여할 수 있도록 합니다." ARP는 주소 결정 프로토콜입니다. 컨테이너는 공인 주소를 유지합니다. 호스트가 컨테이너를 대신해 ARP 응답을 수행하므로, 서비스 제공자는 호스트의 MAC 주소만 인식하게 됩니다.

incus config device add web eth0 nic nictype=routed parent=enp1s0 ipv4.address=203.0.113.20

ip route show default에서 부모 인터페이스 이름을 확인하십시오. 최신 이미지는 enp1s0이나 ens3과 같은 이름을 사용하며, eth0는 거의 사용하지 않습니다. 장치 이름을 eth0으로 지정하면 default 프로필에서 제공하는 설정을 덮어쓰게 되어, 컨테이너가 브리지가 아닌 라우팅 인터페이스에 연결됩니다. 내부에서 ip a 및 ip route 명령을 사용하여 결과를 확인하십시오.

컨테이너가 호스트의 서비스에 도달하는 이유

incusbr0 위의 컨테이너는 고유한 네트워크 네임스페이스를 가집니다. 컨테이너에는 호스트를 향한 방화벽 경계가 존재하지 않습니다. 호스트는 게이트웨이 주소에서 해당 브리지에 위치하므로, 컨테이너 내부에서 호스트는 직접 연결 가능한 이웃이며 0.0.0.0에 바인딩된 모든 호스트 서비스는 해당 주소에서 응답합니다.

직접 확인해 보십시오. 호스트에서 리스닝 중인 항목을 나열합니다.

sudo ss -tlnp

그런 다음, 컨테이너 내부에서 ip route가 보고하는 게이트웨이를 대상으로 확인합니다.

ip route show default
nc -zv 10.0.0.1 6379

호스트의 데이터베이스, 메트릭 엔드포인트 또는 관리자 패널이 0.0.0.0에 바인딩되어 있다면 해당 확인은 성공합니다. 패킷이 머신을 떠나지 않았으므로 공급자의 네트워크 방화벽은 해당 패킷을 전혀 볼 수 없습니다. 이것이 "어떻게 도달했는가"라는 질문의 대부분을 차지하는 의외의 사실입니다. 컨테이너는 NAT에 의해 인터넷으로부터 격리되어 있지만, 호스트로부터는 아무것도 격리되어 있지 않습니다.

가능한 한 호스트 서비스를 127.0.0.1에 바인딩하십시오. 그런 다음 호스트에서 브리지를 필터링하십시오. ufw를 사용하는 환경에서 기본 거부(deny) 정책은 이미 컨테이너에서 호스트로 향하는 트래픽을 차단하며, 이는 Incus DNS 및 DHCP를 중단시킵니다. Incus 문서에서 제시하는 해결책은 sudo ufw allow in on incusbr0입니다. 이 단일 명령은 모든 호스트 포트를 모든 컨테이너에 다시 개방합니다. 대신 컨테이너가 실제로 필요한 것만 허용하십시오.

sudo ufw allow in on incusbr0 to any port 53 proto udp
sudo ufw allow in on incusbr0 to any port 53 proto tcp
sudo ufw allow in on incusbr0 to any port 67 proto udp
sudo ufw route allow in on incusbr0
sudo ufw route allow out on incusbr0

두 개의 ufw route 규칙은 인스턴스 트래픽이 호스트를 거쳐 인터넷으로 통과하도록 허용하는 설정입니다. 이 규칙이 없으면 ufw의 라우팅 정책이 포워딩된 패킷을 드롭하므로, 컨테이너는 주소를 할당받아도 아무 곳에도 도달할 수 없습니다.

스냅샷과 프로필

스냅샷은 스토리지 풀 내 인스턴스의 특정 시점 복사본입니다.

incus snapshot create web pre-upgrade
incus info web
incus snapshot restore web pre-upgrade
incus snapshot delete web pre-upgrade

incus info web는 해당 인스턴스가 보유한 스냅샷 목록을 보여줍니다. 스냅샷은 인스턴스별로 일정을 설정할 수 있습니다.

incus config set web snapshots.schedule=@daily
incus config set web snapshots.expiry=4w

스냅샷은 동일한 서버, 동일한 디스크, 동일한 풀 내에 존재합니다. 스냅샷은 잘못된 업그레이드로부터 인스턴스를 보호합니다. 하지만 디스크 고장이나 인스턴스 삭제로부터는 보호하지 못합니다. 백업은 incus export를 사용해야 하며, 백업 파일은 반드시 서버 외부로 전송되어야 합니다.

incus export web /root/web-backup.tar.gz
incus import /root/web-backup.tar.gz

프로필은 인스턴스에 적용되는 설정 키와 장치들의 이름 붙은 집합입니다. 별도로 지정하지 않으면 모든 인스턴스는 default 프로필을 할당받으며, 이 프로필을 통해 루트 디스크와 네트워크 인터페이스가 제공됩니다. default을 수정하면 해당 프로필을 사용하는 모든 인스턴스에 변경 사항이 적용됩니다. 이는 유용한 기능이며, 한 번에 20개의 컨테이너에서 네트워크를 분리하는 등의 작업에 사용됩니다.

incus profile create small
incus profile set small limits.memory=512MiB
incus profile set small limits.cpu=1
incus launch images:debian/13 api -p default -p small

프로필은 나열된 순서대로 적용되므로, 마지막에 나열된 프로필에 설정된 키가 우선합니다. 인스턴스에 최종적으로 적용된 설정은 incus config show api --expanded을 사용하여 확인할 수 있습니다.

Incus 컨테이너 내부에서 Docker 실행하기

Incus 시스템 컨테이너 내부에서 Docker를 실행하려면 nesting 기능을 활성화해야 합니다. Docker는 기본적으로 컨테이너가 생성할 수 없는 자체 네임스페이스와 마운트를 생성하기 때문입니다.

incus config set web security.nesting=true
incus restart web

Incus 문서는 security.nesting를 "인스턴스 내부의 중첩(nesting) 허용 여부"로 정의하며, 컨테이너의 기본값은 false입니다. Incus FAQ에서 다루는 두 가지 추가 사항이 더 있습니다. 컨테이너는 커널 모듈을 로드할 수 없으므로, Docker에 필요한 모듈은 호스트에서 로드되어야 하며 incus config set web linux.kernel_modules overlay,br_netfilter에 나열되어야 합니다. 또한 컨테이너 내부에 /.dockerenv 파일을 생성하면 중첩 환경에서 실패하는 일부 Docker 검사를 건너뛸 수 있습니다.

Ubuntu 24.04 호스트에서는 AppArmor의 비권한 사용자 네임스페이스 제한이 runc가 수행하는 pivot_root을 차단할 수 있습니다. 컨테이너 내부의 Docker는 다음과 같은 메시지를 출력합니다.

failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error jailing process inside rootfs: pivot_root .: permission denied

그리고 호스트의 dmesg에는 apparmor="DENIED" operation="pivotroot" class="mount"을 포함하는 줄이 나타납니다. 사람들이 흔히 사용하는 설정은 kernel.apparmor_restrict_unprivileged_userns입니다. 하지만 이를 끄는 것은 신뢰할 수 있는 해결책이 아닙니다. 이 거부 현상에 대한 업스트림 Incus 버그 리포트에 따르면, 해당 값을 0로 설정해도 문제가 해결되지 않았습니다. 보안 기본값을 변경하기 전에 먼저 dmesg를 읽어보고 AppArmor가 실제로 문제의 원인인지 확인하십시오.

계층을 하나 줄이고 VPS에서 직접 컨테이너를 실행하고 싶다면, VPS에서 Docker 실행하기에서 해당 설정을 다룹니다.

실패 유형 및 확인되는 메시지

호스트에 Docker를 설치한 후 인스턴스의 네트워크가 모두 끊깁니다. Incus 문서에서는 그 원인을 다음과 같이 설명합니다. "Docker가 전역 FORWARD 정책을 drop으로 설정하면 Incus가 트래픽을 전달하지 못하게 되어 인스턴스의 네트워크 연결이 끊깁니다." 인스턴스는 IP 주소를 유지하지만 외부와 통신할 수 없습니다. /etc/docker/daemon.json에서 ip-forward-no-drop을 true로 설정한 다음, 포워딩을 영구적으로 적용하고 Docker의 자체 체인을 통해 브리지를 허용하십시오.

echo "net.ipv4.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo systemctl restart systemd-sysctl
sudo iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
sudo iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

이러한 iptables 규칙은 재부팅 시 유지되지 않습니다. 영구적으로 설정하십시오.

cgroup 오류로 인해 컨테이너가 시작되지 않습니다. Incus FAQ에 이 문제가 기록되어 있습니다. Failed to mount "/sys/fs/cgroup" 관련 메시지는 보통 호스트의 VPN 클라이언트가 Incus가 사용하는 cgroup v2 위에 net_cls cgroup v1 컨트롤러를 마운트했음을 의미합니다. sudo umount /sys/fs/cgroup/net_cls을 실행하면 해결됩니다.

인스턴스가 IPv4 주소를 할당받지 못합니다. incus list을 실행하면 주소 열이 비어 있는 상태로 실행 중인 것을 확인할 수 있습니다. 호스트에서 오는 DHCP 응답이 차단되는 경우이며, 대부분 브리지에 대해 알지 못하는 호스트 방화벽이 원인입니다. ufw를 사용하는 경우 sudo ufw allow in on incusbr0 to any port 67 proto udp를 실행하면 복구됩니다. sudo tcpdump -ni incusbr0 port 67을 사용하여 요청이 도달하는지 확인하십시오.

중첩된 VPS에서 인스턴스가 시작되지 않습니다. 먼저 incus info <name> --show-log을 읽고 sudo journalctl -u incus -n 50를 확인하십시오. systemd-detect-virt의 결과가 lxc 또는 openvz라면, 누락된 기능은 제공자 측의 문제이므로 VPS 내부 설정으로는 해결할 수 없습니다.

스냅샷 속도가 느리고 디스크 용량이 계속 꽉 찹니다. dir 풀을 사용 중입니다. incus storage list을 실행하면 각 풀의 드라이버를 확인할 수 있습니다. Copy-on-write 풀로 전환하려면 새 풀을 생성하고, incus copy web web-new -s fast을 사용하여 인스턴스를 복사한 뒤, 복사본이 정상적으로 시작되는지 확인하고 원본을 삭제하십시오.

FAQ

Incus 컨테이너는 Docker 컨테이너와 동일합니까?

아니요. Docker는 단일 프로세스나 애플리케이션을 패키징합니다. 반면 Incus 시스템 컨테이너는 자체 init, 사용자, 서비스, 패키지 관리자를 갖춘 완전한 운영 체제를 시뮬레이션합니다. Incus 컨테이너는 서버처럼 유지 관리하고 패치를 적용하지만, Docker 컨테이너는 폐기하고 이미지로부터 다시 빌드합니다. 컨테이너에 security.nesting=true를 설정하면 Incus 컨테이너 내부에서 Docker를 실행할 수 있습니다. 반대의 경우는 불가능합니다.

VPS에서 Incus를 실행할 수 있습니까?

KVM 기반 VPS라면 가능합니다. systemd-detect-virt 명령이 kvm 또는 qemu를 출력한다면, 자체 커널을 사용 중이므로 Incus가 하드웨어에서와 동일하게 동작합니다. 만약 lxc, lxc-libvirt 또는 openvz가 출력된다면 해당 VPS 자체가 컨테이너이므로, 그 안의 Incus 컨테이너는 중첩(nested)된 상태가 됩니다. 이는 제공업체가 컨테이너의 중첩 기능을 활성화한 경우에만 작동합니다. 2026년 8월 기준으로 현재 Incus 안정화 브랜치는 최소 커널 6.12를 요구하고 6.0 LTS 브랜치는 5.4를 요구하므로 uname -r도 확인해야 합니다.

VPS용 Incus 스토리지 백엔드로 무엇을 선택해야 합니까?

별도의 블록 장치를 사용할 수 없는 상황이라면 루프 파일 기반의 btrfs을 선택하십시오. dir 드라이버는 copy-on-write 대신 파일을 복사하는 방식을 사용하여 스냅샷을 생성할 때마다 컨테이너 전체를 다시 쓰기 때문에 다른 드라이버보다 훨씬 느립니다. incus admin init --minimal는 자동으로 dir을 선택하므로, 초기 설정 시 대화형 질문에 2분 정도 시간을 투자하는 것이 좋습니다. incus storage create fast btrfs size=30GiB 명령으로 풀을 생성하십시오.

Incus 컨테이너가 호스트에서 실행 중인 서비스에 접근할 수 있는 이유는 무엇입니까?

기본 incusbr0 브리지는 호스트를 컨테이너와 동일한 서브넷의 게이트웨이 주소에 배치하며, 이들 사이에 아무런 필터링이 없기 때문입니다. 0.0.0.0에 바인딩된 모든 호스트 서비스는 해당 주소로 응답하며, 패킷이 머신 외부로 나가지 않으므로 제공업체의 방화벽은 이를 감지하지 못합니다. 호스트 서비스는 127.0.0.1에 바인딩하고, ufw를 사용하는 호스트라면 sudo ufw allow in on incusbr0처럼 전체를 허용하기보다 incusbr0에서 DNS와 DHCP만 허용하도록 설정하십시오.

Incus 컨테이너는 어떻게 백업합니까?

incus export web /root/web-backup.tar.gz은 인스턴스와 해당 스냅샷을 하나의 파일로 내보내며, incus import은 이를 동일한 서버나 다른 서버로 복원합니다. incus snapshot create로 만든 스냅샷은 백업이 아닙니다. 스냅샷은 동일한 디스크의 동일한 스토리지 풀에 저장되므로, 잘못된 업그레이드에서는 살아남을 수 있지만 서버 장애 시에는 데이터가 소실됩니다. incus config set web snapshots.schedule=@daily으로 백업을 예약하고, 내보낸 파일은 서버 외부로 복사해 두십시오.