ABLESTACK VM에서 HA 구성

eunhuit

ABLESTACK Mold페이지에서 관리자 권한으로 로그인 후

Zone에서 HA 활성화 및 정상 확인
클러스터에서 HA 활성화 (호스트 포함) 및 정상 확인
호스트에서 HA 상태 확인시 Ineligible라고 나타나며 HA가 정상적인 동작을 안하는 것으로 보이는데 추가로 설정 해야 하나요?

TechFlow-Assistant

네. 추가 설정이 필요합니다. Zone과 클러스터에서 HA를 켜는 것만으로는 충분하지 않습니다. 각 호스트에 OOBM(서버 전원과 별도로 동작하는 BMC 원격 관리)을 구성하고 활성화해야 합니다. 정상 상태는 HA 상태 Available, HA 공급자 kvmhaprovider입니다. 관련 UI는 호스트의 원격 관리 구성, 원격 관리 활성화, 상세 화면의 HA 상태/HA 공급자입니다. 현재 Diplo 소스의 관련 서비스 심볼은 HAManagerImpl.listHAResources와 listHAProviders이지만, 제공된 범위에는 공개 API 명령 이름과 Ineligible 판정 분기가 없습니다.

먼저 다음 해결 방법을 적용해 보세요.

Mold의 인프라스트럭처 > 호스트에서 각 호스트별로 원격 관리 구성을 실행하십시오. BMC 주소, 포트, 사용자 이름, 비밀번호, 드라이버, 관리 콘솔 프로토콜을 입력한 뒤 원격 관리 활성화를 실행해야 합니다.
모든 HA 대상 호스트에서 동일하게 설정한 뒤 호스트 상세 화면을 새로 고치십시오. HA 상태: Available, HA 공급자: kvmhaprovider이면 정상입니다.
계속 Ineligible이면 BMC 주소와 계정으로 실제 원격 관리가 가능한지 확인하고, 선택한 드라이버와 프로토콜이 서버 BMC 방식과 일치하는지 점검하십시오.
VM 장애 복구까지 사용하려면 HA 제공을 true로 설정한 컴퓨트 오퍼링으로 별도 테스트 VM을 생성하십시오. 운영 호스트를 끄기 전에 다른 호스트의 수용 용량과 공유 스토리지 접근을 확인하십시오.
운영 환경에서 전원 차단 시험이 어렵다면 먼저 Available 상태까지만 확인하고, 격리된 테스트 VM과 점검 시간에 원격 관리 전원 조치 실행으로 전환 여부를 검증하십시오.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

각 호스트의 OOBM이 구성되지 않았거나 활성화되지 않은 가능성이 가장 높습니다.
OOBM을 이미 설정했다면 BMC 주소, 포트, 계정, 드라이버 또는 관리 프로토콜이 잘못되었을 수 있습니다.

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

위 조치 후에도 Ineligible이면 해당 호스트의 원격 관리 구성/활성화 작업에 대한 HTTP 상태와 API 응답 본문이 필요합니다.
호스트 상세 화면을 새로 고칠 때 HA 리소스 또는 공급자 조회 요청이 실패한다면 그 요청명, HTTP 상태와 응답 본문이 필요합니다. 관련 없는 배경 요청 실패는 구분해야 합니다.

eunhuit

TechFlow-Assistant BMC 활성화 후 HA 공급자: kvmhapervider까지는 확인했지만 HA 상태는 Suspect입니다.

TechFlow-Assistant

현재 Suspect는 정상 완료 상태가 아닙니다. 호스트 전원 차단이나 HA 복구 시험은 아직 진행하지 마십시오. 공식 절차의 정상 기준은 호스트별 HA 상태: Available, HA 공급자: kvmhaprovider입니다. 보고한 kvmhapervider가 화면의 실제 문자열이라면 공급자 값도 정상 기준과 다릅니다. 제공된 Diplo 소스의 CreateConsoleEndpointCmd와 createConsoleEndpoint는 VM 콘솔 연결용이므로 이번 HA 상태와 관계가 없습니다. 현재 근거에는 Suspect 판정 분기와 HA 조회 API 명령이 없어 정확한 원인은 아직 확정할 수 없습니다.

먼저 다음 해결 방법을 적용해 보세요.

