KVM, Xen, LXC 차이점: 내 VPS 가상화 방식 확인하기

VPS 플랜이 실제로 판매하는 것

KVM, Xen, LXC는 VPS 플랜을 구성하는 3가지 가상화 계열이며, 이 선택은 제공업체의 랙 구성에 관한 사소한 세부 사항이 아닙니다. 이는 사용자가 자신의 커널을 직접 제어할 수 있는지 여부를 결정합니다. 구매자가 관심을 두는 모든 사항은 이 단 하나의 사실에서 비롯됩니다. 커널 모듈 로드, 스왑 제어, 중첩 가상화 실행, /proc가 자신의 서버를 설명하는지 아니면 타인의 서버를 설명하는지, 그리고 steal time을 측정할 수 있는지 여부가 모두 여기에 달려 있습니다.

전가상화(KVM 및 Xen HVM)는 모든 테넌트에게 커널과 가상 머신을 제공합니다. 반가상화(Paravirtualised) Xen 역시 커널을 제공하지만, 이 커널은 자신이 게스트임을 인지하고 하이퍼바이저에 특권 작업을 요청합니다. 컨테이너 플랜(LXC 또는 OpenVZ 및 Virtuozzo 계열)은 제공업체의 커널 위에서 파일 시스템과 네임스페이스 집합을 제공합니다. 이 세 가지 방식 모두 동일한 세 글자(VPS)라는 이름으로 판매됩니다.

KVM 대 Xen 대 LXC: 커널을 각각 사용하는가, 공유하는가

KVM과 Xen에서는 uname -r이 커널을 지정합니다. 사용자는 다른 커널을 설치하거나 모듈을 로드하고, 해당 커널로 재부팅할 수 있습니다. 이 과정에서 수행하는 어떤 작업도 다른 테넌트에게 영향을 주지 않습니다. 컨테이너 플랜에서는 uname -r이 호스트에서 실행 중인 제공자의 커널을 지정하며, 이는 해당 머신의 모든 컨테이너와 공유됩니다. 사용자는 이를 변경할 수 없으며, apt install linux-image-generic는 부팅되지 않는 파일들을 압축 해제할 뿐입니다.

이 단 하나의 차이점은 어떤 사양서보다 중요합니다. 이 가이드의 나머지 부분은 이 차이점에서 비롯되는 결과들로 이해해야 합니다.

전가상화: KVM 및 Xen HVM

KVM(kernel-based virtual machine)은 일반 Linux 호스트를 하이퍼바이저로 전환하는 Linux 커널 내부 모듈이며, CPU에 내장된 Intel VT-x 또는 AMD-V 명령어를 사용합니다. QEMU는 디스크, 네트워크 카드, 시리얼 콘솔과 같은 가상 하드웨어를 제공합니다. Xen은 설계 방식이 다릅니다. Xen은 그 자체로 하이퍼바이저이며 Linux보다 먼저 부팅됩니다. dom0라고 불리는 권한 있는 제어 도메인이 관리 스택을 실행하며, 각 테넌트는 domU가 됩니다. Xen HVM(hardware virtual machine)은 KVM과 동일한 CPU 확장 기능을 사용하며, 에뮬레이션된 하드웨어는 속도가 느리기 때문에 일반적으로 디스크와 네트워크에 대해 반가상화(paravirtual) 드라이버를 사용합니다. 이 조합을 PVHVM이라고 합니다.

테넌트 입장에서 두 방식은 거의 동일하게 동작합니다. 커널, 부트로더, 실제 블록 장치, 작동하는 modprobe, 정상적인 /proc, 직접 소유한 스왑 공간을 제공받으며, 재부팅 시 실제로 부팅이 수행됩니다. 제공자가 ISO 파일을 연결할 수 있도록 허용한다면, 제공자가 기본으로 제공하지 않는 배포판도 설치할 수 있습니다.

