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/storage-virtualization/question/question-disk-image-format-and-actual-host-usage.md

@@ -20,7 +20,7 @@ source:
 
 # 이 disk image 는 qcow2 인가 RAW 인가, 그리고 Guest 가 보는 크기와 Host 가 실제로 쓰는 크기는 얼마나 다른가
 
-게스트가 100 GB 짜리 디스크를 보고 있어도 호스트에서 그 파일이 차지하는 공간은 훨씬 작을 수 있다. 개념 문서는 그 차이를 예시 숫자로만 들어 두고, 세 명령이 각각 다른 의미의 크기를 보여 준다고 적었다. 이 물음은 이 호스트의 이미지마다 형식과 세 크기를 한 표로 적는 데서 끝난다. 형식과 세 값이 채워지면 저장 공간 계획의 근거가 생기고, 그 뒤의 성능 판단은 여기서 하지 않는다.
+§199 가 2026-09-10 에 이 호스트에서 읽어 둔 값이 있다. 바닥 이미지 `base.qcow2` 의 형식은 qcow2 이고, 20GB 로 선언한 게스트 오버레이 둘의 실제 파일은 1.4 GiB 와 665 MiB 였다. 오버레이마다 세 명령을 돌려 형식과 세 크기를 나란히 읽은 값은 아직 없다. 이 물음은 이미지마다 그것을 한 표로 적는 데서 끝나고, 성능 판단은 여기서 하지 않는다.
 
 ## 관계
 
@@ -40,30 +40,40 @@ source:
 - 게스트가 데이터를 기록하면서 실제 사용량이 늘 수 있다. 개념 문서는 Virtual 100GB 를 유지한 채 Actual 이 1GB 에서 10GB 로, 다시 40GB 로 가는 예를 보였다.
 - 개념 문서는 확인 명령으로 qemu-img info vm1.qcow2 를 들고 virtual size 와 실제 allocation 을 구분해서 봐야 한다고 적었다.
 - RAW 는 qcow2 보다 구조가 단순하다. qcow2 는 Copy-on-Write 와 sparse allocation 과 스냅숏 등에 유리하지만 매핑과 메타데이터 처리가 있고, RAW 는 상대적으로 직접적인 offset 대응으로 간다.
-- 형식만으로 성능을 가르지 말라고 개념 문서가 못박았다. RAW 는 무조건 빠르고 qcow2 는 무조건 느리다는 일반화를 막고, 실제 성능이 캐시 모드와 스토리지 백엔드와 부하 패턴과 큐 깊이와 스냅숏 체인과 그 아래 파일시스템과 물리 장치에 영향을 받는다고 들었다.
+- 형식만으로 성능을 가르지 말라고 개념 문서가 못박았다. RAW 는 무조건 빠르고 qcow2 는 무조건 느리다는 일반화를 막고, 실제 성능은 캐시 모드, 스토리지 백엔드, 부하 패턴, 큐 깊이, 스냅숏 체인, 그 아래 파일시스템, 물리 장치에 영향을 받는다고 적었다.
 - 개념 문서가 이 확인에 적어 둔 명령은 셋이다. 세 명령이 보여주는 의미가 서로 다를 수 있으므로 비교하라고 했다.
   형식과 크기 : qemu-img info
   실제 점유량 : du -h
   파일 크기 : ls -lh
-- 이 호스트의 이미지 형식도 크기도 적힌 기록이 없다.
+- 백엔드가 파일이라는 것은 §187 의 `virt-install` 세 줄과 §199 의 `ls -l` 출력이 보여 준다.
+- 형식과 바닥 이미지의 크기는 §199 가 2026-09-10 에 `test-server` 에서 재 두었다. `qemu-img info /var/lib/libvirt/images/base.qcow2` 가 낸 값은 `file format: qcow2`, `virtual size: 3 GiB (3221225472 bytes)`, `disk size: 335 MiB` 다.
+- 같은 절의 `ls -l /var/lib/libvirt/images/` 가 선언한 크기와 파일 크기를 나란히 보인다.
+  base.qcow2 : 351404032 (335 MiB)
+  kc-lab-1.qcow2 : 1521025024 (1.4 GiB) — 선언 20GB
+  kc-lab-2.qcow2 : 697499648 (665 MiB) — 선언 20GB
+  시드 ISO 두 장 : 각 378880 (370 KiB)
+- §199 는 그 결과를 한 줄로 정리했다. 20GB 씩 둘, 합쳐 40GB 를 선언했지만 실제로는 2.1GB 를 썼다.
+- §199 는 두 오버레이가 두 배 넘게 갈린 이유도 함께 적었다. k3s server 가 agent 보다 두 배 이상 쓰는 것은 컨트롤 플레인 바이너리와 SQLite 때문이다. 그래서 오버레이 크기는 이미지 형식이 아니라 그 게스트가 무엇을 도는지를 따라간다.
+- §231 은 같은 바닥 이미지에 `qemu-img map --output=json` 을 돌려 `compressed: True` 인 구간이 606개이고 전체가 1236개라고 적었다. 3 GiB 가운데 2.01 GiB 가 구멍이고 남은 1010 MiB 를 압축해 324 MiB 가 된다. 배포본 qcow2 는 배포 시점에 이미 zlib 로 압축돼 있어서, 바닥 쪽 차이에는 희소 할당과 압축이 겹쳐 있다. 오버레이에 쌓이는 클러스터는 압축되지 않는다.
 
 ## 가정
 
