Quickemu: 최적화된 Windows, macOS, Linux 가상 머신을 빠르게 실행

• Quickemu는 QEMU용 래퍼로, 실행할 운영체제를 고르면 가상 머신 생성에 필요한 설정을 자동으로 처리해 Windows, macOS, Linux VM을 빠르게 만들고 실행함
• quickget은 원하는 운영체제의 업스트림 OS 이미지를 자동 다운로드하고 VM 설정 파일을 만들며, quickemu는 하드웨어를 탐지해 컴퓨터에 맞는 구성으로 VM을 실행함
• 초기 목표는 Linux 배포판을 빠르게 테스트하는 것이었고, VM과 설정을 외장 USB 저장소나 홈 디렉터리 등 원하는 위치에 둘 수 있으며 실행에 상승 권한이 필요 없음
• 현재는 macOS, Windows, 대부분의 BSD, FreeDOS, Haiku, KolibriOS, OpenIndiana, ReactOS 등 거의 1000개 운영체제 에디션을 지원함
• Linux와 macOS 호스트에서 동작하며 SPICE, 파일 공유, QEMU Guest Agent, VirGL, USB 패스스루, 포트 포워딩, 오디오, EFI와 Legacy BIOS 부팅 등 VM 사용에 필요한 기능을 제공함

---

Quickemu가 하는 일

• Quickemu는 QEMU를 감싼 래퍼로, 가상 머신 생성 시 필요한 설정을 자동으로 처리함
• 사용자는 실행할 운영체제만 선택하면 되고, 많은 설정 옵션을 직접 지정할 필요가 없음
• 핵심 도구는 두 가지임
  • quickget: 원하는 운영체제의 업스트림 OS를 자동 다운로드하고 VM 설정 파일을 생성함
  • quickemu: 호스트 하드웨어를 열거한 뒤 해당 컴퓨터에 맞는 최적 구성으로 가상 머신을 실행함

프로젝트의 출발점과 현재 범위

• 초기 목표는 Linux 배포판 테스트를 빠르게 할 수 있게 만드는 것이었음
• VM과 설정은 외장 USB 저장소나 홈 디렉터리처럼 원하는 위치에 저장할 수 있음
• 가상 머신 실행에는 상승 권한이 필요 없음
• 현재 지원 범위는 Linux 배포판을 넘어 macOS, Windows, 대부분의 BSD, 비Linux 운영체제로 확장됨
  • 지원 예시는 FreeDOS, Haiku, KolibriOS, OpenIndiana, ReactOS 등임

지원 운영체제와 호스트

• 호스트는 Linux와 macOS를 지원함
• 게스트 운영체제는 다음을 포함함
  • macOS Sequoia, Sonoma, Ventura, Monterey, Big Sur, Catalina, Mojave
  • Windows 10과 11, TPM 2.0 포함
  • Windows Server 2022, 2019, 2016
  • Ubuntu와 모든 공식 Ubuntu flavour
  • 대부분의 BSD와 여러 비Linux 운영체제
• ARM64 게스트를 지원해 aarch64 VM을 실행할 수 있음
  • ARM 호스트에서는 네이티브 실행
  • x86_64 호스트에서는 에뮬레이션 실행
• 지원 운영체제 에디션 수는 거의 1000개에 이름

VM 기능

• SPICE 전체 지원을 제공하며 호스트/게스트 클립보드 공유를 포함함
• 파일 공유 방식은 게스트 운영체제에 따라 여러 방식을 지원함
  • VirtIO-webdavd: Linux와 Windows 게스트용 파일 공유
  • VirtIO-9p: Linux와 macOS 게스트용 파일 공유
  • Samba: Linux, macOS, Windows 게스트용 파일 공유이며 호스트에 smbd가 설치되어 있어야 함
• QEMU Guest Agent를 지원해 표준 QMP 명령으로 시스템 수준 에이전트에 접근할 수 있음
• 그래픽과 장치 기능으로 VirGL 가속, USB 장치 패스스루, 스마트카드 패스스루를 지원함
• 네트워크와 입출력 기능도 포함함
  • 게스트로의 자동 SSH 포트 포워딩
  • 네트워크 포트 포워딩
  • 풀 듀플렉스 오디오
  • 점자 지원
  • SecureBoot 포함 또는 미포함 EFI 부팅
  • Legacy BIOS 부팅