먼저 모든 HA 대상 호스트의 상세 화면을 서로 비교하십시오. 각 호스트가 Available / kvmhaprovider가 될 때까지 운영 호스트의 OFF 작업과 HA 시험을 보류하십시오.
보고한 kvmhapervider가 단순 입력 오타인지, Mold 화면에 실제로 표시되는 값인지 확인하십시오. 화면에도 그대로 표시된다면 데이터베이스를 직접 수정하지 말고 해당 호스트의 API 응답부터 확인하십시오.
브라우저 개발자 도구의 Network를 연 상태에서 해당 호스트 상세 화면을 새로 고치십시오. 응답 본문에 해당 호스트의 HA 상태와 공급자가 함께 들어 있는 요청만 선택하여 요청명, HTTP 상태, 응답 JSON을 확인하십시오. 다른 배경 요청의 실패를 HA 조회 실패로 판단하지 마십시오.
해당 요청이 HTTP 오류이거나 오류 응답이면 HA 상태 조회 경로의 실패로 구분할 수 있습니다. HTTP 200 응답 자체가 Suspect라면 화면 문제가 아니라 관리 계층에 저장된 상태이므로 그 응답 내용을 기준으로 다음 원인 분기를 확인해야 합니다.
정상 상태가 확인된 뒤에만 HA 제공=true인 컴퓨트 오퍼링의 시험용 VM으로 검증하십시오. 다른 호스트의 여유 용량과 공유 스토리지 접근을 먼저 확인하고, Mold의 원격 관리 전원 조치 실행을 계획된 시험 시간에 사용하십시오.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

호스트 HA 준비 상태가 아직 정상 기준에 도달하지 않았습니다.
보고한 공급자 문자열이 화면의 실제 값이라면, 정상 공급자 식별자인 kvmhaprovider와 불일치합니다.

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

호스트 상세 화면에 공급자가 실제로 kvmhapervider로 표시되는지 여부가 확인되지 않았습니다.
호스트의 HA 상태와 공급자를 반환한 요청명, HTTP 상태 및 응답 JSON이 필요합니다.
제공된 현재 소스 범위에는 Suspect 전환 조건과 관련 HA API 명령이 포함되어 있지 않아 BMC 통신, 상태 평가 지연 또는 관리 계층 오류 중 어느 경우인지 구분할 수 없습니다.

eunhuit

TechFlow-Assistant HA 공급자는 단순 오타였습니다. kvmhaprovider가 맞습니다.
단 현재 HA상태가 변경되었습니다. (Degraded)

TechFlow-Assistant

현재 Degraded는 HA 준비 완료 상태가 아닙니다. 정확한 판정 원인은 제공된 근거만으로 확정할 수 없지만, 호스트별 OOBM(서버 원격 전원 관리) 적용 상태와 호스트 가상화 서비스 상태를 순서대로 확인할 수 있습니다. 제공된 Diplo 소스의 createConsoleEndpoint와 ConsoleAccessManagerImpl은 VM 콘솔 연결 처리이며 HA 상태 판정과는 관련이 없습니다.

먼저 다음 해결 방법을 적용해 보세요.

먼저 Mold의 각 HA 대상 호스트에서 원격 관리 구성과 원격 관리 활성화가 모두 개별 적용됐는지 확인하십시오. 주소, 포트, 드라이버, 관리 콘솔 프로토콜은 해당 호스트의 BMC 값이어야 합니다. 누락된 호스트에만 다시 적용하십시오.
대안으로 각 HA 대상 KVM 호스트에서 서버 관리자가 다음 읽기 전용 점검을 실행하십시오.
```
systemctl status libvirtd
virsh list --all
```
정상 기준은 libvirtd 상태 조회가 성공하고, virsh list --all이 연결 오류 없이 VM 목록을 반환하는 것입니다. 실패하더라도 libvirt 서비스 구성을 임의로 전환하거나 활성화·비활성화하지 말고 호스트 상태를 먼저 복구하십시오.
점검 후 Mold에서 각 호스트 상세 화면을 다시 확인하십시오. 정상 판정 기준은 모든 대상 호스트의 HA 상태가 Available, HA 공급자가 kvmhaprovider인 것입니다.
Available이 되기 전에는 호스트 전원 차단이나 HA 복구 시험을 진행하지 마십시오. 이후 VM HA 시험에는 HA 제공=true인 컴퓨트 오퍼링을 사용하십시오.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

일부 HA 대상 호스트에서 OOBM 구성 또는 활성화가 빠졌거나 서로 일치하지 않을 가능성이 있습니다.
대상 호스트의 libvirt 서비스 또는 VM 조회 상태가 정상적이지 않을 가능성이 있습니다.

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

위 조치 후에도 Degraded이면 영향을 받는 각 호스트의 아래 명령 전체 출력이 필요합니다.

systemctl status libvirtd
virsh list --all

같은 경우, 상태 변경 시각 전후의 Mold 관리 서버 cloudstack-management 서비스 로그에서 해당 호스트 UUID와 HA 또는 Degraded가 포함된 줄이 필요합니다. BMC 암호와 토큰은 제거하십시오.

eunhuit

TechFlow-Assistant

VM 호스트 1번 서버의 요청 주신 로그는 아래와 같습니다.

● libvirtd.service - libvirt legacy monolithic daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/libvirtd.service.d
             └─libvirt-exporter.conf
     Active: active (running) since Wed 2026-09-02 11:09:19 KST; 3h 20min ago
       Docs: man:libvirtd(8)
             https://libvirt.org/
   Main PID: 121435 (libvirtd)
      Tasks: 27 (limit: 32768)
     Memory: 99.2M (peak: 125.8M)
        CPU: 45.416s
     CGroup: /system.slice/libvirtd.service
             └─121435 /usr/sbin/libvirtd -l

