---
id: 63aef96b-03ef-4dbd-9ba6-9e61c6e695e1
kind: QUESTION
slug: virtio-balloon-configured
title: 이 가상 머신들에 virtio-balloon 이 붙어 있는가
topic: memory-virtualization
topicName: 메모리 가상화
project: virtualization
status: 초안
questionStatus: OPEN
studio: "https://hyeonworks.com/studio/documents/63aef96b-03ef-4dbd-9ba6-9e61c6e695e1/edit"
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
source:
  - final/document.md#83-실제-환경에서-확인할-open-question-oq-8
  - final/document.md#65-virtio-balloon-구조
  - final/document.md#64-ballooning이-필요한-이유
---

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

libvirt 설정에서 balloon 장치를 읽은 기록이 아직 없다. 다만 §198 의 virsh dommemstat 실측에서 kc-lab-2 의 현재 할당이 선언한 4096MB 가 아니라 3120MB 로 나왔다. 근거 문서는 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적었다. 장치가 없거나 게스트 쪽 드라이버가 올라와 있지 않으면 balloon target 을 바꾸는 실험이 성립하지 않으므로, 설정과 게스트 쪽 상태를 읽는 이 확인이 먼저다.

## 관계

- **virtio-balloon 이 Guest 메모리를 회수하고 돌려주는 방식**
  드라이버와 장치가 무엇을 주고받는지를 그 개념이 설명한다. 이 물음은 그 구성이 이 호스트에 있는지만 본다.
- **balloon target 을 바꾸면 게스트가 쓸 수 있는 메모리는 어떻게 따라 움직이는가**
  장치가 붙어 있다는 답이 나와야 그 실험이 시작된다.
- **이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가**
  두 물음이 virsh dommemstat 을 같이 읽으므로 한 번 찍어 나눠 쓴다.

## 사실

- §64 는 호스트가 QEMU 의 게스트 RAM backing 을 볼 수 있지만 게스트 내부에서 어떤 메모리가 중요한지 완전히 알지 못한다고 적었다.
  게스트는 자기 메모리를 애플리케이션 working set · JVM heap · page cache · free 로 구분해 알고 있다.
- §64 는 그래서 호스트가 무작정 게스트 backing 을 swap-out 하기보다 게스트 커널과 협력해 불필요한 메모리를 돌려받는 편이 유리할 수 있다고 적고, 대표적인 메커니즘으로 virtio-balloon 을 들었다.
- §65 는 그 구조를 게스트 커널 아래 virtio-balloon 드라이버와 virtqueue, VM 경계 건너편의 QEMU virtio-balloon 장치, 그리고 호스트 메모리 관리로 그렸다.
- §65 는 virtio-balloon 이 게스트 RAM 자체를 제공하는 장치가 아니라고 못 박았다. 이미 존재하는 게스트 RAM backing 을 호스트와 게스트가 협력해 회수하고 반환하는 데 쓰는 가상 장치다.
- §83 OQ-8 은 확인 명령으로 virsh dumpxml <VM_NAME> 을 들고, 게스트에서도 관련 드라이버나 장치 상태를 확인하라고 적었다.
- §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 로 설정을 통째로 읽을 수 있다고 본다.
- 설정에 balloon 장치가 있으면 게스트 쪽에도 대응하는 드라이버가 보인다고 전제한다. 그 전제가 이 게스트 배포판에서 맞는지는 확인하지 않았다.
- 게스트에 접속해 장치 목록이나 커널 모듈 상태를 읽을 수 있다고 본다.

## 미지수

- 각 가상 머신의 libvirt 설정에 balloon 장치가 있는지.
- 있다면 게스트 안에서 그 드라이버가 실제로 올라와 있는지.
- 이 환경에서 그 드라이버나 장치가 어떤 이름으로 보이는지. 개념 문서가 환경마다 다를 수 있다고만 적고 이름을 남기지 않았다.
- 게스트 쪽 상태를 어떤 명령으로 읽는지. 개념 문서가 게스트 확인 명령을 적지 않아 실행하는 쪽이 정한다.
- 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 종류 및 설정에 따라 달라질 수 있다고 적고 그 동작을 단정하지 않았다. 개념 문서가 단정하지 않은 것을 이 물음이 대신 단정하지 않는다.
- 게스트 쪽에서 쓴 명령과 그 출력을 그대로 남긴다. 이름이 환경마다 다르므로 다음 사람이 같은 것을 찾으려면 무엇을 봤는지가 필요하다.
- 장치가 없는 것으로 나와도 그것을 결함으로 적지 않는다. 이 실험 기반에서 ballooning 을 쓰기로 한 기록이 개념 문서에 없다.
  §70 은 virtio-mem 같은 다른 동적 memory 관리 방식도 존재하므로 모든 동적 VM memory 관리를 ballooning 하나로 일반화하면 안 된다고 적었다. 그래서 balloon 장치가 없다는 답은 이 환경에 동적 메모리 관리가 없다는 뜻이 아니라 이 장치가 없다는 뜻까지다.

## 선택지

### 1. 설정과 게스트 상태를 한 번에 확인한다

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

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

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

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

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

## 다음 검증

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

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