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>
2026-09-17 11:01:55 +09:00
parent d473609e0a
commit 2109f726fe
574 changed files with 159654 additions and 1551 deletions
@@ -19,9 +19,7 @@ source:

 # balloon target 을 바꾸면 게스트가 쓸 수 있는 메모리는 어떻게 따라 움직이는가

-virtio-balloon 은 게스트에 RAM 을 새로 붙여 주는 장치가 아니라, 이미 있는 게스트 RAM 의 backing 을 호스트와 게스트가 협력해 회수하고 되돌려주는 가상 장치다. 호스트는 balloon target 을 조정해 그 balloon 을 부풀리거나 줄인다. 개념 문서는 방향까지 적어 두었는데, inflate 하면 게스트가 쓸 수 있는 RAM 이 줄고 deflate 하면 늘어난다.
-
-개념 문서가 방향만 적고 크기는 적지 않아서, 이 물음이 받는 것은 방향이 아니라 크기와 시점이다. 이 호스트에서 목표값을 한 단계 움직였을 때 게스트가 쓸 수 있는 메모리가 얼마나 줄어드는지를 아직 값으로 받아 본 적이 없다. 그 변화가 언제 보이는지, 어느 지점부터 게스트가 reclaim 과 스왑을 시작하는지도 마찬가지다.
+이 호스트에서 balloon target 을 한 단계 움직였을 때 게스트가 쓸 수 있는 메모리가 얼마나 줄어드는지 아직 값으로 받아 보지 못했다. virtio-balloon 은 게스트 RAM 의 backing 을 회수하고 되돌려주는 장치다. 개념 문서에는 inflate 하면 줄고 deflate 하면 늘어난다는 방향만 적혀 있다.

 ## 관계

@@ -69,7 +67,7 @@ virtio-balloon 은 게스트에 RAM 을 새로 붙여 주는 장치가 아니라
 - 단계마다 Host · VM · Workload 조건을 함께 적는다. 조건을 남기지 않은 결과는 다른 환경에서 다시 쓰기 어렵다.
 - 게스트 OOM 까지 밀어 볼지는 이 실험에서 정하지 않는다.
 - 개념 문서가 목표값을 바꾸는 명령을 적어 주지 않았으므로 실행한 명령과 그 출력을 증거로 함께 남긴다.
- 호스트가 실제로 회수한 backing memory 는 이 실험에서 재지 않는다. 개념 문서가 그 동작을 QEMU 와 KVM 버전, backing 종류, 설정에 따라 달라질 수 있다고만 적고 단정을 피했고, §83 OQ-9 가 준 관측 순서도 호스트 설정을 바꾼 뒤 게스트 쪽 값과 게스트의 reclaim 과 스왑 변화를 보는 데까지다.
+- 호스트가 실제로 회수한 backing memory 는 이 실험에서 재지 않는다. 개념 문서가 그 동작을 QEMU 와 KVM 버전, backing 종류, 설정에 따라 달라질 수 있다고만 적고 단정을 피했기 때문이다. §83 OQ-9 가 준 관측 순서도 호스트 설정을 바꾼 뒤 게스트 쪽 값과 게스트의 reclaim 과 스왑 변화를 보는 데까지다.

 ## 선택지

@@ -18,11 +18,7 @@ source:

 # 게스트 page fault 증가는 workload 변화를 따라가는가

-게스트 안에서 page fault 가 늘었다는 관측 하나로는 무슨 일이 일어났는지 갈리지 않는다. 개념 문서가 든 대표적인 원인은 다섯인데, 그 가운데 demand paging 과 copy-on-write 는 정상 동작이다. 나머지 중 swap-in 은 게스트 RAM 이 모자란다는 신호이고, invalid access 만 프로그램 오류로 이어진다.
-
-이 물음은 이 호스트의 게스트에서 부하를 올렸을 때 fault 지표가 함께 오르는지를 구간을 나눠 받는다. 올랐다면 그 증가가 다섯 원인 가운데 어느 쪽으로 설명되는지까지 본다.
-
-다섯 원인을 하나씩 묻지 않고 한 물음으로 묶었다. 원인마다 물음을 세우면 개념 문서에서 한 줄이던 것이 다섯 편이 되고, §83 OQ-13 이 갈라 보라고 한 네 갈래는 같은 구간의 같은 지표에서 나온다.
+이 호스트의 게스트에서 부하를 올렸을 때 page fault 지표가 함께 오르는지 아직 찍어 보지 않았다. 올랐다면 개념 문서가 든 다섯 원인 가운데 어느 쪽으로 설명되는지까지 본다. 다섯 가운데 demand paging 과 copy-on-write 는 정상 동작이라, 지표가 늘었다는 관측 하나로는 오류인지 아닌지 갈리지 않는다.

 ## 관계

@@ -68,6 +64,7 @@ source:

 ## 제약

+- 다섯 원인을 하나씩 따로 묻지 않고 한 물음으로 묶어 받는다. 나눠 세우면 개념 문서에서 한 줄이던 것이 다섯 편이 되고, §83 OQ-13 이 갈라 보라고 한 네 갈래는 같은 구간의 같은 지표에서 나온다.
 - 같은 구간의 스왑 활동을 함께 적지 않으면 demand paging 과 swap-in 이 갈리지 않는다.
 - fault 지표 하나로 원인을 확정하지 않는다. 개념 문서가 네 갈래를 갈라 보라고 적은 이유가 이것이다.
 - 부하를 만드는 방법을 두 실행에서 같게 둔다. 방법이 바뀌면 fault 증가가 부하 때문인지 방법 때문인지 갈리지 않는다.
@@ -77,7 +74,7 @@ source:

 ### 1. idle 구간과 부하 구간을 나눠 시간에 따른 변화를 받는다

-두 구간에서 vmstat 1 로 시간에 따른 값을 받고, 같은 구간의 스왑 활동과 애플리케이션의 working set 을 함께 남긴다. 부하가 올라간 시각과 fault 가 오른 시각이 겹치는지가 그대로 보이고, 스왑 활동이 없는데 fault 만 올랐으면 demand paging 쪽으로 좁혀진다.
+두 구간에서 vmstat 1 로 시간에 따른 값을 받고, 같은 구간의 스왑 활동과 애플리케이션의 working set 을 함께 남긴다. 부하가 올라간 시각과 fault 가 오른 시각이 겹치는지가 그대로 보인다. 스왑 활동이 없는데 fault 만 올랐으면 demand paging 쪽으로 좁혀진다.

 minor 와 major 를 프로세스 단위로 가르는 것까지는 이 방법으로 나오지 않는다.

@@ -18,9 +18,7 @@ source:

 # 호스트 major fault 와 스토리지 지연은 같은 시간축에서 함께 움직이는가

-개념 문서는 호스트의 메모리 압박에서 시작해 애플리케이션 지연으로 끝나는 사슬을 그려 두었다. 호스트 메모리 압박이 reclaim 과 스왑을 부르고, 그 스왑 I/O 가 스토리지 I/O 를 늘리고, 늘어난 I/O 가 한 물리 장치에서 경합하면 데이터베이스 지연을 거쳐 애플리케이션 지연까지 간다는 순서다.
-
-사슬의 각 마디는 개념으로 이어져 있지만, 이 호스트에서 네 마디가 같은 구간에 함께 움직이는지는 아직 받아 본 적이 없다. 이 물음은 압박 실험을 한 번 돌릴 때 네 계열을 같은 타임스탬프로 받아 그 사슬이 여기서 이어지는지 끊기는지를 가른다.
+이 호스트에서 major fault 와 스왑 활동, 스토리지 지연, 게스트 애플리케이션 지연 네 계열을 같은 시간축에 놓고 본 적이 아직 없다. 개념 문서가 그려 둔 사슬은 호스트 메모리 압박에서 시작한다. 압박이 reclaim 과 스왑을 부르고, 그 스왑 I/O 가 스토리지 경합을 거쳐 데이터베이스 지연과 애플리케이션 지연까지 간다.

 ## 관계

