▲

WSL2는 단순한 VM이 아닌가요?

 (ssg.dev)
6P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • Windows NT의 서브시스템 구조는 다른 운영체제용 프로그램을 실행하기 위한 API 호출 변환 계층으로 구성되어 왔음
  • WSL1은 이러한 전통을 잇는 형태로, 리눅스 호출을 윈도우 커널 호출로 변환하는 가벼운 번역 계층으로 동작
  • WSL2는 성능 문제를 해결하기 위해 Hyper-V 기반의 완전한 리눅스 VM으로 전환되었으며, 실제 리눅스 커널을 실행
  • WSL2는 동적 메모리 관리, Windows 드라이브 마운트, WSLg를 통한 GUI 통합 등으로 일반 VM보다 높은 통합성을 제공
  • 파일 관리의 불편함과 디스크 이미지 의존성 등 한계가 있지만, WSL1과 WSL2의 장단점을 선택적으로 활용할 수 있는 유연성이 중요

Windows NT의 서브시스템 개념

  • Windows NT의 서브시스템(subsystem) 은 다른 운영체제용 프로그램을 실행하기 위한 API 세트와 호출 변환 계층을 의미
    • 과거 NT에는 OS/2 서브시스템(OS2SS.EXE) , POSIX 서브시스템(PSXSS.EXE) 등이 존재
    • CSRSS.EXE는 Win32 API 변환 계층으로, 일부 기능은 커널 모드(WIN32K.SYS)로 이동
  • POSIX 서브시스템은 정부 인증을 위한 최소 구현 수준이었으며, 이후 Interix 기반 Windows Services for Unix로 대체됨

WSL1: 번역 기반 리눅스 계층

  • WSL1(Windows Subsystem for Linux) 은 리눅스 시스템 호출을 윈도우 호출로 변환하는 얇은 번역 계층
    • 실행 시 bash 프로세스만 몇 MB 메모리를 사용하며, Task Manager에서 일반 프로세스로 표시
    • 루트 파일시스템은 NTFS 상의 개별 파일 구조로 존재해 저장 공간 오버헤드가 거의 없음
  • 제한사항
    • I/O 성능 저하: 리눅스와 Win32 파일시스템 API 차이로 인한 변환 비용
    • GUI 실행 시 외부 X 서버 필요 (예: X410)
    • Raw 소켓 미지원으로 traceroute, nmap, tcpdump 등 실행 불가

WSL2: Hyper-V 기반 리눅스 VM

  • 사용자 요구에 따라 Microsoft는 Hyper-V 위에서 동작하는 완전한 리눅스 VM을 도입
    • 루트 파일시스템은 단일 VHDX 파일로 관리
    • 명령어 wsl --set-version "Ubuntu" 2 로 WSL1↔WSL2 간 변환 가능
  • 성능 특성
    • 초기 부팅은 느리지만, 네이티브 리눅스 커널을 실행
    • 메모리 사용은 동적이며, 최대 물리 메모리의 절반까지 확장 가능
    • stress 테스트 결과, 메모리 사용량은 부하에 따라 증가 후 자동 축소
    • 필요 시 wsl --shutdown 명령으로 VM 종료 가능

WSL2의 통합 기능과 한계

  • WSL2는 전통적 VM과 달리 Windows와의 통합성을 강화
    • Windows 드라이브 자동 마운트, 리눅스 드라이브를 \\wsl$\ 경로로 접근, WSLg를 통한 GUI 앱 실행
    • GUI 앱은 Remote Desktop 프로토콜을 통해 스트리밍되며, DPI나 텍스트 스케일링은 별도 설정 필요
  • 파일 관리 문제
    • 리눅스 작업 데이터는 ext4.vhdx 이미지 내부에 저장되어 이식성 및 복구 위험 존재
    • wsl --unregister Distro 실행 시 모든 데이터 즉시 삭제
    • Windows 드라이브(/mnt/c) 사용 시 NTFS + VM 오버헤드로 성능 저하
  • 파일시스템 프로토콜
    • WSL1은 drvfs, WSL2는 Plan9의 9p 프로토콜 사용
    • 변환 과정에서 drvfs가 남는 버그 발생 사례 언급
  • 대안
    • 별도의 VHDX 이미지 생성 후 wsl --mount --vhd로 마운트하여 작업 데이터 분리 권장
    • .wslconfig에서 자동 설정 불가, 스크립트로 처리 필요

결론

  • Windows NT의 모듈형 설계와 안정적 커널 ABI는 오래된 드라이버 호환성을 유지
  • WSL1은 가벼운 메모리 사용이 장점이며, WSL2는 실제 리눅스 커널로 더 높은 호환성과 성능 제공
  • WSL2는 VM의 단점을 최소화하고 호스트 OS와의 통합을 강화한 구조
  • 전통적 정의로는 VM에 가깝지만, 가벼운 통합형 환경으로서 “서브시스템”이라 부를 만한 가치가 있음
▲
crawler 1일전  [-]