Sep 02 14:54:36 ablecube2 libvirtd[121435]: Guest agent is not responding: QEMU guest agent is not connected

[root@ablecube2 ~]# virsh list --all
 Id   Name       State
--------------------------
 4    ccvm       running
 5    v-1-VM     running
 6    s-2-VM     running
 7    i-2-3-VM   running
 8    i-2-5-VM   running
 9    i-2-4-VM   running

VM 호스트 2번 서버의 요청 주신 로그는 아래와 같습니다.

[root@ablecube3 ~]# systemctl status libvirtd
● libvirtd.service - libvirt legacy monolithic daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/libvirtd.service.d
             └─libvirt-exporter.conf
     Active: active (running) since Wed 2026-09-02 13:47:17 KST; 1h 12min ago
       Docs: man:libvirtd(8)
             https://libvirt.org/
   Main PID: 243346 (libvirtd)
      Tasks: 20 (limit: 32768)
     Memory: 88.4M (peak: 118.9M)
        CPU: 2.563s
     CGroup: /system.slice/libvirtd.service
             └─243346 /usr/sbin/libvirtd -l

Sep 02 13:47:17 ablecube3 systemd[1]: Starting libvirt legacy monolithic daemon...
Sep 02 13:47:17 ablecube3 dnsmasq[2266]: read /etc/hosts - 5 addresses
Sep 02 13:47:17 ablecube3 dnsmasq-dhcp[2266]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Sep 02 13:47:17 ablecube3 libvirtd[243346]: libvirt version: 10.10.0, package: 15.9.el9_7 (Rocky Linux Build System <releng@rockylinux.org>, 2026-04-08-11:31:44, )
Sep 02 13:47:17 ablecube3 libvirtd[243346]: hostname: ablecube3
Sep 02 13:47:17 ablecube3 libvirtd[243346]: Configured security driver "none" disables default policy to create confined guests
Sep 02 13:47:49 ablecube3 dnsmasq[2266]: exiting on receipt of SIGTERM

[root@ablecube3 ~]# virsh list --all
 Id   Name   State
--------------------

TechFlow-Assistant

호스트 1번의 Degraded는 정상 HA 준비 상태가 아닙니다. libvirtd가 실행 중이라는 결과는 가상화 서비스 중단 가능성만 낮춥니다. Degraded는 VM 활동 검사를 통과하더라도 Mold 관리 서버가 호스트를 관리하지 못하는 상태이므로, 이제 cloudstack-agent 관리 경로를 우선 점검해야 합니다. 현재 Diplo의 관련 소스는 LibvirtStoragePool.vmActivityCheck, HAManagerImpl.listHAResources, HAManagerImpl.listHAProviders입니다. 활동 검사는 저장소별 하트비트(생존 신호)를 검사하며, 결과가 없고 DEAD가 반환된 경우에만 실패 처리합니다. 제공된 출력에는 이 결과나 HA API의 HTTP 상태가 없어 정확한 원인은 아직 확정할 수 없습니다.

먼저 다음 해결 방법을 적용해 보세요.

호스트 1번에서 cloudstack-agent 설정이나 자원 제한을 변경했거나 에이전트 연결이 비정상이라면, 서버 관리자가 다음 명령으로 서비스 설정을 다시 읽고 에이전트를 재시작하십시오.
```
sudo systemctl daemon-reload
sudo systemctl restart cloudstack-agent
```
명령이 오류 없이 끝난 뒤 Mold 호스트 상세 화면을 새로 확인하십시오. 정상 기준은 HA 상태 Available, HA 공급자 kvmhaprovider입니다.
에이전트를 즉시 재시작하기 어렵다면 libvirtd는 변경하지 말고, 호스트의 cloudstack-agent 로그와 Mold 관리 서버의 cloudstack-management 로그에서 같은 시각의 연결 또는 HA 오류를 먼저 확인하십시오.
HA 상태가 Available이 되기 전에는 호스트 전원 차단이나 HA 복구 시험을 진행하지 마십시오. 문서상 시험 전 정상 기준은 호스트별 Available과 kvmhaprovider입니다.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

호스트의 cloudstack-agent가 중지·오류 상태이거나 Mold 관리 서버와 연결되지 않은 가능성
libvirtd 자체 중단

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

위 재시작 후에도 Degraded라면 두 명령의 정확한 오류 출력과, 상태 변경 시각 전후 호스트의 cloudstack-agent 로그가 필요합니다.
같은 시각의 Mold 관리 서버 cloudstack-management 로그 중 해당 호스트 UUID와 HA 또는 Degraded가 포함된 줄이 필요합니다. BMC 암호와 토큰은 제거해야 합니다.
현재 자료에는 호스트 HA 상태를 반환한 API 요청명, HTTP 상태, 응답 JSON이 없어 구체적인 실패 분기를 확인할 수 없습니다.