@@ -19,9 +19,7 @@ source:

 # 호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가

-게스트는 자기가 RAM 에 접근한다고 생각하는데, 그 backing page 가 호스트 RAM 에 없으면 호스트에서는 page fault 와 swap-in I/O 를 기다린 뒤에야 게스트 실행이 이어진다. 개념 문서는 그 경로가 스토리지 경합을 거쳐 애플리케이션 지연까지 이어질 수 있다고 그려 두었을 뿐 이 호스트에서 재지 않았다.
-
-이 물음은 baseline 을 잡고 호스트에 메모리 압박을 유도한 뒤 게스트 지연을 다시 재서, 그 경로가 실제로 이어지는지 확인한다.
+개념 문서가 그린 경로대로 호스트 메모리 압박이 스토리지 경합을 거쳐 게스트 애플리케이션 지연까지 이어지는지 이 호스트에서 재지 않았다. 게스트는 자기가 RAM 에 접근한다고 본다. 그런데 backing page 가 호스트 RAM 에 없으면 호스트에서 page fault 와 swap-in I/O 를 기다린 뒤에야 게스트 실행이 이어진다.

 ## 관계

@@ -81,13 +79,13 @@ source:
 - 압박을 유도한 상태로 운영 실험을 겹쳐 돌리지 않는다. 같은 스토리지를 쓰는 다른 실험이 있으면 시간을 나눈다.
 - 지연이 올랐다는 관측만으로 원인을 호스트 메모리로 확정하지 않는다. 같은 구간의 CPU 와 스토리지 지표를 함께 놓고 §86 의 분류로 계층을 가른다.
 - 압박의 허용 범위를 정하는 일은 이 물음 밖이다. 여기서는 경로가 이어지는지만 본다.
- 이 실험을 순서에서 앞당기지 않는다. §84 의 권장 실험 순서에서 압박 실험은 열두 단계 가운데 열 번째이고, 앞의 다섯 단계가 호스트와 가상 머신 조건을 채워 두므로 먼저 돌리면 세 구간에 남길 조건을 그때 다시 모아야 한다.
+- 이 실험을 순서에서 앞당기지 않는다. §84 의 권장 실험 순서에서 압박 실험은 열두 단계 가운데 열 번째다. 앞의 다섯 단계가 호스트와 가상 머신 조건을 채워 두므로, 먼저 돌리면 세 구간에 남길 조건을 그때 다시 모아야 한다.

 ## 선택지

 ### 1. 세 구간을 한 번에 돌리고 네 종류 지표를 같이 남긴다

-baseline, 압박, 압박 해제 세 구간에서 게스트 지연 · 호스트 vmstat · 스토리지 지연 · CPU 를 같은 시각에 기록한다. §83 OQ-7 이 적은 순서 그대로이고, 세 구간이 한 표에 들어가면 지연 변화가 어느 지표와 함께 움직였는지 그 표에서 읽힌다.
+baseline, 압박, 압박 해제 세 구간에서 게스트 지연 · 호스트 vmstat · 스토리지 지연 · CPU 를 같은 시각에 기록한다. §83 OQ-7 이 적은 순서 그대로다. 세 구간이 한 표에 들어가면 지연 변화가 어느 지표와 함께 움직였는지 그 표에서 읽힌다.

 압박을 유도하는 방법을 먼저 정해야 하고, 게스트에 같은 부하를 세 번 거는 준비가 필요하다.

@@ -18,11 +18,7 @@ source:

 # 이 호스트의 THP 정책과 huge page 상태는 무엇인가

-THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이 맞는 메모리 영역에 Huge Page 를 알아서 활용하려는 기능이다. 그 활용 범위를 정하는 정책 값이 커널과 배포판, 호스트 설정에 따라 다르다 보니, 개념 문서는 값을 적지 않고 실제 시스템에서 읽으라고만 했다.
-
-이 물음은 그 값을 읽는 데서 끝난다. 정책이 always 인지 madvise 인지 never 인지, 그리고 huge page 항목 넷의 값이 호스트와 두 게스트에 대해 적히면 닫힌다.
-
-§83 이 적은 열린 물음 열넷 가운데 확인 명령이 함께 적힌 것은 아홉이고 OQ-4 가 그 아홉에 든다. 명령이 없는 다섯은 전부 구간을 나눠 견주는 실험이고, 이 물음은 명령 두 줄의 출력으로 닫힌다.
+이 호스트의 THP 정책이 always 인지 madvise 인지 never 인지, huge page 항목 넷의 값이 얼마인지 아직 읽지 않았다. THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이 맞는 영역에 Huge Page 를 활용하려는 기능이다. 정책 값은 커널과 배포판에 따라 다르다.

 ## 관계

@@ -52,6 +48,7 @@ THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이
  HugePages_Total
  HugePages_Free
  Hugepagesize
+- §83 이 적은 열린 물음 열넷 가운데 확인 명령이 함께 적힌 것은 아홉이고, OQ-4 가 거기 든다. 명령이 없는 나머지 다섯은 전부 구간을 나눠 견주는 실험이다.
 - 이 호스트에서 그 다섯을 읽은 기록이 개념 문서에 없다. 게스트 쪽 값도 없다.

 ## 가정
@@ -99,4 +96,4 @@ THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이
 3. 같은 두 명령을 가상 머신마다 따로 찍고 호스트 값과 나란히 적는다.
 4. 실행한 명령과 출력, 찍은 시각을 함께 증거로 남긴다.

-닫는 조건 : 다섯 항목의 값이 호스트와 각 게스트에 대해 적히면 닫는다. HugePages_Total 이 0 이 아니면 그 풀을 가상 머신이 쓰고 있는지는 「가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가」가 받는다. 정책이 always 로 나오고 지연에 민감한 워크로드를 돌리고 있으면 §54 가 든 compaction 영향을 측정할지는 Decision 으로 넘긴다. 이 물음 자체는 정책 값을 확정하는 데서 끝난다.
+닫는 조건 : 다섯 항목의 값이 호스트와 게스트마다 적히면 닫는다. HugePages_Total 이 0 이 아니면 그 풀을 가상 머신이 쓰고 있는지는 「가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가」가 받는다. 정책이 always 로 나오고 지연에 민감한 워크로드를 돌리고 있으면 §54 가 든 compaction 영향을 측정할지는 Decision 으로 넘긴다. 이 물음 자체는 정책 값을 확정하는 데서 끝난다.
@@ -18,11 +18,7 @@ source:

 # NUMA remote access 가 이 작업의 지연을 실제로 바꾸는가

-NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가 어느 RAM 에 접근하느냐에 따라 비용이 달라질 수 있는 구조다. 배치가 어긋나 있다는 것과 그 어긋남 때문에 느려진다는 것은 다른 확인이다.
-
-개념 문서는 remote access 가 local access 와 같은 비용이라고 가정할 수 없다고까지 적었는데, 얼마나 다른지는 적지 않았다. 단순 토폴로지만 보고 성능 문제라고 단정하지 말라는 단서도 같은 항목에 달렸다. 이 물음은 이 호스트에서 같은 워크로드를 local 배치와 remote 위주 배치로 각각 돌려 두 값을 견주는 데까지 간다.
-
-§83 의 열린 물음 열넷 가운데 둘은 이 주제로 올리지 않고 CPU 가상화 쪽 물음에 합쳤다. 노드 수와 vCPU 배치는 한 번 읽으면 닫히고 그 물음이 이미 같은 것을 묻고 있어서다. 이 물음은 합치지 않았는데, 토폴로지를 아는 것과 지연이 달라지는 것이 한 번의 측정으로 함께 닫히지 않기 때문이다.
+이 호스트에서 local 배치와 remote 위주 배치로 같은 워크로드를 돌려 두 값을 견준 기록이 없다. NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가 어느 RAM 에 접근하느냐에 따라 비용이 달라질 수 있는 구조다. 배치가 어긋나 있다는 것과 그 어긋남 때문에 느려진다는 것은 다른 확인이다.

 ## 관계

