OpenStack

RHOSP OpenStack VM 기동 Action Log 분석 가이드

RHOSP Nova compute 로그에서 VM 기동 흐름을 추적하는 방법입니다. request-id, VIF, OVS tap, Cinder attachment 경고를 기준으로 실제 점검 명령과 판단 순서를 정리했습니다.

devmes

• 조회 182

RHOSP에서 VM 기동, 재기동, 마이그레이션, 인터페이스 재연결 같은 이벤트를 확인할 때 가장 먼저 보는 컴포넌트는 Nova입니다. RHOSP는 OpenStack 서비스를 컨테이너로 실행하지만, 운영자가 로그를 보기 쉽게 각 서비스 로그를 호스트의 /var/log/containers/ 아래에도 남깁니다. 따라서 VM 관련 장애를 볼 때는 먼저 compute 노드의 /var/log/containers/nova/nova-compute.log에서 요청 ID, 인스턴스 ID, 포트 ID, 볼륨 ID를 잡고 Neutron, Cinder, libvirt, Open vSwitch 로그로 좁혀가는 방식이 좋습니다.

RHOSP nova-compute 로그 위치 예시

이 로그에서 먼저 잡아야 할 값

아래 로그는 req-f243eaae-0d82-491b-8b78-843698ddb03c라는 request-id로 묶인 Nova compute 동작입니다. 같은 request-id가 찍힌 줄은 하나의 API 요청 또는 내부 작업 흐름에 속한다고 보면 됩니다. 이 예시에서는 VIF를 뽑았다가 다시 꽂는 동작, Cinder 볼륨 마운트 정리 경고, compute 호스트의 UEFI/NUMA 관련 메시지가 같은 시간대에 같이 발생했습니다.

  • req-f243eaae-0d82-491b-8b78-843698ddb03c: Nova 요청 흐름을 따라갈 request-id
  • 4e23f3e3-aee2-4144-967a-e8179b31b91f: Neutron port 또는 VIF ID
  • tap4e23f3e3-ae: compute 노드의 Open vSwitch tap 인터페이스 이름
  • volume-9ce4fc5b-5ea1-4de3-a911-398dbbe0aae8: 정리 대상으로 언급된 Cinder 볼륨 attachment
  • cn02: 로그를 확인한 compute 노드

예시 로그

