출처: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
소개
Proxmox VE 9.x는 몇 가지 새로운 주요 기능을 제공합니다. 업그레이드를 신중하게 계획하고, 시작하기 전에 백업을 생성하고 검증하며, 광범위한 테스트를 수행해야 합니다. 기존 구성에 따라 다운타임을 포함한 여러 수동 작업이 필요할 수 있습니다.
참고: 업그레이드 프로세스를 시작하기 전에 항상 유효하고 테스트된 백업이 필요합니다. 테스트 랩 환경에서 백업을 미리 테스트해 보세요.
시스템이 사용자 지정되었거나 추가 패키지 또는 기타 타사 저장소/패키지를 사용하는 경우 해당 패키지도 Debian Trixie로 업그레이드되어 호환되는지 확인하세요.
일반적으로 Proxmox VE 8.x 시스템을 Proxmox VE 9.x로 업그레이드하는 방법은 두 가지가 있습니다.
- 새 하드웨어에 새로 설치(백업에서 VM 복원)
- apt를 통한 제자리 업그레이드(단계별)
새로운 설치
- 모든 VM과 컨테이너를 외부 저장소에 백업합니다( 백업 및 복원 참조 ).
- /etc에 있는 모든 파일을 백업하세요필수: /etc/pve의 파일,
/etc/passwd,/etc/network/interfaces, 및/etc/resolv.conf기본 설치와 다른 모든 항목. - ISO에서 최신 Proxmox VE 9.x를 설치합니다(이렇게 하면 기존 호스트의 모든 데이터가 삭제됩니다).
- 브라우저 캐시를 비우고/또는 웹 UI를 강제로 다시 로드합니다( CTRL+ SHIFT+ R, MacOS의 경우 ⌘+ Alt+ R).
- 해당되는 경우 클러스터를 다시 빌드합니다.
- 파일을 복원합니다
/etc/pve/storage.cfg(이렇게 하면 백업에 사용된 외부 저장소를 사용할 수 있습니다). - 방화벽 구성을 복원합니다
/etc/pve/firewall/(/etc/pve/nodes/<node>/host.fw해당되는 경우). - 백업에서 모든 VM을 복원합니다( Backup and Restore 참조 ).
모든 VM/CT가 단일 공유 스토리지에 있는 경우 명령줄에 익숙한 관리자는 업그레이드 시 백업 및 복원을 우회하는 절차를 따를 수 있습니다.
주요 변경 사항
API 변경 사항에 대한 릴리스 노트를 참조하세요: https://pve.proxmox.com/wiki/Roadmap#9.0-known-issues
In-place 업그레이드
현재 In-place 업그레이드는 apt를 통해 수행됩니다. 이 업그레이드 방법을 사용하려면 apt에 대한 지식이 필요합니다.
필수 조건
- 모든 노드에서 Proxmox VE 8.4의 최신 버전으로 업그레이드되었습니다.
pve-manager 버전이 최신8.4.1버전이 아니면 노드에 올바른 패키지 저장소 구성(Web UI, Node -> Repositories)이 있는지 확인하세요. - 하이퍼 컨버지드 Ceph: Proxmox VE를 9.0으로 업그레이드하기 전에 모든 Ceph Quincy 또는 Ceph Reef 클러스터를 Ceph 19.2 Squid로 업그레이드하세요. 각각 Ceph Quincy to Reef , Ceph Reef to Squid 가이드를 따라가세요 .
- Proxmox Backup Server를 함께 설치했습니다. Proxmox Backup Server 3 to 4 upgrade how-to 참고.
- 노드에 안정적으로 액세스할 수 있어야 합니다. IKVM/IPMI와 같은 호스트 독립 채널이나 물리적 액세스를 통해 액세스하는 것이 좋습니다.SSH만 사용할 수 있는 경우 동일하지만 실제 운영 환경이 아닌 시스템에서 업그레이드를 먼저 테스트해 보는 것이 좋습니다.SSH 연결이 중단되더라도 업그레이드를 계속할 수 있도록 터미널 멀티플렉서(예: tmux 또는 screen)를 사용하는 것이 좋습니다.
- 건강한 클러스터
- 모든 VM 및 CT의 유효하고 테스트된 백업(문제가 발생할 경우)
- 루트 마운트 지점에 최소 5GB의 여유 디스크 공간이 필요하며, 이상적으로는 10GB 이상이어야 합니다.
- 알려진 업그레이드 문제 확인
업그레이드 테스트
독립형 서버를 사용하여 업그레이드 테스트를 쉽게 수행할 수 있습니다. 테스트 하드웨어에 Proxmox VE 8.4 ISO를 설치한 후, Proxmox VE 8.4의 최신 마이너 버전으로 업그레이드합니다( Package repositories 참조 ). 운영 환경과 최대한 유사하게 복제하려면 모든 관련 구성을 테스트 머신에 복사하거나 생성한 후 업그레이드를 시작합니다. VM에 Proxmox VE 8.4를 설치하고 이 환경에서 업그레이드를 테스트할 수도 있습니다.
단계별 조치
다음 작업은 클러스터의 각 Proxmox VE 노드의 명령줄에서 수행해야 합니다.
콘솔이나 SSH를 통해 작업을 수행하세요. 특히 SSH 연결이 중단되는 것을 방지하려면 콘솔을 사용하는 것이 좋습니다. GUI에서 제공하는 가상 콘솔을 통해 연결된 상태에서는 업그레이드를 수행하지 마세요. 업그레이드 중에 연결이 중단될 수 있습니다. SSH만 사용 가능한 경우, SSH 연결이 중단될 경우 문제를 방지하기 위해 터미널 멀티플렉서(예: tmux 또는 screen)를 사용하는 것이 좋습니다.
계속 진행하기 전에 모든 VM과 CT의 유효한 백업이 생성되었는지 확인하세요.
pve8to9 체크리스트 스크립트를 계속 사용하세요
최신 Proxmox VE 8.4 패키지에는 간단한 체크리스트 프로그램이 pve8to9포함되어 있습니다. 이 프로그램은 업그레이드 전, 도중, 그리고 후에 발생할 수 있는 문제에 대한 힌트와 경고를 제공합니다. 다음을 실행하여 실행할 수 있습니다.
pve8to9
모든 검사를 활성화 하여 실행하려면 다음을 실행하세요.
pve8to9 --full
업그레이드하기 전에 최소한 한 번 전체 검사를 실행하세요.
이 스크립트는 검사 및 보고 기능만 제공합니다. 기본적으로 시스템 변경 사항은 적용되지 않으므로 어떤 문제도 자동으로 해결되지 않습니다. Proxmox VE는 사용자 정의가 매우 까다로울 수 있으므로 스크립트가 특정 설정에서 발생할 수 있는 모든 문제를 인식하지 못할 수 있습니다.
문제 해결을 시도할 때마다 스크립트를 다시 실행하는 것이 좋습니다. 이렇게 하면 수행된 작업이 해당 경고를 실제로 해결했는지 확인할 수 있습니다.
중요한 가상 머신 및 컨테이너 이동
업그레이드 기간 동안 VM 및 CT를 계속 실행해야 하는 경우 업그레이드되는 노드에서 다른 곳으로 마이그레이션하세요.
클러스터 업그레이드를 계획할 때 염두에 두어야 할 마이그레이션 호환성 규칙:
- 이전 버전의 Proxmox VE에서 최신 버전으로 VM이나 CT를 마이그레이션하는 작업은 항상 가능합니다.
- 최신 Proxmox VE 버전에서 이전 버전으로 마이그레이션하는 것이 가능할 수 있지만 일반적으로 지원되지 않습니다.
참고 : 부분적으로 업그레이드된 클러스터에서 Proxmox VE 9로 이미 업그레이드된 노드에서 GUI에 로그인한 상태에서 Proxmox VE 8을 실행 중인 노드에서 작업(예: 게스트 마이그레이션)을 수행하면 사소한 불일치가 발생할 수 있습니다. Proxmox VE 8을 실행 중인 노드에서 게스트를 마이그레이션하는 동안 오류나 경고가 표시되면 해당 노드에서 GUI에 로그인하여 마이그레이션을 다시 시도하세요.
구성된 APT 저장소 업데이트
먼저, 시스템에서 최신 Proxmox VE 8.4 패키지를 사용하고 있는지 확인하세요.
apt update
apt dist-upgrade
pveversion
마지막 명령은 최소한 8.4.1또는 그 이상의 내용을 보고해야 합니다.
참고: 하이퍼컨버지드 Ceph 설정의 경우, Ceph Squid(버전 19)를 실행 중인지 확인하십시오. 출력을 확인하여 ceph --version확인하십시오. Ceph Squid를 실행 중이 아닌 경우, upgrade guide for Ceph Reef to Squid 참조하여 먼저 업그레이드를 완료하십시오. Ceph Squid로 업그레이드하기 전에 아래 단계를 진행하지 마십시오.
Debian Base Repositories를 Trixie로 업데이트
모든 Debian 및 Proxmox VE 저장소 항목을 Trixie로 업데이트합니다.
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list
Debian Bookworm 전용 저장소가 남아 있지 않은지 확인하세요. 그렇지 않으면 #해당 줄의 시작 부분에 기호를 추가하여 해당 저장소를 주석 처리할 수 있습니다. 및 의 모든 항목을 확인하고 /etc/apt/sources.list, /etc/apt/sources.list.d/pve-enterprise.list 올바른 Proxmox VE 9 / Debian Trixie 저장소는 Package Repositories를 참조하세요 .
Proxmox VE 9 패키지 저장소 추가
엔터프라이즈 저장소를 사용하는 경우, 새로운 deb822 스타일로 Proxmox VE 9 엔터프라이즈 저장소를 추가할 수 있습니다. 다음 명령을 실행하여 관련 pve-enterprise.sources파일을 생성하세요.
cat > /etc/apt/sources.list.d/pve-enterprise.sources << EOF
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
위와 같이 새 엔터프라이즈 저장소를 추가한 후 apt 가 제대로 선택되는지 확인하세요. 먼저 apt update를 실행한 후 apt policy를 실행하면 됩니다 . 오류가 표시되지 않고 apt policy에서 원하는 저장소만 출력되는지 확인하세요. 그런 다음 이전 /etc/apt/sources.list.d/pve-enterprise.list 파일을 제거할 수 있습니다. apt update와 apt policy를 다시 실행하여 이전 저장소가 제거되었는지 확인하세요.
구독 없는 저장소를 사용하는 경우 패키지 저장소를 참조하세요 . 다음 명령을 사용하여 Proxmox VE 9 구독 없는 저장소를 추가할 수 있습니다.
cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
엔터프라이즈 저장소와 마찬가지로, apt를 사용하여 저장소를 올바르게 선택했는지 확인하세요 . 그런 다음 apt update, apt policy를 사용 하거나 /etc/apt/sources.list/, etc/apt/sources-list.d/pve-install-repo.list.list 추가한 다른 .list 파일 에서 이전 Proxmox VE 8 비구독 저장소를 제거하세요. apt updateapt policy를 다시 실행하여 이전 저장소가 제거되었는지 확인하세요.
Ceph 패키지 저장소 업데이트
참고 : 하이퍼 컨버지드 Ceph 설정의 경우에만, 확실하지 않으면 이 노드의 웹 UI에서 Ceph 패널과 구성된 저장소를 확인하세요.
모든 ceph.com 저장소를 proxmox.com ceph 저장소로 교체하세요.
참고 : 이 시점에서 Proxmox VE에 직접 설치된 하이퍼 컨버지드 Ceph 클러스터는 Ceph 19.2 Squid를 실행해야 합니다 . 그렇지 않으면 Debian 13 Trixie에서 Proxmox VE 9로 업그레이드하기 전에 Ceph를 먼저 업그레이드해야 합니다! Proxmox VE 웹 UI의 각 노드 Ceph 패널에서 현재 Ceph 버전을 확인할 수 있습니다.
Proxmox VE 8부터 Ceph용 엔터프라이즈 저장소가 존재하여 프로덕션 환경에 최적의 환경을 제공합니다. 아래 명령을 실행하여 새로운 deb822 스타일로 Trixie 기반 Ceph 엔터프라이즈 저장소를 추가하세요.
cat > /etc/apt/sources.list.d/ceph.sources << EOF
Types: deb
URIs: https://enterprise.proxmox.com/debian/ceph-squid
Suites: trixie
Components: enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
먼저 apt를 실행한 후 apt update와 apt policy를 실행하여 파일이 제대로 선택되었는지 확인하세요 . 오류가 발생하지 않아야 하며, 새 저장소가 apt policy 의 출력에 제대로 표시되어야 합니다 . 그런 다음 이전 파일 /etc/apt/sources.list.d/ceph.list을 제거할 수 있습니다. apt update와 apt poliocy 를 실행한 후 를 다시 실행하여 파일이 제대로 제거되었는지 확인하세요.
401 오류로 업데이트가 실패하는 경우, Ceph에 대한 새로운 액세스 권한이 부여되었는지 확인하기 위해 먼저 구독을 새로 고쳐야 할 수 있습니다. 이 작업은 웹 UI나 pvesubscription update --force을 통해 수행하세요.
구독이 없으면 no-subscription저장소를 사용할 수 있습니다. 다음 명령을 사용하여 새 deb822 스타일로 추가하세요.
cat > /etc/apt/sources.list.d/ceph.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/ceph-squid
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
엔터프라이즈 저장소와 마찬가지로, apt update와 apt policy를 사용하여 apt파일을 올바르게 선택했는지 확인하세요 . 그런 다음 이전 파일 /etc/apt/sources.list.d/ceph.list 을 제거할 수 있습니다.
백포트 줄이 있는 경우 제거하세요. 업그레이드는 백포트 저장소의 패키지가 설치된 상태에서 테스트되지 않았습니다.
패키지 인덱스 새로 고침
저장소 패키지 인덱스를 업데이트하고 오류가 보고되지 않았는지 확인하세요.
apt update
시스템을 Debian Trixie 및 Proxmox VE 9.0으로 업그레이드
이 단계를 완료하는 데 걸리는 시간은 시스템 성능, 특히 루트 파일 시스템의 IOPS와 대역폭에 따라 크게 달라집니다. 느린 스피너는 최대 60분 이상 걸릴 수 있지만, SSD 스토리지를 사용하는 고성능 서버의 경우 dist-upgrade를 5분 이내에 완료할 수 있습니다.
업그레이드된 패키지의 초기 세트를 받으려면 다음 단계부터 시작하세요.
apt dist-upgrade
위 단계에서는 구성 파일의 변경 사항과 일부 서비스를 다시 시작하도록 승인하라는 메시지가 표시됩니다. 여기서 기본 구성은 해당 패키지에 의해 업데이트되었습니다.
apt-listchanges의 출력 결과가 표시될 수도 있는데, “q” 키를 눌러 종료할 수 있습니다. 기본 키보드 선택을 묻는 메시지가 표시되면 화살표 키를 사용하여 해당 키보드로 이동한 후 Enter 키를 누르세요.
서비스 재시작에 대한 질문(예: 패키지 업그레이드 중에 묻지 않고 서비스를 재시작할까요?)의 경우, 업그레이드 후 재부팅하면 모든 서비스가 정상적으로 재시작되므로 확실하지 않으면 기본값을 사용하세요.
문제의 각 파일에 대한 차이점을 확인하고 귀하의 설정에 가장 적합한 답변을 선택하는 것이 좋습니다.
변경 사항이 있는 일반적인 구성 파일과 권장되는 선택 사항은 다음과 같습니다.
/etc/issue-> Proxmox VE는 부팅 시 자동으로 이 파일을 생성하며, 로그인 콘솔에는 외관상의 효과만 줍니다.여기서는 기본값인 “아니요”(현재 설치된 버전 유지)를 사용하는 것이 안전합니다./etc/lvm/lvm.conf-> Proxmox VE와 관련된 변경 사항이 업데이트되며, 새로운 구성 버전이 유용할 수 있습니다.직접 추가 변경을 하지 않았고 확실하지 않은 경우 여기서 “예”(패키지 관리자 버전 설치)를 선택하는 것이 좋습니다./etc/ssh/sshd_config-> 이 파일을 수동으로 변경하지 않은 경우 유일한 차이점은ChallengeResponseAuthentication no를KbdInteractiveAuthentication no로 바꾼 것과 주석( 로 시작하는 줄#)의 일부 무관한 변경 사항일 것입니다. 이 경우 두 옵션 모두 안전하지만, 더 이상 사용되지 않는ChallengeResponseAuthentication옵션에서 벗어나려면 패키지 관리자 버전을 설치하는 것이 좋습니다. 다른 변경 사항이 있는 경우, 해당 내용을 자세히 검토하고 그에 따라 결정하는 것이 좋습니다./etc/default/grub-> 이 부분은 수동으로 변경한 경우에만 일반적으로 요청되므로, 예를 들어 커널 명령줄 옵션을 추가하는 경우 특별히 주의해야 합니다. 관련 변경 사항이 있는지 차이점을 확인하는 것이 좋습니다. 주석( 로 시작하는 줄#)의 변경 사항은 관련이 없습니다. 확실하지 않은 경우 “아니요”(현재 설치된 버전 유지)를 선택하는 것이 좋습니다./etc/chrony/chrony.conf-> 로컬에서 변경한 사항이 있는 경우 글로벌 구성에서 해당 사항을conf.d폴더로 옮기거나 , 사용자 지정 시간 원본의 경우 해당sources.d폴더로 옮기는 것이 좋습니다. 자세한 내용은 시스템의 파일/etc/chrony/conf.d/README와/etc/chrony/sources.d/README를 참조 하세요 .직접 추가 변경을 하지 않았고 확실하지 않은 경우 여기서 “예”(패키지 관리자 버전 설치)를 선택하는 것이 좋습니다.
결과 확인 및 업데이트된 커널로 재부팅
dist-upgrade 명령이 성공적으로 종료되면 검사기 스크립트를 다시 확인하고 pve8to9시스템을 재부팅하여 새로운 Proxmox VE 커널을 사용할 수 있습니다.
이전에 6.14 커널을 사용했더라도 Proxmox VE 8의 옵트인 패키지를 통해 재부팅해야 합니다. 이는 업데이트된 커널이 최신 Proxmox VE 9 컴파일러 및 ABI 버전으로 (다시) 빌드되었기 때문에 나머지 시스템과의 최상의 호환성을 보장하기 위해 필요합니다.
Proxmox VE 업그레이드 후
브라우저 캐시를 비우고/또는 웹 UI를 강제로 다시 로드합니다( CTRL+ SHIFT+ R, macOS의 경우 ⌘+ Alt+ R).
클러스터의 경우
- 모든 노드가 최신 패키지 버전으로 작동 중인지 확인하세요.그렇지 않은 경우 다음 노드에서 업그레이드를 계속하고 #Prerequisites 에서 다시 시작하세요.
- Proxmox VE 9에서는 HA 그룹 대신 HA 규칙이 사용됩니다. HA와 HA 그룹을 함께 사용하는 경우, 모든 클러스터 노드가 Proxmox VE 9로 업그레이드되면 HA 그룹이 HA 규칙으로 자동 마이그레이션됩니다. 모든 클러스터 노드를 업그레이드한 후 HA 그룹이나 규칙에 문제가 발생하면
pve-ha-crm활성 CRM 노드에서journalctl -eu pve-ha-crm로 로그에서 오류를 확인하세요.
선택 사항: apt 저장소 소스 현대화
다음을 실행하여 기존 저장소 소스를 권장되는 deb822 스타일 형식으로 마이그레이션할 수 있습니다.
apt modernize-sources
다음 프롬프트에 “n”으로 답하면 명령이 변경하는 내용을 적용하기 전에 확인할 수 있습니다. 변경 사항을 적용하려면 명령을 다시 실행하고 프롬프트에 “Y”로 답하면 됩니다.
이 명령은 이전 .list파일에 .bak 내용을 추가하여 기존 파일을 유지합니다. 따라서 새 .source 파일과 이전 저장소 구성이 해당 .list.bak 파일에 저장됩니다 . 새 형식에서 모든 것이 원활하게 작동하는지 확인한 후 남아 있는 백업 파일을 제거할 수 있습니다.
체크리스트 문제
proxmox-ve 패키지가 너무 오래되었습니다
구성된 패키지 저장소 항목을 확인하세요. 이 단계에서는 Proxmox VE 8.x 및 Bookworm에 대한 항목이어야 합니다( Package_Repositories 참조 ). 그런 다음 다음을 실행합니다.
apt update
이어서
apt dist-upgrade
PVE 9로 업그레이드하기 전에 최신 Proxmox VE 8.x 패키지를 받으세요 .
LVM/LVM-thin 스토리지에는 자동 활성화가 활성화된 게스트 볼륨
LVM 또는 LVM 씬 스토리지에서 게스트 볼륨은 LVM 논리 볼륨(LV)에 해당합니다. 기본적으로 LVM은 부팅 후 또는 LVM 스토리지가 iSCSI LUN에 있는 경우 iSCSI 로그인 후와 같이 LV가 표시되면 자동으로 활성화합니다. PVE 9부터 자동 활성화가 비활성화된 상태로 새 LV가 생성됩니다. 이러한 LV는 더 이상 자동으로 활성화되지 않으며, 필요 시 Proxmox VE에 의해 활성화됩니다. 공유 LVM 스토리지가 있는 클러스터(예: 공유 iSCSI/FC LUN)에서 이 기능을 사용하면 게스트/디스크 생성 또는 게스트 마이그레이션 실패를 유발할 수 있는 문제를 방지할 수 있습니다. 자세한 내용은 버그 #4997을 참조하십시오.
기존 LV의 경우, 활성 및 활성화된 LVM 및 LVM-씬 스토리지의 모든 게스트 볼륨에 대한 자동 활성화를 비활성화하는 마이그레이션 스크립트를 제공합니다. 마이그레이션 스크립트는 에 있으며 /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation, pve8to9 체크리스트 스크립트는 필요한 경우 이 마이그레이션 스크립트를 실행할 것을 권장합니다. 공유 LVM 스토리지에 게스트 볼륨이 있는 경우, 위에서 설명한 문제를 방지하기 위해 마이그레이션 스크립트를 실행하는 것이 좋습니다. 게스트 볼륨이 로컬 LVM 또는 LVM-씬 스토리지에만 있는 경우, 마이그레이션 스크립트 실행은 선택 사항입니다.
알려진 업그레이드 문제
일반
데비안 기반 배포판인 Proxmox VE는 데비안에 영향을 미치는 대부분의 문제와 변경 사항의 영향을 받습니다. 따라서 데비안 Trixie 업그레이드 관련 문제를 반드시 읽어 보시기 바랍니다 . 특히, /tmp는 이제 tmpfs파일 시스템으로 , 최대 50%의 메모리를 사용하며, 시스템 실행 중 /tmp와 /var/tmp의 파일들이 정기적으로 정리됩니다 .
Proxmox VE 9.0 변경 로그의 알려진 문제 목록도 확인하세요: https://pve.proxmox.com/wiki/Roadmap#9.0-known-issues
업그레이드 시 패키지 ‘proxmox-ve’를 제거하려고 합니다.
Proxmox VE ISO를 사용하지 않고 일반 Debian Trixie에 Proxmox VE를 설치한 경우, 현재 9.x 설정과 충돌하는 ‘linux-image-amd64’ 패키지가 설치되었을 수 있습니다. 이 문제를 해결하려면 다음을 수행하여 이 패키지를 제거해야 합니다.
apt remove linux-image-amd64
dist-upgrade 전.
업그레이드 중에 커널 감사 메시지가 활성화
Debian Bookworm과 Debian Trixie 사이의 특정 systemd 기본값에 대한 변경으로 인해 journald가 Proxmox VE 9로 업그레이드하는 동안 커널 감사 메시지를 기록하기 시작합니다.
특히, 데비안 Bookworm 및 이전 버전에서는 감사 로깅이 기본적으로 비활성화되었지만, 해당 소켓 systemd-journald-audit.socket 은 활성화된 상태로 유지되었습니다. 데비안 Trixie에서는 이 설정이 역전되었습니다. 감사 로깅이 다시 기본적으로 활성화되어 업스트림과 일치하지만, systemd-journald-audit.socket는 이제 기본적으로 비활성화됩니다. 그러나 소켓은 업그레이드 중에도 활성화된 상태로 유지되므로 감사 로그 메시지가 나타나기 시작합니다.
업그레이드 중에 과도한 감사 메시지가 기록되는 것을 방지하려면 업그레이드하기 전에 systemd-journald-audit.socket 을 비활성화하고 중지할 수 있습니다.
systemctl disable --now systemd-journald-audit.socket
그렇지 않으면 업그레이드가 완료된 후 노드를 재부팅하면 감사 메시지가 더 이상 기록되지 않습니다.
타사 스토리지 플러그인
외부 저장소 플러그인을 사용하는 경우 플러그인 작성자가 Proxmox VE 9.0에 맞게 플러그인을 조정할 때까지 기다려야 합니다.
이전 하드웨어 및 새로운 6.14 커널 및 기타 소프트웨어
10년 이상 전에 출시된 구형 하드웨어의 호환성은 최신 하드웨어만큼 철저하게 테스트되지 않았습니다. 구형 하드웨어의 경우, 프로덕션 머신을 업그레이드하기 전에 Proxmox VE 9와 동일하거나 최소한 유사한 하드웨어의 호환성을 테스트하는 것이 좋습니다.
Ceph는 최소한 AMD Opteron 2427(2009년 출시) 및 AMD Turion II Neo N54L(2010년 출시) CPU에서 “illegal instruction” 오류가 발생하는 것으로 보고되었습니다.
이 섹션에서는 잠재적인 함정과 해결 방법에 대한 내용을 확장하여 설명하겠습니다.
UEFI 모드에서 GRUB가 LVM에서 부팅에 실패할 수 있음
PVE 8 이전 버전의 grub 버그 로 인해 grub이 disk `lvmid/...` not found 오류 메시지와 함께 LVM에서 부팅되지 않을 수 있습니다. UEFI 모드로 부팅할 때는 수정 사항이 포함된 새 grub 버전이 시스템 부팅에 실제로 사용되는지 확인해야 합니다.
ZFS에 루트가 있는 시스템과 레거시 모드로 부팅하는 시스템은 영향을 받지 않습니다.
LVM에 root가 있는 EFI 모드로 부팅하는 시스템에서는 다음을 사용하여 올바른 grub 메타 패키지를 설치합니다.
[ -d /sys/firmware/efi ] && apt install grub-efi-amd64
자세한 내용은 해당 위키 페이지를 참조하세요 .
Systemd-boot 메타 패키지는 부트로더 구성을 자동으로 변경하므로 제거해야 합니다.
Debian Trixie에서는 systemd-boot 패키지가 systemd-boot-efi(부팅에 사용되는 EFI 바이너리 포함), systemd-boot-tools(tools포함 ) 및 systemd-boot 메타 패키지(자체 및 다른 패키지의 업그레이드 시 실행되고 systemd-boot를 부트로더로 설치하는 후크 포함)로 더욱 세분화되었습니다.
Proxmox Systems는 일반적으로 systemd-boot를 루트 ZFS 및 보안 부팅 없이 UEFI 부팅하는 등 일부 구성에서만 부팅을 사용하므로 proxmox-boot-tool, systemd-boot 메타 패키지를 제거해야 합니다. 이 패키지는 bookworm의 bootctl에 포함되어 있으므로 PVE 8.1부터 PVE 8.4 ISO까지 설치된 시스템에 자동으로 제공됩니다.
pve8to9체크리스트 스크립트에서 권장하는 경우 , systemd-boot 메타 패키지는 수동으로 설치하여 부트로더로 systemd-boot사용하지 않는 한 안전하게 제거할 수 있습니다. systemd-boot-efi 및 systemd-boot-tools가 필요할 경우, pve8to9는 해당 사항을 경고합니다. pve8to9 체크리스트 스크립트는 업그레이드 상태에 따라 출력을 변경하며, 업그레이드 전후에 지속적으로 실행되어야 합니다. 해당 스크립트는 적절한 시점에 제거하거나 추가해야 할 패키지를 표시합니다.
systemd-boot 메타 패키지를 설치해 두어야 하는 유일한 상황은 시스템을 systemd-boot수동으로 설정하는 경우입니다.
systemd-boot에 대한 버그 도 참조하세요 .
LVM Thin Pool을 수리해야 합니다.
일부 시스템에서는 업그레이드 후 LVM Thin Pool을 수동으로 복구해야 할 수 있으며, 다음과 같은 오류 메시지가 표시됩니다.
Check of pool pve/data failed (status:64). Manual repair required!
lvconvert --repair pve/data 명령을 사용하여 풀을 복구하세요. 원인은 아직 조사 중입니다.
VM 라이브 마이그레이션
다양한 호스트 CPU를 사용한 VM 라이브 마이그레이션
서로 다른 CPU 모델, 특히 서로 다른 공급업체가 있는 노드 간의 라이브 마이그레이션은 VM이 응답하지 않고 CPU 사용률이 높아지는 등의 문제를 일으킬 수 있습니다.
업그레이드 시 먼저 비운영 VM에서 라이브 마이그레이션을 테스트하는 것이 좋습니다. 따라서 라이브 마이그레이션을 사용하는 클러스터에서는 동종 설정을 사용하는 것이 좋습니다.
네트워크
네트워크 인터페이스 이름 변경
새로운 커널이 일부 하드웨어의 더 많은 기능(예: 가상 함수)을 인식하고 인터페이스 이름이 종종 PCI(e) 주소에서 파생되기 때문에 일부 NIC의 이름이 변경될 수 있으며 이 경우 네트워크 구성을 조정해야 합니다.
일반적으로 IPMI 또는 IKVM을 통해 Proxmox VE의 호스트 콘솔에 독립적인 원격 연결을 구축하거나, 주요 업그레이드 또는 네트워크 변경 후 자체 네트워크가 작동하지 않더라도 서버를 관리할 수 있는 물리적 액세스를 확보하는 것이 좋습니다.
Proxmox VE 9에는 모든 네트워크 인터페이스를 nicX 기반 이름에 고정하는 데 도움이 되는 pve-network-interface-pinning 도구가 있습니다.
기존 Ceph Full Mesh 설정이 부팅되지 않습니다.
Ceph Server 가이드를 위한 Full Mesh Network 의 이전 버전에서는 구성에 frr을 다시 시작하기 위한 post-up 줄이 포함되어 있습니다.
post-up /usr/bin/systemctl restart frr.service
Proxmox VE 9로 업그레이드하면 FRR이 이제 networking.service에 의존하게 되어 노드 재시작 시 교착 상태가 발생하므로 이 문제가 해결됩니다. 새로운 순서로 인해 FRR은 이제 항상 네트워크 구성이 적용된 후에 시작되므로 업그레이드하기 전에 네트워크 구성에서 이 줄을 삭제하면 됩니다.
cgroup V1 제거
Proxmox VE 7.0부터 기본 환경은 순수 cgroupv2입니다. Proxmox VE 8에서는 레거시 cgroupv1 환경을 수동으로 활성화할 수 있었지만, 레거시 cgroupv1 환경을 지원하지 않는 Proxmox VE 9에서는 더 이상 이 기능이 지원되지 않습니다.
즉, systemd 버전 230(2016년 출시!) 또는 이전 버전을 실행하는 컨테이너는 Proxmox VE 9에서 지원되지 않습니다. 여전히 해당 컨테이너(예: CentOS 7 또는 Ubuntu 16.04)를 실행하는 경우 남은 Proxmox VE 8 지원 주기(추정 EOL은 2026년 7월)를 해당 컨테이너 OS의 최신 버전으로 마이그레이션하는 기간으로 활용하세요.
NVIDIA vGPU 호환성
NVIDIA의 GRID/vGPU 기술을 사용하는 경우, 드라이버가 사용 중인 커널과 호환되어야 합니다. 업그레이드하기 전에 호스트에서 GRID 버전 18.3(드라이버 버전 570.158.02 – 2025년 7월 기준) 이상을 사용해야 합니다. 이전 버전(예: 15.x)은 커널 버전 6.0 이상과 호환되지 않으며, Proxmox VE 9.0에는 커널 버전 6.14 이상이 포함되어 있습니다.
베타 버전에서는 호환성을 보장할 수 없습니다. 테스트된 버전의 최종 목록은 https://pve.proxmox.com/wiki/NVIDIA_vGPU_on_Proxmox_VE에서 확인하세요.
표시된 VM 메모리 소비량이 더 높습니다.
경우에 따라 업그레이드 후 VM의 Memory usage성능이 더 높아질 수 있습니다. 심지어 100%를 조금 넘을 수도 있습니다.
VM이 자세한 메모리 사용량을 보고하지 않는 경우, Proxmox VE는 호스트의 메모리 사용량을 표시합니다. Proxmox VE 9에서는 호스트의 메모리 사용량 계산 방식이 조정되어 VM의 메모리 오버헤드를 고려합니다. 따라서 경우에 따라 백분율이 100% 이상으로 치솟을 수 있습니다.
새 Host memory usage 필드가 VM 요약 패널의 Memory Usage 필드와 동일하면 Proxmox VE가 VM의 내부 메모리 사용 정보를 수집하지 못한 것입니다.
다음 조건 중 하나가 적용되는 경우 이런 일이 발생합니다.
Ballooning DeviceVM의 고급 메모리 설정에서 이 기능이 비활성화되었습니다.이렇게 하면 게스트의 내부 메모리 사용 정보를 수집하는 통신 채널이 제거됩니다.- 게스트는 자세한 메모리 사용 정보를 보고하지 않습니다.
- 예를 들어, FreeBSD는 메모리 사용 세부 정보를 보고하지 않는 것으로 알려져 있는데, 여기에는 pfSense 나 OPNsense 와 같은 인기 있는 방화벽도 포함됩니다 .
- Windows 게스트에
BalloonService가 설치되지 않았거나 실행 중이 아닌 경우 .
QEMU 머신 버전 10.0 이상을 사용하는 VM에서 Veeam 백업이 작동하지 않습니다.
Thick LVM 스냅샷과 같은 기능을 준비하기 위해 Proxmox VE가 디스크를 QEMU에 내부적으로 연결하는 방식을 변경해야 했습니다. 이는 QEMU 머신 버전 10.0이상을 사용하는 가상 머신에 적용됩니다. Veeam은 아직 이러한 변경 사항에 적응하지 못했습니다. 영향을 받는 가상 머신의 머신 버전을 고정 9.2+pve1하거나 업그레이드를 연기하십시오.
가상 머신용 커널 6.14를 사용한 호스트 PCI 패스스루가 가끔씩 중단됨
일부 사용자들은 PCI 패스스루를 사용하는 가상 머신이 커널 6.14를 사용할 때 더 이상 시작되지 않는다고 보고했습니다. 해결 방법은 이전 커널을 부팅하는 것입니다. 이 문제를 해결하려면 이전 커널을 고정하세요.
문제 해결
“trixie” 업그레이드 실패
Trixie의 저장소 구성이 올바른지 확인하세요.
네트워크 장애가 발생하여 업그레이드가 부분적으로만 완료된 경우 다음을 통해 상황을 복구해 보세요.
apt -f install
다음 메시지가 표시되면:
W: (pve-apt-hook) You are attempting to remove the meta-package 'proxmox-ve'!
그러면 적절한 Trixie 저장소가 구성되지 않았기 때문에 현재 존재하는 패키지 중 하나 이상을 업그레이드할 수 없습니다.
이전에 사용된 저장소(예: Bookworm의 경우) 중 Trixie에 존재하지 않거나 Bookworm의 저장소로 업그레이드되지 않은 저장소가 무엇인지 확인하세요.
해당 Trixie 저장소가 있는 경우 구성을 업그레이드합니다( Ceph 패키지 저장소 업데이트 섹션도 참조하세요 ).
업그레이드가 불가능한 경우 업그레이드 시도 전 상태로 모든 저장소를 구성한 후 다음을 실행합니다.
apt update
다시 한 번. 그런 다음 해당 저장소에 현재 설치된 모든 패키지를 제거합니다. 그런 다음 업그레이드 절차를 다시 시작합니다.
grub 실패로 인해 부팅할 수 없습니다.
Grub 실패에서 복구를 참조하세요 .
Proxmox VE 6.4 ISO 이전의 레거시 BIOS 부팅을 사용하여 ZFS에 시스템을 설치한 경우, grub의 ZFS 구현과 최신 ZFS 버전 간의 비호환성으로 인해 부팅이 중단될 수 있습니다. 자세한 내용은 proxmox-boot-tool ZFS로 전환하는 방법(Proxmox 부팅 도구로 레거시 부팅 전환) 문서를 참조하세요.