@@ -38,10 +34,11 @@ NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가
 ## 사실

 - remote access 는 local access 와 동일한 비용이라고 가정할 수 없으며, 추가 지연과 대역폭 비용이 있을 수 있다.
- 큰 가상 머신에서는 게스트에게 NUMA 토폴로지 자체를 노출할 수 있고, 가능하면 게스트가 인식하는 토폴로지와 실제 호스트 배치가 합리적으로 맞물리도록 구성할 수 있다. 개념 문서가 든 예는 노드마다 vCPU 여덟과 RAM 32 GiB 를 둔 가상 머신이고, 이 프로젝트의 가상 머신이 그 크기인지는 적혀 있지 않다.
+- 큰 가상 머신에서는 게스트에게 NUMA 토폴로지 자체를 노출할 수 있고, 가능하면 게스트가 인식하는 토폴로지와 실제 호스트 배치가 합리적으로 맞물리도록 구성할 수 있다. 개념 문서가 든 예는 노드마다 vCPU 여덟과 RAM 32 GiB 를 둔 가상 머신이다. 이 프로젝트의 가상 머신이 그 크기인지는 적혀 있지 않다.
 - 개념 문서가 적은 실험 순서는 local 배치로 baseline 을 잡고 지연과 처리량과 메모리 지표를 받은 뒤, remote 위주 배치로 바꿔 동일 워크로드를 다시 돌려 견주는 것이다.
 - 같은 항목이 NUMA node 가 2개 이상인 경우에만 우선순위를 높이라고 적었다.
 - 단순 토폴로지만 보고 성능 문제라고 단정하지 않는다는 단서도 같은 항목에 있다.
+- §83 의 열린 물음 열넷 가운데 둘은 이 주제로 올리지 않고 CPU 가상화 쪽 물음에 합쳤다. 노드 수와 vCPU 배치는 한 번 읽으면 닫히는 데다, 그 물음이 이미 같은 것을 묻고 있어서다. 이 물음은 합치지 않았는데, 토폴로지를 아는 것과 지연이 달라지는 것이 한 번의 측정으로 함께 닫히지 않기 때문이다.
 - 개념 문서는 이 비교에 쓸 워크로드도, 지연과 처리량을 재는 명령도 적지 않았다. 실험 순서만 적혀 있다.
 - 이 호스트에서 두 배치를 각각 구성해 본 기록이 없다.

@@ -71,7 +68,7 @@ NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가

 ### 1. 같은 워크로드를 두 배치에서 돌려 값을 견준다

-local 배치에서 지연과 처리량과 메모리 지표를 받고, remote 위주로 바꿔 같은 워크로드를 같은 조건으로 다시 돌린다. 개념 문서가 적은 순서 그대로이고, 차이가 나든 나지 않든 그 값이 다음 판단의 근거가 된다.
+local 배치에서 지연과 처리량과 메모리 지표를 받고, remote 위주로 바꿔 같은 워크로드를 같은 조건으로 다시 돌린다. 개념 문서가 적은 순서를 그대로 따르는 방법이라, 차이가 나든 나지 않든 그 값이 다음 판단의 근거가 된다.

 배치를 바꾸는 방법을 먼저 정해야 하고, 두 실행 사이에 다른 조건을 고정하는 데 손이 간다.

@@ -19,9 +19,7 @@ source:

 # QEMU 메모리는 vCPU 가 도는 NUMA node 와 같은 node 에 있는가

-NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 RAM 에 닿느냐에 따라 접근 비용이 달라지는 구조를 말한다. 게스트의 vCPU 는 호스트에서 QEMU 의 vCPU 스레드이고, 그 스레드를 어느 논리 CPU 에 올릴지는 호스트 스케줄러가 정한다. 그 가상 머신의 메모리를 실제로 떠받치는 호스트 쪽 페이지가 어느 노드에 있는지는 그것과 따로 정해진다. 둘이 다른 노드로 갈리면 게스트 안에서는 평범한 memory load 로 보이는 동작이 실제 하드웨어에서는 노드 사이 interconnect 를 건넌다.
-
-이 물음이 받는 것은 그 어긋남이 성능을 바꾸는지가 아니다. 이 호스트의 가상 머신마다 vCPU 배치와 메모리 배치가 지금 어디에 놓여 있는지를 값으로 적는 데까지다.
+이 호스트의 가상 머신마다 vCPU 가 도는 노드와 메모리가 놓인 노드가 같은지 다른지 적은 값이 없다. NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 RAM 에 닿느냐에 따라 접근 비용이 달라지는 구조를 말한다. 이 물음은 지금 배치를 값으로 적는 데까지다. 그 어긋남이 지연을 바꾸는지는 다른 물음이 받는다.

 ## 관계

@@ -37,7 +35,7 @@ NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 RAM 에 닿느냐에
 ## 사실

 - 게스트 vCPU 는 호스트에서 QEMU 의 vCPU 스레드이고, 그 스레드는 호스트 Linux 스케줄러를 거쳐 호스트 논리 CPU 에서 실행된다.
- 어떤 가상 머신의 vCPU 스레드가 Node 0 의 CPU 에서 도는데 그 가상 머신의 호스트 쪽 physical backing page 가 Node 1 에 있으면 remote access 가 생길 수 있다. 게스트 안에서는 그것도 단순한 memory load 로 보인다.
+- 어떤 가상 머신의 vCPU 스레드가 Node 0 의 CPU 에서 도는데 그 가상 머신의 호스트 쪽 physical backing page 가 Node 1 에 있으면 remote access 가 생길 수 있다. 게스트 안에서는 그것도 단순한 memory load 로 보이지만 실제 하드웨어에서는 NUMA interconnect 를 건널 수 있다.
 - vCPU 를 특정 노드의 CPU 에 pinning 해도 메모리가 다른 노드에 주로 배치되어 있으면 pinning 이후에도 remote memory access 가 많아질 수 있다. 그래서 vCPU 배치와 메모리 배치를 함께 본다.
 - 개념 문서가 이상적인 예로 든 구성은 한 가상 머신의 vCPU 넷이 Node 0 의 CPU 에 붙고 그 가상 머신의 메모리 backing 도 Node 0 RAM 인 경우다.
 - 개념 문서는 이 확인에 쓸 명령을 적어 두었다.
@@ -79,14 +77,14 @@ QEMU 프로세스마다 numastat -p 를 돌리고, 같은 시각에 virsh vcpuin

 ### 2. 부하를 준 상태에서 한 번 더 받는다

-idle 상태의 배치만 보면 메모리가 아직 실제로 할당되지 않은 구간을 볼 수 있다. 게스트에서 workload 를 돌린 뒤 같은 두 값을 다시 받으면 실제로 쓰이는 메모리가 어느 노드에 잡히는지까지 나온다.
+idle 상태의 배치만 보면 메모리가 아직 실제로 할당되지 않은 구간을 볼 수 있다. 게스트에서 워크로드를 돌린 뒤 같은 두 값을 다시 받으면 실제로 쓰이는 메모리가 어느 노드에 잡히는지까지 나온다.

-실행이 두 번으로 늘고 어느 workload 를 쓸지 먼저 정해야 하는데, 그 선택이 결과를 바꾸기 때문에 workload 조건을 함께 적는다.
+실행이 두 번으로 늘고 어느 워크로드를 쓸지 먼저 정해야 하는데, 그 선택이 결과를 바꾸기 때문에 Workload 조건을 함께 적는다.

 ### 3. 게스트 안에서 numactl 로 확인한다 — 제외

 게스트에서도 NUMA 를 볼 수 있으니 게스트 안에서 확인하자는 방법이다.