이러한 기능에 대한 대가는 밀도에서 지불하게 됩니다. 할당된 4 GB 메모리는 귀하의 머신에 전용으로 고정되므로, 귀하가 유휴 상태일 때 이웃 테넌트에게 빌려줄 수 없습니다. 또한 모든 게스트는 QEMU 프로세스, 자체 페이지 테이블, 자체 페이지 캐시를 유지해야 합니다. 이러한 비용 때문에 KVM 플랜은 동일한 사양을 보여주는 컨테이너 플랜보다 더 높은 가격이 책정됩니다.

Paravirtualised Xen과 이를 식별하는 방법

Xen PV는 CPU에 가상화 명령어가 도입되기 이전에 등장했습니다. 특권 명령어를 가로채는 대신, 게스트 커널을 수정하여 하이퍼바이저를 직접 호출하도록 설계되었습니다. 이는 2005년 당시의 핵심 목표였던 VT-x 없이도 구동이 가능하게 했습니다. 커널은 pygrub이나 pvgrub을 통해 사용자의 디스크 이미지 내부에서 로드되므로 사용자의 커널을 그대로 사용하지만, 반드시 PV 게스트 지원을 포함하여 빌드되어야 합니다.

PV 환경임을 나타내는 징후는 다음과 같습니다. lscpu는 가상화 유형을 full가 아닌 para으로 보고하며, /sys/hypervisor/type가 존재하고 Xen을 명시합니다. 또한 디스크 장치명은 vda이나 sda이 아닌 xvda 형식을 따릅니다. PV 게스트는 정보를 게시할 펌웨어가 없으므로, SMBIOS나 DMI 테이블을 읽는 도구들은 아무런 정보도 찾을 수 없습니다.

이 방식의 가장 큰 제약은 중첩 가상화(nested virtualisation)를 영구적으로 사용할 수 없다는 점입니다. PV 게스트에는 CPU 가상화 확장 기능이 노출되지 않으므로, 게스트 내부에서 다른 하이퍼바이저를 실행할 수 없습니다. Xen 프로젝트 자체가 사라진 것은 아닙니다. Xen PV는 점차 사용이 줄어드는 방식이며, 프로젝트의 방향성은 PVH 및 HVM으로 전환되었습니다. 서비스 계획에 "Xen"이라고 명시되어 있다면 어떤 방식인지 확인해야 합니다. HVM은 현대적인 일반 VPS와 동일하지만, PV는 더 낮은 가격으로 책정되어야 하는 서비스입니다.

컨테이너 VPS: LXC와 OpenVZ 계열

컨테이너 VPS는 호스트 제공자의 커널 위에서 실행되는 Linux 네임스페이스(프로세스 ID, 마운트, 네트워크 인터페이스, 호스트 이름, 사용자에 대한 분리된 뷰)와 cgroups(커널의 자원 제한 기능)의 집합입니다. 귀하의 init는 호스트의 프로세스입니다. 귀하의 ls은 에뮬레이션이나 별도의 스케줄러 개입 없이 호스트 커널에서 직접 실행됩니다. 이것이 컨테이너가 빠르고 밀도가 높은 이유입니다.

주문 페이지에서 볼 수 있는 명칭으로는 LXC, Proxmox VE 컨테이너(LXC 기반), OpenVZ, Virtuozzo가 있습니다. OpenVZ 7과 Virtuozzo는 동일한 개념에서 파생된 상용 제품입니다.

사용자에게는 다음 네 가지가 달라집니다:

• 모듈. modprobe은 어떠한 모듈도 삽입할 수 없습니다. WireGuard, ZFS 또는 특정 netfilter 모듈이 호스트 제공자의 커널에 이미 포함되어 있지 않다면 사용할 수 없습니다.
• sysctl. /proc/sys의 대부분은 읽기 전용입니다. 네트워킹은 실제 네임스페이스이므로 net.ipv4.ip_forward와 그 주변 설정은 일반적으로 쓰기가 가능합니다. vm.swappiness나 fs.file-max과 같은 시스템 전체 설정은 호스트의 권한에 속합니다.
• 중첩 컨테이너. LXC 컨테이너 내부의 Docker는 제공자가 중첩(nesting)을 활성화하고 스토리지 드라이버가 호환될 때만 작동합니다. 무작정 가정하기보다 구매 전에 테스트하십시오.
• 커널 버전. 호스트 제공자의 업그레이드 일정과 재부팅 주기를 그대로 따르게 됩니다.

