feat(pipeline): keycloak-session-store 25편·virtualization 59편을 S3→S5→S6 으로 돌린다

기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만
있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문
종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다.

SSOT 결함 둘을 고쳤다.

- kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이
  「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽
  `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다.
- virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데
  원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다.

기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은
둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더
든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다).

계약을 셋 고쳤다.

- kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/**
  28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는
  것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온
  것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수
  대조했을 때 가장 가까운 커밋도 28개가 어긋났다).
- virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고
  재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다.
- kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고
  넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다.

style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져
(실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고,
engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고
있었다(Question 기록에서 11.94 → 3.86).

verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-exit-distribution-for-keycloak-workload.md

@@ -18,7 +18,7 @@ source:
 
 # Keycloak 작업의 VM Exit 분포는 idle · CPU-bound · I/O-bound 와 어떻게 다른가
 
-VM Exit 은 게스트를 실행하던 CPU 가 하이퍼바이저가 개입해야 하는 조건을 만나 제어권을 KVM 쪽으로 넘기는 전환이다. 정상적인 가상화 동작이라 Exit 이 있다는 것만으로 문제가 되지 않는다. 다만 하이퍼바이저가 개입해야 하는 Exit 이 특정 작업에서 지나치게 빈번하고 처리 비용이 커지면 성능에 영향을 줄 수 있다. Keycloak 을 돌리는 구간이 그런 작업인지 보려면 다른 구간의 Exit 분포와 견줘야 하는데, 이 호스트에서 Exit 을 관측하는 도구가 열리는지부터 확인하지 않았다.
+이 호스트에서 Exit 을 받아 본 기록이 없고 관측 도구가 열리는지부터 확인하지 않았다. VM Exit 은 게스트를 실행하던 CPU 가 제어권을 KVM 쪽으로 넘기는 정상 동작이라, 있다는 것만으로 문제가 되지 않는다. Keycloak 구간에서 Exit 이 얼마나 잦은지는 나머지 네 구간의 분포와 견줘야 갈린다.
 
 ## 관계
 
@@ -40,6 +40,7 @@ VM Exit 은 게스트를 실행하던 CPU 가 하이퍼바이저가 개입해야
 - Exit 이 많다는 관측 하나로 장애라고 판단하지 않는다.
 - 환경이 지원하면 perf kvm 으로 KVM 관련 실행 통계를 확인할 수 있고, 예로 든 명령은 sudo perf kvm stat live 다.
 - 지원되는 명령과 표시되는 Exit 이유는 커널과 perf 버전, CPU 아키텍처와 설정에 따라 다를 수 있어 perf kvm --help 를 함께 확인한다. 필요하면 KVM tracepoint 를 이용한 별도 추적도 검토한다.
+- §197 은 2026-09-10 에 이 호스트에서 커널 7.2.2-arch1-1 과 QEMU emulator version 11.1.1 을 받아 적었다. CPU 는 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 이고 lscpu 의 Virtualization 은 VT-x 다. perf 버전은 적혀 있지 않다.
 - 비교 후보로 적어 둔 구간은 idle, CPU-bound 작업, I/O 가 많은 작업, Keycloak 정상 요청, Keycloak 부하 테스트 다섯이다.
   이 목록은 개념 문서가 앞선 물음 자리에 적어 둔 것이고, 이 질문의 제목이 든 것은 그 가운데 앞쪽 셋이다. 받아야 하는 구간은 제목이 든 것보다 둘 많다.
 
@@ -64,7 +65,7 @@ VM Exit 은 게스트를 실행하던 CPU 가 하이퍼바이저가 개입해야
 - 표시되는 Exit 이유는 커널과 perf 버전, CPU 아키텍처와 설정에 따라 달라지므로 다른 환경에서 나온 분포와 이 호스트의 분포를 바로 견주지 않는다.
 - Exit 횟수만 세지 않는다. Exit 이유와 작업 종류, 처리 위치, 같은 구간의 지연을 함께 받아 적는다.
 - 도구가 열려야 측정이 시작된다. 열리지 않으면 이 질문은 값 없이 닫힌다.
-- sudo 가 필요한 명령이라 이 호스트에서 그 권한으로 실행할 수 있어야 한다.
+- sudo 가 필요한 명령인데, §204 는 이 호스트의 sudo 가 비밀번호를 요구해 비대화식으로는 읽지 못했다고 적었다. 그래서 콘솔에 붙어 직접 치는 실행으로 잡는다.
 - 이 호스트에서 Exit 을 실제로 받아 본 기록이 없다.
 
 ## 선택지

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-host-numa-topology.md

@@ -17,7 +17,7 @@ source:
 
 # 이 호스트의 NUMA 토폴로지는 가상 머신 성능을 고려해야 할 구조인가
 
-멀티소켓이나 NUMA(Non-Uniform Memory Access) 구조의 호스트에서는 vCPU 가 어느 노드의 CPU 에서 실행되고 그 가상 머신의 메모리가 어느 노드에 놓였는지가 성능에 영향을 줄 수 있다. 이 물음은 그 영향을 재는 것이 아니라, 이 호스트가 애초에 그 조건에 들어가는지를 먼저 가른다. 단일 노드로 나오면 지금 실험에서 우선순위를 낮추고, 다중 노드로 나오면 vCPU 와 메모리 배치를 따로 다룬다.
+이 호스트의 NUMA 노드 수를 확인한 기록이 없다. §197 이 받은 `lscpu` 출력에 NUMA 줄이 없어서다. NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 메모리에 접근하느냐에 따라 접근 비용이 달라지는 구조다. 단일 노드면 지금 실험에서 우선순위를 낮추고, 다중 노드면 vCPU 와 메모리 배치를 따로 다룬다.
 
 ## 관계
 
@@ -33,7 +33,10 @@ source:
   단일 NUMA 노드 : 지금 실험에서 우선순위를 낮춘다
   다중 NUMA 노드 : vCPU 와 메모리 배치를 별도 Case 후보로 올린다
   개념 문서가 남긴 열린 물음 열둘 가운데 닫는 갈래를 스스로 적어 둔 것은 이 하나다.
-- 개념 문서는 이 확인에 쓸 명령을 적지 않았다. 다른 확인 항목과 달리 NUMA 쪽에는 예로 든 명령이 없다.
+- §24.11 은 이 확인에 쓸 명령을 적지 않았다. 다른 확인 항목과 달리 NUMA 쪽에는 예로 든 명령이 없다.
+- 메모리 가상화 쪽 §78 이 그 명령을 든다. 노드 수는 `lscpu` 의 NUMA 줄로 보라고 적고 `numactl --hardware` 를 추가로 든다. QEMU 프로세스별 메모리 분포는 `numastat -p <QEMU_PID>`, vCPU 배치는 `virsh vcpupin <VM_NAME>` 과 `virsh vcpuinfo <VM_NAME>` 이다.
+- §197 이 2026-09-10 에 이 호스트에서 받은 `lscpu` 출력은 `Model name` 이 `11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz`, `CPU(s)` 가 8, `Core(s) per socket` 이 4, `Thread(s) per core` 가 2 다. 네 줄만 `grep` 으로 걸러 받아서 NUMA 줄은 거기 없다.
+- §24.11 이 문제를 두는 조건은 멀티소켓 또는 NUMA 구조인데, 그 네 줄에는 `Socket(s)` 도 NUMA 줄도 없다.
 - 이 호스트의 NUMA 노드 수를 확인한 기록이 없다.
 
 ## 가정
@@ -42,19 +45,20 @@ source:
 - 단일 노드로 나오면 vCPU 가 실행되는 노드와 메모리가 놓인 노드가 갈리지 않으므로 다른 노드의 메모리를 읽을 일이 지금 실험에서 성능 차이를 만들지 않는다고 본다.
   그 추론을 이 호스트에서 확인하지는 않았다.
 - 두 가상 머신의 메모리 배치가 실행 중에 바뀌지 않는다고 전제한다.
+  §198 은 virtio-balloon 이 안 쓰는 만큼 호스트에 돌려준다고 적었으므로 할당된 양은 실행 중에 바뀐다. 노드 배치까지 따라 바뀌는지는 적혀 있지 않다.
 
 ## 미지수
 
 - 이 호스트가 단일 NUMA 노드인지 다중 NUMA 노드인지.
 - 다중이라면 두 가상 머신의 vCPU 와 메모리가 각각 어느 노드에 배치되어 있는지.
-- 노드 수와 배치를 이 환경에서 어떤 명령으로 읽는지. 개념 문서가 그 명령을 적지 않아 실행하는 쪽이 정한다.
+- §78 이 든 명령 가운데 `numactl` 과 `numastat` 이 이 호스트에 깔려 있는지.
 - 다중으로 나왔을 때 배치를 바꾸는 일이 지금 가상 머신 구성에서 가능한지.
 
 ## 제약
 
-- 이 질문이 다중 노드로 닫혀도 여기서 NUMA 튜닝을 정하지 않는다. 상세한 메모리 배치는 메모리 가상화를 다루는 개념 문서가 받는다.
-- 쓸 명령을 개념 문서가 정해 주지 않으므로, 실행한 명령과 그 출력을 함께 증거로 남겨야 다음 사람이 같은 값을 다시 읽을 수 있다.
-- 이 호스트에서 잰 값이 없어 다른 장비의 노드 구성을 근거로 삼지 않는다.
+- 이 질문이 다중 노드로 닫혀도 여기서 NUMA 튜닝을 정하지 않는다. 상세한 메모리 배치는 §73~§78 과 그것을 받을 메모리 가상화 개념 기록이 다룬다.
+- §24.11 쪽에는 예로 든 명령이 없고 §78 쪽 명령은 메모리 가상화 절에 있다. 그래서 실행한 명령과 그 출력을 함께 증거로 남긴다.
+- 이 호스트의 노드 수를 잰 값이 없어 다른 장비의 노드 구성을 근거로 삼지 않는다.
 
 ## 선택지
 
@@ -70,16 +74,16 @@ source:
 
 단일로 나오면 함께 받은 배치는 쓰지 않게 되는데, 대신 실행이 한 번으로 끝난다.
 
-### 3. 메모리 가상화 개념 문서를 쓸 때 함께 본다 — 제외
+### 3. 메모리 가상화 쪽에서 함께 본다 — 제외
 
-상세한 메모리 배치를 그쪽에서 다루기로 했으니 확인도 그때 하자는 방법이다.
-지금 필요한 판단은 이 항목을 실험 목록의 어디에 둘지 하나이고, 그것은 노드 수만으로 갈린다. 메모리 가상화 쪽을 기다리면 그동안 우선순위를 정하지 못한 채로 둔다.
-개념 문서가 적은 다음 기반 영역은 메모리 가상화가 아니라 네트워크 가상화이고, 메모리 쪽을 언제 정리하는지는 적혀 있지 않다.
+상세한 메모리 배치를 §73~§78 이 다루므로 확인도 그쪽에서 하자는 방법이다.
+지금 필요한 판단은 이 항목을 실험 목록의 어디에 둘지 하나이고, 그것은 노드 수만으로 갈린다.
+§78 은 먼저 topology 를 측정하고 NUMA 최적화가 필요한지 판단한다고 적었다. 그 순서대로면 노드 수는 여기서 재고 배치 조정을 그쪽이 받는다.
 
 ## 다음 검증
 
-1. 호스트의 NUMA 노드 구성을 확인해 노드 수를 적는다.
-2. 이 확인에 쓴 명령과 그 출력을 함께 증거로 남긴다. 개념 문서가 명령을 적어 두지 않아 실행한 쪽이 무엇을 썼는지 기록해야 한다.
-3. 다중 노드로 나오면 vCPU 가 실행되는 노드와 가상 머신 메모리가 배치된 노드까지 이어서 적는다.
+1. `lscpu` 를 NUMA 줄까지 받아 노드 수를 적고 `numactl --hardware` 로 한 번 더 본다 (§78).
+2. 실행한 명령과 그 출력을 함께 증거로 남긴다. §24.11 쪽에 예로 든 명령이 없어서 무엇을 썼는지 적어 두지 않으면 다음 사람이 같은 값을 다시 읽지 못한다.
+3. 다중 노드로 나오면 `virsh vcpupin <VM_NAME>` 으로 vCPU 배치를, `numastat -p <QEMU_PID>` 로 그 QEMU 프로세스의 메모리 분포를 이어서 적는다 (§78).
 
-닫는 조건 : 단일 NUMA 노드로 나오면 지금 실험에서 우선순위를 낮추고 닫는다. 다중 NUMA 노드로 나오면 vCPU 와 메모리 배치를 별도 Case 후보로 올리고, 이 프로젝트가 메모리 가상화 쪽 정리를 가질 때 그리로 넘긴다.
+닫는 조건 : 단일 NUMA 노드로 나오면 §27 이 적은 대로 지금 실험에서 우선순위를 낮추고 닫는다. 다중 NUMA 노드로 나오면 vCPU 와 메모리 배치를 별도 Case 후보로 올리고 §24.11 과 함께 §73~§78 쪽으로 넘긴다.

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-idle-vcpu-thread-appearance.md

@@ -18,7 +18,7 @@ source:
 
 # 게스트가 유휴 상태일 때 vCPU 스레드는 이 테스트 환경에서 어떻게 보이는가
 
-게스트에 할 일이 없으면 vCPU 스레드가 잠들거나 대기 상태로 들어가고, 그동안 호스트는 그 물리 CPU 를 다른 작업에 쓸 수 있다. 이 서술이 이 환경에서도 그대로 보이는지는 QEMU 프로세스의 스레드 목록을 유휴와 부하 두 상태에서 찍어 봐야 아는데, 아직 어느 쪽도 찍지 않았다. 이 QEMU 버전에서 vCPU 스레드가 어떤 이름으로 나오는지도 모른다.
+유휴와 부하 두 상태에서 QEMU 프로세스의 스레드 목록을 아직 어느 쪽도 찍지 않았다. §10 은 게스트에 할 일이 없으면 vCPU 스레드가 잠들거나 대기 상태로 들어가고, 그동안 호스트가 그 물리 CPU 를 다른 작업에 쓸 수 있다고 적었다. 그 서술이 이 환경에서도 보이는지, 이 QEMU 에서 그 스레드가 어떤 이름으로 나오는지가 남았다.
 
 ## 관계
 
@@ -53,7 +53,11 @@ Guest 실행 재개
 
 §10 은 깨우는 이유로 타이머, 인터럽트, I/O 완료를 든다.
 
-§14.6 은 ps -T -p <QEMU_PID> 또는 top -H -p <QEMU_PID> 로 vCPU 관련 스레드를 호스트에서 관찰할 수 있다고 적으면서, 환경과 QEMU 버전에 따라 이름은 다를 수 있다는 단서를 함께 단다.
+§14.6 은 ps -T -p <QEMU_PID> 또는 top -H -p <QEMU_PID> 로 vCPU 관련 스레드를 호스트에서 관찰할 수 있다고 적는다. 환경과 QEMU 버전에 따라 이름은 다를 수 있다는 단서를 함께 단다.
+
+§197 은 2026-09-10 에 이 호스트에서 qemu-system-x86_64 --version 을 받아 QEMU emulator version 11.1.1 을 적었다. §14.6 이 이름이 다를 수 있다고 든 조건 가운데 QEMU 버전이 여기서 정해진다.
+
+§222 는 가상 머신 하나가 호스트에서 QEMU 프로세스 하나로 돈다고 적었고, §218 은 kc-lab-1 과 kc-lab-2 에 각각 vCPU 2 를 적었다.
 
 §20 은 게스트의 유휴 상태와 CPU 부하 상태를 비교하라고 적고 확인 명령으로 둘을 든다.
 
@@ -62,9 +66,9 @@ ps -eLo pid,tid,psr,pcpu,stat,comm
 
 ## 가정
 
-QEMU 프로세스의 PID 를 먼저 찾아야 한다. 가상 머신 두 대가 도는 호스트에서 어느 PID 가 어느 가상 머신인지 가리는 방법을 아직 정하지 않았다.
+QEMU 프로세스의 PID 를 먼저 찾아야 한다. §197 이 잰 시점의 이 실험대는 게스트가 세 대라 §14.5 의 ps -ef | grep '[q]emu' 는 프로세스 셋을 준다. 셋 가운데 하나는 엣지 게스트이고 vCPU 1 이다(§194). 어느 PID 가 어느 가상 머신인지 가리는 방법은 아직 정하지 않았다.
 
-vCPU 스레드를 이름으로 못 가리면 스레드 수를 그 가상 머신의 vCPU 수와 맞춰 가린다고 전제한다.
+vCPU 스레드를 이름으로 못 가리면 스레드 수를 그 가상 머신의 vCPU 수와 맞춰 가린다고 전제한다. kc-lab-1 과 kc-lab-2 라면 그 수가 2 다.
 
 유휴라고 부를 상태를 이 가상 머신에서 만들 수 있다. 가상 머신 안에서 도는 것이 있으면 완전한 유휴가 아니다.
 
@@ -84,7 +88,7 @@ vCPU 스레드 말고 어떤 스레드가 같은 QEMU 프로세스 아래에 함
 
 ## 제약
 
-이 호스트에서 찍은 출력이 없다. §10 은 개념 흐름을 그린 것이고 이 환경의 실제 출력이 아니다. 결과가 §10 과 같으면 개념에 흡수되고 다르면 Case 가 된다는 갈림을 처음에는 이 물음을 따로 세우지 않을 이유로 봤다. 지금은 그것을 그대로 닫는 조건으로 쓴다 — 어느 쪽으로 갈리든 물음은 닫힌다.
+이 호스트에서 그 스레드 목록을 찍은 출력이 없다. §10 은 개념 흐름을 그린 것이고 이 환경의 실제 출력이 아니다. 결과가 §10 과 같으면 개념에 흡수되고 다르면 Case 가 되므로, 어느 쪽으로 갈리든 이 물음은 닫힌다.
 
 §14.6 이 스레드 이름은 환경과 QEMU 버전에 따라 다를 수 있다고 적기 때문에, 이름으로 거르는 절차를 미리 굳혀 둘 수 없다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-is-production-on-a-hypervisor.md

@@ -18,9 +18,8 @@ source:
 
 # 운영 서버는 CPU 가상화 계층의 영향을 받는 구조인가
 
-§18 과 §20 은 K3s 가 호스트 스케줄러로 바로 가는 경로와 게스트 · vCPU · 하이퍼바이저를 더 지나는 경로를 나란히 적었다.
-§25 의 진단표는 문제마다 주된 계층을 갈라 놓아서, Virtualization 과 Host 계층에만 걸리는 행이 따로 있다.
-운영 서버가 두 경로 중 어느 쪽인지는 SSOT 에 적혀 있지 않은데, 그 구조가 정해져야 진단표의 어느 행을 운영 진단에 쓸지 고를 수 있다.
+운영 서버가 bare-metal 인지 상위 하이퍼바이저나 클라우드 가상 머신 위인지는 SSOT 에 적혀 있지 않다.
+§25 의 진단표에는 Virtualization 과 Host 계층에만 걸리는 행이 따로 있어서, 그 구조가 정해져야 어느 행을 운영 진단에 쓸지 고를 수 있다.
 
 ## 관계
 
@@ -51,6 +50,9 @@ CPU contention · Scheduling latency : Host Scheduler
 Steal time 증가 : Guest 에서 관측
 Host CPU saturation : Host
 
+§218 은 운영을 `desktop` 이라 부르고 그 배치를 `nginx → 127.0.0.1:30080(NodePort) → Traefik` 으로 적었다. 이 실험대의 배치와 다른 것은 단일 노드냐 2노드냐 하나다.
+§284 는 그 `desktop` 이 Ubuntu 라고 적는다. 같은 절이 이 실험대가 `sites-available` 방식을 쓰는 이유도 적었다. 「운영(`desktop`)이 Ubuntu라 그 구조를 쓰고 있으므로, 설정을 운영으로 옮길 때 경로가 그대로 맞는 편이 낫다는 판단이다.」 SSOT 가 운영과 같다고 적은 것은 그 2홉 경로와 이 설정 관례 둘이다.
+
 운영 서버가 bare-metal 인지 상위 하이퍼바이저나 클라우드 가상 머신 위인지는 SSOT 에 적혀 있지 않다.
 
 ## 가정
@@ -65,7 +67,7 @@ Host CPU saturation : Host
 
 운영 서버가 bare-metal 호스트에 직접 K3s 를 설치한 것인가, 상위 하이퍼바이저나 클라우드 가상 머신 위에 있는가.
 
-하이퍼바이저 위라면 그 호스트의 CPU 지표를 우리가 볼 수 있는가.
+하이퍼바이저 위라면 그 호스트의 CPU 지표를 볼 수 있는가.
 클라우드 가상 머신이면 호스트 쪽 실행 대기열과 사용률을 읽을 수 없어 §25 의 Host 행을 그대로 쓰기 어려워진다.
 
 운영 서버에 직접 붙어 명령을 돌릴 수 있는가.
@@ -74,8 +76,8 @@ Host CPU saturation : Host
 
 이 물음은 부하를 걸어 재는 것이 아니라 구성을 확인해서 닫는다.
 
-§14.1~§14.3 은 그 장비가 가상 머신을 직접 돌리는 호스트 인지를 보여 준다.
-그 장비 자신이 어떤 하이퍼바이저의 게스트 인지는 이 세 명령이 말해 주지 않는다.
+§14.1~§14.3 은 그 장비가 가상 머신을 직접 돌리는 호스트인지를 보여 준다.
+그 장비 자신이 어떤 하이퍼바이저의 게스트인지는 이 세 명령이 말해 주지 않는다.
 
 구조가 정해지기 전에는 §25 의 어느 행을 운영 진단에 넣을지 고를 수 없다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-pinning-before-and-after.md

@@ -18,7 +18,7 @@ source:
 
 # CPU pinning 전후로 Keycloak 지연과 vCPU 스케줄링 변동이 달라지는가
 
-vCPU 스레드가 실행될 호스트 논리 CPU 를 특정 집합으로 제한하는 설정을 CPU pinning 이라고 한다. 적절히 걸면 스케줄링 변동이 줄지만 잘못 걸면 특정 CPU 에만 작업이 몰린다. 이 호스트에서는 pinning 을 걸지 않은 상태의 Keycloak 지연도, 건 상태의 지연도 아직 재지 않았으므로 pinning 이 지금 작업에 이점을 주는지는 말할 수 없다.
+이 호스트에서는 pinning 을 걸지 않은 상태의 Keycloak 지연도, 건 상태의 지연도 아직 재지 않았다. CPU pinning 은 vCPU 스레드가 실행될 호스트 논리 CPU 를 특정 집합으로 제한하는 설정이다. 논리 코어 8 과 게스트별 vCPU 2 는 §197 · §218 에 나왔지만, 묶은 뒤 지연과 CPU 별 사용률이 어떻게 달라지는지는 재 봐야 갈린다.
 
 ## 관계
 
@@ -36,6 +36,7 @@ vCPU 스레드가 실행될 호스트 논리 CPU 를 특정 집합으로 제한
   치우침을 만드는 쪽에 호스트 프로세스가 함께 들어 있다.
 - 스레드가 최근 실행된 논리 CPU 는 ps -eLo pid,tid,psr,pcpu,comm | grep qemu 의 PSR 로 볼 수 있다.
 - PSR 값 하나가 vCPU 가 물리 CPU 에 영구 고정되어 있다는 뜻은 되지 않는다. pinning 을 걸지 않았다면 스케줄링에 따라 달라질 수 있다.
+- 이 호스트의 논리 코어는 8 이고(§197), kc-lab-1 과 kc-lab-2 에 준 vCPU 는 각각 2 다(§218). 실험대가 잡은 vCPU 는 2 + 2 + 1 = 5 다(§197).
 - pinning 이 지금 작업에서 실제 이점을 주는지는 실험으로 확인하기로 했고, 아직 그 실험을 돌리지 않았다.
 
 ## 가정
@@ -52,14 +53,14 @@ vCPU 스레드가 실행될 호스트 논리 CPU 를 특정 집합으로 제한
 - pinning 뒤 Keycloak 지연이 달라지는지, 달라진다면 어느 방향인지.
 - 같은 tid 의 PSR 변동이 실제로 줄어드는지.
 - 변동이 줄어드는 대신 특정 논리 CPU 로 작업이 몰리는지.
-- 어떤 논리 CPU 집합에 묶을지. 이 호스트의 논리 CPU 수와 각 가상 머신의 vCPU 수를 아직 적지 않았다.
-- 호스트 쪽 Nginx 와 다른 호스트 프로세스가 그 집합을 함께 쓰는지.
+- 어떤 논리 CPU 집합에 묶을지. 논리 코어 8 과 게스트별 vCPU 2 는 §197 · §218 에 나왔지만, 그 여덟 가운데 어느 코어에 묶을지는 CPU 별 사용률을 보고 정해야 한다.
+- 호스트 쪽 Nginx 와 다른 호스트 프로세스가 그 집합을 함께 쓰는지. §179 는 그 Nginx 를 엣지 게스트로 옮겼다고 적었으므로, 묶을 집합을 고르기 전에 호스트에 무엇이 남아 있는지부터 이번 실행에서 적는다.
 
 ## 제약
 
 - pinning 여부만으로 판정하지 않는다. 지연과 PSR 변동, CPU 별 사용률 셋을 같은 실행에서 받아 적는다.
 - 「전」과 「후」 두 실행의 부하가 같아야 지연 차이를 pinning 쪽으로 읽을 수 있다.
-- 이 호스트에서 잰 값이 하나도 없어 견줄 값을 이번 실행이 함께 만든다.
+- 이 호스트에서 지연도 PSR 변동도 CPU 별 사용률도 잰 값이 없어 견줄 값을 이번 실행이 함께 만든다.
 - 이 실행 전에 pinning 을 쓸지 말지를 먼저 정하지 않는다. 잰 값이 없는 상태로 정하면 그 선택이 감수하는 비용을 적을 수 없다.
 - 묶는 대상은 vCPU 스레드다. 게스트 안의 Keycloak 파드 배치는 이 질문이 다루지 않는다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-steal-time-increase-under-two-cpu-bound-vms.md

@@ -18,10 +18,8 @@ source:
 
 # 가상 머신 두 대를 CPU-bound 로 만들면 게스트 steal time 은 얼마나 오르는가
 
-§24.4 는 steal time 을 게스트에 실행할 작업이 있는데도 하이퍼바이저나 호스트가 그 vCPU 스레드를 즉시 실행시키지 못한 시간으로 적었다.
-게스트의 `top` 에서 `%st` 로 보이는 값이지만, §13 과 §24.4 는 그 값 하나로 원인을 확정해서는 안 된다고 함께 못 박았다.
-§27 은 이 물음에서 호스트의 CPU 사용률과 실행 대기열, QEMU vCPU 스레드, 각 게스트의 `%st` 를 함께 재라고 적었다.
-이 호스트에서 `%st` 를 잰 값이 없어서, 부하 전 기준값부터 남겨야 증가폭을 숫자로 적을 수 있다.
+이 호스트에서 게스트의 steal time(`%st`)을 잰 값이 없어 부하 전 기준값부터 남겨야 한다.
+논리 코어는 8 이고(§197) 두 게스트에 준 vCPU 는 각각 2 다(§218). 둘을 더해도 코어 수를 넘지 않는다. 그런 구성에서도 두 대를 동시에 CPU-bound 로 만들면 `%st` 가 오르는지는 §27 이 든 네 항목을 부하 전후로 찍어야 갈린다.
 
 ## 관계
 
@@ -49,6 +47,10 @@ source:
 §24.3 은 경쟁 대상이 QEMU vCPU 스레드만은 아니라고 적었다.
 호스트에 Nginx 를 직접 설치하고 가상 머신 두 대를 실행하는 테스트 환경에서는 가상 머신 밖의 호스트 작업도 CPU 경쟁에 포함된다.
 
+§197 은 2026-09-10 에 이 호스트에서 잰 값을 적었다. Core(s) per socket 4 에 Thread(s) per core 2 라 논리 코어가 8 이다.
+같은 절은 VM 에 주는 vCPU 가 논리 코어를 나눠 쓰는 것이고 합이 8 을 넘어도 libvirt 는 막지 않는다고 적으면서, 이 실험대는 2 + 2 + 1 = 5 로 잡아 여유를 뒀다고 덧붙였다.
+§218 의 2026-09-03 배치는 kc-lab-1 과 kc-lab-2 에 각각 vCPU 2 를 적었다.
+
 §27 의 OQ-7 은 함께 측정할 항목으로 넷을 들었다.
 
 Host CPU utilization
@@ -61,7 +63,7 @@ QEMU vCPU thread
 ## 가정
 
 두 가상 머신을 동시에 CPU-bound 로 만들면 vCPU 스레드끼리 호스트 CPU 시간을 두고 경쟁하게 된다고 전제한다.
-이 호스트의 논리 CPU 수와 두 가상 머신의 vCPU 합계가 SSOT 에 적혀 있지 않아서, 경쟁이 생기는 구성인지도 아직 전제로만 두었다.
+두 게스트의 vCPU 합 4 는 논리 코어 8 보다 적어서 §12 가 그린 초과 할당 상태는 아니다. 그래도 경쟁이 생기는지는 같은 코어를 호스트 쪽 작업이 얼마나 쓰는지에 달려 있어 아직 전제로 둔다.
 
 두 게스트에 같은 정도의 부하를 걸 수 있다고 전제한다.
 한쪽이 더 세게 걸리면 두 %st 를 나란히 놓고 읽을 수 없다.
@@ -75,7 +77,7 @@ QEMU vCPU thread
 
 그 증가가 호스트 실행 대기열과 같은 방향으로 움직이는가.
 
-이 호스트의 논리 CPU 수는 얼마이고 두 가상 머신의 vCPU 합계는 그 수에 견줘 어느 정도인가.
+부하 구간에 호스트 쪽 작업이 같은 논리 코어를 얼마나 쓰는가.
 
 ## 제약
 
@@ -87,6 +89,8 @@ QEMU vCPU thread
 
 부하 구간에 호스트에서 Nginx 같은 다른 작업이 함께 돌면 %st 의 증가분을 두 가상 머신 사이의 경쟁으로만 읽을 수 없다.
 
+§24.3 이 그 목록을 그릴 때 둔 환경은 호스트에 Nginx 를 직접 설치하고 가상 머신 두 대를 실행하는 구성이다. §179 는 그 Nginx 를 엣지 게스트로 옮겼고 호스트가 직접 들던 `:443` 에는 지금 리스너가 없다고 적었으므로, 부하 구간에 호스트 쪽에서 무엇이 도는지는 그 목록이 아니라 그때의 호스트에서 받아 적는다.
+
 OQ-1 과 이 물음은 같은 부하 실행에서 값을 얻는다. 그래도 한 물음으로 합치지 않았다.
 합치면 경쟁이 있었다는 결론과 그것이 %st 로 얼마나 보였다는 결론 가운데 어느 쪽 기준으로 닫혔는지가 남지 않는다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-throttling-vs-contention.md

@@ -18,7 +18,7 @@ source:
 
 # cgroup CPU 제한과 호스트 vCPU 경쟁을 지표로 가를 수 있는가
 
-가상 머신 안에서 K3s 를 돌리는 지금 구성에서는 Keycloak 파드가 자신에게 걸린 CPU 상한에 막혀 느려진 것(cgroup throttling)과 호스트 CPU 를 제때 받지 못해 느려진 것(Host vCPU contention)이 같은 애플리케이션 지연으로 관찰될 수 있다. 계층별 진단표는 두 원인을 다른 계층에 갈라 놓고 먼저 볼 항목도 따로 적어 두었다. 다만 이 호스트에서 두 원인을 각각 재현해 그 항목들이 실제로 다르게 움직이는지는 확인하지 않았다.
+이 호스트에서 throttled time 도 steal time 도 잰 값이 없다. 가상 머신 안에서 K3s 를 돌리는 구성이라, 파드가 자기 CPU 상한에 막힌 것과 호스트 CPU 를 제때 못 받은 것이 같은 애플리케이션 지연으로 보일 수 있다. §25 가 두 원인에 갈라 적은 확인 항목이 실제로 갈리는지는 두 원인을 각각 재현해야 안다.
 
 ## 관계
 
@@ -43,6 +43,7 @@ source:
   cgroup 쪽은 파드가 CPU 를 더 쓰려 해도 상한에 막힌 것이고, 경쟁 쪽은 실행 가능한 작업이 늘면서 지연이 늘어난 것이다.
   갈라 적힌 현상은 각 계층에서 보이는 모습이라, 애플리케이션 지연만 보고 있으면 그 구분이 드러나지 않는다.
 - 그 표는 지표 하나로 원인을 확정하려고 만든 것이 아니라 어느 계층부터 조사할지 범위를 줄인다.
+- §197 은 2026-09-10 에 이 호스트의 논리 코어를 8 로, 실험대가 잡은 vCPU 를 2 + 2 + 1 = 5 로 적었다. §218 은 kc-lab-1 과 kc-lab-2 에 각각 vCPU 2 를 적었다.
 - 이 호스트에서 throttled time 도 steal time 도 잰 값이 없다.
 
 ## 가정
@@ -67,8 +68,8 @@ source:
 - 두 재현이 비슷한 크기의 지연 증가를 만들어야 지표 조합을 견줄 수 있다.
 - 지표 하나로 원인을 확정하지 않는다. 게스트 · 호스트 · K3s 세 쪽을 같은 시각에 받아 적는다.
 - refresh 경쟁 실험은 CPU 자원을 여유 있게 둔 상태에서 먼저 돌리므로 이 재현은 그 실험과 같은 시간에 걸지 않는다.
-- 이 호스트의 논리 CPU 수와 두 가상 머신의 vCPU 수를 개념 문서가 적어 두지 않았다.
-  부하 쪽 재현이 실제로 경쟁을 만드는지는 그 두 값을 적은 뒤에 판단한다.
+- 두 게스트의 vCPU 합 4 가 논리 코어 8 보다 적어서, 부하 쪽 재현이 경쟁을 만들려면 호스트 쪽 작업까지 같은 코어를 써야 한다.
+  부하를 걸었는데 경쟁이 나오지 않는 것도 이 재현의 결과로 받는다.
 
 ## 선택지
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-throughput-vs-vcpu-count.md

@@ -18,10 +18,8 @@ source:
 
 # vCPU 를 늘릴수록 이 호스트에서 Keycloak 처리량도 계속 오르는가
 
-§11 은 4 vCPU 를 실행 컨텍스트 4개를 주는 것으로 적었지, 물리 CPU 4개를 가상 머신이 영구적으로 소유하는 것으로 적지 않았다.
-§24.6 은 vCPU 를 많이 할당한다고 항상 성능이 좋아지지는 않는다고 적었다.
-§27 은 비교 구성으로 2 vCPU · 4 vCPU · 8 vCPU 를 들었다.
-세 구성에 같은 Keycloak 부하를 걸어 본 기록이 이 호스트에 없어서, 처리량이 어디서부터 더 오르지 않는지는 모른다.
+이 호스트에서 vCPU 수를 바꿔 가며 Keycloak 처리량을 잰 값이 없다.
+논리 코어가 8 이라(§197) §27 이 든 8 vCPU 구성에서는 한 게스트의 vCPU 수가 코어 수와 같아진다. 처리량이 어디서부터 더 오르지 않는지는 세 구성에 같은 부하를 걸어야 갈린다.
 
 ## 관계
 
@@ -43,6 +41,9 @@ source:
 
 §27 의 OQ-8 은 vCPU 추가가 실제 처리량과 지연에 어떤 영향을 주는지 확인하는 비교 구성으로 2 vCPU / 4 vCPU / 8 vCPU 를 들었다.
 
+§197 은 2026-09-10 에 이 호스트의 논리 코어를 8 로 적었다. Core(s) per socket 4 에 Thread(s) per core 2 다.
+같은 절은 VM 에 주는 vCPU 가 논리 코어를 나눠 쓰는 것이고 합이 8 을 넘어도 libvirt 는 막지 않는다고 적으면서, 이 실험대는 2 + 2 + 1 = 5 로 잡아 여유를 뒀다고 덧붙였다.
+
 이 호스트에서 vCPU 수를 바꿔 가며 Keycloak 처리량을 잰 값은 없다.
 
 ## 가정
@@ -63,13 +64,15 @@ vCPU 를 2 에서 4, 8 로 올렸을 때 처리량과 지연이 어디서부터
 
 좋아지지 않는다면 원인이 작업의 병렬성 부족인가 호스트 전체 CPU 부족인가.
 
-이 호스트의 논리 CPU 수는 얼마이고, 8 vCPU 구성이 그 수를 넘는가.
+8 vCPU 구성을 잴 때 나머지 게스트를 함께 띄우는가. 총 vCPU 가 논리 코어 8 을 넘긴 채로 잰 값인지 아닌지가 §24.6 의 두 원인 가운데 어느 쪽을 보는지를 가른다.
 
 ## 제약
 
 vCPU 수만 바꾸고 Keycloak 설정과 부하는 세 실행에서 고정한다.
 
-8 vCPU 가 호스트 논리 CPU 수를 넘는지에 따라 재는 것이 작업의 병렬성인지 초과 할당인지 달라지므로, 호스트 논리 CPU 수를 먼저 적는다.
+논리 코어가 8 이라 8 vCPU 구성에서는 한 게스트의 vCPU 수가 코어 수와 같아진다. 나머지 게스트를 함께 띄우면 합이 8 을 넘으므로, 세 실행마다 그때 떠 있던 게스트와 총 vCPU 를 함께 적는다.
+
+§186 은 가이드의 실측 줄이 「이 실험대의 호스트는 16 코어 전부에서 지원한다」인데 §178 의 대상 환경은 논리 코어 8 이라고 적고, 어느 쪽이 이 호스트의 값인지는 재지 않았다고 남겼다. 이 기록이 8 을 놓고 짜는 것은 §197 이 2026-09-10 에 그 값을 직접 받아 적었기 때문이다.
 
 §24.6 이 든 두 원인을 가르려면 처리량과 지연만으로는 부족하다. 게스트의 %st 를 같은 실행에서 남긴다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-vcpu-thread-migration-without-pinning.md

@@ -18,9 +18,8 @@ source:
 
 # pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가
 
-§5 는 QEMU vCPU 스레드도 다른 호스트 스레드와 마찬가지로 Linux 스케줄러가 실행할 논리 CPU 를 정한다고 적었다.
-관찰 수단은 §14.7 이 든다. `PSR` 은 `ps` 가 찍어 주는 값이고, 그 스레드가 최근 실행된 논리 CPU 를 가리킨다.
-다만 이 호스트에서 `PSR` 을 찍어 본 기록이 없어서, 같은 vCPU 스레드가 시간에 따라 다른 논리 CPU 로 옮겨 가는지는 아직 모른다.
+이 호스트에서 `PSR` 을 찍어 본 기록이 없어서, pinning 없이 같은 vCPU 스레드가 논리 CPU 사이를 옮겨 다니는지 아직 모른다.
+`PSR` 은 `ps` 가 찍어 주는 값이고 그 스레드가 최근 실행된 논리 CPU 를 가리킨다(§14.7). 이 호스트의 논리 코어는 8 이고 두 게스트의 vCPU 는 각각 2 다(§197 · §218).
 
 ## 관계
 
@@ -43,6 +42,9 @@ CPU pinning 을 적용하면 실행 위치를 특정 논리 CPU 집합으로 제
 
 §20 의 OQ-5 는 PSR 과 스케줄러 추적으로 관찰한다고만 적었을 뿐 관찰한 결과는 남기지 않았다.
 
+§197 은 2026-09-10 에 이 호스트에서 잰 값을 적었다. Core(s) per socket 4 에 Thread(s) per core 2 라 논리 코어가 8 이고, 실험대가 잡은 vCPU 는 2 + 2 + 1 = 5 다.
+§218 의 2026-09-03 배치는 kc-lab-1 과 kc-lab-2 에 각각 vCPU 2 를 적었다.
+
 이 호스트에서 PSR 을 실제로 찍은 기록은 SSOT 에 없다.
 
 ## 가정
@@ -68,7 +70,7 @@ CPU pinning 을 적용하면 실행 위치를 특정 논리 CPU 집합으로 제
 
 ## 제약
 
-이 프로젝트에는 이 호스트에서 잰 값이 하나도 없어서, 지금 이동 여부를 적으면 관측이 아니라 추측이 된다.
+이 호스트에서 PSR 을 찍은 값이 없어서, 지금 이동 여부를 적으면 관측이 아니라 추측이 된다.
 
 PSR 은 최근 실행된 논리 CPU 하나만 보여 주므로 두 표본 사이에 일어난 이동은 잡히지 않는다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-virtualization-layer-saturation-during-refresh.md

@@ -18,7 +18,7 @@ source:
 
 # Keycloak 동시 refresh 실험 중 CPU 가상화 계층이 결과를 흔들 만큼 포화되는가
 
-Keycloak refresh token 경쟁 실험은 가상 머신 두 대 위에서 돌기 때문에 원래 검증하려던 구조 아래에 KVM 계층이 하나 더 붙는다. 실험 구간에서 요청이 느려지거나 실패했을 때 그것을 refresh 경쟁 문제로 읽어도 되는지는 같은 구간의 호스트 CPU 사용량과 steal time 을 봐야 갈린다. steal time 은 게스트의 vCPU 에 실행할 작업이 있는데도 다른 작업 때문에 곧바로 실행되지 못한 상황을 가리키는 지표다(§13). 그런데 §20 이 함께 관찰하라고 든 다섯 지표를 아직 한 번도 같이 찍지 않았다.
+§20 이 함께 관찰하라고 든 다섯 지표를 아직 한 번도 같이 찍지 않았다. Keycloak refresh 경쟁 실험은 가상 머신 두 대 위에서 돌기 때문에, 원래 검증하려던 구조 아래에 KVM 계층이 하나 더 붙는다. 실험 구간의 지연을 refresh 경쟁으로 읽어도 되는지는 같은 구간의 호스트 CPU 와 steal time 이 갈라 준다.
 
 ## 관계
 
@@ -68,6 +68,8 @@ Host : CPU contention · CPU overcommit · Host saturation
 
 §26 은 refresh 경쟁을 검증하는 첫 실험에서 가능하면 CPU 자원을 여유 있게 유지하고, 그 상태에서 같은 세션과 같은 refresh token 에 대한 동시 요청을 만들어 동시성 문제를 먼저 확인하라고 적는다. 트래픽을 늘려 CPU/DB/Redis/K3s 자원 포화를 관찰하는 것은 별도의 부하·스트레스 Case 로 나눈다.
 
+§13 은 steal time 을 게스트 vCPU 에 실행할 작업이 있는데 다른 작업 때문에 즉시 실행되지 못하는 상황을 가리키는 단서로 적었다.
+
 §20 이 refresh 경쟁 실험 중 동시에 관찰하라고 든 다섯
 
 Host CPU
@@ -78,11 +80,14 @@ DB/Redis latency
 
 §20 은 그 목적이 refresh 경쟁과 호스트 자원 경쟁을 분리하는 것이라고 밝힌다.
 
+§197 은 2026-09-10 에 이 호스트에서 논리 코어 8 과 Mem: 11648 을 받아 적었고, 실험대가 잡은 vCPU 를 2 + 2 + 1 = 5 로 적었다. 실험 구간의 값은 아직 없다.
+
 ## 가정
 
 refresh 경쟁 실험이 Keycloak latency 와 DB/Redis latency 를 이미 재고 있다고 전제한다. 그 실험이 어떤 값을 어떤 주기로 내는지는 이 근거 문서에 적혀 있지 않다.
 
 기준값을 찍는 구간과 실험 구간 사이에 호스트의 다른 작업이 달라지지 않는다.
+§211 은 2026-09-03 과 2026-09-10 사이에 호스트 RAM 이 물리 증설되고 게스트가 두 대에서 세 대로 늘었다고 적으면서, 두 값이 어긋나 보이면 「틀린 것이 아니라 다른 날이다」라고 못 박았다. 기준값과 실험 구간은 같은 날 같은 구성에서 받아야 이 전제가 선다.
 
 다섯 지표의 시각을 맞춰 읽을 수 있다고 전제한다. 호스트 쪽과 게스트 쪽 시계가 어긋나면 부하 구간을 겹쳐 놓을 수 없기 때문이다.
 
@@ -104,7 +109,7 @@ refresh 경쟁 실험이 Keycloak latency 와 DB/Redis latency 를 이미 재고
 
 §26 이 첫 실험을 CPU 여유 상태로 못박기 때문에, 이 질문은 실험 조건을 바꾸지 않고 관찰 지표만 덧붙여 답해야 한다. §17.1 이 refresh token 경쟁을 확인하는 데 반드시 호스트 CPU 를 100% 까지 밀 필요는 없다고 적었으므로, 실험을 그대로 두고 관찰만 덧붙이는 것이 §26 의 조건과도 어긋나지 않는다.
 
-이 호스트에서 잰 값이 없어 기준값부터 만들어야 한다. 실험 구간의 값만 있으면 그 값이 평소 값인지 실험 때문에 오른 값인지 갈리지 않는다.
+이 호스트에서 그 다섯 지표를 잰 값이 없어 기준값부터 만들어야 한다. 실험 구간의 값만 있으면 그 값이 평소 값인지 실험 때문에 오른 값인지 갈리지 않는다.
 
 §22 의 Claim 12·13 은 이 환경에서 실제로 그러한지를 주장하는 것이라, 재기 전에는 Case 도 Question 도 되지 않는다고 보고 그대로 두었다. 이 물음을 그와 갈라 먼저 올린 것은 아는 것과 모르는 것이 실험 전에도 갈리기 때문이다.
 

docs/virtualization/tech-log-studio/cpu-virtualization/question/question-vm-exit-distribution-by-workload.md

@@ -18,7 +18,7 @@ source:
 
 # 실제 작업에서 주로 발생하는 VM Exit 은 무엇인가
 
-VM Exit 은 게스트를 실행하던 CPU 가 하이퍼바이저가 개입해야 하는 조건을 만나 KVM 쪽으로 제어권을 넘기는 전환이고, 가상 머신이 꺼지는 것이 아니다(§7.2). §8 은 Exit 을 낼 수 있는 동작을 일곱 가지로 들지만, 그 가운데 무엇이 실제로 Exit 을 내는지는 이 호스트의 VMX 설정과 돌리는 작업이 정한다. 유휴 구간과 CPU-bound 구간, Keycloak 부하 구간이 서로 다른 Exit 분포를 낼지는 재 봐야 알고, 그 전에 `perf kvm` 이 이 환경에서 열리는지부터 확인하지 않았다.
+`perf kvm` 이 이 환경에서 열리는지부터 아직 확인하지 않았다. VM Exit 은 게스트를 실행하던 CPU 가 KVM 쪽으로 제어권을 넘기는 전환이지 가상 머신이 꺼지는 것이 아니다(§7.2). §8 이 든 일곱 동작 가운데 무엇이 실제로 Exit 을 내는지는 이 호스트의 VMX 설정과 돌리는 작업이 정한다.
 
 ## 관계
 
@@ -52,6 +52,8 @@ CPU 에는 MSR(Model-Specific Register)이 있고 RDMSR 과 WRMSR 로 접근한
 
 §14.9 는 환경이 지원하면 perf kvm 으로 KVM 관련 실행 통계를 확인할 수 있다고 하면서 sudo perf kvm stat live 를 예로 든다. 지원되는 명령과 표시되는 Exit 이유는 커널, perf 버전, CPU 아키텍처 및 설정에 따라 다를 수 있다. 그래서 perf kvm --help 를 함께 확인하고, 필요하면 KVM tracepoint 를 이용한 별도 추적도 검토하라고 적는다.
 
+§197 은 2026-09-10 에 이 호스트에서 커널 7.2.2-arch1-1 과 QEMU emulator version 11.1.1 을 받아 적었다. CPU 는 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 이고 lscpu 의 Virtualization 은 VT-x 다. §14.9 가 표시되는 Exit 이유를 좌우한다고 든 것 가운데 커널과 CPU 아키텍처는 여기서 정해진다. perf 버전은 적혀 있지 않다.
+
 §20 이 든 비교 후보 다섯
 
 idle
@@ -64,7 +66,7 @@ Keycloak 부하 테스트
 
 다섯 작업을 이 호스트에서 각각 만들 수 있다. Keycloak 정상 요청과 부하 테스트는 이미 돌리는 실험을 그대로 쓴다고 전제한다.
 
-호스트에서 sudo 로 perf 를 돌릴 수 있다.
+호스트에서 sudo 로 perf 를 돌릴 수 있다. §204 는 이 호스트의 sudo 가 비밀번호를 요구해 비대화식으로는 읽지 못했다고 적었으므로, 콘솔에 붙어 직접 치는 실행으로 잡는다.
 
 한 작업을 재는 동안 다른 가상 머신이 내는 Exit 이 결과에 섞이지 않는다고 전제하는데, perf kvm 이 호스트 전체를 보는지 프로세스 하나만 보는지는 확인하지 않았다.
 
@@ -84,7 +86,7 @@ perf kvm 이 열리지 않을 때 KVM tracepoint 로 같은 것을 볼 수 있
 
 ## 제약
 
-이 호스트에서 잰 값이 없기 때문에, 분포를 재기 전에 도구가 열리는지부터 확인해야 한다. 도구가 이 환경에서 되는지부터 봐야 한다는 것은 이 물음을 접을 이유가 아니라 다음 검증의 첫 단계다. 열리지 않는 것으로 확인되는 것도 이 물음을 닫는 결과이기 때문이다.
+이 호스트에서 Exit 분포를 잰 값이 없기 때문에, 분포를 재기 전에 도구가 열리는지부터 확인해야 한다. 열리지 않는 것으로 확인되는 것도 이 물음을 닫는 결과다.
 
 §8 에 따르면 어떤 동작이 Exit 을 내는지는 VMX 설정이 정하기 때문에, 나온 분포는 이 호스트의 설정에 딸린 값이라 다른 호스트로 옮겨 읽을 수 없다.