빠른 시작 흐름

• Quickemu 설치 후 두 단계로 VM을 만들고 실행함
• quickget으로 ISO 이미지를 다운로드하고 VM 설정 파일을 만듦

quickget nixos unstable minimal

• quickemu로 quickget이 만든 설정 파일을 사용해 VM을 시작함

quickemu --vm nixos-unstable-minimal.conf

• 인자 없이 quickget을 실행하면 지원되는 모든 운영체제 목록을 볼 수 있음

문서와 참고 자료

• 위키는 시작 방법과 고급 설정 및 사용법을 다룸
  • Installation: 설치
  • Create Linux virtual machines: Linux VM 생성
  • Create macOS virtual machines: macOS VM 생성
  • Create Windows virtual machines: Windows VM 생성
  • Advanced quickemu configuration: 고급 Quickemu 설정
  • Advanced quickget features: 고급 quickget 기능
  • Alternative frontends: 대체 프런트엔드
  • References: 참고 자료

[GN⁺]

Hacker News 의견들

• https://virt-manager.org/ 추천함. 내 환경에서는 훨씬 잘 동작했고, SSH로 원격 시스템의 QEMU를 실행하는 것도 지원함
  예전에 서로 다른 VM 호스트들과 로컬 VM을 많이 관리할 때 늘 사용했음
  • virt-manager는 가장 과소평가된 소프트웨어 중 하나임. 강력하고 자주 쓰게 됨
    VM에 대한 기본 용어는 어느 정도 알아야 하지만, 기능과 힘이 꽉 찬 예전식 GUI가 많이 떠오름
    필요가 단순하거나 VM 쪽에 덜 익숙하다면 Gnome Boxes가 같은 백엔드를 쓰면서도 깔끔한 GUI를 제공함. 단순한 만큼 유연성은 줄지만, 나중에 Boxes에 노출되지 않은 설정을 조정해야 하면 Gnome Boxes VM을 virt-manager로 열 수 있다는 점이 좋음
  • 같은 건 아니지만 Quickemu도 SSH 너머에서 잘 동작함
    SSH로 원격 시스템에서 실행하면 Fedora의 로컬 Wayland 세션에 QEMU 콘솔을 “X 포워딩”해줌
    처음에는 헤드리스 모드로 돌리는 줄 알았는데 창이 떠서 꽤 놀랐음 :)
  • 설정만 하는 프로그램이 이렇게 중요하고 유용할 수 있다는 게 놀라움
    설정이 그 설정 대상 소프트웨어와 분리되어 있다면 어떨지 상상해보게 됨. 각 UI 프로그램이 바퀴를 다시 발명한 방식을 익히는 대신, 좋아하는 설정 관리자를 골라 쓸 수 있을 것임
    지금 가장 가까운 건 텍스트 설정 파일임. 이를 쓰는 모든 프로그램은 특정 언어와 저장 위치를 골라야 함
    요즘 많이 생각하는 아이디어는 설정 중개 계층임. 사용자에게 보이는 설정 UI에는 원하는 언어/형식을 쓰고, 그 데이터를 단일 진실 공급원으로 삼아 소프트웨어가 읽을 설정 파일을 생성하는 방식임
  • libvirt와 virt-manager는 실제 소프트웨어인 QEMU 및 KVM에 대한 단순화된 사용자 인터페이스일 뿐임. 설정 파일을 파싱하고 QEMU 바이너리에 올바른 옵션을 넘기는 정도의 비교적 사소한 문제를 해결함
    설정 파일 기반 시작/중지나 직렬 콘솔 접근 같은 유용한 관리 기능도 있지만, 이런 건 셸 스크립트로 직접 구현하기도 아주 단순함. libvirt의 스토리지 처리는 끔찍하게 장황하고 복잡한데도 thin LV나 ZFS도 제대로 다루지 못함
    표준 기업식 방식으로 돌리고 싶고 QEMU나 셸 같은 기본 소프트웨어를 배울 생각이 없거나, libvirt의 애매한 기능이 꼭 필요한 게 아니라면 KVM 위에서 QEMU를 직접 쓰고 자체 스크립트를 쓰는 편을 권함. 별로인 Python 래퍼보다 QEMU를 더 많이 배우게 되고 시스템 제어권도 커짐
    또한 IBM/Red Hat은 virt-manager를 새 웹 인터페이스인 Copilot 쪽으로 밀면서 사실상 폐기한 것처럼 보임
    Quickemu는 큰 복잡한 UI를 배우느라 시간을 쓰지 않고 예제를 잠깐 본 뒤 새 VM을 바로 띄울 수 있어 더 흥미로움
  • QEMU에 명령줄 옵션을 직접 넘기는 방식이 좋음. Windows NT on MIPS나 Ultrix 같은 오래된 OS에는 이 방식이 잘 맞음