-게스트가 보는 토폴로지는 가상 머신에 노출된 것이고 이 물음이 찾는 것은 호스트 쪽 physical backing 이 어느 노드에 있느냐이므로, 게스트 쪽 값으로는 그 배치를 알 수 없다.
+게스트가 보는 토폴로지는 가상 머신에 노출된 것이다. 이 물음이 찾는 것은 호스트 쪽 physical backing 이 어느 노드에 있느냐이므로, 게스트 쪽 값으로는 그 배치를 알 수 없다.
 개념 문서는 큰 가상 머신에서 게스트에게 NUMA 토폴로지 자체를 노출하고 게스트 노드와 호스트 배치가 대응되도록 구성할 수 있다고 적어 두었다. 이 프로젝트의 가상 머신이 그런 구성인지는 그 문서에 없어서, 게스트 값이 호스트 배치를 어디까지 반영하는지도 재기 전에는 모른다.

 ## 다음 검증
@@ -94,7 +92,7 @@ idle 상태의 배치만 보면 메모리가 아직 실제로 할당되지 않
 1. 호스트가 다중 NUMA 노드라는 확인을 CPU 가상화 쪽 물음에서 먼저 받는다.
 2. 가상 머신마다 QEMU 프로세스를 찾아 numastat -p <QEMU_PID> 로 노드별 메모리 분포를 찍는다.
 3. 같은 시각에 virsh vcpuinfo <VM_NAME> 와 virsh vcpupin <VM_NAME> 로 vCPU 배치를 적는다.
-4. 두 값을 가상 머신마다 한 표로 나란히 놓고, 노드가 같은지 갈리는지 적는다.
+4. 두 값을 가상 머신마다 한 표로 나란히 놓고, 노드가 같은지 다른지 적는다.
 5. Host · VM · Workload 조건을 같은 기록에 남긴다.

 닫는 조건 : 노드별 메모리 분포와 vCPU 배치가 가상 머신마다 한 표로 적히면 닫는다. 둘이 같은 노드로 모여 있으면 개념 문서가 경고한 어긋남이 이 환경에는 없다고 적고 닫는다. 어긋나 있으면 그 표가 Case 가 되고, 그 어긋남이 지연까지 바꾸는지는 「NUMA remote access 가 이 작업의 지연을 실제로 바꾸는가」가 받는다. memory binding 을 걸지 말지는 그 뒤 Decision 으로 넘긴다. 단일 NUMA 노드로 나오면 이 물음은 이 환경에 적용되지 않는다고 적고 닫는다.
@@ -19,16 +19,14 @@ source:

 # QEMU 프로세스가 실제로 붙잡고 있는 호스트 메모리는 얼마이고 어떻게 나뉘어 있는가

-게스트 RAM 은 QEMU(Quick Emulator, 가상 머신을 실행하는 호스트 userspace 프로그램) 프로세스의 주소 공간 안에 마련된다고 §40 이 적었다. 그래서 「이 가상 머신이 호스트 메모리를 얼마나 쓰고 있는가」는 그 프로세스가 지금 얼마나 큰지를 읽는 물음이 된다.
-
-이 물음은 실행 중인 가상 머신마다 QEMU 프로세스가 호스트에 얼마나 resident 한지, 그 값이 설정한 메모리(configured memory)와 얼마나 벌어져 있는지, 그리고 그 backing 이 anonymous 인지 huge page 인지를 적는다. 이 호스트에서 그 값을 읽은 기록은 없다.
+이 호스트에서 QEMU 프로세스가 붙잡고 있는 메모리를 읽은 기록이 없다. 게스트 RAM 은 QEMU(Quick Emulator, 가상 머신을 실행하는 호스트 userspace 프로그램) 프로세스의 주소 공간 안에 마련된다고 §40 이 적었다. 그래서 이 가상 머신이 호스트 메모리를 얼마나 쓰고 있는가는 그 프로세스가 얼마나 큰지를 읽는 물음이 된다.

 ## 관계

 - **Guest 메모리 주소가 물리 RAM 에 닿기까지 — GVA · GPA · HPA**
  QEMU 가 마련한 호스트 주소 공간이 게스트 물리 주소와 어떻게 이어지는지를 그 기록이 설명한다.
 - **이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가**
-  같은 접속에서 값을 받는다. 그쪽이 적는 설정 값을 옆에 놓아야 여기서 벌어짐을 적을 수 있다.
+  같은 접속에서 값을 받는다. 그쪽이 적는 설정 값을 옆에 놓아야 여기서 얼마나 벌어져 있는지 적을 수 있다.
 - **가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가**
  여기서 huge page 항목이 보이면 그 물음으로 넘긴다.
 - **메모리 실험 결과에는 Host · VM · Workload 조건을 함께 남긴다**
@@ -42,7 +40,7 @@ source:

 §41 은 QEMU 가 마련한 호스트 userspace 메모리 영역이 게스트 GPA 의 어느 범위를 떠받치는지를 KVM 에 등록한다고 적고, 대표 ioctl 로 KVM_SET_USER_MEMORY_REGION 을 들었다. 역할은 셋으로 갈린다. QEMU 는 게스트 RAM 을 위한 호스트 userspace backing 을 내주고, KVM 은 게스트의 메모리 영역과 가상화 매핑을 관리하며, 실행 중의 주소 변환은 CPU 가 한다.

-§42 는 설정한 메모리와 게스트가 현재 실제 사용하는 메모리, 호스트에서 현재 resident 한 물리 메모리 셋이 같지 않을 수 있다고 적었다. 그 차이를 만드는 것으로 호스트의 demand paging, backing 종류, HugeTLB, memory locking, preallocation, overcommit 정책을 들었다.
+§42 는 설정한 메모리(configured memory)와 게스트가 현재 실제 사용하는 메모리, 호스트에서 현재 resident 한 물리 메모리 셋이 같지 않을 수 있다고 적었다. 그 차이를 만드는 것으로 호스트의 demand paging, backing 종류, HugeTLB, memory locking, preallocation, overcommit 정책을 들었다.

 §83 의 OQ-3 은 확인 명령으로 ps -ef | grep qemu 와 ps -o pid,rss,vsz,cmd -p <QEMU_PID> 를 적었다. 필요하면 cat /proc/<QEMU_PID>/status 와 cat /proc/<QEMU_PID>/smaps_rollup 을 보고, 설정한 메모리와 RSS/anonymous/huge-page 상태를 비교하라고 했다.

@@ -74,7 +72,7 @@ smaps_rollup 을 읽을 권한이 있다고 전제한다. 다른 사용자의

 이 호스트에서 QEMU 프로세스의 크기를 읽은 값이 없다. §40 의 8 GiB 와 §42 의 16 GiB 는 설명을 위한 예시이므로 이 환경의 값으로 옮겨 쓰지 않는다.

-설정한 메모리를 옆에 놓지 않으면 벌어짐을 적을 수 없다. 그 값은 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 받는다.
+설정한 메모리를 옆에 놓지 않으면 얼마나 벌어져 있는지 적을 수 없다. 그 값은 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 받는다.

 §42 가 게스트 사용량과 호스트 resident 를 다른 값으로 갈라 놓았기 때문에, resident 크기 하나로는 게스트가 그 메모리를 지금 쓰고 있는지 알 수 없다.

@@ -105,7 +103,7 @@ backing 이 anonymous 인지 huge page 인지는 나오지 않는다. 그 항목
 1. ps -ef | grep qemu 로 실행 중인 QEMU 프로세스의 PID 를 찾고 가상 머신 이름과 짝짓는다 (§83 OQ-3).
 2. 프로세스마다 ps -o pid,rss,vsz,cmd -p <QEMU_PID> 를 찍는다.
 3. cat /proc/<QEMU_PID>/status 와 cat /proc/<QEMU_PID>/smaps_rollup 을 남겨 anonymous 와 huge page 항목을 읽는다.