[root@compute-node nova]# grep 'req-f243eaae-0d82-491b-8b78-843698ddb03c' /var/log/containers/nova/nova-compute.log
2023-05-11 22:17:02.046 2 INFO oslo.privsep.daemon [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Running privsep helper: ['sudo', 'nova-rootwrap', '/etc/nova/rootwrap.conf', 'privsep-helper', '--config-file', '/usr/share/nova/nova-dist.conf', '--config-file', '/etc/nova/nova.conf', '--privsep_context', 'vif_plug_ovs.privsep.vif_plug', '--privsep_sock_path', '/tmp/tmpiiu57xea/privsep.sock']
2023-05-11 22:17:03.693 2 INFO oslo.privsep.daemon [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Spawned new privsep daemon via rootwrap
2023-05-11 22:17:04.080 2 INFO os_vif [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Successfully unplugged vif VIFOpenVSwitch(active=False,address=fa:16:3e:9f:bb:6f,bridge_name='br-int',has_traffic_filtering=True,id=4e23f3e3-aee2-4144-967a-e8179b31b91f,network=Network(ae759962-0b1f-450b-a40e-2fc480dcdc8a),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap4e23f3e3-ae')
2023-05-11 22:17:04.130 2 WARNING nova.virt.libvirt.volume.mount [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Request to remove attachment (volume-9ce4fc5b-5ea1-4de3-a911-398dbbe0aae8, 97283f05-df0f-427a-845e-69ba9e7d1700) from /var/lib/nova/mnt/40d55001e20c8b0c18fba9e3735b045e, but we don't think it's in use.
2023-05-11 22:17:04.136 2 INFO nova.virt.libvirt.host [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] UEFI support detected
2023-05-11 22:17:04.175 2 WARNING nova.virt.libvirt.driver [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] This host appears to have multiple sockets per NUMA node. The `socket` PCI NUMA affinity will not be supported.
2023-05-11 22:17:04.199 2 INFO oslo.privsep.daemon [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Running privsep helper: ['sudo', 'nova-rootwrap', '/etc/nova/rootwrap.conf', 'privsep-helper', '--config-file', '/usr/share/nova/nova-dist.conf', '--config-file', '/etc/nova/nova.conf', '--privsep_context', 'nova.privsep.sys_admin_pctxt', '--privsep_sock_path', '/tmp/tmp0rgo3j20/privsep.sock']
2023-05-11 22:17:05.443 2 INFO oslo.privsep.daemon [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Spawned new privsep daemon via rootwrap
2023-05-11 22:17:06.397 2 INFO os_vif [req-f243eaae-0d82-491b-8b78-843698ddb03c 9a2e2fabecf241789b88b2847366db1f b4fd09ed562842a19776a088c687c55d - default default] Successfully plugged vif VIFOpenVSwitch(active=False,address=fa:16:3e:9f:bb:6f,bridge_name='br-int',has_traffic_filtering=True,id=4e23f3e3-aee2-4144-967a-e8179b31b91f,network=Network(ae759962-0b1f-450b-a40e-2fc480dcdc8a),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap4e23f3e3-ae')

라인별 해석

로그 패턴 의미 운영 판단
Running privsep helper, Spawned new privsep daemon via rootwrap Nova가 일반 권한으로 직접 처리할 수 없는 네트워크/시스템 작업을 nova-rootwrap와 privsep helper를 통해 실행합니다. 이 문구 자체는 장애가 아닙니다. 뒤에 ERROR, 권한 실패, rootwrap filter 실패가 이어지는지 확인합니다.
Successfully unplugged vif VM의 Neutron 포트에 해당하는 OVS VIF를 compute 노드에서 분리했습니다. 재부팅, resize, migrate, interface detach/attach, 네트워크 재연결 흐름에서 정상적으로 나올 수 있습니다.
Request to remove attachment... but we don't think it's in use Nova가 볼륨 attachment 마운트 경로를 정리하려 했지만, 현재 사용 중인 마운트로 판단하지 않았다는 경고입니다. VM 디스크 I/O 장애가 있으면 Cinder attachment, libvirt XML, 실제 마운트 상태를 같이 확인해야 합니다. 단독으로 보면 잔여 attachment 정리 경고일 수 있습니다.
UEFI support detected compute 호스트에서 UEFI 지원을 감지했습니다. 정보성 로그입니다. VM 부팅 방식 문제라면 flavor/image metadata의 boot mode와 같이 봅니다.
multiple sockets per NUMA node 호스트 CPU topology가 Nova의 PCI NUMA affinity 일부 기능과 맞지 않을 수 있다는 경고입니다. 일반 VM 기동 실패보다 SR-IOV, PCI passthrough, NUMA pinning 워크로드에서 영향 여부를 확인합니다.
Successfully plugged vif OVS VIF가 다시 붙었습니다. unplugged 뒤 plugged까지 성공했으므로 이 구간만 보면 VIF 재연결은 완료된 흐름입니다.

실무 진단 순서

장애 분석에서는 한 파일만 보고 결론을 내리면 안 됩니다. Nova 로그에서 request-id와 리소스 ID를 잡은 뒤 OpenStack API, Neutron 포트, libvirt 도메인, OVS 포트, Cinder attachment를 순서대로 대조해야 합니다.

이 사례의 판단

이 로그만 기준으로 보면 치명적인 VM 기동 실패 로그라기보다 Nova가 VIF를 재연결하고, 관련 시스템 작업을 rootwrap/privsep로 수행하며, 볼륨 마운트 정리 과정에서 확인용 경고를 남긴 흐름에 가깝습니다. 특히 Successfully unplugged vif 이후 Successfully plugged vif까지 이어졌기 때문에 네트워크 포트 재연결 자체는 성공한 것으로 해석할 수 있습니다.

다만 같은 시간대에 VM 장애가 실제로 있었다면 결론은 달라질 수 있습니다. VM이 ERROR 상태였는지, task_state가 남아 있었는지, Neutron port status가 ACTIVE인지, libvirt domain이 running인지, Cinder attachment가 꼬였는지를 같이 봐야 합니다. request-id 하나만으로 Nova 내부 흐름은 볼 수 있지만, 최종 사용자 장애 여부는 VM 상태와 게스트 내부 네트워크까지 확인해야 확정됩니다.

운영 중 바로 하면 안 되는 것

  • request-id만 보고 곧바로 nova-compute를 재시작하지 않습니다. 해당 compute 노드에 실행 중인 VM, live migration 가능 여부, 서비스 disable 여부를 먼저 확인해야 합니다.
  • 볼륨 attachment 경고만 보고 Cinder DB나 attachment record를 수동 삭제하지 않습니다. API 상태, libvirt XML, 실제 mount 상태를 먼저 맞춰봐야 합니다.
  • OVS tap이 안 보인다고 바로 VM을 강제 재부팅하지 않습니다. Neutron port binding, os-vif 로그, OVS bridge, libvirt interface 순서로 확인합니다.
  • NUMA 경고를 일반 VM 장애 원인으로 단정하지 않습니다. PCI passthrough, SR-IOV, dedicated CPU policy 같은 조건이 있을 때 영향 범위를 따로 판단합니다.

빠른 체크리스트

  1. Nova 로그에서 req- request-id, instance UUID, port ID, volume ID를 추출합니다.
  2. openstack server show와 openstack server event list로 VM 상태와 이벤트를 확인합니다.
  3. 포트 ID 기준으로 openstack port show, ovs-vsctl, ip link를 대조합니다.
  4. 인스턴스 이름 기준으로 virsh domstate, virsh domiflist, virsh dumpxml을 확인합니다.
  5. 볼륨 경고가 있으면 openstack volume show, findmnt, Cinder/Nova 로그를 함께 확인합니다.
  6. 재시작이 필요하면 compute 서비스 disable, VM 영향 범위, 롤백 방법을 정리한 뒤 진행합니다.
BGM EVER