Hacker News 의견들

• 좋은 업데이트임. VIRTIO_NET_F_MTU 협상이 Apple 가상화 스택에서 여러 게스트 OS 구현의 걸림돌이었음
  스펙이 모호해서 Linux는 그냥 작동하지만 OpenBSD는 하드 MTU 제한을 처리하기 위해 별도 패치를 넣어야 했음
  M4/M5 칩의 단일 스레드 성능 덕분에 OpenBSD 게스트는 pf 설정 테스트나 격리된 메일 서버 실행에 최적의 환경임
  이제 viogpu를 안정적으로 쓸 수 있어서, 빠른 VM 설치 시 시리얼 콘솔만 쓰던 방식에서 벗어날 수 있게 됨
  Helg와 Stefan에게 큰 박수를 보냄
  • 유니커널(unikernel)이면 더 좋을지도 모름. 다만 그 경우엔 OS 없이 동작할 수 있는 메일 서버용 유니커널이 필요함
  • 나는 그런 그래픽 환경이 필요 없음. 내 IaC(인프라 코드) 는 VM을 띄울 때 어떤 상호작용도 원하지 않음
• 더 큰 소식은 이 업데이트가 QEMU 호환성 버그를 해결했다는 점임
  이 버그 때문에 arm64에서 OpenBSD가 X를 시작할 때 멈췄는데, 7.3 버전의 프레임버퍼 변경 이후 생긴 문제였음
  유일한 해결책은 커널 드라이버를 비활성화하는 것이었는데, 이제 더 많은 사람들이 OpenBSD를 문제 없이 써볼 수 있을 것 같음
  • 나도 그중 한 명임. 한동안 써보고 싶었는데, 내 유일한 머신이 MacBook Pro라서 못 했음
  • QEMU가 X를 시작해야 하는 이유가 뭔지 궁금함. 그건 OpenBSD의 역할 아닌가 싶음
• 이건 Virtualization.framework(Apple의 1st-party VMM)에 관한 이야기임
  OpenBSD는 오래전부터 Hypervisor.framework + QEMU 조합으로도 작동했음
  • 이름이 너무 헷갈림. 두 프레임워크를 구분하기가 거의 불가능함
  • 잘 모르겠는데, 그게 Tahoe에서 도입된 거였나? 이전엔 불가능했던 걸 해결한 이유가 궁금함
  • 나도 혼동했음. UTM은 내부적으로 QEMU를 쓰지만, 이제 OpenBSD 스냅샷이 QEMU에서 매끄럽게 부팅됨. 여전히 가상화된 상태이긴 함
• 내가 뭔가 놓친 걸 수도 있지만, VM을 테스트할 때 메모리가 한 번 커지면 절대 줄어들지 않는 문제가 있었음
  이게 실제 이슈라면 개선이 있는지 궁금함
  • 게스트가 호스트에게 “이 메모리를 완전히 해제했으니 회수해도 된다”고 알려주는 건 꽤 복잡한 일임
    반대로 게스트가 4GiB RAM이 있다고 믿지만 실제로는 접근할 때만 호스트가 할당하는 건 훨씬 단순함
    VM은 컨테이너와 완전히 다른 존재임
  • VM을 어디서 테스트했는지 궁금함. 전 세계적으로 수억 개의 VM이 매일 돌아가고 있음
• 이걸 직접 해보는 가이드가 있을까? 나는 raw hypervisor를 써본 적이 없음
  • 빠른 Kagi 검색으로 이 블로그 글을 찾았음. 아마 도움이 될 수도 있음
  • 기본적으로 커널과 필요 시 RAM 디스크를 만들어서 Linux처럼 부팅하면 됨
• 약간 관련된 이야기지만, UTM Remote는 정말 훌륭한 VM 원격 클라이언트임
  다른 하이퍼바이저 프로토콜(libvirtd, bhyve 등)도 지원해줬으면 함
• OpenBSD가 게스트로 실행될 때 보안성이 충분한지 궁금함
  호스트가 수학적으로 침입할 수 없을 정도로 격리되는지 알고 싶음. 키 관리 용도로 이상적일 수도 있음
  • 2025년 기준 OpenBSD는 AMD SEV/SEV-ES를 지원하고, SEV-SNP는 개발 중임
    적절한 하드웨어가 있다면 충분히 격리 가능함
    관련 내용은 BSDCan 2025 발표에서도 다뤄짐
  • 하지만 호스트 커널과 VMM은 여전히 게스트 메모리를 볼 수 있음. 그런 용도로는 추천하지 않음
• 참고로 이 Redox fork는 완전히 Rust 기반이며 Makefile이 전혀 없음
• 잘했음! 현재 FreeBSD 15는 UTM에서 X가 전혀 작동하지 않음
  RDP/VNC만 가능한 상황인데, 이번 개선으로 프레임버퍼가 동작할 수 있길 기대함