▲

OpenBSD-current, 이제 Apple Hypervisor에서 게스트로 실행 가능

 (undeadly.org)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • OpenBSD/arm64가 Apple Hypervisor 환경에서 게스트 운영체제로 동작 가능해짐
  • 일련의 커밋을 통해 그래픽 처리와 네트워크 기능이 수정 및 개선되어 커널 패닉과 X11 블랙스크린 문제 해결
  • 이제 Apple Virtualization 환경에서 완전하게 동작하며, 최신 Apple Silicon Mac 에서 이용 가능

Apple Hypervisor에서의 OpenBSD/arm64 지원

  • 최근 커밋을 통해 OpenBSD/arm64 가 Apple Hypervisor 에서 게스트 운영체제로 실행 가능
    • 관련 커밋은 Helg Bredow(helg@)와 Stefan Fritsch(sf@)가 수행

Helg Bredow의 viogpu 수정

  • sys/dev/pv/viogpu.c 파일에서 viogpu_wsmmap() 함수가 수정됨
    • 기존에는 커널 가상 주소(kva)를 반환했으나, 이제 bus_dmamem_mmap(9) 을 통해 물리 주소를 반환
    • 이 수정으로 QEMU에서 X11 실행 시 발생하던 검은 화면 문제와 Apple Hypervisor에서의 커널 패닉이 해결됨
  • 프레임버퍼를 호스트 메모리로 전송하기 전 bus_dmamap_sync(9) 호출 추가
    • 이를 통해 다른 CPU에서 실행 중인 호스트가 프레임버퍼 업데이트를 인식 가능
    • 수정 검토와 피드백은 kettenis@가 수행, 승인(ok)은 sf@가 부여

Stefan Fritsch의 virtio 네트워크 수정

  • sys/dev/pv/if_vio.c 파일에서 VIRTIO_NET_F_MTU 기능 지원 추가
    • 하이퍼바이저로부터 hardmtu 값을 가져와 현재 MTU를 동일하게 설정
    • virtio 표준이 명확하지 않지만, Linux와 동일한 방식을 채택
  • ETHER_MAX_HARDMTU_LEN을 상한으로 사용하여 이전의 MAXMCLBYTES보다 정확한 처리
    • 하이퍼바이저가 이보다 큰 MTU를 요청할 경우, VIRTIO_NET_F_MTU 기능 없이 재협상 수행
  • 이 커밋으로 OpenBSD가 Apple Virtualization 환경에서 완전하게 동작
    • 입력 및 테스트는 helg@가 수행, 승인(ok)은 jan@가 부여

사용자 안내 및 테스트 권장

  • 이 변경은 최신 Apple Silicon Mac 모델 사용자에게 특히 유용
  • 현재 스냅샷 버전에서 테스트 가능하며, 사용자 피드백 요청
▲
GN⁺ 2일전  [-]
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만 가능한 상황인데, 이번 개선으로 프레임버퍼가 동작할 수 있길 기대함
답변달기