• 지난번 올라왔을 때의 보안 주의사항을 다시 남김[1]
  이 도구는 인터넷에서 임의 파일을 내려받고, 그 체크섬을 또 인터넷의 다른 임의 파일과 대조함[2]
  최선의 보안 관행은 아님. 올바른 방식은 배포판 개발자의 GPG 키를 저장소에 커밋해두고 모든 파일을 그 키로 검증하는 것임
  그렇다고 이 프로젝트가 여러 OS를 부팅시키기 위해 QEMU에 넘길 올바른 플래그를 찾아낸 노력을 깎아내리려는 건 아님
  [1] https://news.ycombinator.com/item?id=28797129
  [2] https://github.com/quickemu-project/quickemu/blob/0c8e1a5205...
  • 이게 왜 보안 문제인지 설명해줄 수 있나? GPG 키 검증이 진본성을 보장하는 최선의 방식이긴 하지만, 거의 모두가 하는 것과 다르지 않게 배포판 자체 HTTPS 사이트에서 ISO를 내려받는 것임
    게다가 대부분이 하지 않는 해시 일치 검증까지 추가로 수행함
  • 이 중 얼마나 낡은 관행일까? TCP/TLS가 이미 체크섬과 출처 서명을 해줘야 하는 것 아닌가?
    FTP 시절에는 체크섬과 GPG가 필수였음. HTTP/TCP에서는 재시도와 체크섬 처리는 TCP가 하니 GPG 필요성이 더 커지지만, 중간자 공격 때문에 둘 다 여전히 필요했음
    그런데 HTTPS라면 여전히 왜 중요할까? HTTPS가 두 검증과 서명 확인을 대신 해주는 것 아닌가
  • 게다가 작성자가 라이브 스트리밍 중에 마이크가 켜진 상태로 기계식 키보드로 사용자 비밀번호를 입력함
  • “인터넷에서 임의 파일”을 내려받는 건 아니고, 원본 출처만 쓰는 것처럼 보임
  • 참고로 macOS는 이제 서명 검증을 함. Windows에는 사용 가능한 서명이 없음
    올해 Hacker News의 관심이 계기가 되어 누군가 Linux용 서명 검증을 구현해주면 좋겠음
• macOS에서는 UTM[0]이 이걸 꽤 잘 해줌. 미리 만들어진 이미지 갤러리[1]도 작게 제공함
  0. https://mac.getutm.app/
  1. https://mac.getutm.app/gallery/
  • UTM은 iPad에서도 동작함. TTY 모드의 Arch Linux를 꽤 잘 실행할 수 있었음
    https://docs.getutm.app/installation/ios/
• libvirt에는 virt-install이 포함되어 있어서 Windows와 여러 Linux 배포판을 빠르게 생성하고 자동 설치할 수 있음. mac에서는 안 해봤음
  최근 Alma Linux 예시는 다음과 같음
  $ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattended
  커피 한 잔 마시고 오면 설치가 끝난 Alma Linux VM이 동작하고 있음. 지원 OS 목록은 libvirt 버전에 따라 달라지며, 다음으로 확인함
  $ osinfo-query os
  • Fedora 39 디스크 이미지가 필요하면 virt-builder도 있음
    $ virt-builder fedora-39
    나중에 virt-install --import로 libvirt에 가져올 수 있음
  • virt-install이 ISO를 자동으로 내려받나? 시도하면 이런 메시지가 나옴
    $ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattended
ERROR Validating install media 'alma9.iso' failed: Must specify storage creation parameters for non-existent path '/home/foo/alma9.iso'.
  • 이 결과가 어떻게 될지 명확하지 않음. 호스트명은 무엇이고, 디스크는 어떻게 파티션되고, 어떤 패키지가 설치되며, 시간대와 키보드 배열은 무엇으로 설정되는지 등이 궁금함
  • 이걸 하려면 libosinfo-bin을 설치해야 했음
• 이런 도구의 편의성은 훌륭하지만, 주요 스크립트 두 개를 합치면 Bash 5000줄 정도임
  실행하기 전에 검토하고 싶지만, Bash 5000줄을 읽고 싶지는 않음
  • 셸 스크립트가 보통 읽기 즐겁지 않다는 데는 대체로 동의하지만, 이 코드는 실제로 나쁘지 않음
    설득이 될지는 모르겠지만, 실행하기 전에 Bash 스크립트를 읽어봤고 꽤 잘 구조화되어 있었음. 기능이 함수로 잘 나뉘어 있고, 변수명도 합리적이며, 유용한 주석이 있고, 이상한 제어 흐름이나 간접 호출도 없으며, 난해한 명령 사용도 최소화되어 있음. 지금까지 본 셸 스크립트 중 가장 읽기 쉬운 축에 들어감
    이 스크립트가 실제로 하는 일을 생각해보면 코드가 비교적 직선적인 것도 말이 됨. 핵심은 QEMU를 시작하는 명령 하나를 실행하는 것임. 나머지 코드는 그 명령에 어떤 인자를 줄지 로컬 시스템을 확인하거나, 필요하면 파일 몇 개를 내려받는 작업임
  • 셸 스크립트라는 이유만으로 다른 소프트웨어와 다르게 볼 이유가 있나? OS를 실행하기 전에 커널 소스를 읽나? 웹 브라우저는?
    맹목적으로 실행해야 한다는 뜻은 아니지만, 우리가 실행할 소프트웨어를 고르는 기준은 보통 소스 코드에 익숙한지 여부에 의존하지 않음
  • 정말 걱정되고 시간이 있다면 욕먹을 수도 있지만 ChatGPT로 코드에 대해 대화해볼 수도 있음. 프롬프트는 이런 식으로 가능함
    “You are a linux guru, and you have extensive experience with bash and all forms of unix/linux. I am going to be pasting a large amount of code in a little bit at a time. Every time I paste code and send it to you, you are going to add it to the previous code and ask me if I am done. When I am done we are going to talk about the code, and you are going to help me break it down and understand what is going on. If you understand you will ask me to start sending code, otherwise ask me any questions before you ask for the code.”
    더 짧은 코드, 그래도 프롬프트 한도를 넘는 1000줄 미만 코드에는 이 방법을 써봤고 꽤 잘 동작했음. 요즘 ChatGPT가 게을러진 건 인정하고, 가끔은 게으르게 굴지 말고 요청한 전체 출력을 달라고 명시해야 하지만 전반적으로 코드 설명은 꽤 잘해줌
  • 이건 소프트웨어 전반의 신뢰 형성 문제라고 봄. 신뢰를 어떻게 세우고, 개발자와 사용자에게 어떤 기대와 책임이 있는지의 문제임
    “많은 눈이 모든 버그를 얕게 만든다”는 문구는 일부 사용자에게 사고를 멈추게 하는 클리셰처럼 보임. 공개되어 검토 가능하니 괜찮을 것이라고 여기고, 모든 것을 검사하는 코드 감사자 무리가 돌아다니는 이미지를 떠올리는데, 실제로는 선의보다 악의 쪽을 더 예상하게 됨
    Windows 쪽에는 수십 년 동안 트윅 유틸리티가 꾸준히 있었음. “대기업” 개발자들은 시스템 성능을 끝까지 끌어낼 동기가 없고, 빠른 설정이나 레지스트리 트윅 뒤에 모두에게 유용한 쉬운 옵션을 남겨뒀다고 믿는 사람들을 끌어들임. 가끔 보이는 TronScript가 떠오르는데, 역사와 참여도를 보면 냄새 테스트는 통과할 것 같아 좋다고 보지만, 자동화라는 이름으로 세부 사항을 숨기고 사용자를 대신해 좋은 결정을 해주길 기대하게 만듦. 파고들어 무슨 일이 왜 일어나는지 조사하고 배울 수도 있지만, 많은 사람에게는 사실상 바이너리나 다름없음
    다행인 점은 이런 도구 대부분은 사용층이 제한적이라 침해할 가치가 크지 않다는 것임. 특정 브랜드가 충분히 많이 쓰이면 2017년에 백도어가 심어진 Piriform의 CCleaner 같은 상황이 생길 수 있음