-- 이미지 경로가 앞선 물음에서 확정된다고 본다. 경로가 없으면 세 명령을 어디에 돌릴지 정해지지 않는다.
-- 백엔드가 파일이라고 전제한다. 호스트 블록 장치로 나오면 이 물음 자체가 이 호스트에 적용되지 않는다.
+- §199 가 목록으로 보인 경로가 지금도 그 가상 머신들이 쓰는 이미지라고 본다. 도메인 정의와 대조한 출력은 없다.
+- 오버레이도 바닥과 같은 qcow2 라고 본다. §187 이 `backing_store` 로 만들었다고 적었지만 오버레이에 `qemu-img info` 를 돌린 출력은 없다. §232 는 그 출력의 `backing file:` 줄이 없으면 바닥 이미지이고 있으면 오버레이라고 적었으므로, 오버레이에 한 번 돌리면 형식과 이 가정이 같은 출력에서 함께 갈린다.
 - 세 명령을 같은 시점에 돌린다고 본다. 실제 사용량은 게스트가 기록하면서 늘 수 있어서, 시점이 벌어지면 한 표에 서로 다른 시각의 값이 들어간다.
 
 ## 미지수
 
-- 가상 머신마다 디스크 이미지가 qcow2 인지 RAW 인지.
-- qemu-img info 가 보여 주는 virtual size 와 disk size 가 각각 얼마인지.
-- du -h 의 실제 점유량과 ls -lh 의 파일 크기가 그 값들과 얼마나 벌어져 있는지.
+- 오버레이 `kc-lab-1.qcow2` 와 `kc-lab-2.qcow2` 의 `qemu-img info` 값. 형식과 virtual size, disk size 를 이미지마다 읽은 기록이 없고, §199 가 읽은 것은 바닥 `base.qcow2` 하나다.
+- `du -h` 의 실제 점유량이 §199 의 `ls -l` 바이트 수와 얼마나 벌어지는지. 두 명령은 서로 다른 것을 센다.
+- 엣지 게스트의 이미지. §199 는 엣지를 만들기 전 시점이라 목록에 `kc-lab-edge.qcow2` 가 없다.
+- 지금 시점의 값. §199 는 2026-09-10 값이고 그 뒤로 오버레이가 얼마나 자랐는지는 재지 않았다. 증가를 볼 수 있는 구간은 그 앞 한 주뿐이다 — §215 가 2026-09-03 에 그린 배치에서 `kc-lab-1.qcow2` 는 264M 이고 일주일 뒤 §199 의 같은 파일이 1.4 GiB 다. 두 값은 어긋난 것이 아니라 다른 날의 것이라고 §211 이 스냅샷 날짜로 못박았다.
 
 ## 제약
 
 - 성능 결론을 여기서 내지 않는다. 형식만으로 일반화하지 말라고 개념 문서가 적었고, 성능은 부하와 지연을 재는 다른 물음들이 받는다.
 - 한 시점의 세 값만 적는다. 그 차이가 시간에 따라 어떻게 자라는지는 별도 측정으로 넘긴다.
-- 앞선 물음이 Source 를 확정하기 전에는 이 확인을 시작할 수 없다.
+- qcow2 파일 안이 어떻게 생겼는지는 여기서 다루지 않는다. 매핑표와 클러스터와 refcount 는 §231 이 맡고, 이 물음은 명령이 내놓는 값만 받는다.
 - 개념 문서는 형식을 묻는 물음과 세 크기를 묻는 물음을 따로 적었는데 여기서는 하나로 받았다. 형식은 qemu-img info 출력의 첫 줄이고 세 값을 견주는 일의 전제라 같은 출력으로 함께 닫힌다. 같은 측정으로 닫히는 물음을 두 편으로 두지 않는다.
 
 ## 선택지

docs/virtualization/tech-log-studio/storage-virtualization/question/question-guest-fsync-latency-vs-host-storage-latency.md

@@ -21,7 +21,7 @@ source:
 
 # Guest 의 fsync() 지연과 Host storage 지연은 같이 오르는가
 