구매한 제품 확인 방법

서버에서 다음 명령들을 실행하고 결과를 종합적으로 확인하십시오. 단일 명령만으로는 판단할 수 없습니다.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt은 고정된 어휘 목록 중 하나의 짧은 식별자를 출력합니다. 머신 측 식별자에는 kvm, qemu, xen, amazon, vmware가 포함됩니다. 컨테이너 측 식별자에는 lxc, lxc-libvirt, openvz, docker, systemd-nspawn가 포함됩니다. 감지된 내용이 없으면 none을 출력하고 0이 아닌 종료 코드를 반환합니다. -c 형식은 컨테이너 기술에 대해서만 응답하므로, 판매 페이지의 설명과 관계없이 여기서 none 이외의 결과가 나오면 컨테이너임이 확정됩니다.

lscpu은 하이퍼바이저 공급업체 이름을 출력하며, 가상화 유형이 full인지 para인지 명시합니다. 이를 통해 Xen HVM과 Xen PV를 구분할 수 있습니다. /sys/hypervisor/type는 Xen 환경에서만 존재합니다.

/lib/modules 확인은 사람들이 자주 간과하지만 가장 직접적인 방법입니다. 시스템이 해당 커널로 실행 중임이 분명함에도 실행 중인 커널 버전에 해당하는 디렉터리가 없거나 비어 있다면, 해당 커널은 파일 시스템에서 온 것이 아닙니다. 호스트에서 제공된 것이며 모듈 트리가 이미지에 설치되지 않은 상태입니다. 이는 컨테이너입니다.

독립적인 교차 검증을 위해 sudo apt install -y virt-what && sudo virt-what를 전용 도구로 사용하여 감지 테스트를 수행할 수 있습니다. 이 도구는 root 권한이 필요하며, 베어메탈 환경에서는 아무것도 출력하지 않습니다.

컨테이너에서 /proc가 잘못된 머신 정보를 표시하는 이유

KVM이나 Xen 게스트 환경에서 /proc/meminfo은 하이퍼바이저가 할당한 메모리에 대해 커널이 자체적으로 계산한 값입니다. 이는 가상 머신에 대한 정확한 정보이며, 호스트에 대해서는 아무런 정보를 제공하지 않습니다. 이것이 바로 가상 머신의 본질입니다.

컨테이너에는 이러한 계산을 수행하는 별도의 커널이 없으므로, /proc은 호스트의 /proc을 그대로 보여줍니다. LXCFS는 cgroup 제한에 맞춰 일부 파일을 재작성하는 작은 파일 시스템이며, /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats 및 /sys/devices/system/cpu/online를 처리합니다. Proxmox는 이를 기본적으로 마운트하지만, 많은 소규모 제공업체는 그렇지 않습니다. 이 경우 free -m은 호스트의 전체 메모리를 보고하고, nproc은 머신의 모든 코어를 표시하며, uptime은 호스트의 가동 시간을 보고하게 됩니다.

소프트웨어는 이 파일들을 참조하여 스스로의 규모를 결정하므로, 이는 단순한 표시상의 문제가 아닙니다. worker_processes auto을 사용하는 nginx는 자신이 볼 수 있는 코어 수를 기준으로 동작합니다. 64코어 호스트에서 2코어 할당량을 가진 컨테이너의 make -j$(nproc)은 64개의 컴파일러를 실행합니다. MemTotal를 통해 캐시 크기를 결정하는 JVM이나 데이터베이스는 cgroup이 허용하지 않는 큰 값을 선택하게 되며, 프로세스가 제한에 도달하면 커널이 해당 프로세스를 강제 종료합니다. 이 종료 기록은 호스트의 커널 로그에 남지만, 사용자는 이를 확인할 수 없습니다.