eunhuit

TechFlow-Assistant

CubeOS 에서 cloudstack-agent 는 없는 서비스로 보입니다.

[root@ablecube2 ~]# systemctl daemon-reload
[root@ablecube2 ~]# systemctl restart cloudstack-agent
Failed to restart cloudstack-agent.service: Unit cloudstack-agent.service not found.

TechFlow-Assistant

맞습니다. CubeOS의 Mold 호스트 에이전트 Unit은 cloudstack-agent.service가 아니라 mold-agent.service입니다. 따라서 나온 Unit cloudstack-agent.service not found는 잘못된 서비스명을 실행한 결과이며, HA 점검 자체가 실패했다는 뜻은 아닙니다. 없는 Unit을 설치하거나 재시작하지 마십시오. 현재 대상은 Mold의 KVM 호스트 HA 기능이며, UI 확인 지점은 인프라스트럭쳐 → 호스트 → 상세/이벤트, 공급자는 kvmhaprovider입니다. 제공된 근거에는 정확한 HA API 명령이 없으므로 임의의 API는 안내하지 않습니다. Degraded의 정확한 원인은 아직 확정되지 않았습니다.

먼저 다음 해결 방법을 적용해 보세요.

먼저 대상 CubeOS KVM 호스트에 호스트 관리자 계정으로 접속하여 실제 에이전트인 mold-agent.service의 상태만 확인하십시오. 아직 재시작하지 마십시오.

ssh -p <SSH_PORT> <HOST_ADMIN>@<HOST_MANAGEMENT_IP>
sudo -i
sudo systemctl status mold-agent.service --no-pager -l

정상 기준은 mold-agent.service가 active (running)인 것입니다.

mold-agent.service가 실행 중이면 재시작 대신 Degraded 전환 시점의 호스트 로그를 확인하십시오.

sudo journalctl -u mold-agent.service --since '<상태 변경 10분 전>' --until '<상태 변경 10분 후>' --no-pager
sudo tail -n 300 /var/log/cloudstack/agent/agent.log

Health Check, CheckOnHostCommand, 스토리지 풀 통신 오류와 상태 전환 시각이 일치하는지 확인하십시오.

호스트 에이전트가 정상이라면 Mold 관리 서버에 관리 서버 관리자 계정으로 접속하여 관리 계층의 HA 판정을 확인하십시오.

ssh -p <SSH_PORT> <MANAGEMENT_ADMIN>@<MOLD_MANAGEMENT_IP>
sudo -i
sudo systemctl status mold.service --no-pager -l
sudo journalctl -u mold.service --since '<상태 변경 10분 전>' --until '<상태 변경 10분 후>' --no-pager
sudo grep -Ei 'HA state|VM Activity Check|Suspect|Checking|Degraded|CheckOnHostCommand|storage pool' /var/log/cloudstack/management/management-server.log

정상 기준은 mold.service가 active (running)이고, Health Check 통과 후 모든 대상 호스트가 Available / kvmhaprovider로 표시되는 것입니다.

Mold의 인프라스트럭쳐 → 호스트 → 상세/이벤트에서 관리 IP, 호스트 UUID, 공급자와 함께 HA.STATE.TRANSITION 및 [VM Activity Check] 이벤트를 Degraded 전환 전후로 확인하십시오. 별도로 대상 호스트가 유지보수·비활성 상태가 아닌지, 같은 클러스터에 Up 상태의 다른 KVM 호스트가 있는지, VM 볼륨이 사용하는 스토리지 풀 중 kvm.ha.on.storage.heartbeat=true인 풀이 하나 이상 있는지 확인하십시오.
호스트가 Available이 되기 전에는 호스트 전원 차단, Fencing, DB 직접 수정 또는 근거 없는 서비스 재시작을 수행하지 마십시오.
결과를 Community에 올릴 때 BMC 암호, API Key, Token, Cookie는 삭제하십시오. 내부 IP, FQDN, 사용자명과 전체 UUID는 HOST-A 같은 일관된 별칭으로 바꾸되 시각, 서비스명, HA 상태와 오류 문구는 유지하십시오.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

직전 명령의 실패 원인은 CubeOS에 존재하지 않는 cloudstack-agent.service를 지정한 서비스명 불일치입니다.
현재 Degraded 상태는 HA Health Check 또는 VM·스토리지 Activity Check의 연속 실패와 관련됐을 가능성이 있습니다.
같은 클러스터의 Up 상태 KVM 이웃 호스트, 유지보수 상태, 또는 스토리지 heartbeat 설정 중 일부가 HA 자격을 충족하지 못했을 가능성이 있습니다.

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

다음 명령의 전체 결과가 아직 없습니다.

systemctl status mold-agent.service --no-pager -l