-게스트 안의 fsync() 는 게스트 파일시스템과 블록 계층과 virtio-blk 와 QEMU 를 지나 호스트 스토리지까지 의미가 전달되어야 하는 요청이다. 그 전달이 이 호스트에서 실제로 이어지는지는 두 계열을 같은 시간축에 놓고 봐야 갈린다. 이 물음은 게스트 쪽 애플리케이션 지연과 호스트 쪽 스토리지 지연을 같은 타임스탬프로 남겨, 둘이 함께 움직이는지를 확인한다.
+게스트 안의 fsync() 는 게스트 파일시스템, 블록 계층, virtio-blk, QEMU 를 지나 호스트 스토리지까지 의미가 전달되어야 하는 요청이다. 그 전달이 이 호스트에서 실제로 이어지는지는 두 계열을 같은 시간축에 놓고 봐야 갈린다. 이 물음은 게스트 쪽 애플리케이션 지연과 호스트 쪽 스토리지 지연을 같은 타임스탬프로 남겨, 둘이 함께 움직이는지를 확인한다.
 
 ## 관계
 
@@ -45,7 +45,7 @@ source:
 - §150 은 write(fd, data, size) 의 성공만으로는 정전 이후 생존을 보장하지 않고, 필요한 시점에 fsync(fd) 로 변경 내용을 필요한 영속성 경계까지 반영하도록 요청한다고 적었다.
 - §150 은 가상 머신에서 그 요청이 지나야 하는 경로를 이렇게 그렸다.
   PostgreSQL, fsync(), Guest Filesystem, Guest Block Layer, FLUSH 등, virtio-blk, QEMU/Backend, Host Storage Stack, Physical Storage
-- §148 은 write() 완료와 writeback 완료와 fsync/flush 완료와 전원 장애에도 안전한 durability 가 서로 같지 않다고 못박았다.
+- §148 은 write() 완료, writeback 완료, fsync/flush 완료, 전원 장애에도 안전한 durability 가 서로 같지 않다고 못박았다.
 - §170 은 PostgreSQL 이 WAL 등의 durability protocol 을 사용하며 필요한 시점에 스토리지 동기화를 수행한다고 적었다. 가상 머신의 스토리지 계층이 flush 와 fsync 의 의미를 제대로 보존하지 않으면 PostgreSQL 이 전제한 영속성과 실제 스토리지 동작이 어긋날 수 있다.
 - §171 은 모든 쓰기에서 스토리지 동기화를 기다리면 지연이 커질 수 있고, 특히 DB 부하에서는 fsync() 지연이 트랜잭션 지연과 연결될 수 있다고 적었다.
 - §171 은 더 적극적인 캐싱으로 쓰기 지연을 개선할 수 있지만 durability semantics 는 반드시 보존해야 한다고 덧붙였다. fsync() 를 없애서 빨라졌다면 그것이 최적화가 아니라 durability contract 를 제거한 것일 수 있다.
@@ -67,7 +67,7 @@ source:
 - 겹친다면 두 값이 같은 크기로 움직이는지, 게스트 쪽이 더 크게 벌어지는지.
 - 게스트 지연은 오르는데 호스트 스토리지 지연이 따라 오르지 않는 구간이 있는지. 있다면 그 차이가 게스트 쪽 대기에서 생기는지 QEMU 와 백엔드 쪽에서 생기는지.
 - 이때 걸려 있던 캐시 모드가 무엇인지. 그 값은 별도 물음이 읽는다.
-- 게스트 쪽 지연을 어떤 단위로 기록할지. 개념 문서는 게스트에서 지연을 재는 명령을 적지 않았고 호스트 쪽 iostat 만 적었다.
+- 게스트 쪽 지연을 무엇으로 어떤 단위로 기록할지. §169 가 게스트 쪽에 적은 명령은 장치 입출력과 마운트를 보는 것이라, 애플리케이션이나 트랜잭션 지연은 거기서 나오지 않는다.
 
 ## 제약
 
@@ -76,7 +76,7 @@ source:
 - 측정 조건에 캐시 모드와 백엔드 형식과 장치 이름을 함께 적는다. 이 셋이 없으면 같은 값을 다른 환경과 견줄 수 없다.
 - 측정하는 동안 다른 스토리지 실험을 같은 장치 위에서 겹쳐 돌리지 않는다.
 - 호스트 지연이 오른 이유까지 이 물음이 가르지 않는다. 다른 가상 머신의 부하인지 호스트 메모리 압박인지는 그것을 재는 두 물음이 받는다.