와 개발자 쓱이 있네

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • WSL2는 Hyper-V의 하위 집합 위에서 동작하며, 기본적으로 하이퍼바이저 위의 VM임
    하지만 일반 Hyper-V VM과는 다른 점이 있음. 예를 들어, WSL2의 Linux 배포판은 GPU 파티셔닝(즉, PCI/GPU 패스스루)과 DirectX의 특수 구현을 통해 X나 Wayland 환경에서도 GPU 가속을 사용할 수 있음
    이런 기능은 PowerShell 등을 통한 해킹으로 일반 Hyper-V에서도 가능하지만, 공식적으로는 Windows Server에서만 지원됨

    • GPU 패스스루가 기본 Windows 11에서도 되는 줄 알았는데, 자세히 보지 않았음. 그래도 꽤 인상적인 기능임. 그래픽 관련 기능에 대해 새 글을 써볼까 생각 중임
    • 결국 그건 그냥 일반 VM이지만, 자동화된 점이 좋음
      다만 “X나 Wayland가 렌더링을 담당한다”는 건 오해임. 실제로 GPU를 사용하는 건 애플리케이션 자체이고, X/Wayland는 렌더링이 끝난 후 윈도우 합성 정도만 담당함
      색상 변환 같은 복잡한 작업도 있지만 계산량은 적음
    • WSL2와 WinNT 커널이 둘 다 Hyper-V 위에서 거의 같은 수준으로 동작하는 것 아님? 물론 NT 커널은 하드웨어 접근 권한이 더 많음
    • Linux 실행을 위해 Windows Server 라이선스를 사서 설치해야 한다고 상상해보면 웃김
    • WSL2의 그래픽 통합은 기대보다 실망스러웠음. 예전 X-server 설정이 더 나았음. 하지만 X는 현대 API를 지원하지 않아 개발자들이 점점 관심을 잃고 있음. WSL2 지원이 늘어나면 개선되길 바람

  • WSL1은 pico process 기반으로, Drawbridge 연구에서 파생된 기술임
    관련 영상 The Linux Kernel Hidden Inside Windows 10과 WSL Pico Process Overview 참고
    같은 Drawbridge 기술이 SQL Server를 Linux에서 실행할 때도 사용됨
    Ars Technica 기사에 자세히 나와 있음

  • WSL2로 전환한 이유는 이해하지만, WSL1 개발을 완전히 중단한 건 아쉬움
    우리 CI 환경은 대부분 Linux 기반이지만, 일부 툴체인은 Wine에서 잘 안 돌아감(MSVC 같은 경우)
    그래서 Windows에서 Linux 빌드를 원활히 실행할 수 있는 환경이 필요했음. WSL1은 이게 가능했지만, WSL2는 프로세스 네임스페이스나 파일 디스크립터를 공유하지 않아 여러 우회 방법이 필요함
    IO 속도는 빨라졌지만, 파일 공유가 느려서 실사용에는 부적합함

    • WSL2에서도 /mnt/c를 통해 Windows 파일 접근은 가능함
    • MSVC 대신 clang-cl과 xwin을 조합해보는 것도 방법임.
      예전에 Python C 확장 모듈을 이 방식으로 빌드해본 적 있음

  • WSL2는 Windows 환경과 매우 긴밀히 통합된 VM임
    회사 정책상 Windows를 써야 해서 개발용으로 매일 사용 중인데, 대부분의 경우 꽤 쾌적함

    • 회사에서 제공한 VM으로 작업 중인데 성능이 점점 답답해짐. WSL2로 바꿔볼까 고민 중임.
      다만 RHEL8 기반이라 Debian 계열만 지원하는 게 불편함. 그래픽 앱 지원은 요즘 어떤지 궁금함
    • “긴밀한 통합”이라는데, 실제로는 ps나 top에서 VM 프로세스만 보임.
      docker run -it ubuntu로도 비슷한 기능이 가능한데, 어떤 점이 다른지 궁금함.
      개인적으로는 분리된 작업공간이 너무 불편했음

  • WSL2는 결국 가벼운 VM임. Firecracker와 비슷한 개념으로, 빠른 부팅과 낮은 메모리 사용을 목표로 함
    하지만 Docker를 여러 개 돌리면 메모리 요구량이 커짐. 최소 20GB 이상은 있어야 쾌적함

    • 다행히 요즘은 32GB 램 노트북도 예전처럼 비싸지 않음
    • WSL2 부팅이 1~2초로 매우 빠른데, 어떻게 구현했는지 궁금함. BIOS 화면을 생략하는 건 알겠지만, 그 외에도 뭔가 최적화가 있는 듯함

  • 개인적으로 WSL1이 훨씬 유용함. C++과 .NET 툴체인, ssh/scp 등 대부분의 CLI 도구가 잘 작동함
    반면 WSL2는 쓸모가 거의 없음. Linux VM이 필요하면 VMware를 씀
    VMware는 스냅샷 트리, 3D 가속, USB 장치 연결, 가상 네트워크 구성 등 기능이 풍부하고 GUI도 편리함

  • WSL 내부 VM 디스크는 \\wsl$ 경로로 접근 가능함
    오래된 소프트웨어가 UNC 경로를 지원하지 않으면 드라이브 문자로 매핑해서 해결 가능함

  • VHDX 파일이 계속 커지는 문제가 있음. 수동으로 압축(compact) 해야 함

    • sparse VHD를 활성화하면 도움이 됨. 완벽하진 않지만 systemd-trim 서비스로 일부 해결 가능함
      관련 이슈는 GitHub WSL #12103 참고
      그래도 안 되면 수동 최적화 방법을 사용할 수 있음
    • 자동 축소 기능이 있긴 하지만, 오히려 문제를 일으킬 때도 있음

  • 참고로 WSL은 기본적으로 Windows 방화벽 규칙을 우회함. 왜 Microsoft가 이렇게 설계했는지 의문임

    • 정말 그런가? WSL에서 ssh 연결이 잘 안 돼서 항상 고생했음

  • 실제 ext4 파티션을 마운트해서, 이미지 파일 기반 블록 디바이스 시뮬레이션으로 인한 성능 손실을 줄일 수 있을지 궁금함

답변달기