공식적인 수치는 /proc이 아닌 cgroup에 존재합니다.

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

위 경로는 현재 배포판에서 사용하는 cgroup v2 경로입니다. max를 읽었을 때 memory.max가 출력된다면 해당 레벨에 제한이 설정되지 않았음을 의미합니다. cpu.max은 마이크로초 단위의 쿼터와 주기를 출력하므로, 200000 100000은 주기당 2개의 CPU 코어 시간을 의미합니다. 이전 버전인 cgroup v1 호스트에서는 동일한 값이 /sys/fs/cgroup/memory/memory.limit_in_bytes 및 /sys/fs/cgroup/cpu/cpu.cfs_quota_us 아래에 위치합니다.

스왑과 스왑의 실질적 소유권

KVM 및 Xen 환경에서 스왑은 사용자의 것입니다. 스왑은 디스크의 파일이나 파티션이며, 커널이 직접 페이징을 수행합니다.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show 명령을 실행하면 이제 해당 파일의 크기와 우선순위가 표시되어야 합니다. 만약 swapon 명령이 해당 파일을 거부한다면, dd if=/dev/zero of=/swapfile bs=1M count=2048 명령을 사용하여 파일을 생성하십시오. 일부 파일 시스템에서는 데이터가 기록되지 않은 미리 할당된(preallocated) 파일을 거부하기 때문입니다. /swapfile none swap sw 0 0 항목을 /etc/fstab 파일에 추가하십시오. 그렇지 않으면 재부팅 후 스왑이 사라집니다.

컨테이너 환경에서는 이 중 어느 것도 사용자의 것이 아닙니다. swapon 명령은 권한이 없는 컨테이너가 보유하지 않은 기능을 필요로 하므로, 사용자가 직접 스왑 파일을 생성하려고 하면 권한 문제로 실패하며 디스크에 도달하지도 못합니다. 컨테이너 계획에서 스왑이라고 부르는 것은 호스트의 cgroup 설정이며, cgroup v2에서는 memory.swap.max 항목으로 관리되고 호스트 자체의 스왑 장치를 기반으로 합니다. 구형 OpenVZ 계획에서는 디스크보다는 버스트 크레딧에 더 가까운 "vswap" 허용량을 판매했습니다. 사용자는 스왑의 상한선을 확인할 수는 있지만, 그 아래에 있는 장치를 직접 제어할 수는 없습니다.

중첩 가상화와 거짓을 말하는 CPU 플래그

중첩 가상화란 VPS 내부에서 하이퍼바이저를 실행하는 것을 의미합니다. QEMU 게스트, Vagrant 박스, 또는 자체 VM을 포함한 중첩 가상화 실습 환경 등이 이에 해당합니다. 이를 위해서는 두 가지 조건이 모두 충족되어야 합니다. 호스트 제공자가 중첩 가상화를 활성화해야 하며, 게스트에게 CPU의 가상화 확장 기능이 노출되어야 합니다.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

중첩 가상화가 활성화된 KVM 게스트에서는 /dev/kvm이 존재하며, kvm-ok은 가속 기능을 사용할 수 있는지 여부를 명확하게 보고합니다. Xen HVM에서는 기술적으로 가능하지만 제공되는 경우가 드뭅니다. Xen PV에서는 불가능합니다.

컨테이너 환경에서는 이 확인 과정이 교육적인 방식으로 실패합니다. /proc/cpuinfo는 호스트의 파일이므로 vmx 또는 svm 플래그가 존재하며, 이는 실제로 사실입니다. 하위의 물리적 CPU는 해당 명령어 세트를 보유하고 있습니다. 하지만 그것은 사용자의 것이 아닙니다. 네임스페이스 내에는 /dev/kvm가 없으며, kvm_intel 모듈을 로드할 수도 없습니다. 방금 읽은 플래그는 사용자가 제어하는 머신이 아니라, 사용자가 게스트로 실행 중인 머신을 설명할 뿐입니다. 이는 일반적인 규칙을 보여주는 가장 명확한 사례입니다. 컨테이너에서 /proc는 사용자가 소유한 서버가 아니라, 네임스페이스와 그 주변의 하드웨어를 설명합니다.