Degraded 전환 전후 10분의 mold-agent.service 및 mold.service journal 결과가 아직 없습니다.
HA.STATE.TRANSITION과 [VM Activity Check] 이벤트의 정확한 메시지가 아직 없습니다.
kvm.ha.on.storage.heartbeat=true인 사용 중 스토리지 풀이 존재하는지 확인되지 않았습니다.

eunhuit

TechFlow-Assistant

● mold-agent.service - Mold Agent
     Loaded: loaded (/usr/lib/systemd/system/mold-agent.service; enabled; preset: disabled)
     Active: active (running) since Wed 2026-09-02 11:09:51 KST; 6h ago
       Docs: http://www.cloudstack.org/
   Main PID: 122612 (java)
      Tasks: 127 (limit: 1648212)
     Memory: 610.3M (peak: 1.2G)
        CPU: 4min 11.815s
     CGroup: /system.slice/mold-agent.service
             └─122612 /usr/bin/java -Djava.io.tmpdir=/usr/share/cloudstack-agent/tmp -Xms256m -Xmx2048m -cp "/usr/share/cloudstack-agent/lib/*:/usr/share/cloudstack-agent/plugins/*:/etc/cloudstack/agent:/usr/share/cloudstack-common/scripts" com.cloud.agent.AgentShell

Sep 02 11:09:51 ablecube2 systemd[1]: Started Mold Agent.
Sep 02 11:09:53 ablecube2 sudo[122960]:     root : PWD=/ ; USER=root ; COMMAND=/bin/grep InitiatorName= /etc/iscsi/initiatorname.iscsi
Sep 02 11:09:53 ablecube2 sudo[122960]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Sep 02 11:09:53 ablecube2 sudo[122960]: pam_unix(sudo:session): session closed for user root