-- 그 가운데 메모리 압박 쪽 물음과는 호스트 스토리지 지표를 같이 본다. 그래도 한 물음으로 합치지 않았다. 그쪽은 호스트에서 major fault 를 유도해 그것이 스토리지를 미는지를 보고 이쪽은 게스트의 fsync() 가 호스트까지 전달되는지를 봐서, 유도 방법도 견주는 계열도 달라 한 실행으로 닫히지 않는다.
+- 그 가운데 메모리 압박 쪽 물음과는 호스트 스토리지 지표를 같이 본다. 그래도 한 물음으로 합치지 않았다. 그쪽은 호스트에서 major fault 를 유도해 그것이 스토리지를 미는지를 보고, 이쪽은 게스트의 fsync() 가 호스트까지 전달되는지를 본다. 유도 방법도 견주는 계열도 달라서 한 실행으로 닫히지 않는다.
 
 ## 선택지
 

docs/virtualization/tech-log-studio/storage-virtualization/question/question-host-block-device-under-the-disk-image.md

@@ -20,7 +20,7 @@ source:
 
 # disk image 는 최종적으로 어느 Host block device 위에 있는가
 
-게스트의 디스크가 호스트에서는 파일 하나라는 것까지는 백엔드를 묻는 앞 물음이 확정한다. 그 파일은 다시 호스트 파일시스템 위에 있고 그 파일시스템은 어느 파티션과 물리 장치 위에 있어서, 이미지 경로에서 시작해 그 아래를 마운트와 파티션과 장치 이름까지 따라 내려가야 한다. 두 가상 머신의 이미지가 같은 장치를 쓰는지도 여기서 갈린다.
+이 호스트의 루트가 `/dev/nvme0n1p3` 이고 이미지가 `/var/lib/libvirt/images/` 에 모여 있다는 것까지는 §197 과 §199 가 적었다. 남은 것은 그 디렉터리가 그 파티션 위에 있다는 것을 `findmnt` 와 `lsblk` 출력으로 잇는 일이다. 두 가상 머신의 이미지가 같은 장치를 쓰는지가 거기서 갈리고, 그 출력에 나온 장치 이름이 스케줄러를 묻는 물음의 입력이 된다.
 
 ## 관계
 
@@ -48,22 +48,25 @@ source:
 - §175 OQ-5 는 확인 명령으로 lsblk 와 findmnt 를 들었다.
 - §169 의 호스트 관측 명령 목록에도 lsblk 가 들어 있다.
 - §158 의 vm1.qcow2 와 /dev/nvme0n1 은 경로를 설명하려고 든 예시 이름이고 이 호스트에서 읽은 값이 아니다.
-- 이 호스트의 마운트 배치와 물리 장치 이름은 개념 문서에 없다.
+- §197 은 2026-09-10 에 `df -h /` 를 돌려 `/dev/nvme0n1p3  226G  9.9G  204G   5% /` 를 받았다. 이 호스트의 루트 파일시스템이 그 파티션 위에 있다.
+- §199 의 `ls -l` 은 이미지가 `/var/lib/libvirt/images/` 아래에 모여 있는 것을 보였고, 같은 절의 `virsh pool-info default` 는 Capacity 225.31 GiB, Allocation 7.84 GiB, Available 217.46 GiB 를 냈다. §199 는 그 Allocation 이 풀 전체, 곧 호스트 루트 파일시스템의 사용량이라고 적었다.
+- 그래서 `default` 풀이 루트 파일시스템 위에 있고 게스트 두 대의 오버레이가 같은 디렉터리에 있다.
+- `findmnt` 와 `lsblk` 출력은 SSOT 에 없다. 이미지 경로가 어느 마운트에 속하고 그 마운트의 장치가 어느 파티션과 상위 장치에 걸려 있는지를 명령으로 확인한 기록이 없다.
 
 ## 가정
 
 - 이미지 경로가 앞 물음에서 이미 확정되어 있다고 보고 그 경로에서 시작한다. 백엔드가 파일이 아니라 호스트 블록 장치면 이 확인은 장치 이름에서 시작한다.
 - 확인하는 동안 마운트 구성과 이미지 위치가 바뀌지 않는다고 전제한다.
-- findmnt 가 보여 주는 source 이름이 물리 장치 이름과 다를 수 있다고 보고 lsblk 로 상하 관계까지 이어서 읽는다.
+- findmnt 가 보여 주는 source 이름이 물리 장치 이름과 다를 수 있다고 보고, 어느 상위 장치에 속하는지까지 lsblk 로 이어서 읽는다.
 - 호스트에 붙어 두 명령을 같은 시각에 돌릴 수 있다고 본다.
 
 ## 미지수
 