AES-NI와 CPU 기능 노출

AES-NI(advanced encryption standard new instructions)는 AES 암호화 연산을 소프트웨어 방식보다 몇 배 더 빠르게 수행하도록 돕는 CPU 명령어 세트입니다. TLS 종료, 디스크 암호화, SSH, 백업 파이프라인 모두 이 기능에 의존합니다.

KVM 환경에서 게스트가 인식하는 CPU 모델은 공급자가 QEMU를 위해 설정한 값에 따라 결정됩니다. host passthrough를 사용하면 실제 플래그를 그대로 볼 수 있습니다. 반면 qemu64와 같은 일반 모델을 사용하거나, 서로 다른 호스트 간의 마이그레이션을 위해 의도적으로 구형 베이스라인을 선택한 경우 aes 플래그가 누락될 수 있으며, 이 경우 OpenSSL은 자동으로 소프트웨어 연산 방식으로 전환됩니다.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

세 번째 명령어는 OpenSSL 매뉴얼에서 라이브러리 내부의 해당 명령어들을 비활성화하는 예시입니다. 이 명령은 AES-NI 비트와 VAES 비트를 지우고 나머지는 그대로 둡니다. 두 처리량 수치를 비교해 보십시오. 만약 두 수치가 비슷하다면 애초에 고속 경로가 사용되지 않고 있었던 것이며, VPS에서 AES-NI를 올바르게 확인하는 방법을 통해 플랜을 확정하기 전 5분 정도 시간을 투자할 가치가 있습니다.

컨테이너 앞단에는 별도의 CPU 모델이 존재하지 않으므로 /proc/cpuinfo에 나열된 플래그는 호스트의 실제 플래그이며 사용자에게 그대로 적용됩니다. 이는 컨테이너 플랜의 확실한 장점이며, 이 가이드에서 공유 커널이 사용자에게 유리하게 작용하는 유일한 지점입니다.

Steal time의 발생 원인과 컨테이너에 Steal time이 없는 이유

Steal time은 가상 CPU가 실행 준비를 마쳤음에도 하이퍼바이저가 다른 작업을 수행하느라 실행되지 못한 시간을 의미합니다. 이 값은 st의 top와 vmstat에 나타나며, /proc/stat의 cpu 라인에서 여덟 번째 필드로 표시됩니다.

게스트 운영체제는 실행되지 않는 동안에는 시간을 측정할 수 없으므로 스스로 이 값을 계산할 수 없습니다. 하이퍼바이저가 이 정보를 알려주어야 합니다. KVM은 게스트가 반가상화 클록 인터페이스를 통해 등록한 페이지에 누적 실행 시간을 기록하며, Xen은 동일한 작업을 위해 vCPU별 실행 상태 영역을 유지합니다. 사용자가 확인하는 수치는 하이퍼바이저가 직접 보고하는 값이므로, 이 값이 존재하며 신뢰할 수 있는 이유이기도 합니다.

Steal time이 높다는 것은 호스트가 과도하게 할당(oversubscribed)되어 있으며, 현재 다른 사용자의 작업이 바쁘게 처리되고 있음을 의미합니다. 이는 판매된 vCPU와 물리적 코어 간의 비율을 보여주는 지표이며, Steal time을 읽어 시끄러운 이웃(noisy neighbour)을 식별하는 방법은 계획한 리소스가 실제 사양만큼 충분한지 확인할 수 있는 유일한 측정값입니다.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

