2026년 Proxmox VE 9.2 가상 머신 확장 후 공간이 늘지 않는 이유?

Proxmox VE 9.2는 2026년 5월 21일 공개됐습니다(공식 출시 안내). 하지만 가상 디스크를 확장해도 게스트 운영체제의 파티션과 파일 시스템까지 자동으로 커지는 것은 아닙니다. 먼저 호스트 저장소에 여유가 있는지 확인하고, 가상 디스크부터 게스트 파일 시스템까지 용량이 멈춘 단계를 찾아야 합니다.

관리형 Proxmox VE 9.2 서버나 가상 머신 자원 풀에서 확장 후 용량 표시가 바뀌지 않는 시스템 관리자에게 적합합니다.
여러 고객의 가상 머신을 맡은 MSP 운영자는 데이터 보호와 변경 절차를 점검할 수 있습니다.
개발 테스트나 내부 서비스용 가상 머신을 운영하는 소규모 IT 팀은 재구축 없이 확장할 수 있는지 판단하는 데 활용할 수 있습니다.

Proxmox VE 9.2 가상 머신 확장 문제는 용량 계층부터 나눠 봅니다

용량은 호스트 저장소, 가상 디스크, 게스트 블록 장치, 파티션과 논리 볼륨, 파일 시스템처럼 여러 계층으로 이어집니다. 앞 단계의 크기가 커져도 뒤 단계가 그대로라면 게스트에서 보는 사용 가능 공간은 늘지 않습니다.

호스트 저장소가 부족한데 VM 안에서만 확장을 반복하면 문제가 해결되지 않습니다. 반대로 호스트와 가상 디스크에 여유가 있어도 게스트 파티션이 기존 크기라면 게스트 안에서 별도의 조정이 필요합니다. Proxmox의 저장소 유형과 동작 방식은 공식 관리 안내서의 저장소 설명을 기준으로 확인하세요.

변경 전에 대상과 여유 공간을 확인합니다

다음 순서를 따르면 다른 VM이나 디스크를 실수로 변경할 위험을 줄일 수 있습니다.

1. 대상 VM을 확인합니다. VM 식별자와 디스크 항목을 대조합니다. qm config <VMID>로 VM 설정을 확인하고, 확장하려는 디스크가 무엇인지 기록합니다. qm 명령의 인수와 동작은 Proxmox 공식 명령 참고 자료에서 확인할 수 있습니다.
2. 호스트 저장소를 점검합니다. Proxmox의 저장소 상태와 사용 중인 백엔드의 여유 공간을 확인합니다. 얇은 할당 방식에서는 가상 디스크에 설정된 크기와 호스트에서 실제로 소비하는 공간이 같다고 단정하지 마세요.
3. 백업과 복구 경로를 확인합니다. 작업 전에 백업이 최신인지 확인하고, 필요한 데이터를 복구할 방법을 준비합니다. 파티션이나 LVM을 변경할 때는 서비스 영향을 검토해 작업 시간을 정하세요.
4. 가상 디스크만 확장합니다. 대상과 여유 공간을 확인한 뒤 qm resize <VMID> <디스크> +<용량>과 같은 명령을 검토합니다. 실제 VM 식별자, 디스크 이름, 크기 형식은 설치된 버전의 안내와 VM 설정에 맞춰야 합니다. 실행 전에는 공식 qm 명령 설명을 확인하세요.
5. 게스트에서 장치 크기를 확인합니다. 리눅스에서는 lsblk와 df -hT로 블록 장치와 파일 시스템을 비교합니다. 윈도우에서는 디스크 관리 도구에서 디스크와 볼륨의 상태를 확인합니다. 여기서 가상 디스크 크기가 보이지 않으면 파티션을 변경하지 말고 대상 VM과 게스트의 장치 인식 상태부터 다시 점검합니다.

위험 작업 전 확인: 백업에서 실제로 복구할 수 있는지, 호스트 저장소에 공간이 있는지, 변경 뒤 되돌릴 방법이 있는지 확인하세요. 저장소 백엔드나 게스트 디스크 구성을 모르면 확장을 진행하지 않는 것이 좋습니다.

파티션과 파일 시스템은 따로 확인합니다

게스트 장치가 커진 뒤에도 파일 시스템이 그대로라면, 먼저 파티션이 새 영역을 포함하는지 확인해야 합니다. 파티션 조정은 파일 시스템 확장과 같은 작업이 아닙니다. 파티션 변경 전에 복구 가능한 백업과 복구 절차를 다시 확인하세요.

LVM은 PV와 LV의 관계를 확인한 뒤 조정해야 합니다. 절차를 확인할 때는 Red Hat의 논리 볼륨 관리 안내를 참고하세요. ext4는 Debian의 resize2fs 설명, XFS는 xfs_growfs 매뉴얼에 나온 적용 조건을 따라야 합니다. 윈도우 기본 볼륨은 Microsoft의 볼륨 확장 안내에서 조건을 확인하세요.