-- 이미지가 놓인 디렉터리가 어느 마운트 지점에 속하는지.
-- 그 마운트가 어느 파티션 위에 있고 그 파티션이 어느 블록 장치에 속하는지.
-- 가상 머신들의 이미지가 같은 장치를 공유하는지 서로 다른 장치에 있는지.
+- `/var/lib/libvirt/images/` 가 `/` 마운트에 속한다는 것을 `findmnt` 출력으로 확인한 기록. §199 는 풀을 설명하며 그렇게 적었을 뿐 명령 출력을 남기지 않았다.
+- `nvme0n1p3` 위에 파티션이 어떻게 놓여 있고 그것이 어느 상위 장치에 속하는지. `lsblk` 출력이 없다.
 - 이미지를 담은 파일시스템이 무엇인지. §158 은 ext4 와 XFS 를 예로 들었을 뿐 이 호스트의 값을 적지 않았다.
-- 그 장치가 NVMe 인지 다른 종류인지. §163 이 SATA/SCSI device 를 따로 언급했으므로 확인 명령의 장치 이름도 그에 따라 달라진다.
+- 엣지 게스트의 이미지도 같은 장치에 있는지. §199 의 목록은 엣지를 만들기 전 시점이라 그 파일이 없다.
+- `base.qcow2` 가 오버레이와 같은 장치에 있는지. §231 은 오버레이의 매핑 항목이 0 인 클러스터를 읽으면 바닥 파일의 같은 위치를 읽는다고 적었고 §215 는 게스트 둘이 그 바닥 하나를 공유한다고 그렸다. 그래서 따라 내려갈 경로가 오버레이 하나로 끝나지 않는다.
 
 ## 제약
 
@@ -96,6 +99,6 @@ source:
 1. 백엔드를 묻는 앞 물음이 확정한 Source 경로를 그대로 가져온다.
 2. 경로마다 findmnt 로 그 경로가 속한 마운트와 source device 를 적는다 (§175 OQ-5).
 3. 같은 경로에 lsblk 를 돌려 그 장치에 파티션이 어떻게 나뉘어 있고 어느 상위 장치에 속하는지 적는다.
-4. 이미지 경로, 마운트, 파티션, 장치를 가상 머신마다 한 행으로 남긴다.
+4. 이미지 경로, 마운트, 파티션, 장치를 가상 머신마다 한 행으로 남긴다. 게스트 둘이 공유하는 `base.qcow2` 도 한 행으로 함께 적는다.
 
 닫는 조건 : 이미지마다 최종 블록 장치 이름이 확정되면 닫는다. 가상 머신들이 같은 장치를 공유하면 §159 가 그린 상황이 이 환경이라고 적고, 그것이 지연으로 이어지는지는 VM1 부하와 VM2 지연을 재는 물음이 받는다. 서로 다른 장치면 그 사실을 적고 그 물음의 전제가 이 환경에 없다고 함께 적는다. 어느 쪽이든 여기서 확정한 장치 이름을 I/O Scheduler 를 묻는 물음으로 넘긴다.

docs/virtualization/tech-log-studio/storage-virtualization/question/question-host-io-scheduler.md

@@ -55,7 +55,9 @@ bfq
 
 §175 OQ-6 은 같은 파일을 장치 이름을 넣어 읽으라고 했다.
 
-이 호스트의 값은 개념 문서에 없다. §163 의 nvme0n1 과 sda 는 명령의 모양을 보이려고 든 예시 이름이다.
+§197 은 2026-09-10 에 `df -h /` 를 돌려 이 호스트의 루트가 `/dev/nvme0n1p3` 위에 있는 것을 받았고, §199 는 이미지가 `/var/lib/libvirt/images/` 아래에 있다고 적었다. 명령에 넣을 장치 이름의 후보가 거기서 나온다. 다만 §197 이 낸 이름은 파티션이고 §163 이 경로에 넣어 보인 것은 nvme0n1 과 sda 처럼 장치 쪽 이름이다. 둘 가운데 무엇이 들어가는지는 앞 물음의 lsblk 가 상위 장치를 보인 뒤에 갈린다.
+
+이 호스트의 스케줄러 값은 SSOT 에 없다. `/sys/block` 아래의 파일을 읽은 출력이 어디에도 없고, §163 의 nvme0n1 과 sda 는 명령의 모양을 보이려고 든 예시 이름이다.
 
 ## 가정
 

docs/virtualization/tech-log-studio/storage-virtualization/question/question-qemu-disk-cache-mode.md

@@ -40,7 +40,7 @@ source:
 
 §154 는 cache=none 을 개념적으로 Host Page Cache 를 우회하는 방향의 I/O 구성으로 놓았다. 이중 caching 은 줄일 수 있지만, Host Page Cache 우회가 무조건 즉시 durable media 반영을 뜻하지는 않는다.
 
