Files
document-haness/docs/virtualization/tech-log-studio/storage-virtualization/question/question-host-block-device-under-the-disk-image.md
T
DongHyeonkaandClaude Opus 5 2109f726fe 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

9.2 KiB

id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source
id kind slug title topic topicName project status questionStatus studio sourceRevision source
eead2379-94fe-463a-9e5e-06a01bf2105d QUESTION host-block-device-under-the-disk-image disk image 는 최종적으로 어느 Host block device 위에 있는가 storage-virtualization 스토리지 가상화 virtualization 초안 OPEN https://hyeonworks.com/studio/documents/eead2379-94fe-463a-9e5e-06a01bf2105d/edit no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
final/document.md#175-실제-테스트-서버에서-확인할-open-questions-oq-5
final/document.md#158-host-block-layer
final/document.md#159-여러-vm이-하나의-nvme를-공유하면
final/document.md#141-qemu가-물리-ssd를-직접-제어하는-것은-아니다
final/document.md#163-실제-i-o-scheduler-확인

disk image 는 최종적으로 어느 Host block device 위에 있는가

이 호스트의 루트가 /dev/nvme0n1p3 이고 이미지가 /var/lib/libvirt/images/ 에 모여 있다는 것까지는 §197 과 §199 가 적었다. 남은 것은 그 디렉터리가 그 파티션 위에 있다는 것을 findmntlsblk 출력으로 잇는 일이다. 두 가상 머신의 이미지가 같은 장치를 쓰는지가 거기서 갈리고, 그 출력에 나온 장치 이름이 스케줄러를 묻는 물음의 입력이 된다.

관계

  • VM 아래에 한 번 더 있는 Host block stack — blk-mq · I/O Scheduler · NVMe 이미지 파일 아래에서 무엇이 그 입출력을 받는지를 그 개념이 설명한다.
  • /dev/vda 뒤에 있는 것 — qcow2 · RAW · Host block device 백엔드가 파일인지 장치인지에 따라 여기서 따라 내려갈 경로의 시작이 달라진다.
  • 이 호스트의 /dev/vda 는 어떤 backend 에 붙어 있는가 그 물음이 확정한 Source 경로가 이 확인의 입력이다.
  • 이 호스트의 I/O Scheduler 는 무엇인가 여기서 확정한 장치 이름을 넣어야 그 물음의 명령이 완성된다.
  • VM1 의 storage 부하가 VM2 의 지연을 실제로 밀어 올리는가 두 가상 머신이 같은 장치를 쓰는지가 그 실험의 전제다.
  • Guest 안에서 본 disk 로 backend 를 단정하지 않는다 게스트 쪽 이름에서 물리 장치를 추정하지 않고 호스트에서 따라 내려가는 순서를 그 기준이 요구한다.

사실

  • §141 은 백엔드가 qcow2 파일이면 QEMU 가 결국 호스트 리눅스에 파일 입출력을 요청한다고 적었다. 그 요청은 Host Kernel, Host Filesystem, Host Block Layer, NVMe Driver 를 지나 Physical NVMe 로 내려간다. 게스트의 스토리지 스택 아래에 호스트의 스토리지 스택이 한 번 더 존재할 수 있다.
  • §158 은 qcow2 와 RAW 의 파일 입출력이 호스트 파일시스템을 거쳐 실제 호스트 블록 입출력이 된다고 적고 경로를 이렇게 그렸다. QEMU, vm1.qcow2, Host ext4/XFS, Host Block Layer, /dev/nvme0n1
  • §158 은 Host Block Layer 가 그 입출력을 가상 머신 안의 PostgreSQL 이 냈는지 호스트 프로세스가 냈는지 본질적으로 구분해서 처리하는 계층이 아니라고 밝혔다. 모두 호스트의 블록 요청이다.
  • §159 는 VM1 의 QEMU 와 VM2 의 QEMU 와 Nginx 와 호스트의 다른 프로세스가 같은 Host Block Layer 를 지나 하나의 NVMe 로 간다고 그렸다.
  • §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 풀이 루트 파일시스템 위에 있고 게스트 두 대의 오버레이가 같은 디렉터리에 있다.
  • findmntlsblk 출력은 SSOT 에 없다. 이미지 경로가 어느 마운트에 속하고 그 마운트의 장치가 어느 파티션과 상위 장치에 걸려 있는지를 명령으로 확인한 기록이 없다.

가정

  • 이미지 경로가 앞 물음에서 이미 확정되어 있다고 보고 그 경로에서 시작한다. 백엔드가 파일이 아니라 호스트 블록 장치면 이 확인은 장치 이름에서 시작한다.
  • 확인하는 동안 마운트 구성과 이미지 위치가 바뀌지 않는다고 전제한다.
  • findmnt 가 보여 주는 source 이름이 물리 장치 이름과 다를 수 있다고 보고, 어느 상위 장치에 속하는지까지 lsblk 로 이어서 읽는다.
  • 호스트에 붙어 두 명령을 같은 시각에 돌릴 수 있다고 본다.

