DongHyeonkaandClaude Opus 5
2109f726fe
기록 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>
9.5 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 | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1f76d54b-bb17-4174-8128-0c2d71d4256f | QUESTION | vm-disk-backend-mapping | 이 호스트의 /dev/vda 는 어떤 backend 에 붙어 있는가 | storage-virtualization | 스토리지 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/1f76d54b-bb17-4174-8128-0c2d71d4256f/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
이 호스트의 /dev/vda 는 어떤 backend 에 붙어 있는가
게스트 안에서 보이는 디스크 이름 하나는 서로 다른 세 가지 호스트 구성 위에서 똑같이 나온다. qcow2 파일일 수도 있고, RAW 파일일 수도 있고, Host block device 를 그대로 붙인 것일 수도 있다. 그래서 이 물음은 성능이나 용량을 재기 전에 이 호스트의 가상 머신이 그중 어느 구성인지부터 출력으로 확정한다. 여기서 갈린 결과가 이 주제의 다음 물음 둘이 이 환경에 적용되는지를 정한다.
관계
- /dev/vda 뒤에 있는 것 — qcow2 · RAW · Host block device 이 물음이 가르려는 세 갈래를 그 글이 설명한다.
- Guest 의 write() 가 virtqueue 에 실리기까지 — VFS · Filesystem · Page Cache · Block Layer · virtio-blk 게스트가 보는 그 이름이 어디에서 나왔는지를 그 글이 설명한다.
- Guest 안에서 본 disk 로 backend 를 단정하지 않는다 이 확인을 반복 적용할 기준으로 편 글이고, 이 물음이 그 기준의 첫 항목을 이 호스트에서 채운다.
- 이 disk image 는 qcow2 인가 RAW 인가, 그리고 Guest 가 보는 크기와 Host 가 실제로 쓰는 크기는 얼마나 다른가 Source 가 파일로 나왔을 때 이어지는 물음이다.
- disk image 는 최종적으로 어느 Host block device 위에 있는가 같은 조건에서 그 파일 아래를 잇는 물음이다.
사실
§135 는 virtio-blk 를 쓰는 가상 머신에서 /dev/vda 나 /dev/vdb 같은 이름이 흔히 보인다고 적었다. Guest Linux 는 그 이름을 하나의 block device 로 인식하지만, 그것이 호스트의 실제 SSD 를 뜻하지는 않는다.
백엔드가 반드시 파일일 필요도 없다. §145 는 그 아래에 qcow2 파일, RAW 파일, Host block device 셋이 올 수 있다고 갈라 적고, 게스트에 그 이름이 있다는 정보만으로는 백엔드 구조를 알 수 없다고 못박았다.
§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 를 지나 그 파일까지 이어진다. 그 경로는 대응이 어떻게 읽히는지 보이려고 든 예시이지 이 호스트에서 읽은 값이 아니다.
이 호스트의 가상 머신은 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 스냅샷이라 지금 도메인 정의와 대조되지 않았다.
가정
호스트와 각 게스트에 붙어 명령을 돌릴 수 있다고 본다.
확인하는 동안 디스크 구성이 바뀌지 않는다고 본다.
§215 가 그린 배치가 지금도 그대로라고 보고 대조할 대상으로 삼는다. §211 은 그 그림이 2026-09-03 값이고 그 뒤에 엣지 게스트가 늘었다고 적었다.
미지수
지금 돌고 있는 도메인에 붙은 디스크가 §187 이 만들 때 준 둘과 같은지.
각 Target 의 Source 경로가 virsh domblklist 출력에 무엇으로 나오는지.
게스트 안에서 lsblk 로 본 장치와 파티션이 §215 가 그린 vda 와 vdb 에 그대로 대응하는지.
엣지를 더한 뒤의 배치. §215 는 게스트 두 대였을 때의 그림이고 §178 은 지금 게스트가 셋이라고 적었다.
제약
이 물음은 백엔드가 무엇인지까지 답한다. 형식과 크기는 다음 물음이 받고, 성능은 여기서 판정하지 않는다.
게스트 안에서 본 이름은 답이 되지 않는다. §145 가 그 추론을 명시적으로 막았기 때문이다.
다른 장비의 디스크 구성을 근거로 삼지 않는다. 이 호스트에서 얻은 출력은 §199 의 ls -l 과 virsh pool-info default 뿐이고, Target 과 Source 의 대응은 그 안에 없다.
선택지
1. 게스트와 호스트를 한 번씩 돌고 한 표로 남긴다
§146 이 든 두 명령을 그대로 돌린다. 각 게스트에서 lsblk 로 보이는 block device 와 파티션을 받고, 호스트에서 가상 머신마다 virsh domblklist <VM_NAME> 을 돌려 Target 과 Source 를 받는다. 두 출력이 있으면 게스트가 보는 이름과 호스트의 실제 대상이 가상 머신마다 한 행으로 이어진다.
로그인할 수 없는 가상 머신이 있으면 그쪽은 호스트 출력만 얻고, 게스트가 그 디스크를 어떤 파티션으로 나눠 쓰는지는 비게 된다.
2. 호스트 쪽 출력만 먼저 받는다
virsh domblklist 는 호스트에서만 돌아가고 Target 과 Source 를 한 번에 주기 때문에, 가상 머신에 로그인하지 않아도 백엔드 경로가 확정된다. 이어지는 두 물음이 요구하는 이미지 경로도 바로 얻는다.
대신 게스트가 그 디스크를 어떤 이름과 파티션으로 보고 있는지가 빠진다. 나중에 게스트 안에서 잰 스토리지 수치를 이 표에 붙이려면 그때 대응을 다시 확인해야 한다.
3. libvirt 정의 전문을 받아 disk 요소를 읽는다 — 제외
virsh dumpxml 은 disk 요소에 source 와 driver 를 함께 담고 있어서 백엔드 경로와 cache 설정을 한 번에 볼 수 있다.
§175 는 dumpxml 을 cache mode 를 확인하는 항목에 두었고, 연결 확인에는 §146 과 같은 domblklist 를 들었다. 여기서 dumpxml 을 쓰면 한 출력으로 두 물음이 닫히게 되어 어느 확인이 무엇을 근거로 끝났는지가 흐려진다. cache 값은 그 물음이 받는다.
다음 검증
- 각 게스트에서 lsblk 를 돌려 보이는 block device 와 파티션을 적는다.
- 호스트에서 가상 머신마다 virsh domblklist <VM_NAME> 을 돌려 Target 과 Source 를 적는다.
- 가상 머신마다 한 행으로 정리하고 두 명령의 출력을 그대로 증거로 둔다.
닫는 조건 : 가상 머신마다 Target 과 Source 의 대응이 출력으로 확정되면 닫는다. Source 가 파일이면 형식과 실제 사용량을 묻는 물음과 그 파일이 올라간 Host block device 를 묻는 물음으로 이어진다. Host block device 면 §145 가 적은 그 갈래가 이 환경이라고 적고, qcow2 를 전제한 후속 물음 둘은 이 호스트에 적용되지 않는다고 함께 적는다.