-§155 는 cache=writeback 을 Host Page Cache 를 사용할 수 있는 구성으로 놓았다. 일반 write 는 Host RAM 에서 빠르게 completion 될 수 있고, 나중에 Host RAM 에서 Storage 로 내려간다. 이 설정이어도 Guest 의 fsync()/FLUSH 가 무시되지는 않는다. 정상적인 stack 이라면 durability 요구가 Guest fsync/FLUSH 에서 virtio FLUSH, QEMU/backend, Host sync/flush, Storage 를 지난다. 거기서 필요한 완료 확인을 받아 Guest completion 까지 전달되어야 한다고 적었다.
+§155 는 cache=writeback 을 Host Page Cache 를 사용할 수 있는 구성으로 놓았다. 일반 write 는 Host RAM 에서 빠르게 완료될 수 있고, 나중에 Host RAM 에서 Storage 로 내려간다. 이 설정이어도 Guest 의 fsync()/FLUSH 가 무시되지는 않는다. 정상적인 stack 이라면 durability 요구가 Guest fsync/FLUSH 에서 virtio FLUSH, QEMU/backend, Host sync/flush, Storage 를 지난다. 거기서 필요한 완료 확인을 받아 Guest completion 까지 전달되어야 한다고 적었다.
 
 §156 은 그래서 정확한 표현을 이렇게 적었다. writeback caching 에서는 volatile cache 가 존재할 수 있으므로, Guest 의 flush/fsync semantics 가 전체 backend/storage stack 에서 올바르게 보존되는지가 중요하다.
 
@@ -48,7 +48,11 @@ source:
 
 §175 OQ-4 는 확인 방법으로 virsh dumpxml <VM_NAME> 을 들고, disk driver 설정의 cache 관련 값을 확인하라고 했다.
 
-이 호스트에 어느 값이 걸려 있는지도, 어느 값을 쓰기로 정했다는 기록도 개념 문서에 없다.
+§187 은 게스트를 만든 `virt-install` 세 줄을 그대로 적었는데 거기에 cache 옵션이 없다. 디스크는 `--disk size=20,backing_store=/var/lib/libvirt/images/base.qcow2` 와 `--disk vol=default/seed-kc-lab-1.iso,device=disk,bus=virtio,readonly=on` 둘로만 지정했다.
+
+§178 과 §197 이 이 호스트의 판을 적었다. QEMU 11.1.1 과 libvirt 12.7.0 이고 커널은 `7.2.2-arch1-1` 이다. 값이 적혀 있지 않을 때 무엇이 적용되는지는 그 판들이 정한다.
+
+이 호스트의 disk 요소에 어느 값이 걸려 있는지도, 어느 값을 쓰기로 정했다는 기록도 SSOT 에 없다. `virsh dumpxml` 출력이 없다.
 
 ## 가정
 

docs/virtualization/tech-log-studio/storage-virtualization/question/question-vm-disk-backend-mapping.md

@@ -39,39 +39,53 @@ source:
 
 §135 는 virtio-blk 를 쓰는 가상 머신에서 /dev/vda 나 /dev/vdb 같은 이름이 흔히 보인다고 적었다. Guest Linux 는 그 이름을 하나의 block device 로 인식하지만, 그것이 호스트의 실제 SSD 를 뜻하지는 않는다.
 
-backend 가 반드시 파일일 필요도 없다. §145 는 그 아래에 qcow2 파일과 RAW 파일과 Host block device 셋이 올 수 있다고 갈라 적고, 게스트에 그 이름이 있다는 정보만으로는 backend 구조를 알 수 없다고 못박았다.
+백엔드가 반드시 파일일 필요도 없다. §145 는 그 아래에 qcow2 파일, RAW 파일, Host block device 셋이 올 수 있다고 갈라 적고, 게스트에 그 이름이 있다는 정보만으로는 백엔드 구조를 알 수 없다고 못박았다.
 
-§140 은 가상 머신 경계를 넘으면 QEMU 가 등장한다고 그렸다. QEMU 의 virtio-blk Device Model 과 Block Backend 가 게스트의 virtual I/O 를 호스트 backend 에 연결한다.
+§140 은 가상 머신 경계를 넘으면 QEMU 가 등장한다고 그렸다. QEMU 의 `virtio-blk` 장치 모델과 블록 백엔드가 게스트의 가상 I/O 를 호스트 백엔드에 연결한다.
 
 확인 방법으로는 §146 과 §175 OQ-1 이 같은 둘을 든다. 게스트에서는 lsblk 를 돌리고, 호스트에서는 virsh domblklist <VM_NAME> 을 돌린다.
 
 §146 의 예시 출력은 Target vda 에 Source /var/lib/libvirt/images/vm1.qcow2 가 붙은 한 행이었다. 그 대응이 나오면 게스트의 /dev/vda 에서 virtio-blk 와 QEMU 를 지나 그 파일까지 이어진다. 그 경로는 대응이 어떻게 읽히는지 보이려고 든 예시이지 이 호스트에서 읽은 값이 아니다.
 