-4. 같은 접속에서 설정한 메모리와 지금 쓰는 메모리를 묻는 물음의 값을 옆에 놓고 벌어짐을 적는다.
+4. 같은 접속에서 설정한 메모리와 지금 쓰는 메모리를 묻는 물음의 값을 옆에 놓고 얼마나 벌어져 있는지 적는다.
 5. 남기는 조건은 메모리 실험 조건 기준을 따른다.

 닫는 조건 : 가상 머신마다 설정 값 · RSS · VSZ 와 anonymous/huge-page 구성이 한 표에 적히면 닫는다. RSS 가 설정 값에 크게 못 미치면 §42 가 말한 차이를 이 호스트에서 확인한 것이 되므로, 주소 변환 개념 기록의 확인 사례로 넣는다. huge page backing 이 보이면 HugeTLB backing 을 묻는 물음으로 넘긴다.
@@ -18,7 +18,7 @@ source:

 # 지금 게스트와 호스트에서 swap 이 실제로 오가고 있는가

-Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다는 뜻은 아니다. 그 값이 과거에 swap-out 된 cold page 때문에 커져 있을 수도 있어서, §63 은 값이 얼마인가 대신 지금 swap-in/out 이 지속되는가를 물으라고 적었다. 이 물음은 그 질문을 이 호스트와 두 게스트에서 같은 시각에 던진다. 게스트 swap 과 호스트 swap 은 서로 다른 경로이므로 한쪽만 보고 다른 쪽을 짐작하지 않는다.
+Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다는 뜻은 아니다. 그 값이 과거에 swap-out 된 cold page 때문에 커져 있을 수도 있어서, §63 은 값이 얼마인가 대신 지금 swap-in/out 이 지속되는가를 물으라고 적었다. 이 물음은 그 질문을 이 호스트와 게스트 세 대에서 같은 시각에 던진다. 게스트 swap 과 호스트 swap 은 서로 다른 경로이므로 한쪽만 보고 다른 쪽을 짐작하지 않는다.

 ## 관계

@@ -46,14 +46,16 @@ Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다
 - §61 은 게스트 swap 을 게스트 애플리케이션에서 시작해 게스트 메모리 압박, 게스트 커널, 게스트 swap, /dev/vda, virtio-blk, QEMU 를 거쳐 호스트 스토리지로 내려가는 경로로 그렸다.
 - §61 은 호스트 swap 을 게스트 RAM 이 QEMU 의 메모리 backing 을 거쳐 호스트 메모리 압박을 받고 호스트 커널이 호스트 swap 으로 내리는 경로로 그렸다. 같은 절이 두 경로를 같지 않다고 적고, 게스트가 메모리 여유가 있어 보이는데 호스트에서 swap 이나 reclaim 이 심할 수도 있다고 덧붙였다.
 - 개념 문서는 vmstat 출력에서 어느 열을 swap-in 과 swap-out 으로 읽는지 적지 않았다.
- 이 호스트와 두 게스트에서 free -h 나 vmstat 를 찍은 기록이 개념 문서에 없다.
+- 호스트에서 free 를 찍은 기록은 §178 과 §197 에 있다. 2026-09-10 에 test-server 에서 free -m 을 head -2 로 잘라 받은 출력이라 Mem 줄까지만 남아 있고 Swap 줄이 없다.
+- 게스트 세 대에서 free 나 vmstat 를 찍은 기록도, 호스트에서 vmstat 를 돌린 기록도 개념 문서에 없다.
+- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대다.

 ## 가정

- 호스트와 두 게스트에 동시에 접속해 같은 구간을 관측할 수 있다고 본다.
+- 호스트와 게스트 세 대에 동시에 접속해 같은 구간을 관측할 수 있다고 본다.
 - 관측하는 동안 실험용 부하를 따로 걸지 않고 평상시 상태를 재는 것으로 둔다. 그 상태가 이 호스트의 대표적인 상태인지는 한 번의 관측으로 알 수 없다.
 - 게스트와 호스트의 시계가 맞아 두 기록을 같은 시간축에 놓을 수 있다고 전제한다.
- 두 가상 머신 모두 swap 영역을 갖고 있다고 보고 게스트 쪽을 읽는다. 설정에 swap 이 없으면 게스트 쪽 관측은 그 사실로 끝난다.
+- 게스트 세 대 모두 swap 영역을 갖고 있다고 보고 게스트 쪽을 읽는다. 설정에 swap 이 없으면 게스트 쪽 관측은 그 사실로 끝난다.

 ## 미지수

@@ -61,6 +63,7 @@ Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다
 - Swap Used 가 0 이 아니라면 그 값이 과거에 내려간 cold page 때문인지 지금 진행 중인 swap 활동 때문인지.
 - §63 이 든 나머지 셋 가운데 reclaim pressure 와 major fault 를 이 환경에서 어떤 값으로 읽는지. 그 둘을 읽는 명령은 개념 문서에 없다.
 - 관측을 얼마나 오래 해야 지속 여부를 말할 수 있는지. 개념 문서는 vmstat 1 만 적고 관측 길이를 적지 않았다.
+- 호스트에 swap 영역이 설정돼 있는지. §178 과 §197 의 free 출력이 Mem 줄까지만 잘려 있어 Swap 줄을 보지 못했다.

 ## 제약

@@ -75,9 +78,9 @@ Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다

 ### 1. 게스트와 호스트에서 같은 구간을 동시에 관측한다

-세 곳에서 free -h 를 한 번 찍어 기준을 남기고, vmstat 1 을 같은 시각에 시작해 같은 길이로 돌린다. §61 이 갈라 놓은 두 경로가 같은 시간축의 값으로 남아 한쪽만 움직이는 경우와 둘 다 움직이는 경우를 구분할 수 있다.
+호스트와 게스트 세 대, 네 곳에서 free -h 를 한 번 찍어 기준을 남기고 vmstat 1 을 같은 시각에 시작해 같은 길이로 돌린다. §61 이 갈라 놓은 두 경로가 같은 시간축의 값으로 남아 한쪽만 움직이는 경우와 둘 다 움직이는 경우를 구분할 수 있다.

-세 곳에 동시에 붙어야 하고 관측 길이를 먼저 정해야 한다.
+네 곳에 동시에 붙어야 하고 관측 길이를 먼저 정해야 한다.

 ### 2. 호스트만 먼저 관측한다

@@ -91,9 +94,9 @@ free -h 한 번씩으로 끝내는 방법이다. §63 이 그 값만으로 판

 ## 다음 검증

-1. 호스트와 각 게스트에서 free -h 를 한 번씩 찍어 그 시점의 Swap Used 를 기준으로 남긴다.
-2. 세 곳에서 vmstat 1 을 같은 시각에 시작해 미리 정한 길이만큼 돌리고, 출력에서 swap-in 과 swap-out 으로 읽은 열의 이름을 함께 적는다.
+1. 호스트와 각 게스트에서 free -h 를 한 번씩 찍어 그 시점의 Swap Used 를 기준으로 남긴다. 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대다.
+2. 네 곳에서 vmstat 1 을 같은 시각에 시작해 미리 정한 길이만큼 돌리고, 출력에서 swap-in 과 swap-out 으로 읽은 열의 이름을 함께 적는다.
 3. 같은 구간에서 §63 이 든 나머지 셋 가운데 읽을 수 있는 것 — reclaim pressure · major fault · storage latency — 을 어떤 명령으로 읽었는지와 함께 남긴다.
-4. 세 기록을 같은 시간축에 놓고 어느 쪽에서 무엇이 움직였는지 적는다.
+4. 네 기록을 같은 시간축에 놓고 어느 쪽에서 무엇이 움직였는지 적는다.

 닫는 조건 : 관측 구간 내내 게스트와 호스트 모두 swap-in 과 swap-out 이 0 이면 지금은 swap 이 오가지 않는다고 적고 닫는다. Swap Used 가 0 이 아니어도 그렇게 적는다. 한쪽에서 swap 이 오가면 §61 의 두 경로 중 어느 쪽인지를 적고, 그 구간의 스토리지 지연과 게스트 지연을 함께 적어 「호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가」로 넘긴다.
@@ -18,7 +18,7 @@ source:

 # 이 가상 머신들에 virtio-balloon 이 붙어 있는가

-virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtqueue 로 맞물려 동작한다. 장치가 없거나 게스트 쪽 드라이버가 올라와 있지 않으면 balloon target 을 바꾸는 실험 자체가 성립하지 않으므로, 동적 메모리 회수를 다루기 전에 이 확인이 먼저다. 개념 문서는 확인 명령까지만 적고 이 호스트의 설정은 읽지 않았다.
+libvirt 설정에서 balloon 장치를 읽은 기록이 아직 없다. 다만 §198 의 virsh dommemstat 실측에서 kc-lab-2 의 현재 할당이 선언한 4096MB 가 아니라 3120MB 로 나왔다. 근거 문서는 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적었다. 장치가 없거나 게스트 쪽 드라이버가 올라와 있지 않으면 balloon target 을 바꾸는 실험이 성립하지 않으므로, 설정과 게스트 쪽 상태를 읽는 이 확인이 먼저다.

 ## 관계

@@ -40,11 +40,18 @@ virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtq
 - §83 OQ-8 은 환경에 따라 드라이버 이름과 표시 방식이 달라질 수 있으므로 실제 장비에서 검증하라는 단서를 달았다.
  그래서 개념 문서에는 게스트 쪽에서 무엇을 찾아야 하는지가 이름으로 적혀 있지 않다.
 - §83 OQ-2 는 가상 머신 메모리 확인 명령으로 virsh dominfo <VM_NAME> · virsh dumpxml <VM_NAME> · virsh dommemstat <VM_NAME> 셋을 들었다.
+- §198 은 VM 에 준 메모리가 상한이지 점유가 아니라고 적으면서 virtio-balloon 이 안 쓰는 만큼 호스트에 돌려준다고 덧붙였다.
+- §198 이 virsh dommemstat 으로 k3s 게스트 두 대를 재서 아래 값을 받았다. k3s 만 떠 있고 Keycloak 은 올리기 전 상태다.
+  kc-lab-1 : 할당 5120MB · 실사용 353MB
+  kc-lab-2 : 할당 3120MB · 실사용 301MB
+- kc-lab-2 는 virt-install --memory 4096 으로 만들었는데 현재 할당이 3120MB 로 나왔다. §198 은 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적고 단정하지 않았다.
+- §198 은 dommemstat 의 actual 이 현재 할당이고 선언한 상한은 virsh dominfo 의 Max memory 에 있다고 적으면서, 이 실험대에서 그 두 값을 나란히 찍어 보지 않았다고 미측정으로 남겼다.
+- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대이고, §198 의 측정에 kc-lab-edge 는 들어 있지 않다.
 - 이 호스트의 가상 머신 설정에서 balloon 관련 요소를 읽은 기록이 개념 문서에 없다.

 ## 가정

- 두 가상 머신 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
+- 게스트 세 대 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
 - 설정에 balloon 장치가 있으면 게스트 쪽에도 대응하는 드라이버가 보인다고 전제한다. 그 전제가 이 게스트 배포판에서 맞는지는 확인하지 않았다.
 - 게스트에 접속해 장치 목록이나 커널 모듈 상태를 읽을 수 있다고 본다.

@@ -54,10 +61,13 @@ virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtq
 - 있다면 게스트 안에서 그 드라이버가 실제로 올라와 있는지.
 - 이 환경에서 그 드라이버나 장치가 어떤 이름으로 보이는지. 개념 문서가 환경마다 다를 수 있다고만 적고 이름을 남기지 않았다.
 - 게스트 쪽 상태를 어떤 명령으로 읽는지. 개념 문서가 게스트 확인 명령을 적지 않아 실행하는 쪽이 정한다.
+- kc-lab-2 의 현재 할당이 선언값보다 작은 것이 balloon 회수 때문인지 다른 경로로 정해진 값인지. §332 는 virsh setmem 이 현재 할당을 바꾸는 명령이라고 적었다. §187 은 게스트 메모리를 3584MB 에서 5120MB 와 4096MB 로 재배분했다고 적었다.
+- kc-lab-edge 의 값. §198 이 그 게스트를 재지 않았다.

 ## 제약

 - 이 물음에서 balloon target 을 움직이지 않는다. 구성 여부를 적는 것이 전부다.
+- §198 의 값은 설정 확인을 대신하지 않는다. 근거 문서가 회수해 간 것으로 보인다고 적은 것을 이 물음이 관측으로 올리지 않는다.
 - 설정에 장치가 있다는 것만으로 동작한다고 적지 않는다. §83 OQ-8 이 게스트 쪽 상태도 확인하라고 적었다.
 - 설정과 드라이버가 둘 다 보여도 호스트가 backing 을 실제로 언제 회수하는지는 이 확인으로 알 수 없다. §67 이 정확한 Host-side release 동작은 QEMU/KVM 버전, backing 종류 및 설정에 따라 달라질 수 있다고 적고 그 동작을 단정하지 않았다. 개념 문서가 단정하지 않은 것을 이 물음이 대신 단정하지 않는다.
 - 게스트 쪽에서 쓴 명령과 그 출력을 그대로 남긴다. 이름이 환경마다 다르므로 다음 사람이 같은 것을 찾으려면 무엇을 봤는지가 필요하다.
@@ -70,18 +80,19 @@ virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtq

 가상 머신마다 virsh dumpxml 을 찍어 balloon 관련 요소를 인용하고, 이어서 각 게스트에서 드라이버나 장치 상태를 읽어 실제로 보이는 이름과 함께 적는다. §83 OQ-8 이 요구한 두 확인이 한 번에 끝난다.

-게스트 두 대에 접속해야 하고, 게스트 쪽 확인 명령을 실행하는 쪽이 정해야 한다.
+게스트 세 대에 접속해야 하고, 게스트 쪽 확인 명령을 실행하는 쪽이 정해야 한다.

 ### 2. 호스트 설정만 읽고 넘어간다

-virsh dumpxml 두 번으로 끝난다. 설정에 balloon 장치가 없으면 게스트 쪽을 볼 이유가 없어 이 물음이 거기서 닫힌다.
+게스트마다 virsh dumpxml 을 한 번씩 치는 것으로 끝난다. 설정에 balloon 장치가 없으면 게스트 쪽을 볼 이유가 없어 이 물음이 거기서 닫힌다.

 장치가 있는 것으로 나오면 게스트 쪽 드라이버가 올라와 있는지를 확인하러 다시 가야 한다.

 ## 다음 검증

-1. 가상 머신마다 virsh dumpxml <VM_NAME> 을 남기고 balloon 관련 요소를 그대로 인용한다.
+1. 가상 머신마다 virsh dumpxml <VM_NAME> 을 남기고 balloon 관련 요소를 그대로 인용한다. 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대다.
 2. 각 게스트에서 balloon 관련 드라이버나 장치 상태를 확인하고, 실행한 명령과 실제로 보인 이름을 함께 적는다.
-3. 같은 실행에서 virsh dommemstat <VM_NAME> 출력도 받아 남긴다. 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 같은 출력을 읽는다.
+3. 같은 실행에서 virsh dommemstat <VM_NAME> 과 virsh dominfo <VM_NAME> 을 나란히 찍어 현재 할당과 Max memory 를 함께 남긴다. §198 이 dommemstat 만 찍어 그 둘을 나란히 보지 않았다.
+4. 세 게스트의 값을 같은 표에 적는다. 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 같은 출력을 읽는다.

 닫는 조건 : 설정과 게스트 쪽 상태가 둘 다 적히면 닫는다. 붙어 있지 않으면 이 환경에서는 ballooning 이 동작하지 않는다고 적고 「balloon target 을 바꾸면 게스트가 쓸 수 있는 메모리는 어떻게 따라 움직이는가」는 열지 않은 채로 둔다. 장치가 없으면 그 실험이 성립하지 않는다. 붙어 있으면 그 물음으로 넘긴다.
@@ -18,9 +18,7 @@ source:

 # 이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가