컨테이너 환경에서는 이 열의 값이 변하지 않습니다. 사용자 프로세스와 스케줄러 사이에 하이퍼바이저가 존재하지 않기 때문입니다. 사용자의 프로세스는 호스트의 CPU 스케줄러에서 다른 모든 테넌트의 프로세스와 함께 일반적인 작업으로 대기합니다. 리소스 경합이 발생하면 단순히 작업 처리 시간이 길어질 뿐, 그 원인을 지칭하는 카운터는 존재하지 않습니다. 가장 유사한 지표는 쿼터 스로틀링(quota throttling)입니다. 제공자가 cpu.max을 설정하면, /sys/fs/cgroup/cpu.stat는 다음 쿼터 윈도우를 기다리는 데 소요된 nr_throttled 주기와 throttled_usec 마이크로초를 계산합니다. 이는 사용자의 쿼터에 대해서만 적용되며, 다른 사용자와의 경쟁으로 인한 지연은 포함하지 않습니다. 주의할 점은, 제공자의 컨테이너 호스트 자체가 가상 머신인 경우 /proc/stat에 Steal time이 나타날 수 있다는 것입니다. 이는 사용자 본인이 아닌 해당 호스트의 상태를 나타냅니다.

오버셀링과 컨테이너 플랜이 더 저렴한 이유

솔직한 답변은 간단합니다. 컨테이너 플랜이 더 저렴한 이유는 제공업체가 동일한 머신을 더 많은 사람과 공유하기 때문입니다.

메모리는 격차가 가장 큰 부분입니다. KVM 게스트의 RAM은 해당 게스트에 할당되므로, 256 GB 호스트는 오버헤드를 제외하고 대략 256 GB만큼의 게스트를 판매합니다. 반면 컨테이너의 메모리 제한은 예약이 아닌 상한선이며, 컨테이너가 사용하지 않는 메모리는 즉시 다른 컨테이너가 사용할 수 있습니다. 따라서 제공업체는 물리적 RAM의 몇 배에 달하는 제한을 판매할 수 있으며, 대부분의 경우 문제없이 작동합니다. 이는 속임수가 아닙니다. 충분한 수의 테넌트가 동시에 바빠지기 전까지는 정상적으로 작동하며, 그 시점이 되면 모든 테넌트의 서비스가 중단됩니다.

CPU는 KVM을 포함한 모든 플랜 유형에서 실제 코어 수보다 더 많은 vCPU를 판매하는 방식으로 오버셀링됩니다. 디스크는 거의 모든 곳에서 씬 프로비저닝(thin provisioned)됩니다. 컨테이너는 여기에 더 높은 밀도를 쌓습니다. 하나의 커널, 하나의 페이지 캐시를 사용하며 게스트별 QEMU 프로세스가 없으므로 호스트는 훨씬 더 많은 테넌트를 수용할 수 있습니다.

이로 인해 포기해야 하는 것은 격리 수준이며, 이는 공포 조장이 아닌 실제 엔지니어링상의 절충안입니다. 커널을 공유하므로 커널 버그는 공통의 문제가 되며, 컨테이너 탈출은 곧바로 호스트에 대한 침해로 이어집니다. 가상 머신을 탈출하려면 하이퍼바이저 버그가 필요한데, 이는 훨씬 더 작고 공략하기 어려운 공격 대상입니다. 또한 제공업체의 커널 업그레이드 및 재부팅 일정을 그대로 따라야 합니다. 이러한 요소가 중요하다면 가격만 보고 결정하기 전에 VPS 호스팅의 실제 안전성에 관한 내용을 먼저 읽어보시기 바랍니다.

어떤 것을 구매해야 하는가

자신만의 커널이 필요하다면 KVM을 구매하십시오. WireGuard나 ZFS 모듈, 특정 커널 버전, 중첩 가상화(nested virtualisation), 스왑(swap)에 대한 실질적인 제어권이 필요하거나, 감사인에게 설명할 수 있는 명확한 경계가 필요한 경우가 이에 해당합니다. 예산 내에서 일반적인 서비스를 운영하고, 제공업체의 커널이 최신 상태이며, 의존하는 기능이 이미 커널에 포함되어 있음을 확인했다면 컨테이너 플랜을 구매하십시오. 대부분의 목적에서 Xen HVM은 KVM과 동일하게 취급하면 되며, 여전히 Xen PV로 판매되는 상품은 구매 전 확인이 필요합니다.