자주 묻는 확장 후 용량 문제

리눅스에서 사용 가능 공간이 그대로 표시되는 경우

가상 디스크 확장은 게스트의 파일 시스템까지 자동으로 확장하지 않습니다. lsblk로 장치와 파티션 크기를, df -hT로 파일 시스템 크기를 비교하세요. 장치는 커졌는데 파일 시스템이 그대로라면 파티션이나 LVM 단계가 남았는지 확인합니다. 호스트 저장소의 여유 공간도 별도로 점검해야 합니다.

리눅스에서 가상 디스크 확장 뒤 확인할 순서

블록 장치가 새 크기를 인식하는지 확인한 다음, 파티션과 LVM 사용 여부를 살펴봅니다. LVM을 쓰면 PV와 LV의 크기가 새 공간을 반영하는지 각각 확인하세요. 마지막으로 파일 시스템 종류에 맞는 확장 절차를 검토합니다. ext4와 XFS에 같은 명령을 적용하지 말고, 실제 마운트와 장치 구성을 확인한 뒤 진행합니다.

파티션과 파일 시스템 중 멈춘 위치를 찾는 방법

장치, 파티션, 논리 볼륨, 파일 시스템의 크기를 나란히 비교하면 용량이 반영되지 않은 계층을 찾을 수 있습니다. 장치 크기만 늘었다면 파티션 단계가 남았을 수 있습니다. 파티션이나 LV가 커졌지만 df 결과가 그대로라면 파일 시스템을 확인하세요. 단계가 확인되기 전에는 변경 명령을 실행하지 않습니다.

확장 전 호스트 저장소와 백업 점검

먼저 대상 VM과 디스크를 확인하고 호스트 저장소의 여유와 형식을 살펴보세요. 백업이 존재하는지뿐 아니라 필요한 데이터를 복구할 수 있는지도 확인합니다. 파티션이나 LVM을 변경한다면 작업 시간과 복구 방법을 정해야 합니다. 저장소 방식이나 게스트 구성을 확인할 수 없다면 변경을 미루고 먼저 정보를 확보하세요.

조건에 맞춰 다음 작업을 선택합니다

• 호스트 저장소에 여유가 없거나 상태가 불명확하면 VM 확장을 멈추고 저장소부터 점검합니다.
• 호스트 저장소와 VM 설정은 충분하지만 게스트 장치가 기존 크기라면 대상 VM, 디스크 항목, 게스트 인식 상태를 다시 확인합니다.
• 게스트 장치는 커졌고 파티션이 기존 크기라면 백업과 복구 경로를 확인한 뒤 파티션 조정 가능성을 검토합니다.
• 파티션은 커졌지만 LV가 그대로라면 실제 LVM 구성을 확인하고 PV와 LV를 순서대로 점검합니다.
• LV 또는 파티션이 파일 시스템보다 크다면 ext4, XFS, 윈도우 볼륨 등 실제 유형에 맞는 공식 절차를 확인합니다.
• 저장소 백엔드나 게스트 레이아웃을 확인할 수 없다면 추측으로 명령을 실행하지 말고 작업을 보류합니다.

작업 뒤에는 qm config의 디스크 설정, 게스트 블록 장치, 파티션과 LV, 파일 시스템의 크기를 다시 대조하세요. SSH 또는 RDP로 게스트에 접속해야 한다면 AmdMetal 접속 안내에서 접속 방법을 확인할 수 있습니다.

VM 용량 부족과 호스트 저장소 부족은 다른 문제입니다

한 VM의 파일 시스템 공간만 부족하고 호스트 저장소에 여유가 있다면 가상 디스크 확장을 검토할 수 있습니다. 반대로 여러 VM에서 공간 부족이 반복되거나 호스트 저장소가 빠르게 소진된다면, VM 하나를 늘리는 대신 저장소 사용량과 전체 용량 계획을 먼저 살펴야 합니다.

공유 클라우드 인스턴스는 CPU와 디스크의 배정 방식, 저장소 변경 조건이 제공 정책에 따라 달라질 수 있습니다. VM을 장기간 운영하면서 디스크 구성과 자원 배분을 직접 관리해야 한다면, 공유 인스턴스보다 독점형 AMD 물리 서버가 더 적합한지 비교할 만합니다. 다만 현재 호스트 저장소의 여유를 모른 채 서버를 늘리는 것은 해결책이 아닙니다. 먼저 AmdMetal의 실제 상품과 저장소 선택 항목을 확인하고, 지금의 VM 용량 문제와 전체 저장소 계획을 구분해 판단하세요.

자주 묻는 질문