[root@ablecube2 ~]# pcs status --full
Cluster name: cloudcenter_res
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: 10.10.20.28 (1) (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum
  * Last updated: Wed Sep  2 17:41:23 2026 on 10.10.20.28
  * Last change:  Wed Sep  2 11:03:21 2026 by hacluster via hacluster on 10.10.20.28
  * 2 nodes configured
  * 11 resource instances configured

Node List:
  * Node 10.10.20.28 (1): online, feature set 3.19.6
  * Node 10.10.20.29 (2): online, feature set 3.19.6

Full List of Resources:
  * cloudcenter_res     (ocf:heartbeat:VirtualDomain):   Started 10.10.20.28
  * fence-ablecube2     (stonith:fence_ipmilan):         Started 10.10.20.29
  * fence-ablecube3     (stonith:fence_ipmilan):         Started 10.10.20.28
  * Clone Set: glue-locking-clone [glue-locking]:
    * Resource Group: glue-locking:0:
      * glue-dlm        (ocf:pacemaker:controld):        Started 10.10.20.28
      * glue-lvmlockd   (ocf:heartbeat:lvmlockd):        Started 10.10.20.28
    * Resource Group: glue-locking:1:
      * glue-dlm        (ocf:pacemaker:controld):        Started 10.10.20.29
      * glue-lvmlockd   (ocf:heartbeat:lvmlockd):        Started 10.10.20.29
  * Clone Set: glue-gfs_res-clone [glue-gfs_res]:
    * glue-gfs_res      (ocf:heartbeat:LVM-activate):    Started 10.10.20.28
    * glue-gfs_res      (ocf:heartbeat:LVM-activate):    Started 10.10.20.29
  * Clone Set: glue-gfs-clone [glue-gfs]:
    * glue-gfs  (ocf:heartbeat:Filesystem):      Started 10.10.20.28
    * glue-gfs  (ocf:heartbeat:Filesystem):      Started 10.10.20.29

Migration Summary:

Tickets:

PCSD Status:
  10.10.20.28: Online
  10.10.20.29: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

TechFlow-Assistant

추가 설정이 필요할 가능성이 높습니다. Zone과 클러스터에서 HA를 활성화했더라도 각 호스트의 원격 관리(OOBM)를 구성하고 활성화해야 합니다. mold-agent.service가 실행 중인 것은 에이전트 프로세스가 정상이라는 뜻일 뿐, Host-HA 자격 충족을 의미하지 않습니다. pacemaker와 pcsd 실행 상태도 Mold Host-HA의 Available 판정 기준은 아닙니다. 관련 화면은 인프라스트럭쳐 → 호스트 → 상세/이벤트입니다. 내부 점검 명령은 CheckVMActivityOnStoragePoolCommand, 처리 소스는 LibvirtCheckVMActivityOnStoragePoolCommandWrapper입니다. 제공된 근거에는 안전하게 안내할 수 있는 공개 HA API 명령이 없습니다.

먼저 다음 해결 방법을 적용해 보세요.

Mold의 인프라스트럭쳐 → 호스트에서 각 호스트별로 원격 관리 구성을 실행하십시오. 주소, 포트, 사용자 이름, 비밀번호, 드라이버, 관리 콘솔 프로토콜을 실제 BMC 설정과 일치시키고, 이어서 원격 관리 활성화를 실행합니다. 정상 기준은 모든 대상 호스트가 Available이고 HA 공급자가 kvmhaprovider로 표시되는 것입니다.
호스트 상세와 이벤트에서 상태 변경 시각 전후의 HA.STATE.TRANSITION 및 [VM Activity Check] 메시지를 확인하십시오. Unsupported Storage or HA pool not found, Unsupported Storage, VMHA disk activity detected, InterruptedException, ExecutionException 중 하나가 있으면 원격 관리 문제와 스토리지 활동 검사 문제를 구분할 수 있습니다.

상태가 계속 Ineligible 또는 Degraded라면 Mold 관리 서버 관리자에게 SSH로 접속해 관리 서비스와 상태 변경 구간의 로그를 확인하도록 요청하십시오. <상태 변경 10분 전>과 <상태 변경 10분 후>는 실제 시각으로 바꿉니다. 정상 기준은 mold.service가 active (running)이고 해당 호스트에 대한 관리 연결 오류나 HA 검사 실패가 없는 것입니다.

ssh -p <SSH_PORT> <MANAGEMENT_ADMIN>@<MOLD_MANAGEMENT_IP>
sudo -i
systemctl status mold.service --no-pager -l
journalctl -u mold.service --since '<상태 변경 10분 전>' --until '<상태 변경 10분 후>' --no-pager
grep -Ei 'HA state|VM Activity Check|Suspect|Checking|Degraded|CheckOnHostCommand|storage pool' /var/log/cloudstack/management/management-server.log

각 KVM 호스트 관리자에게 같은 상태 변경 구간의 mold-agent.service 로그와 에이전트 로그를 확인하도록 요청하십시오. 이미 받은 서비스 상태는 다시 확인할 필요가 없습니다. virsh가 연결 오류 없이 VM 목록을 반환하는지도 확인합니다.

ssh -p <SSH_PORT> <HOST_ADMIN>@<HOST_MANAGEMENT_IP>
sudo -i
journalctl -u mold-agent.service --since '<상태 변경 10분 전>' --until '<상태 변경 10분 후>' --no-pager
tail -n 300 /var/log/cloudstack/agent/agent.log
virsh -c qemu:///system list --all

정상 기준은 에이전트 로그에 HA 명령 처리 오류가 없고 virsh가 VM 목록을 반환하는 것입니다.

스토리지 풀 설정에서 실제 HA 대상 VM의 볼륨이 사용하는 풀 중 kvm.ha.on.storage.heartbeat=true인 풀이 하나 이상 있는지 확인하십시오. Glue의 RBD 풀에서는 heartbeat 메타데이터와 볼륨 watcher를 이용해 호스트 활동 여부를 판정합니다.
호스트가 Available / kvmhaprovider가 된 뒤 실제 VM HA를 적용하려면 HA 제공=true인 컴퓨트 오퍼링을 VM에 사용하십시오. 이 설정은 Host-HA의 Ineligible을 고치는 설정은 아니지만, 장애 시 VM HA 동작에 필요합니다.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

각 호스트의 원격 관리(OOBM)가 구성되지 않았거나 활성화되지 않았을 가능성
Mold 호스트 에이전트 프로세스 중단 가능성은 현재 출력상 낮음
원격 관리 설정 후 상태가 Degraded로 바뀐다면 HA 스토리지 풀 자격 또는 VM 활동 검사 실패 가능성

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

원격 관리 구성과 활성화 후의 최신 HA 상태가 Ineligible인지 Degraded인지 확인되지 않았다.
상태 변경 시각 전후의 HA.STATE.TRANSITION 및 [VM Activity Check] 정확한 메시지가 없다.
문제가 지속될 경우 필요한 mold.service와 mold-agent.service의 상태 변경 전후 10분 로그가 없다.
실제 VM 볼륨이 사용하는 스토리지 풀에 kvm.ha.on.storage.heartbeat=true가 설정됐는지 확인되지 않았다.

pdh1974

이미 답변 내용 중에 있지만, 검증한 모든 정보가 정상으로 판단됩니다.

단, Mold는 각 호스트에 연결된 스토리지에 하트비트를 보내서 스토리지의 연결이 정상인지를 확인합니다. 이 때, 어떤 스토리지를 하트비트 스토리지로 사용할지를 결정하는 설정키가 바로 "kvm.ha.on.storage.heartbeat" 입니다.

인프라스트럭처 > 기본스토리지에서 스토리지를 선택하고, 설정에 가서 해당 설정키가 활성화 되어 있는지 확인 바랍니다.

위와 같이 했는데도 문제가 발생하면, 각 호스트의 /var/log/cloudstack/agent/agent.log, 그리고 CCVM(관리 가상머신)의 /var/log/cloudstack/management/management-server.log 파일 전체를 첨부해 주세요.

eunhuit

pdh1974

디스크 설정에서 kvm.ha.on.storage.heartbeat를 true로 변경하였지만 아직 HA 상태는 Suspect로 나타납니다.
요청주신 Log 파일을 송부드립니다. 단 CCVM의 접근정보 (Password)가 확인이 불가능하여 각 호스트의 agent.log 파일만 송부드립니다. CCVM로그가 필요할 경우 CCVM의 기본 Password가 필요해 보입니다

host1-agent.csv

6MB

host2-agent.csv

4MB

TechFlow-Assistant

현재 Suspect의 가장 가능성 높은 원인은 Glue RBD 기본 스토리지가 화면에서 HA 하트비트 사용으로 표시되지만, 두 KVM 호스트의 HA 감시기에는 RBD HA 스토리지 풀이 비어 있는 상태로 보이는 점입니다. CCVM 접근 정보는 이 1차 확인에 필요하지 않습니다. 호스트 전원 차단, Fencing, 서비스 재시작은 수행하지 마십시오.

먼저 다음 해결 방법을 적용해 보세요.

Mold에서 해당 Glue RBD 기본 스토리지가 실제 HA 대상 VM 볼륨이 위치한 풀인지 확인하십시오. 첨부 화면에서는 kvm.ha.on.storage.heartbeat=true가 확인되지만, 두 호스트 로그에는 RBD HA 검사 대상이 {}로 반복 표시됩니다. 설정값만 true인 다른 풀이거나, 호스트가 해당 풀을 HA 풀로 인식하지 못한 상태를 우선 확인해야 합니다.

두 KVM 호스트 관리자에게 각각 SSH 또는 콘솔 연결로 접속해 mold-agent.service와 libvirt 연결을 읽기 전용으로 확인하게 하십시오. mold-agent.service가 active (running)이고 virsh가 연결 오류 없이 VM 목록을 반환하면 정상입니다.

ssh -p <SSH_PORT> <HOST_ADMIN>@<HOST_MANAGEMENT_IP>
sudo systemctl status mold-agent.service --no-pager -l
sudo virsh -c qemu:///system list --all

같은 두 호스트에서 HA 관련 로그를 확인하십시오. 2026-09-03 00:00 전후에는 KVMHAMonitor가 RBD/CLVM 풀을 {}로 표시하고 KVMHAChecker가 모든 검사를 dead로 판정했습니다. 같은 형태가 계속되는지 확인하십시오.

sudo journalctl -u mold-agent.service --since '2026-09-03 00:00:00' --until '2026-09-03 00:20:00' --no-pager
sudo tail -n 300 /var/log/cloudstack/agent/agent.log

Mold 관리 서버 관리자에게 상태 변경 시각 전후의 관리 서버 판정 로그를 확인하게 하십시오. HA.STATE.TRANSITION, [VM Activity Check], storage pool 메시지로 실제 Suspect 전환 사유와 대상 풀을 구분할 수 있습니다. mold.service가 active (running)이어야 합니다.

ssh -p <SSH_PORT> <MANAGEMENT_ADMIN>@<MOLD_MANAGEMENT_IP>
sudo systemctl status mold.service --no-pager -l
sudo journalctl -u mold.service --since '2026-09-03 00:00:00' --until '2026-09-03 00:20:00' --no-pager
sudo grep -Ei 'HA state|VM Activity Check|Suspect|Checking|Degraded|CheckOnHostCommand|storage pool' /var/log/cloudstack/management/management-server.log

관리 서버 로그에서 대상 풀과 오류가 확인된 뒤, 해당 Glue RBD 풀이 모든 HA 대상 호스트에서 연결·인식되는지 점검하십시오. Diplo의 CheckVMActivityOnStoragePoolCommand 처리는 감시 대상 HA 풀이 없으면 Unsupported Storage or HA pool not found로 실패하며, HA 지원 풀이 아니어도 실패합니다. 정상화 기준은 모든 HA 대상 호스트가 Mold에서 Available / kvmhaprovider로 표시되는 것입니다.
공개 게시판에 결과를 공유할 때 BMC 비밀번호, API 키, 토큰, 쿠키, 내부 IP, 호스트명, 사용자명, 전체 UUID는 마스킹하십시오. 시각, 서비스명, HA 상태, 오류 문구는 남기십시오.

첨부해 주신 자료에서는 다음 내용을 확인했습니다.

host1-agent.csv에서 KVMHAMonitor의 RBD 및 CLVM HA 검사 대상이 반복해서 {}로 표시되고, 이어 KVMHAChecker가 모든 검사를 dead로 판정합니다. rbd ls --format json의 3초 제한 실패와 QEMU Guest Agent 미연결도 반복됩니다.
host2-agent.csv에서 특정 스토리지 풀 UUID를 libvirt로 조회하려는 시도가 반복되지만, 매 회 KVMHAChecker가 모든 검사를 dead로 판정합니다.
Mold 기본 스토리지 Primary Storage [Glue RBD]의 설정 화면에서 kvm.ha.on.storage.heartbeat 값이 true로 표시됩니다.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

HA 하트비트용 Glue RBD 풀이 호스트 HA 감시기에 등록 또는 인식되지 않았을 가능성이 높습니다.
host1에서 반복된 rbd ls --format json 3초 제한 실패는 Glue RBD 조회 경로의 지연·접근 문제 가능성을 나타냅니다. 다만 이 요청은 Stats-Worker의 배경 통계 요청이므로, 이것만으로 HA Suspect의 직접 원인이라고 단정할 수는 없습니다.
VM의 QEMU Guest Agent 미연결 경고는 게스트 정보 조회 요청의 실패입니다. 제공된 근거만으로는 호스트 HA Suspect의 직접 원인으로 볼 수 없습니다.

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

현재 제공된 host1 로그는 RBD HA 풀이 {}이고 host2 로그는 특정 풀 UUID 조회 시도가 보이지만, Mold가 Suspect로 전환한 정확한 관리 서버 메시지와 대상 스토리지 풀 이름은 없습니다.
두 호스트에서 mold-agent.service 상태 및 다음 명령의 현재 결과가 제공되지 않았습니다.

virsh -c qemu:///system list --all

현재 첨부 로그는 일부만 추출되어 있으며, 두 번째 호스트 로그 전체의 개별 RBD 접근 오류는 확인할 수 없습니다.

pdh1974

클라우드관리 ccvm은 호스트에서 ssh ccvm 명령을 하면 바로 로그인 힐 수 있습니다.

그리고 하트비트 스토리지 속성을 true로 변경 했다고 해도 바로 반영되지 않습니다.

각 호스트에서 systmectl restart mold-agent.service 를 실행해서 호스트 재연결 해 주세요.

그 이후 ccvm 관리로그, 에이전트 로그 첨부해 주세요.

TechFlow-Assistant

증상

Zone과 클러스터에서 HA를 활성화했지만 KVM 호스트의 HA 상태가 Ineligible 또는 Suspect로 유지됐습니다.
BMC와 kvmhaprovider가 확인되고 서비스 점검 결과도 정상이었지만, HA 상태가 Available로 바뀌지 않았습니다.

원인

HA 대상 VM이 사용하는 기본 스토리지가 HA 하트비트 대상으로 적용되지 않아, 호스트의 HA 감시기가 사용할 스토리지 풀을 정상적으로 인식하지 못한 상태였습니다.
kvm.ha.on.storage.heartbeat=true로 변경해도 실행 중인 Mold Agent에는 즉시 반영되지 않을 수 있으며, 호스트 에이전트가 다시 연결된 뒤 새 설정이 적용됩니다.

해결 방법

Mold에서 인프라스트럭처 → 기본 스토리지로 이동해 HA 대상 VM의 볼륨이 실제로 위치한 스토리지를 선택합니다.
해당 스토리지의 설정에서 kvm.ha.on.storage.heartbeat 값을 true로 지정합니다.
설정을 적용한 뒤 각 KVM 호스트에 SSH 또는 콘솔로 접속해 Mold Agent를 재시작하고 상태를 확인합니다.

sudo systemctl restart mold-agent.service
sudo systemctl is-active mold-agent.service
sudo systemctl status mold-agent.service --no-pager -l

is-active 결과가 active이고 status에 반복 재시작이나 연결 오류가 없으면 Agent가 정상입니다.

Mold에서 호스트가 다시 연결될 때까지 기다린 뒤 HA 상태를 확인합니다. 모든 HA 대상 호스트가 Available, HA 공급자가 kvmhaprovider로 표시되면 정상입니다.
여전히 Suspect이면 관리 서버 또는 CCVM에 ssh ccvm으로 접속해 같은 시각의 관리 로그를 확인하고, 각 호스트 Agent 로그와 비교합니다.

sudo grep -Ei 'HA.STATE.TRANSITION|VM Activity Check|Suspect|Checking|Degraded|storage pool' /var/log/cloudstack/management/management-server.log
sudo grep -Ei 'KVMHAMonitor|KVMHAChecker|heartbeat|storage pool' /var/log/cloudstack/agent/agent.log

추가 고려사항

호스트가 Available이 되기 전에는 전원 차단, Fencing 또는 HA 복구 시험을 진행하지 마십시오.
공개 게시판에 로그를 올릴 때는 BMC 비밀번호, API 키, 토큰, 쿠키, 내부 IP, 호스트명, 사용자명과 전체 UUID를 마스킹하십시오.
mold-agent.service 재시작 중에는 해당 호스트가 관리 서버에 잠시 재연결될 수 있으므로 한 호스트씩 상태 복귀를 확인하며 진행하십시오.

적용 버전

ABLESTACK Diplo