Proxmox VE 운영 레퍼런스 (릴리즈 9.1.2)
노드, 게스트, 서비스는 다운되거나, 연결이 끊기거나, 작업 중 사라질 수 있습니다.
절대 가정하지 마십시오: 실제 상태를 다시 조회하고, 타임아웃 내에 재시도하며, 우아하게 성능을 저하시키십시오.
자체 치유 패턴은 bitranox:coding-resilience를 참조하십시오.
1. 클러스터 구성 (자동 탐지)
| 확인 사항 | 명령어 |
|---|---|
| 환경 | pveversion --verbose (전체 컴포넌트 버전: 커널, pve-manager, corosync, qemu-server) |
| 노드 | pvecm nodes (개수, 이름, ID) / pvecm status (IP, 쿼럼, 전송, 링크 상태) |
| 쿼럼 | pvecm status -- "Quorate" 필드 확인. 임계값: floor(총_노드_수/2) + 1 |
| API 접근 | pvesh (로컬 CLI), pveproxy (HTTPS :8006), REST API. 스크립트에는 --output-format json 사용 |
| 스토리지 | pvesm status (활성 스토리지) / cat /etc/pve/storage.cfg (전체 구성) |
| 네트워크 | pvesh get /nodes/{노드}/network --output-format json / cat /etc/network/interfaces |
| 구독 | pvesubscription get (상태 확인) / pvesubscription set <키> (키 적용) |
2. 안전 프로토콜
| 규칙 | 세부 사항 |
|---|---|
| 파괴적 대량 작업 금지 | 1개 이상의 노드에 영향을 미치는 명령어(재부팅, 종료, 대량 VM 중지)는 명시적인 사용자 확인이 필요합니다. |
| 쿼럼 확인 | 노드 재부팅/유지보수 전: pvecm status. (현재 - 1) < floor(총계/2) + 1 이면 중단. 2-노드 클러스터에서는 QDevice 확인. |
| 먼저 백업 | VM 구성 변경 또는 업그레이드 전에 백업 존재 확인: pvesm list {스토리지} --content backup |
| 강제 삭제 금지 | 리소스 ID 확인 없이 --purge 또는 --force 사용 금지: qm config {VMID} 또는 pct config {VMID} |
| HA 상태 | HA 리소스 변경 전: ha-manager status -- 진행 중인 마이그레이션/펜싱이 없는지 확인. |
| 네트워크 변경 | 항상 먼저 드라이 런: ifreload -a -n (ifupdown2에는 --test 없음). 게스트 트래픽을 전달하는 브리지에서 ifdown 사용 금지. 원격 적용 및 DHCP/본드/WLAN 트랩: references/host-networking.md 참조. |
| Corosync 구성 | 먼저 복사, 복사본 편집, 현재 백업, 그런 다음 이동. 항상 config_version 증가. |
| 스토리지 작업 | 스토리지 제거 전: pvesm list {스토리지}로 VM/CT가 참조하지 않는지 확인. |
| 보호 플래그 | qm set {VMID} --protection 1 / pct set {VMID} --protection 1로 실수로 삭제 방지. |
| ZFS 속성 전체 검사 | PVE는 게스트의 구성된 디스크 크기를 데이터 세트의 refquota로 저장합니다. 모든 데이터 세트에서 refquota/refreservation을 지우는 전체 검사는 각 게스트의 디스크 제한을 조용히 제거하는 반면 pct config는 여전히 이전 크기를 보고하므로 하나의 컨테이너가 풀을 채울 수 있습니다. subvol- 또는 vm-로 시작하는 리프 이름은 제외하십시오. |
3. 액션 리뷰 프로토콜
필수. Proxmox 노드, VM 또는 컨테이너에서 직접 실행되는 모든 액션(명령어, 구성 변경, 서비스 작업) 전에 이 리뷰를 수행하십시오.
예외: 읽기 전용 작업 - 로그 읽기, 상태 조회, 변경 없이 정보 수집 - 은 안전한 것으로 간주되며 이 리뷰 없이 즉시 수행할 수 있습니다.
이 게이트는
opus에서 실행하십시오. 이 강력한 방어/레드팀 판단은 라이브 인프라에 대한 변경을 제어합니다 - 약한 모델은 중단, 데이터 손실 및 쿼럼 위험을 과소평가합니다.opus에서 리뷰를 수행하십시오: 고정된opus서브에이전트에medium노력으로 위임(리뷰 디스패치, bitranox:process-agents-subagent-driven-development "리뷰 디스패치" 참조)하거나, (인라인으로 유지하는 경우) 실행 전에 스위치-모델-또는-계속 진행을 제안하십시오. 알 수 없는 하위 계층에서 이 게이트를 실행하지 마십시오.bitranox:process-agents-subagent-driven-development("세션 모델은 고정됨" / "구체적인 계층") 참조.
3.1 강력한 방어 프롬프트
Proxmox 서버에서 실행될 계획된 액션 또는 구성을 이상적이고 가장 성공적인 형태로 고려하십시오. 이 액션이 가장 안전하고, 효율적이며, 최적으로 통합된 솔루션을 나타낸다고 상상하십시오. 이 액션이 시스템 관리 목표를 완벽하게 충족하고, 안정성을 높이며, 사용자 요구를 완전히 충족시키는 방법을 설명하십시오.
3.2 레드팀 프롬프트
마치 경험 많은 관리자 또는 보안 분석가처럼 잠재적인 위험을 찾아내기 위해 계획된 Proxmox 액션을 검토하십시오. 구성의 가능한 약점, 중단 위험, 데이터 손실 또는 의도하지 않은 부작용을 식별하십시오. 최악의 시나리오에서 계획의 견고성을 테스트하여 압박 속에서도 안전하고 신뢰할 수 있는지 확인하십시오.
3.3 결정
레드팀 리뷰가 끝나면 식별된 위험 또는 약점이 계획된 액션을 중단할 만큼 심각한지 평가하십시오. 액션이 안전하고, 논리적이며, 견고해 보이면 즉시 실행할 수 있습니다. 중대한 불확실성이 남아 있으면 사용자에게 명시적으로 확인을 요청해야 합니다. 명확한 결정으로 결론을 내리십시오: "액션 실행" 또는 "사용자에게 확인 요청".
4. 코드 및 응답 스타일
- 응답: 짧고, 정확하며, CLI 중심(
pvesh,pvecm,pvesm,qm,pct,ha-manager,vzdump,pvesr,pvenode,pveceph,pveum,pveam). - 문제 해결: 항상 먼저 로그 조회:
journalctl -u pvedaemon -n 50,pvenode task list --errors 1,/var/log/pveproxy/access.log. - JSON 선호:
--output-format json또는json-pretty사용. 스크립트 구문 분석에는--noborder --noheader사용. - 롤백 계획: 모든 변경에는 롤백이 포함되어야 합니다. 먼저 구성 파일을 백업하십시오. 스토리지/VM 변경 전에 백업이 있는지 확인하십시오.
5. 클러스터 크기 빠른 표
| 크기 | 동작 |
|---|---|
| 단일 노드 | 클러스터 작업 없음. HA 없음. 로컬 스토리지 + 외부 백업에 집중. |
| 2-노드 | QDevice 강력 권장. 없으면: 노드 1개 손실 = 쿼럼 손실. 비상시 pvecm expected 1. |
| 3+ 노드 | 전체 HA. floor((N-1)/2) 실패 허용(3노드: 1, 5노드: 2). |
노드 수 탐지: pvecm nodes | grep -c '^\s*[0-9]'
6. 문제 해결 빠른 참조
| 문제 | 진단 |
|---|---|
| 클러스터에 쿼럼이 없음 | pvecm status > "Quorate: No". 연결 확인, systemctl status corosync. 비상시: pvecm expected 1. |
| 노드가 가입되지 않음 | UDP 5405-5412, 시간 동기화, SSH(TCP 22) 확인. 시도: pvecm add {IP} --fingerprint {SHA256}. |
| VM이 시작되지 않음 | 잠금 확인. |
(원본 문서가 잘렸으므로 여기서 종료)