-이 호스트의 가상 머신이 어떤 Source 에 붙어 있는지를 적은 기록은 개념 문서에 없다.
+이 호스트의 가상 머신은 libvirt 로 정의되어 있다. §187 이 게스트를 만든 `virt-install` 세 줄을 그대로 적었고 §199 가 `virsh pool-info default` 출력을 남겼다.
+
+그 `virt-install` 세 줄은 게스트마다 디스크를 둘씩 붙인다. 하나는 `--disk size=20,backing_store=/var/lib/libvirt/images/base.qcow2` 로 만든 오버레이이고, 다른 하나는 `--disk vol=default/seed-kc-lab-1.iso,device=disk,bus=virtio,readonly=on` 으로 붙인 시드 볼륨이다. 엣지만 `--disk size=10` 이다.
+
+§215 는 그 결과를 게스트 쪽 이름으로 그렸다. `vda` 는 20G 이고 ext4 로 마운트돼 거기서 부팅한다. `vdb` 는 370K 이고 레이블이 CIDATA 인 iso9660 이라 마운트되지 않는다. `vda` 뒤에 `kc-lab-1.qcow2` 가 있고 그 아래 backing 으로 `base.qcow2` 가 있어서, 게스트 두 대가 그 바닥 하나를 공유한다.
+
+§199 는 2026-09-10 에 `ls -l /var/lib/libvirt/images/` 를 돌린 출력을 남겼고 거기에 `base.qcow2`, `kc-lab-1.qcow2`, `kc-lab-2.qcow2`, 시드 ISO 둘이 파일로 보이므로 이 호스트의 백엔드는 §145 가 가른 셋 가운데 파일 쪽이다.
+
+§234 는 그 파일들이 게스트에 어떻게 붙는지를 한 줄로 적었다. 이 실험대의 게스트는 `vda`(qcow2 오버레이)와 `vdb`(raw 시드 ISO) 두 디스크다. 그래서 한 게스트 안에서도 Target 둘의 형식이 갈리고, 한 행만 읽고 백엔드를 정하면 나머지 한 행이 빠진다.
+
+시드에 `bus=virtio` 가 붙은 이유는 §237 이 확정된 함정으로 적어 두었다. `virt-install --cloud-init` 은 시드 ISO 를 SATA CD-ROM 으로 붙이는데 Debian `genericcloud` 변종에는 물리 하드웨어 드라이버가 빠져 있어 게스트가 그 장치를 보지 못하고, 오류 메시지는 어디에도 남지 않은 채 hostname 이 `localhost` 로 남는 것으로만 드러난다. 그래서 §237 은 이 확인의 성공 판정을 시드 ISO 가 `sda` 가 아니라 `vdb` 로 보이는 것이라고 적었다. Target 이름 자체가 판정 대상이다.
+
+`virsh domblklist` 출력은 SSOT 에 없다. Target 과 Source 를 한 행으로 이어 보인 출력이 없고, §215 의 배치는 게스트가 두 대이던 2026-09-03 스냅샷이라 지금 도메인 정의와 대조되지 않았다.
 
 ## 가정
 
 호스트와 각 게스트에 붙어 명령을 돌릴 수 있다고 본다.
 
-이 환경의 가상 머신이 libvirt 로 정의되어 있어서 virsh 가 그 가상 머신을 안다고 전제한다. §146 과 §175 OQ-1 이 확인 방법으로 virsh 명령을 든 것이 근거이고, 이 호스트에서 확인하지는 않았다.
-
 확인하는 동안 디스크 구성이 바뀌지 않는다고 본다.
 
+§215 가 그린 배치가 지금도 그대로라고 보고 대조할 대상으로 삼는다. §211 은 그 그림이 2026-09-03 값이고 그 뒤에 엣지 게스트가 늘었다고 적었다.
+
 ## 미지수
 
-이 호스트의 각 가상 머신에 디스크가 몇 개 붙어 있는지.
+지금 돌고 있는 도메인에 붙은 디스크가 §187 이 만들 때 준 둘과 같은지.
 
-각 Target 의 Source 가 무엇인지.
+각 Target 의 Source 경로가 `virsh domblklist` 출력에 무엇으로 나오는지.
 
-그 Source 가 파일인지 Host block device 인지.
+게스트 안에서 `lsblk` 로 본 장치와 파티션이 §215 가 그린 `vda` 와 `vdb` 에 그대로 대응하는지.
+
+엣지를 더한 뒤의 배치. §215 는 게스트 두 대였을 때의 그림이고 §178 은 지금 게스트가 셋이라고 적었다.
 
 ## 제약
 
-이 물음은 backend 가 무엇인지까지 답한다. 형식과 크기는 다음 물음이 받고, 성능은 여기서 판정하지 않는다.
+이 물음은 백엔드가 무엇인지까지 답한다. 형식과 크기는 다음 물음이 받고, 성능은 여기서 판정하지 않는다.
 
 게스트 안에서 본 이름은 답이 되지 않는다. §145 가 그 추론을 명시적으로 막았기 때문이다.
 