• 흥미로워 보이는데, Ubuntu에서 가끔 VirtualBox로 Windows 11만 돌리는 사람에게 어떤 장점이 있는지 알려줄 수 있나?
  • VM으로 무엇을 하느냐에 따라 크게 달라져서 답하기 어려움. 이건 QEMU 래퍼처럼 보이고, 새 VM을 쉽게 띄우도록 합리적인 설정을 골라주려는 도구로 보임
  • 특히 GPU 가속 측면이 있음. vbox 안의 Windows에서 화상회의를 돌리는 건 거의 불가능하고, 조금만 복잡한 GUI 앱도 상당히 지연됨
  • Gnome Boxes의 대안에 더 가까워 보임. 최신 이미지를 내려받고 해당 배포판/OS에 맞는 기본 설정을 제공하며, Windows와 macOS 같은 까다로운 OS도 추가로 지원하는 도구임
  • 실제로 macOS를 실행한다면 VirtualBox나 VMware에 설치하는 것보다 큰 장점임. 그쪽에서는 여러 가지를 패치해야 해서 실행이 매우 어려움
• Linux에서는 Incus/LXD를 강력히 추천함. VM 실행은 이렇게 간단함

  incus launch images:ubuntu/22.04 --vm my-ubuntu-vm  
  

  실행 후 셸 접근은 다음과 같이 함

  incus exec my-ubuntu-vm /bin/bash  
  

  Incus/LXD는 시스템 컨테이너도 지원함
  • 좋아하지만 거의 언급되지 않는 것으로 systemd-nspawn이 있음. docker create --name ubuntu ubuntu:22.04를 실행하고 docker export ubuntu로 임의의 Docker 이미지에서 tar를 만듦
    그런 다음 /var/lib/machines/ubuntu에 풀면 됨. systemd가 들어 있는 이미지를 고르거나 컨테이너 안에 systemd를 설치해야 함. 마지막으로 machinectl start ubuntu와 machinectl shell ubuntu로 들어감
    systemd-nspawn은 매우 단순하고 가볍고, 실제 Linux 머신을 아주 잘 에뮬레이션함. systemd 기반의 임의 루트 파티션을 가져와 systemd-nspawn으로 부팅하면 그대로 동작함
• VM을 단순히 실행하는 것과 비교한 성능 변화 수치가 있나? 보통 Linux 호스트 안에서 Linux 게스트를 돌리는데 게스트 성능에 자주 실망함
  VM 경험을 튜닝하는 조사는 해본 적이 없어서 얼마나 놓치고 있는지 궁금함. 5% 빠른가? 100%인가?
  • 어떻게 실행하고 있나? 적절한 설정으로 KVM/QEMU를 돌리면 거의 베어메탈 성능이 나옴
• Arm, 즉 Apple Silicon에서 네이티브로 실행되나? 최신 macOS 버전은 어떤가? 그래픽 가속은 있나? 네트워크는 어떻게 처리되나?
• Proxmox와 어떤 차이가 있는지, 여기서 하는 최적화를 내 Proxmox 환경에 수동으로 재현할 수 있는지 궁금함
  • 이건 Proxmox와 엄청나게 다름. Proxmox는 많은 서버를 VM으로 호스팅해야 하는 연구실과 데이터센터용으로 만들어졌음
    Quickemu는 주로 데스크톱 사용을 겨냥한 것으로 보임