미지수

  • /var/lib/libvirt/images// 마운트에 속한다는 것을 findmnt 출력으로 확인한 기록. §199 는 풀을 설명하며 그렇게 적었을 뿐 명령 출력을 남기지 않았다.
  • nvme0n1p3 위에 파티션이 어떻게 놓여 있고 그것이 어느 상위 장치에 속하는지. lsblk 출력이 없다.
  • 이미지를 담은 파일시스템이 무엇인지. §158 은 ext4 와 XFS 를 예로 들었을 뿐 이 호스트의 값을 적지 않았다.
  • 엣지 게스트의 이미지도 같은 장치에 있는지. §199 의 목록은 엣지를 만들기 전 시점이라 그 파일이 없다.
  • base.qcow2 가 오버레이와 같은 장치에 있는지. §231 은 오버레이의 매핑 항목이 0 인 클러스터를 읽으면 바닥 파일의 같은 위치를 읽는다고 적었고 §215 는 게스트 둘이 그 바닥 하나를 공유한다고 그렸다. 그래서 따라 내려갈 경로가 오버레이 하나로 끝나지 않는다.

제약

  • 확인만 한다. 마운트를 바꾸거나 이미지를 다른 장치로 옮기지 않는다. 배치를 바꾸면 지금 구성에서 무엇을 공유하는지 못 본다.
  • §158 이 예로 든 이름을 이 호스트의 값으로 옮겨 적지 않는다. 출력에 나온 이름만 적는다.
  • 여기서 나온 장치 이름이 다음 두 물음의 입력이므로, 가상 머신마다 한 행으로 남기고 어느 이미지에서 나온 이름인지 함께 적는다.
  • 장치를 나눌지 말지는 이 물음이 정하지 않는다. 공유하고 있다는 사실과 그것이 지연을 실제로 밀어 올리는지는 다른 물음이 받는다.
  • 백엔드를 묻는 앞 물음과 이어서 돌리게 되지만 한 물음으로 합치지 않았다. 그쪽은 게스트의 장치가 어느 Source 에 붙어 있는지까지 확정하고 이 물음은 그 경로가 놓인 물리 장치까지 내려간다. 닫는 명령이 다르고 그 출력이 여는 다음 물음도 다르다.

선택지

1. 이미지 경로마다 findmnt 로 마운트를 읽고 lsblk 로 그 아래를 잇는다

경로 하나에서 시작해 마운트, source device, 파티션, 상위 장치까지 한 줄기로 내려간다. §175 OQ-5 가 든 두 명령 그대로이고, 이미지가 여럿이면 경로마다 같은 순서를 되풀이한다.

가상 머신이 늘어난 만큼 실행 횟수도 늘어난다.

2. 호스트 전체의 lsblk 를 먼저 한 장 받고 그 위에 이미지 경로를 얹는다

장치와 파티션의 전체 모양을 먼저 확보한 뒤 findmnt 로 각 이미지가 그 가운데 어디에 붙는지 표시해서, 두 가상 머신이 같은 장치를 쓰는지가 한 장에서 바로 보이게 한다.

이미지 경로와 마운트의 대응은 결국 findmnt 로 한 번 더 확인해야 한다.

3. 제외 — 가상 머신 한 대만 확인하고 나머지는 뒤로 미룬다

한 대만 따라 내려가도 경로의 모양은 확인된다. 그러나 이 물음이 답해야 하는 것에는 가상 머신들이 같은 장치를 공유하는지가 들어 있는데, 그것은 한 대의 출력만으로는 갈리지 않는다.

다음 검증

  1. 백엔드를 묻는 앞 물음이 확정한 Source 경로를 그대로 가져온다.
  2. 경로마다 findmnt 로 그 경로가 속한 마운트와 source device 를 적는다 (§175 OQ-5).
  3. 같은 경로에 lsblk 를 돌려 그 장치에 파티션이 어떻게 나뉘어 있고 어느 상위 장치에 속하는지 적는다.
  4. 이미지 경로, 마운트, 파티션, 장치를 가상 머신마다 한 행으로 남긴다. 게스트 둘이 공유하는 base.qcow2 도 한 행으로 함께 적는다.

닫는 조건 : 이미지마다 최종 블록 장치 이름이 확정되면 닫는다. 가상 머신들이 같은 장치를 공유하면 §159 가 그린 상황이 이 환경이라고 적고, 그것이 지연으로 이어지는지는 VM1 부하와 VM2 지연을 재는 물음이 받는다. 서로 다른 장치면 그 사실을 적고 그 물음의 전제가 이 환경에 없다고 함께 적는다. 어느 쪽이든 여기서 확정한 장치 이름을 I/O Scheduler 를 묻는 물음으로 넘긴다.