-이 호스트에서 얻은 출력이 없으므로 다른 장비의 디스크 구성을 근거로 삼지 않는다.
+다른 장비의 디스크 구성을 근거로 삼지 않는다. 이 호스트에서 얻은 출력은 §199 의 `ls -l` 과 `virsh pool-info default` 뿐이고, Target 과 Source 의 대응은 그 안에 없다.
 
 ## 선택지
 
@@ -83,13 +97,13 @@ backend 가 반드시 파일일 필요도 없다. §145 는 그 아래에 qcow2
 
 ### 2. 호스트 쪽 출력만 먼저 받는다
 
-virsh domblklist 는 호스트에서만 돌아가고 Target 과 Source 를 한 번에 주기 때문에, 가상 머신에 로그인하지 않아도 backend 경로가 확정된다. 이어지는 두 물음이 요구하는 이미지 경로도 바로 얻는다.
+virsh domblklist 는 호스트에서만 돌아가고 Target 과 Source 를 한 번에 주기 때문에, 가상 머신에 로그인하지 않아도 백엔드 경로가 확정된다. 이어지는 두 물음이 요구하는 이미지 경로도 바로 얻는다.
 
 대신 게스트가 그 디스크를 어떤 이름과 파티션으로 보고 있는지가 빠진다. 나중에 게스트 안에서 잰 스토리지 수치를 이 표에 붙이려면 그때 대응을 다시 확인해야 한다.
 
 ### 3. libvirt 정의 전문을 받아 disk 요소를 읽는다 — 제외
 
-virsh dumpxml 은 disk 요소에 source 와 driver 를 함께 담고 있어서 backend 경로와 cache 설정을 한 번에 볼 수 있다.
+virsh dumpxml 은 disk 요소에 source 와 driver 를 함께 담고 있어서 백엔드 경로와 cache 설정을 한 번에 볼 수 있다.
 
 §175 는 dumpxml 을 cache mode 를 확인하는 항목에 두었고, 연결 확인에는 §146 과 같은 domblklist 를 들었다. 여기서 dumpxml 을 쓰면 한 출력으로 두 물음이 닫히게 되어 어느 확인이 무엇을 근거로 끝났는지가 흐려진다. cache 값은 그 물음이 받는다.
 

docs/virtualization/tech-log-studio/storage-virtualization/question/question-vm1-storage-load-vs-vm2-latency.md

@@ -51,11 +51,13 @@ Storage Contention : IOPS / bandwidth / queue / device 처리시간 경쟁
 
 §175 OQ-7 이 적은 실험은 한 문장이다. VM1 에서 별도의 테스트 파일이나 디스크로 controlled I/O load 를 발생시키고 VM2 의 애플리케이션 지연과 Host storage 지표를 동시에 본다. 부하를 무엇으로 만들지, 얼마나 크게 얼마나 오래 걸지는 그 한 문장에 없어서 재는 쪽이 정한다.
 
-이 호스트에서 그렇게 재 본 결과는 개념 문서에 없다. §168 의 30% 와 2초 도 CPU 와 지연이 어긋날 수 있다는 것을 보이려고 든 예시 값이다.
+이 호스트의 배치는 §197 과 §199 가 적었다. 루트가 `/dev/nvme0n1p3` 위에 있고 게스트 이미지가 전부 `/var/lib/libvirt/images/` 아래에 있다. `virsh pool-info default` 가 낸 Capacity 225.31 GiB 는 §199 가 호스트 루트 파일시스템이라고 적은 그 풀의 값이다. 그 디렉터리가 그 파티션 위에 있다는 것을 `findmnt` 로 확인한 출력은 없다.
+
+이 호스트에서 부하를 걸고 두 값을 나란히 재 본 결과는 SSOT 에 없다. §168 의 30% 와 2초도 CPU 와 지연이 어긋날 수 있다는 것을 보이려고 든 예시 값이다.
 
 ## 가정
 
-두 가상 머신의 이미지가 같은 block device 위에 있다고 보고 실험을 짠다. 앞 물음이 서로 다른 장치라고 확정하면 이 전제가 없어진다.
+두 가상 머신의 이미지가 같은 block device 위에 있다고 보고 실험을 짠다. 같은 디렉터리에 있다는 것까지는 §199 가 보였고, 그 디렉터리 아래를 장치까지 이은 출력은 앞 물음이 낸다.
 
 VM1 에 controlled I/O load 를 걸었다가 걷을 수 있고, 걷은 뒤 상태가 부하 이전의 기준 구간으로 돌아온다고 본다. 돌아오는지는 세 번째 구간에서 확인한다.