-§42 는 가상 머신에 설정한 메모리와 게스트가 지금 실제로 쓰는 메모리, 그리고 호스트에서 지금 resident 한 물리 메모리를 서로 다른 세 값으로 갈라 놓았다. 이 물음은 그 세 값이 이 호스트에서 각각 얼마인지를 가상 머신마다 적는다.
-
-세 값이 벌어져 있는지에 따라 다음에 무엇을 잴지가 갈린다. 설정한 총량이 호스트 RAM 을 넘으면 §57 이 서술한 overcommit 구성에 이 환경이 들어가고, 넘지 않으면 그 절의 시나리오는 여기 걸리지 않는다. 이 호스트의 물리 RAM 도 각 가상 머신에 설정한 메모리도 개념 문서에 적혀 있지 않다.
+호스트 RAM 11,648MiB 와 게스트 배정 합 10,240MB 가 실측으로 나왔고 배정 합이 더 작다. 게스트가 지금 실제로 쓰는 메모리와 호스트에서 resident 한 물리 메모리는 아직 안 쟀다. 이 물음은 그 두 값을 가상 머신마다 적어 설정 값과 얼마나 벌어지는지를 본다.

 ## 관계

@@ -45,11 +43,21 @@ Host 에서 현재 resident 한 Physical Memory

 세 값을 갈라 놓는 요인으로 §42 가 든 것은 호스트의 demand paging, backing 종류, HugeTLB, memory locking, preallocation, overcommit 정책이다. 그래서 가상 머신 RAM 16 GiB 를 호스트 RAM 에서 고정된 연속 16 GiB 로 단순화하면 안 된다고 같은 절이 적었다.

-§57 은 게스트에 설정한 메모리 총량이 호스트 물리 RAM 보다 큰 구성이 가능할 수 있는 이유를, 설정 용량과 현재 실제 working set 또는 resident 메모리가 같지 않을 수 있다는 데서 찾았다. 다만 모든 가상 머신의 실제 수요가 동시에 증가하면 문제가 발생한다고 이어 적었다.
+설정 용량과 현재 실제 working set 또는 resident 메모리가 같지 않을 수 있기 때문에, 게스트에 설정한 메모리 총량이 호스트 물리 RAM 보다 큰 구성도 가능할 수 있다고 §57 이 적었다. 다만 모든 가상 머신의 실제 수요가 동시에 증가하면 문제가 발생한다고 이어 적었다.

 §83 의 OQ-2 는 확인 명령을 호스트 쪽과 게스트 쪽으로 나눠 적었다. 호스트에서는 virsh dominfo <VM_NAME> 과 virsh dumpxml <VM_NAME>, virsh dommemstat <VM_NAME> 을 쓰고, 게스트에서는 free -h 와 cat /proc/meminfo 를 쓴 뒤 호스트의 QEMU 프로세스 상태와 비교한다.

-이 호스트의 물리 RAM 과 각 가상 머신에 설정한 메모리를 적은 값은 개념 문서 어디에도 없다. §57 의 32 GiB 와 16 GiB, §42 의 16 GiB 는 설명을 위한 예시다.
+이 호스트의 물리 RAM 은 §178 이 실측으로 적었다. 2026-09-10 에 test-server 에서 free -m 으로 받은 출력의 Mem 줄 total 이 11648 이고, free -m 은 MiB 단위라 11,648MiB 다.
+
+게스트 세 대에 배정한 메모리는 §187 이 적었다.
+
+kc-lab-edge : 1024MB
+kc-lab-1 : 5120MB
+kc-lab-2 : 4096MB
+
+배정 합은 10,240MB 다. 호스트 RAM 11,648MiB 보다 작아서 배정률은 10240/11648 = 87.9% 이고, 배정하지 않고 남은 것이 1,408MiB 다. 그래서 「Guest configured memory 총량이 Host physical RAM보다 크다」는 §57 의 조건에 이 배치는 해당하지 않는다.
+
+§57 의 32 GiB 와 16 GiB, §42 의 16 GiB 는 설명을 위한 예시라 이 환경의 값이 아니다.

 §85 가 실험마다 함께 남기라고 적은 VM 조건에 Configured RAM 과 Current RAM 이 들어 있다. 이 물음이 내는 값은 여기서 한 번 쓰고 마는 것이 아니라 뒤따르는 메모리 실험의 조건 칸으로 그대로 들어간다.

@@ -65,21 +73,19 @@ Host 에서 현재 resident 한 Physical Memory

 ## 미지수

-이 호스트의 물리 RAM 은 얼마인가.
+지금 각 게스트가 실제로 쓰고 있는 메모리는 얼마인가.

-각 가상 머신에 설정한 메모리는 얼마이고, 그 합이 호스트 RAM 을 넘는가.
+호스트에서 그 가상 머신 몫으로 resident 한 메모리는 얼마인가.

-넘든 넘지 않든, 지금 각 게스트가 실제로 쓰고 있는 메모리는 얼마이고 호스트에서 그 가상 머신 몫으로 resident 한 메모리는 얼마인가.
-
-세 값이 설정 값과 얼마나 벌어져 있는가.
+그 두 값이 배정한 값과 얼마나 벌어져 있는가.

 ## 제약

-이 호스트에서 잰 값이 없다. §42 와 §57 이 든 숫자는 개념을 보이려고 든 예시이므로 이 환경의 값으로 옮겨 쓰지 않는다.
+게스트 사용량과 호스트 resident 는 이 호스트에서 잰 값이 없다. §42 와 §57 이 든 숫자는 개념을 보이려고 든 예시이므로 이 환경의 값으로 옮겨 쓰지 않는다.

 §84 의 권장 실험 순서는 가상 머신 설정 값 확인과 게스트 free/meminfo 확인을 둘째와 셋째로 나눠 적었다. 여기서는 그 둘을 한 물음으로 묶는다. 이 물음이 답할 것이 세 값의 차이라서 호스트 쪽과 게스트 쪽을 다른 시각에 찍으면 그 차이가 어느 시점의 것인지 말할 수 없다.

-세 값을 서로 다른 시각에 찍으면 비교가 성립하지 않는다. 게스트 사용량은 workload 가 달라지면 같이 움직인다.
+세 값을 서로 다른 시각에 찍으면 비교가 성립하지 않는다. 게스트 사용량은 워크로드가 달라지면 같이 움직인다.

 이 물음은 설정한 값과 실제 사용량의 차이를 적는 데까지다. 그 차이가 있을 때 무엇이 일어나는지는 swap 과 호스트 메모리 압박을 다루는 물음들이 받는다.

@@ -89,15 +95,15 @@ QEMU 프로세스 쪽 값은 여기서 닫지 않는다. virsh 가 보고하는

 ### 1. 실행 중인 가상 머신 전부를 한 번에 찍는다

-virsh list 로 실행 중인 가상 머신을 세고, 각각에 대해 호스트 세 명령과 게스트 두 명령을 같은 시각에 돌린다. 설정 총량과 호스트 RAM 을 그 자료 하나로 견줄 수 있어서 overcommit 여부가 이 실행에서 정해진다.
+virsh list 로 실행 중인 가상 머신을 세고, 가상 머신마다 호스트 세 명령과 게스트 두 명령을 같은 시각에 돌린다. 게스트 사용량과 호스트 resident 를 가상 머신마다 같은 시각의 값으로 받는다.

 가상 머신이 여럿이면 명령 수가 늘어 같은 시각을 지키기 어려워진다. 그럴 때는 호스트 쪽을 먼저 한 번에 돌리고 게스트 쪽을 이어서 돌린 뒤 두 시각을 함께 적는다.

 ### 2. 가상 머신 하나로 표 모양을 먼저 정하고 나머지로 넓힌다

-한 대에 대해 다섯 명령을 돌려 세 값을 어디서 읽는지 확정한 다음 나머지에 같은 순서를 적용한다. 값을 잘못 읽어 표를 다시 만드는 일을 줄인다.
+한 대에서 다섯 명령을 돌려 세 값을 어디서 읽는지 확정한 다음 나머지에 같은 순서를 적용한다. 값을 잘못 읽어 표를 다시 만드는 일을 줄인다.