이 분류에 속하지 않는 두 가지 형태가 있습니다. Firecracker microVM은 각 테넌트에게 컨테이너와 유사한 수준의 시작 속도로 실제 커널을 제공하며, 이는 서버리스 플랫폼이 구동되는 방식입니다. Incus 시스템 컨테이너는 직접 제어하는 하드웨어에서 컨테이너 모델을 직접 운영할 수 있게 해주며, 이는 서비스를 구매하는 것과는 다른 위치에 있습니다. 용어가 이해하기 어렵다면, VPS의 실제 의미와 VPS, VM, VPC의 차이에서 이 가이드가 전제로 하는 용어들을 다루고 있습니다.

FAQ

내 VPS가 KVM인지 컨테이너인지 어떻게 확인합니까?

systemd-detect-virt -c 명령을 실행하십시오. none 이외의 결과가 나오면, 상품명과 관계없이 컨테이너 환경에서 실행 중인 것입니다. 탐지 결과가 조작될 수 있으므로 두 가지 방법을 추가로 확인하십시오. lscpu 명령은 하이퍼바이저 공급업체와 가상화 유형(full 또는 para)을 명시합니다. 컨테이너에서는 실행 중인 커널이 호스트의 것이고 모듈 트리가 파일 시스템에 설치되어 있지 않으므로 ls /lib/modules/$(uname -r) 파일이 없거나 비어 있습니다. sudo virt-what 명령은 이 질문만을 위해 작성된 도구를 사용하여 독립적인 결과를 제공합니다.

왜 free -m 명령은 내 요금제보다 훨씬 많은 메모리를 표시합니까?

LXCFS가 마운트되지 않은 컨테이너 요금제를 사용 중이기 때문입니다. /proc/meminfo는 호스트의 파일이며, free는 호스트의 메모리 상태를 그대로 보고합니다. 실제 메모리 한도는 cgroup에 의해 결정됩니다. /sys/fs/cgroup/memory.max에서 한도를, /sys/fs/cgroup/memory.current에서 현재 사용량을 확인하십시오. 구형 cgroup v1 호스트라면 /sys/fs/cgroup/memory/memory.limit_in_bytes을 확인하십시오. 캐시나 워커 풀 크기를 결정하는 서비스는 free 값이 아닌 cgroup 한도 값을 기준으로 설정해야 합니다.

LXC VPS에서 Docker나 WireGuard를 실행할 수 있습니까?

사용자가 설치하는 것과는 무관하며, 상황에 따라 다릅니다. 두 서비스 모두 호스트의 커널에 의존하며, 사용자가 커널 모듈을 직접 로드할 수 없기 때문입니다. WireGuard는 호스트에 모듈이 이미 존재하고 사용자에게 노출된 경우 작동하며, 그렇지 않은 경우 사용자 공간 구현체인 wireguard-go을 대안으로 사용합니다. Docker는 공급자가 중첩(nesting)을 허용해야 하며 컨테이너 내부에서 작동하는 스토리지 드라이버가 필요합니다. 구매 전에 문의하거나, 언제든 해지 가능한 기간 동안 테스트하십시오.

왜 컨테이너 VPS에서는 steal time이 보고되지 않습니까?

Steal time은 하이퍼바이저가 가상 CPU를 스케줄링할 때만 존재하며, 하이퍼바이저가 커널이 읽는 페이지에 해당 수치를 기록하기 때문에 보고됩니다. 컨테이너 아래에는 하이퍼바이저가 없습니다. 프로세스는 호스트 스케줄러의 일반적인 작업으로 취급되므로, 자원 경합은 단순히 모든 작업이 느려지는 것으로 나타나며 이를 가리키는 카운터는 없습니다. 대신 /sys/fs/cgroup/cpu.stat을 확인하십시오. nr_throttled와 throttled_usec은 cgroup이 다음 CPU 할당량을 기다리는 데 소비한 시간을 계산하며, 이는 컨테이너에서 steal time과 가장 유사한 지표입니다.