-두 번 붙어야 하고, 첫 실행과 두 번째 실행 사이에 게스트 사용량이 달라진다. overcommit 판정에 필요한 설정 값은 그 사이에 바뀌지 않으므로 판정 자체는 갈리지 않는다.
+두 번 붙어야 하고, 첫 실행과 두 번째 실행 사이에 게스트 사용량이 달라진다. 이 물음에 남은 것이 사용량과 resident 두 값뿐이라 그 차이가 답에 그대로 들어간다.

 ### 3. QEMU 프로세스 값까지 이번에 함께 읽는다 — 제외

@@ -110,7 +116,7 @@ QEMU 쪽은 별도의 물음이 이미 받고 있고 그쪽은 anonymous 인지
 1. virsh list 로 실행 중인 가상 머신 이름을 적는다.
 2. 가상 머신마다 호스트에서 virsh dominfo <VM_NAME> 으로 configured/current memory 를, virsh dumpxml <VM_NAME> 으로 memory backing 설정을, virsh dommemstat <VM_NAME> 으로 balloon 계열 값을 남긴다 (§83 OQ-2).
 3. 같은 시각에 각 게스트에서 free -h 와 cat /proc/meminfo 를 찍는다.
-4. 호스트의 free -h 도 함께 남겨 물리 RAM 과 현재 여유를 적는다.
+4. 호스트의 free -h 도 같은 시각에 남겨 그 시점의 여유를 적는다.
 5. 남기는 조건은 메모리 실험 조건 기준을 따른다. QEMU 프로세스의 resident 값은 QEMU 쪽 물음이 받는다.

-닫는 조건 : 설정 값 · 게스트 사용량 · 호스트 resident 세 값을 가상 머신마다 한 표로 적으면 닫는다. 설정 총량이 호스트 RAM 을 넘으면 이 환경이 overcommit 상태라는 사실을 확정한 것이 되고, 그 상태에서 무엇이 일어나는지는 swap 을 묻는 물음과 호스트 메모리 압박을 묻는 물음이 받는다. 넘지 않으면 §57 의 시나리오가 이 환경에 적용되지 않는다.
+닫는 조건 : 설정 값 · 게스트 사용량 · 호스트 resident 세 값을 가상 머신마다 한 표로 적으면 닫는다. 설정 총량이 호스트 RAM 을 넘는지는 §178 과 §187 이 이미 답했고 넘지 않아서 §57 의 시나리오는 이 환경에 적용되지 않는다. 호스트 메모리가 압박을 받을 때 무엇이 일어나는지는 swap 을 묻는 물음과 호스트 메모리 압박을 묻는 물음이 받는다.
@@ -18,7 +18,7 @@ source:

 # 가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가

-HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이나 애플리케이션이 명시적으로 지정해 쓰는 방식이다. 이 호스트의 두 가상 머신이 그 방식으로 RAM 을 받고 있는지는 libvirt 설정 한 곳만 봐서는 끝나지 않는다. §83 OQ-5 가 설정을 읽은 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적었기 때문이다. 세 자료가 서로 맞는지까지 확인해야 이 환경이 어느 쪽으로 backing 되어 있는지가 정해진다.
+HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이나 애플리케이션이 명시적으로 지정해 쓰는 방식이다. 이 호스트의 게스트 세 대가 그 방식으로 RAM 을 받고 있는지는 아직 읽지 않았다. §83 OQ-5 가 libvirt 설정을 읽은 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적어서 설정 한 곳만 봐서는 끝나지 않는다.

 ## 관계

@@ -45,13 +45,15 @@ HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이
 - §83 OQ-5 는 확인 명령으로 virsh dumpxml <VM_NAME> 을 들고, libvirt memory backing 관련 설정을 확인한 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적었다.
 - §83 OQ-3 이 QEMU 프로세스 쪽 명령으로 cat /proc/<QEMU_PID>/smaps_rollup 을 들었다.
  smaps 계열에서 huge page 사용량을 어느 항목 이름으로 읽는지는 개념 문서가 적지 않았다.
- 세 자료 가운데 호스트 쪽은 항목 이름이 적혀 있다. §56 이 호스트 확인 명령을 적으면서 AnonHugePages 와 HugePages_Total 은 같은 의미가 아니라고 못 박았고, §83 OQ-4 도 THP policy · AnonHugePages · HugePages_Total · HugePages_Free · Hugepagesize 를 확인 항목으로 들었다. 이름이 없는 것은 QEMU smaps 쪽 하나다.
- 이 호스트의 libvirt 설정을 읽은 기록이 개념 문서에 없다.
+- 세 자료 가운데 호스트 쪽은 항목 이름이 적혀 있다. §56 은 호스트 확인 명령을 적으면서 AnonHugePages 와 HugePages_Total 이 같은 의미가 아니라고 못 박았다. §83 OQ-4 도 THP policy · AnonHugePages · HugePages_Total · HugePages_Free · Hugepagesize 를 확인 항목으로 들었다. 이름이 없는 것은 QEMU smaps 쪽 하나다.
+- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대이고 배정한 메모리는 차례로 1024MB · 5120MB · 4096MB 다.
+- §197 이 이 실험대의 libvirt 12.7.0 과 QEMU 11.1.1, 커널 7.2.2-arch1-1 을 적었다.
+- 이 호스트의 libvirt 설정을 읽은 기록이 개념 문서에 없다. 호스트 /proc/meminfo 의 huge page 값을 찍은 기록도 없다. huge page 와 THP, HugeTLB 는 SSOT 제2부에서만 서술되고, 실험대를 세우고 값을 잰 제5~9부에는 그 이름이 한 번도 나오지 않는다. 그래서 이 물음이 다시 읽을 기존 출력이 없고 세 자료를 새로 찍어야 한다.

 ## 가정

- 두 가상 머신 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
- 설정에 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 을 쓰지 않는 것으로 읽는다. 그 해석이 이 libvirt 버전에서 맞는지는 확인하지 않았다.
+- 게스트 세 대 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
+- 설정에 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 을 쓰지 않는 것으로 읽는다. 그 해석이 §197 이 적은 libvirt 12.7.0 에서 맞는지는 확인하지 않았다.
 - 세 자료를 같은 시각에 찍으면 같은 순간의 상태를 가리킨다고 전제한다.
 - QEMU 프로세스 번호를 가상 머신마다 가려낼 수 있다고 본다.

@@ -74,7 +76,7 @@ HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이

 ### 1. libvirt 설정부터 읽고 backing 항목이 없으면 거기서 끝낸다

-virsh dumpxml 을 두 번 찍는 것으로 시작한다. 두 설정 모두 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 이 아니라는 답이 거의 정해지고, 호스트 HugePages_Total 이 0 인지만 확인하면 닫힌다.
+게스트마다 virsh dumpxml 을 한 번씩 찍는 것으로 시작한다. 세 설정 모두 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 이 아니라는 답이 거의 정해지고, 호스트 HugePages_Total 이 0 인지만 확인하면 닫힌다.

 설정에 항목이 있으면 결국 세 자료를 다 받아야 하므로 호스트와 QEMU 쪽을 다시 찍으러 간다.

@@ -82,7 +84,7 @@ virsh dumpxml 을 두 번 찍는 것으로 시작한다. 두 설정 모두 memor

 설정과 호스트 /proc/meminfo, QEMU smaps_rollup 을 같은 시각에 받아 나란히 둔다. OQ-5 가 요구한 교차 검증이 한 번의 실행으로 끝나고, 설정과 실제 값이 어긋나는 경우에도 그 어긋남이 같은 시각의 자료로 남는다.

-QEMU 프로세스 번호를 먼저 가려내야 하고, 두 가상 머신이 같은 시각에 켜져 있어야 한다.
+QEMU 프로세스 번호를 먼저 가려내야 하고, 게스트 세 대가 같은 시각에 켜져 있어야 한다.

 ### 3. 호스트 HugePages_Total 하나로 가른다 — 제외