Ya. WSL2 menjalankan kernel Linux sungguhan yang dibangun Microsoft di dalam utility VM yang ringan. VM dikelola oleh WSL di belakang layar, jadi desainnya tidak pernah membuat pengguna memikirkan pengaturan VM atau menunggu boot. Setiap distribusi Linux berjalan sebagai kontainer terisolasi di dalam VM yang dikelola ini.

Mengapa operasi berkas di bawah /mnt/c lambat di WSL2?

Karena akses dari kernel Linux WSL2 ke sistem berkas sisi Windows melalui berbagi berkas yang menyeberangi batas OS. Operasi pada sistem berkas Linux (disk virtual ext4) cepat, jadi aturannya adalah menaruh berkas proyek di sisi OS yang sama dengan alat yang mengerjakannya.

Apakah pemakaian memori besar oleh proses vmmem adalah kebocoran?

Dalam sebagian besar kasus itu bukan kebocoran. Memori WSL2 tumbuh dan menyusut sesuai pemakaian, dan memori yang telah dilepas proses dikembalikan ke Windows di bawah pengaturan pageReporting, yang diaktifkan secara bawaan. Halaman cache berkas, juga, diklaim kembali secara otomatis oleh WSL terkini lewat autoMemoryReclaim di .wslconfig (bawaannya adalah dropCache). Di lingkungan di mana pengaturan ini dinonaktifkan, atau pada WSL yang lebih lama, memori dapat tertinggal sampai VM keluar; dalam kasus itu tetapkan batas atas dengan pengaturan memory, atau kembalikan dengan wsl --shutdown.

Bagaimana Windows Sandbox dapat mem-boot Windows lengkap dari beberapa ratus megabyte disk?

Lewat mekanisme yang disebut dynamic base image. Ia berbagi berkas OS yang tidak dapat diubah dari Windows yang sudah terinstal di host, dan menyimpan salinan bersih hanya dari sejumlah kecil berkas yang dapat diubah. Itu memungkinkannya merakit image lengkap yang dapat di-boot tanpa menyimpan salinan penuh Windows.

Apakah kontainer lebih aman daripada VM?

Tergantung mode isolasinya. Kontainer terisolasi proses berbagi kernel dengan host, dan Microsoft tidak menganggap ini batas keamanan yang kokoh. Ketika Anda menangani kode adversarial, Anda membutuhkan isolasi Hyper-V, yang memberi setiap kontainer kernel khusus sendiri.

Kedalaman virtualisasi Windows (Bagian 3) — Mesin virtual yang boot dalam hitungan detik: mengapa WSL2, Windows Sandbox, dan kontainer begitu ringan

22 Aug 2026 04:00 · Go Komura · Windows, Virtualisasi, WSL2, Windows Sandbox, Kontainer, Hyper-V

Ketika Anda membuat VM Windows di Hyper-V Manager, ia butuh puluhan detik untuk start dan memonopoli beberapa gigabyte memori. Namun di PC yang sama, mengetik wsl mengembalikan shell Linux dalam beberapa detik, dan Windows Sandbox membuka desktop sekali pakai dalam beberapa detik juga.¹

Keduanya berpijak pada Windows hypervisor yang sama (Bagian 1, “Di mana Windows Anda sebenarnya berjalan?”). Di Bagian 2 kita melihat bahwa fondasi ini dapat membuat isolasi yang lebih kuat dari kernel. Jadi mengapa yang satu berat dan yang lain ringan?

Pertanyaan yang dijawab edisi terakhir seri ini hanya satu.

VM penuh itu berat — jadi mengapa WSL2 dan Windows Sandbox begitu ringan?

Pembaca sasaran adalah pengembang dan operator yang memakai WSL2, Windows Sandbox, dan kontainer Windows untuk pengembangan dan validasi, dan ingin memahami keringanan serta kendala mereka dari mekanismenya. Prasyarat adalah Windows 10/11; menelusuri bagian Windows Sandbox mensyaratkan edisi Pro, Enterprise, atau Education (Home dan Windows Server tidak punya fitur ini). Latar belakang adalah gagasan partisi dari Bagian 1. Tingkat kesulitannya menengah.

1. Kesimpulan lebih dulu

VM ringan menjaga garis isolasi (kernel khusus dan batas hypervisor) dan meringankan “salinan OS tamu lengkap”. Sandbox berbagi Windows host sendiri; WSL2 mengganti tamu dengan Linux kecil yang dibangun khusus; dan dalam kedua kasus memori bukan reservasi tetap melainkan dipinjamkan dan dipinjam secara dinamis dengan host.

Sumber bobot VM penuh bukan isolasi sendiri melainkan duplikasi. Image OS lain di disk, halaman senilai OS lain di RAM, dan boot penuh lain setiap kali Anda start. VM ringan memotong duplikasi itu dengan dua kebijakan: “bagi apa yang aman dibagi” (Sandbox) dan “jika tidak dapat dibagi, bangun ulang secara kecil” (WSL2).

flowchart TB
    accTitle: Tiga jenis berbagi yang menopang VM ringan
    accDescr: Image OS yang dulu diduplikasi VM penuh dipotong dengan berbagi di Sandbox dan dengan mengecilkan di WSL2; memori yang alokasi tetap secara bawaan (memori dinamis adalah pengecualian) menjadi pinjam-meminjam dinamis dengan host; start diganti kernel ringan dan penyiapan minimal; hanya batas isolasi yang tetap
    heavy["VM penuh: duplikasi"] --> d1["Disk: salinan image OS"]
    heavy --> more{"Memori atau start?"}
    more --> d2["Memori: default tetap"]
    more --> d3["Start: boot penuh"]
    d1 -->|diganti oleh| s1["Bagi（Sandbox）"]
    s1 -.-> s1b["atau kecilkan（WSL2）"]
    d2 -->|diganti oleh| s2["Pinjam dinamis dari host"]
    d3 -->|diganti oleh| s3["Kernel ringan + min."]

Gambar 1: Kerangka jawaban “hypervisor yang sama, namun ringan” adalah bahwa mereka berhenti menduplikasi, bukan bahwa mereka berhenti mengisolasi.

Di bawah kita melihat WSL2, Windows Sandbox, dan kontainer dalam urutan itu, dan jenis duplikasi mana yang masing-masing potong.

2. Apa yang dibawa VM penuh

Sebagai garis dasar perbandingan, berikut yang dibawa VM tradisional.

Image OS independen. Ia menahan setiap berkas OS tamu di dalam disk virtual. Bahkan jika host punya Windows yang sama, ia tidak membaginya.
Alokasi memori kasar. Default VM tradisional adalah mengalokasikan memori host pada ukuran statis. Mekanisme seperti Hyper-V Dynamic Memory dapat menumbuhkan dan menyusutkan alokasi dalam rentang yang dikonfigurasi, tetapi sarana menyesuaikan dengan perubahan permintaan terbatas.²
Boot penuh tujuan umum. Firmware, boot loader, dan set layanan start dalam urutan yang sama seperti pada mesin fisik.

flowchart TB
    accTitle: Tiga beban yang dibawa VM penuh
    accDescr: VM penuh membawa image OS independen, alokasi memori yang statis secara bawaan, dan boot penuh tujuan umum, dan itu muncul sebagai biaya di disk, RAM, dan waktu start
    fullvm["VM penuh"] --> b1["Image OS independen"]
    fullvm --> more{"Memori atau boot?"}
    more --> b2["Default memori statis"]
    more --> b3["Boot tujuan umum"]
    b1 -.-> c1["Disk ekstra untuk salinan"]
    b2 -.-> c2["Menahan RAM yang tidak terpakai juga"]
    b3 -.-> c3["Butuh puluhan detik"]

Gambar 2: Rincian biaya VM penuh dibayar bukan untuk isolasi melainkan untuk keumuman dan duplikasi.

Ini bukan cacat; ini harga keumuman bahwa “Anda dapat menaruh apa pun di tamu”. Untuk penggunaan seperti menjalankan Linux lama di samping Windows Server, keumuman itu adalah nilainya. Tetapi untuk penggunaan seperti “saya ingin menjalankan OS yang sama (atau yang sudah ditentukan) dengan host, sekarang juga, untuk pengembangan atau validasi”, sebagian besar adalah bagasi yang terbuang. VM ringan menurunkan bagasi itu dengan mempersempit tujuan.

3. WSL2 — utility VM dengan kernel yang dibangun khusus

3.1. Struktur: VM yang dikelola dan distribusi di dalamnya

WSL2 adalah mekanisme yang menjalankan kernel Linux sungguhan di dalam utility VM yang ringan.³ Ada tiga poin.

Kernel-nya sungguhan, tetapi ia produk khusus. Itu kernel Linux yang Microsoft bangun dari cabang Stable, sudah disetel dalam ukuran dan performa untuk WSL2. Pada standar terkini, WSL yang didistribusikan Microsoft Store, kernel diperbarui bersama paket WSL sendiri dan diterapkan dengan wsl --update (pada distribusi in-box yang lebih lama ia datang lewat Windows Update).⁴ Karena kernel sungguhan, kompatibilitas system call lengkap, dan alat seperti Docker berjalan apa adanya.
VM-nya di belakang layar. Membuat, start, dan menghentikan VM dikelola oleh WSL; pengguna hanya membuka shell. Tidak ada layar pengaturan VM dan tidak ada rasa menunggu boot.⁴
Distribusi adalah kontainer di dalam VM. Distribusi seperti Ubuntu dan Debian berjalan sebagai kontainer terisolasi di dalam satu VM yang dikelola. Mereka berbagi namespace jaringan dan kernel, sementara namespace seperti PID, mount, dan user dipisahkan.³

flowchart TB
    accTitle: Arsitektur WSL2
    accDescr: Windows host dan utility VM ringan duduk berdampingan di hypervisor; kernel Linux buatan Microsoft berjalan di dalam VM; dan setiap distribusi berjalan sebagai kontainer terisolasi di dalamnya
    hv["Hypervisor"] --> host["Windows host"]
    hv --> uvm["Utility VM ringan"]
    uvm --> lk["Kernel Linux (buatan Microsoft; diperbarui dengan wsl --update)"]
    lk --> u1["Ubuntu (kontainer)"]
    lk --> u2["Debian (kontainer)"]
    host <-->|"Interop (perintah, berkas, jaringan)"| uvm

Gambar 3: Jawaban “apakah WSL2 itu VM?” adalah “ya, tetapi VM yang dikelola, di belakang layar”, dan bahkan jika Anda menginstal beberapa distribusi tetap ada satu VM.

Saat Anda mengetik wsl, sisi belakangnya tampak seperti ini.

flowchart TB
    accTitle: Dari menjalankan perintah wsl hingga shell kembali dalam beberapa detik
    accDescr: Jika utility VM tidak berjalan ketika wsl dieksekusi, VM ringan dan kernel Linux start; jika sudah berjalan mereka dipakai ulang; dan shell kembali di kontainer distribusi
    cmd["Jalankan wsl"] --> vmq{"Utility VM sudah berjalan?"}
    vmq -->|Tidak| bootvm["Start VM ringan dan kernel Linux (beberapa detik)"]
    vmq -->|Ya| reuse["Pakai ulang VM yang sudah berjalan"]
    bootvm --> shell["Shell kembali di dalam kontainer"]
    reuse --> shell

Gambar 4: Tungguannya hanya start VM minimal, dan di sinilah menurunkan bagasi boot penuh terlihat.

3.2. I/O berkas: di sisi mana Anda menaruhnya membuatnya menjadi hal yang berbeda

Topik yang selalu muncul dalam pembicaraan performa WSL2 adalah di mana Anda menaruh berkas.

Operasi pada berkas di sisi Linux (disk virtual ext4) cepat. Itu karena kernel Linux berbicara langsung dengan sistem berkasnya sendiri, dan percepatan hingga 20x versus WSL1 untuk ekstraksi tarball, serta 2–5x untuk git clone dan npm install, telah dilaporkan.⁴
Operasi pada berkas di sisi Windows (/mnt/c dan sejenisnya) menjadi lambat karena melalui berbagi berkas yang menyeberangi batas OS. Performa sistem berkas lintas-OS adalah satu butir besar di mana WSL2 lebih buruk daripada WSL1.⁴

Jadi aturannya: “taruh berkas proyek di sisi OS yang sama dengan alat yang mengoperasikannya”.⁴ Repositori yang Anda tangani dengan alat build Linux masuk ke sisi Linux; solusi yang Anda bangun di Visual Studio masuk ke sisi Windows.

flowchart TB
    accTitle: Percabangan jalur I/O berkas WSL2
    accDescr: Akses ke disk virtual ext4 sisi Linux langsung dari kernel Linux dan karena itu cepat; akses ke berkas sisi Windows melalui berbagi berkas yang menyeberangi batas OS dan karena itu lambat
    io["Operasi berkas di dalam WSL2"] --> place{"Di sisi mana berkasnya?"}
    place -->|"Sisi Linux (home, dll.)"| ext4["I/O langsung ke disk virtual ext4"]
    place -->|"Sisi Windows (/mnt/c, dll.)"| p9["Lewat berbagi yang menyeberangi batas OS"]
    ext4 --> fast["Cepat (contoh hingga 20x vs. WSL1)"]
    p9 --> slow["Cenderung lambat"]
    slow -.-> fix["Perbaikan: taruh berkas di OS yang memakainya"]

Gambar 5: Yang lambat adalah jalurnya, bukan WSL2, jadi mengubah di mana Anda menaruh berkas sering membuat masalah performa hilang.

3.3. Memori: ia tumbuh, ia menyusut, tetapi tidak selalu mengembalikan semuanya

Pemakaian memori WSL2 (Anda melihatnya sebagai proses vmmem di Task Manager) bukan reservasi tetap; ia tumbuh dan menyusut sesuai pemakaian. Memori yang telah dilepas proses dikembalikan secara otomatis ke Windows di bawah pengaturan pageReporting, yang diaktifkan secara bawaan.⁵ Halaman yang ditahan sebagai cache berkas dulu tidak kembali ke Windows sampai VM keluar.⁴ Di WSL terkini, pengaturan eksperimental .wslconfig autoMemoryReclaim (bawaannya adalah dropCache) juga mengklaim kembali cache secara otomatis.⁵ Di lingkungan di mana pengaturan ini disabled, atau pada WSL yang lebih lama, cache sesi panjang dapat tertinggal sampai VM keluar dan dapat menekan memori host.

flowchart TB
    accTitle: Bagaimana memori WSL2 tumbuh, menyusut, dan dikembalikan
    accDescr: Pertumbuhan permintaan di dalam WSL2 menaikkan pemakaian memori VM; halaman yang dilepas proses dikembalikan ke Windows di bawah pageReporting, yang diaktifkan secara bawaan; cache berkas diklaim kembali secara otomatis oleh autoMemoryReclaim secara bawaan; tetapi pada pengaturan yang dinonaktifkan atau WSL yang lebih lama ia tertinggal sampai VM keluar, dan wsl --shutdown mengembalikan semuanya
    grow["Permintaan memori tumbuh di dalam WSL2"] --> vm["Pemakaian vmmem tumbuh"]
    vm --> freed{"Halaman itu sudah dilepas?"}
    freed -->|"Dilepas proses (ketika pageReporting nyala)"| ret["Dikembalikan otomatis ke Windows"]
    freed -->|Ditahan sebagai cache berkas| amr["autoMemoryReclaim mengklaimnya kembali otomatis (bawaan)"]
    amr -.-> old2["Pada pengaturan yang dinonaktifkan atau WSL lama, tertinggal sampai VM keluar"]
    old2 --> sd["wsl --shutdown mengembalikan semuanya"]

Gambar 6: Yang tampak seperti “ia hanya terus tumbuh” utamanya adalah cache (dan, ketika pageReporting mati, halaman yang dilepas proses juga), jadi kenali jalur pengembalian sebelum Anda memutuskan itu kebocoran.

Jika Anda ingin batas atas yang eksplisit, %UserProfile%\.wslconfig dapat mengendalikan memori keseluruhan VM, jumlah CPU, dan swap.⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

Setelah mengubah pengaturan, restart VM dengan wsl --shutdown agar berlaku. Alokasi dinamis ini — “batas atas adalah pengaturan, pemakaian aktual mengikuti permintaan” — dibawa lebih jauh di topik berikutnya, Windows Sandbox.

4. Windows Sandbox — memakai ulang Windows host

4.1. Dynamic base image: Windows lengkap dalam 500 MB

Windows Sandbox adalah desktop Windows sekali pakai yang diisolasi oleh hypervisor. Tutup dan semuanya hilang; berikutnya, ia start dalam beberapa detik dari keadaan bersih.¹

Teka-teki pertama adalah disk. Ia dapat mem-boot Windows lengkap, namun image dasar Sandbox hanya sekitar 500 MB setelah instalasi, dan 30 MB terkompresi saat distribusi.² Rahasianya adalah dynamic base image.

Sebagian besar berkas OS tidak dapat diubah, jadi salinan host dapat dibagi apa adanya.
Sejumlah kecil berkas yang dapat diubah tidak dapat dibagi, jadi salinan bersihnya disimpan di dalam image dasar.
Saat start, berkas host yang tidak dapat diubah plus salinan lokal berkas yang dapat diubah digabung untuk merakit image Windows lengkap.²

Dengan kata lain, Sandbox tidak mengunduh maupun menyimpan salinan Windows; ia memakai ulang Windows yang sudah terinstal di host untuk start.

flowchart TB
    accTitle: Bagaimana dynamic base image dirakit
    accDescr: Berkas OS yang tidak dapat diubah dari Windows host dibagi; hanya berkas yang dapat diubah yang ditahan sebagai salinan bersih di image dasar; dan keduanya digabung untuk merakit image Windows lengkap Sandbox
    hostw["Windows lengkap host"] --> imm["Berkas OS yang tidak dapat diubah (mayoritas)"]
    hostw --> mut["Berkas OS yang dapat diubah (minoritas)"]
    imm -->|Dibagi apa adanya| img["Image boot Sandbox"]
    mut -->|Simpan salinan bersih| img
    img --> boot["Boot sebagai Windows lengkap"]
    img -.-> size["Hanya sekitar 500 MB yang perlu disimpan"]

Gambar 7: Bentuk menyerahkan duplikasi disk bukan “miliki Windows lain” melainkan “rakit dari Windows host”.

Komposisi itu yang membuat siklus hidup berikut mungkin. Yang dibuang adalah state lokal di dalam Sandbox. Jika Anda telah memetakan folder yang dapat ditulis dari host di berkas konfigurasi .wsb, perubahan di sana tetap di host.⁶

flowchart TB
    accTitle: Siklus hidup Windows Sandbox
    accDescr: Start menyiapkan Windows bersih dalam beberapa detik; setelah validasi aplikasi atau eksperimen Anda menutupnya dan semua state di dalam Sandbox dibuang sehingga berikutnya juga start bersih; tetapi perubahan pada folder host yang dipetakan sebagai dapat ditulis tetap
    launch["Start (beberapa detik)"] --> clean["Windows bersih"]
    clean --> work["Validasi aplikasi atau eksperimen"]
    work --> close2["Tutup"]
    close2 --> discard["Buang semua state di dalam Sandbox"]
    discard -.-> mapped["Perubahan di folder yang dipetakan sebagai dapat ditulis tetap di host"]
    discard -->|Start berikutnya| launch

Gambar 8: Dapat kembali ke bersih setiap kali adalah karena bagian yang dapat diubah adalah salinan sekali pakai, dan membuangnya adalah bagian dari desain.

4.2. Direct map: ntdll.dll yang sama adalah halaman fisik yang sama

Bukan hanya disk tetapi RAM juga dibagi. Karena Sandbox menjalankan image OS yang sama dengan host, teknik yang disebut “direct map” dipakai agar, untuk biner OS, ia memakai halaman memori fisik yang sama dengan host. Ketika ntdll.dll dimuat ke memori di dalam Sandbox, ia menunjuk ke halaman fisik yang sama dengan biner yang sama yang sudah dimuat di host. Tanpa memaparkan rahasia host pada bahaya, ia mencapai jejak memori yang jauh lebih kecil daripada VM tradisional.²

“Bagi halaman fisik yang sama di antara beberapa pengguna” — itu gagasan yang sama dengan berbagi DLL lewat objek section, yang kita ikuti di Bagian 3 seri memori (“Objek section dan copy-on-write”). Mekanisme itu adalah berbagi antar proses; Sandbox melakukannya menyeberangi batas VM.

flowchart TB
    accTitle: Berbagi halaman fisik lewat direct map
    accDescr: Aplikasi di host dan aplikasi di dalam Sandbox berbagi halaman memori fisik yang sama untuk biner OS seperti ntdll, mengurangi pemakaian memori
    happ["Aplikasi di host"] --> hva["Alamat virtual sisi host"]
    sapp["Aplikasi di dalam Sandbox"] --> sva["Alamat virtual sisi Sandbox"]
    hva --> phys["Halaman fisik yang sama (biner OS seperti ntdll.dll)"]
    sva --> phys
    phys -.-> save["Tidak perlu menduplikasi RAM senilai OS"]

Gambar 9: Direct map adalah gagasan berbagi halaman yang telah dipakai antar proses, diterapkan menyeberangi batas VM.

4.3. Meminjamkan dan meminjam memori: lebih seperti proses daripada VM

Terhadap alokasi memori statis VM tradisional, teknologi kontainer yang diduduki Sandbox memutuskan alokasi sumber daya secara dinamis dalam kerja sama dengan host. Jika host kehabisan memori, ia dapat mengklaim kembali memori dari kontainer dengan cara yang sama ia mengklaimnya dari proses biasa.² Hyper-V Dynamic Memory juga menumbuhkan dan menyusutkan alokasi VM dalam rentang yang dikonfigurasi, tetapi Sandbox melangkah lebih jauh: perbedaannya adalah ia meminjamkan dan meminjam di lapangan yang sama dengan manajemen memori host.

flowchart TB
    accTitle: Kerja sama memori antara host dan Sandbox
    accDescr: Default VM tradisional adalah alokasi eksklusif berukuran statis dengan sarana penyesuaian terbatas; Sandbox menjadi sasaran klaim kembali sebagai respons terhadap tekanan memori host dan meminjamkan serta meminjam memori di lapangan yang sama dengan proses biasa
    pressure["Tekanan memori host naik"] --> from{"Dari mana kita klaim kembali?"}
    from --> proc["Working Set proses biasa"]
    from --> sbx["Pemakaian Sandbox (kontainer)"]
    proc --> relief["Memori bebas diamankan"]
    sbx --> relief
    relief -.-> contrast["VM tradisional punya sarana penyesuaian terbatas"]

Gambar 10: Dalam pinjam-meminjam memori, Sandbox berdiri di sisi proses daripada sisi VM, dan menawarkan memori ketika host dalam kesulitan.

Di Bagian 1 kita katakan “performa VM juga bergantung pada sisi host”, tetapi dengan VM ringan kita mengambil satu langkah lagi: alokasi memori sendiri adalah pekerjaan bersama dengan host. Alasan Sandbox dapat dipakai dengan rasa “aplikasi lain” daripada “produk virtualisasi yang berat” adalah kerja sama ini.

Prosedur konkret memakai Sandbox untuk memvalidasi aplikasi bisnis dibahas di “Cara mempercepat validasi aplikasi dengan Windows Sandbox” sebelumnya. Artikel ini adalah mekanisme di bawahnya.

5. Kontainer — di mana Anda menarik garis isolasi

5.1. Isolasi proses dan isolasi Hyper-V

Kontainer Windows punya dua mode isolasi saat berjalan. Image-nya dibagi; Anda memilih dengan flag saat start.⁷

Isolasi proses: beberapa kontainer berbagi kernel dengan host dan mengisolasi lewat virtualisasi per-namespace sistem berkas, registri, port jaringan, ruang ID proses, namespace Object Manager, dan sebagainya. Ini pada dasarnya pendekatan yang sama dengan kontainer Linux.
Isolasi Hyper-V: setiap kontainer berjalan di dalam VM yang sangat dioptimalkan dan punya yang pada dasarnya adalah kernel khusus. Kehadiran VM menaruh isolasi tingkat perangkat keras antara kontainer dan host.⁷

Isolasi lewat namespace dapat digambarkan sebagai versi yang menyeluruh dari teknik yang kita lihat di artikel virtualisasi registri (“Pengalihan dan virtualisasi registri di Windows”) — “tunjukkan realitas yang berbeda di bawah API yang sama”.

flowchart TB
    accTitle: Isolasi proses versus isolasi Hyper-V
    accDescr: Di bawah isolasi proses, kontainer berbagi kernel dengan host dan mengisolasi lewat namespace; di bawah isolasi Hyper-V, setiap kontainer punya kernel khusus di dalam VM yang dioptimalkan
    subgraph pi ["Isolasi proses"]
        c1["Kontainer A"] --> sk1["Kernel bersama dengan host"]
        c2["Kontainer B"] --> sk1
    end
    subgraph hi ["Isolasi Hyper-V"]
        c3["Kontainer C"] --> k3["Kernel khusus (di dalam VM yang dioptimalkan)"]
        c4["Kontainer D"] --> k4["Kernel khusus (di dalam VM yang dioptimalkan)"]
    end
    sk1 ~~~ c3

Gambar 11: Bahkan dengan image kontainer yang sama, apakah Anda menarik garis isolasi di atas kernel atau membelah kernel sendiri adalah pilihan yang Anda buat saat start.

5.2. Yang mana yang dapat Anda sebut “batas keamanan”

Perbedaan antara dua mode ini bukan hanya cerita performa. Microsoft tidak menganggap kontainer terisolasi proses sebagai batas keamanan yang kokoh. Kontainer yang dipelihara (dengan respons kerentanan) sebagai batas keamanan adalah kontainer terisolasi hypervisor, dan isolasi Hyper-V-lah yang harus Anda pilih dalam skenario multi-tenant adversarial.⁸

VBS yang kita lihat di Bagian 2 juga desain yang mengasumsikan “kernel dapat ditembus” dan mundur ke batas hypervisor. Kriteria yang sama berlaku di dunia kontainer. Garis yang mengurung kode yang tidak tepercaya ditarik di batas hypervisor, bukan di dalam kernel bersama.

flowchart TB
    accTitle: Cara memilih isolasi dari seberapa Anda memercayai kode
    accDescr: Jika beban kerja tepercaya, ambil kepadatan dan performa dengan isolasi proses; jika kode tidak tepercaya atau milik orang lain, pilih batas hypervisor seperti kontainer terisolasi Hyper-V, Windows Sandbox yang dikeraskan dengan jaringan dinonaktifkan, atau VM terisolasi
    trust{"Dapatkah Anda memercayai kode itu?"} -->|Ya| dens["Isolasi proses (utamakan kepadatan dan kecepatan)"]
    trust -->|Tidak / kode orang lain| bound["Pilih batas hypervisor"]
    bound --> opt1["Kontainer terisolasi Hyper-V"]
    bound --> opt2["Sandbox yang dikeraskan atau VM terisolasi"]

Gambar 12: Mode isolasi adalah cerita keamanan sebelum cerita performa, dan kepercayaan memutuskan di mana Anda menarik garis.

Omong-omong, menjalankan kontainer terisolasi Hyper-V di dalam VM Hyper-V membuat hypervisor dua lapisan dalam — virtualisasi bersarang. Satu tingkat bersarang didukung dalam produksi pada lingkungan yang memenuhi syarat (prosesor Intel dengan host Windows 10 / Windows Server 2016 atau lebih baru, atau prosesor AMD dengan host Windows 11 / Windows Server 2022 atau lebih baru, dan versi konfigurasi VM yang sesuai di masing-masing), dan prasyarat lebih lanjut adalah pengaturan yang memaparkan ekstensi virtualisasi ke VM luar (ExposeVirtualizationExtensions pada Set-VMProcessor di Hyper-V). Menjalankan WSL2 di dalam VM didukung dengan cara yang sama.⁹ Apakah Anda dapat memakai WSL2 atau Docker di VM pengembangan di cloud juga diputuskan oleh apakah ukuran dan konfigurasi VM itu memaparkan virtualisasi bersarang.

flowchart TB
    accTitle: Struktur virtualisasi bersarang
    accDescr: VM cloud duduk di hypervisor host fisik, dan di dalamnya hypervisor lain (bersarang yang didukung adalah satu tingkat) berjalan untuk menopang WSL2 dan kontainer terisolasi Hyper-V
    phys3["Hypervisor host fisik"] --> cvm["VM cloud (mesin pengembang)"]
    cvm --> nhv["Hypervisor di dalam VM (tingkat bersarang 1)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Kontainer terisolasi Hyper-V"]
    nhv -.-> limit["Bersarang yang didukung adalah satu tingkat"]

Gambar 13: Alasan wsl berjalan di dalam VM cloud adalah bahwa virtualisasi bersarang didukung secara resmi hanya untuk satu tingkat.

5.3. Spektrum isolasi dan keringanan

Menjajarkan pemeran sejauh ini pada satu sumbu, tampak seperti ini.

flowchart TB
    accTitle: Spektrum kekuatan isolasi dan keringanan
    accDescr: Kontainer terisolasi proses paling ringan tetapi berbagi kernel; WSL2, Sandbox, dan kontainer terisolasi Hyper-V adalah VM ringan dengan kernel khusus (Sandbox meringankan dengan berbagi, WSL2 dengan kernel yang dibangun khusus); VM penuh paling berat tetapi tujuan umum
    ax["Ringan ← → Berat"] ~~~ p1
    p1["Kontainer terisolasi proses (kernel bersama)"] --> p2["WSL2, Sandbox, isolasi Hyper-V (VM ringan dengan kernel khusus)"]
    p2 --> p3["VM penuh (menjalankan apa pun; menahan salinan lengkap)"]
    p1 -.-> n1["Batas: namespace"]
    p2 -.-> n2["Batas: hypervisor"]
    p3 -.-> n3["Batas: hypervisor + independensi lengkap"]

Gambar 14: Kelompok VM ringan adalah solusi tengah yang menjaga batas hypervisor dan memotong duplikasi; cara mereka memotongnya terbelah menjadi berbagi untuk Sandbox dan kernel yang dibangun khusus untuk WSL2.

6. Lihat sendiri

Keringanan dan berbagi adalah hal yang dapat Anda amati di mesin di depan Anda.

Waktu start serta naik-turunnya memori (WSL2). Dengan Task Manager terbuka, coba berikut.

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

Jika Anda melakukan build besar atau operasi berkas di dalam WSL2, vmmem tumbuh, dan Anda dapat mengamatinya dikembalikan sekaligus dengan wsl --shutdown.

Perbedaan kecepatan dari di mana Anda menaruh berkas (WSL2). Taruh repositori yang sama di sisi Linux (~/repo) dan di sisi Windows (/mnt/c/repo) dan bandingkan waktu untuk git status atau ekstraksi, dan perbedaan dari Bagian 3.2 muncul dalam angka.

Latar belakang untuk direct map (Sandbox). Start Sandbox dan lihat pertambahan memori di Task Manager di host. Bahwa pertambahannya tetap jauh lebih kecil dari yang “Windows lain” akan membuat Anda bayangkan adalah efek berbagi yang bercerita. Untuk menggali lebih jauh rincian memori sisi host, artikel tentang alat Sysinternals yang membahas cara memakai RAMMap dan VMMap (“Process Explorer / Handle / VMMap dalam praktik”) berguna. Ini, namun, adalah alat untuk melihat klasifikasi proses sisi host dan memori fisik; mereka tidak mengamati langsung berbagi dengan tamu sendiri.

Mode isolasi kontainer (Docker / kontainer Windows). Jika Anda punya lingkungan kontainer Windows, start image yang sama dengan docker run --isolation=process dan --isolation=hyperv dan bandingkan waktu start serta tampilannya di Task Manager (di bawah isolasi proses, proses di dalam kontainer muncul di daftar proses host), dan Anda dapat merasakan di mana garis isolasi duduk.⁷ Isolasi proses, namun, mengandaikan bahwa versi host dan image cocok, dan di OS klien ia terbatas pada pemakaian pengembangan dan uji. Isolasi Hyper-V mengizinkan set kombinasi yang lebih luas, jadi lakukan perbandingan pada pasangan yang kompatibel.¹⁰

7. Tiga salah baca yang harus dihindari dalam praktik

7.1. “WSL2 lambat”

Yang lambat bukan WSL2 melainkan jalur I/O berkas yang menyeberangi batas OS. Ada banyak kasus di mana sekadar memindahkan proyek ke sisi Linux membuat rasanya menjadi hal yang berbeda.⁴ Sebaliknya, menaruh berkas yang akan disentuh alat Windows di sisi Linux sama-sama tidak menguntungkan karena alasan yang sama. Nilai dengan “taruh di OS yang sama dengan sisi yang memakainya”.

7.2. “vmmem yang tumbuh besar adalah kebocoran memori”

Memori WSL2 tumbuh dan menyusut sesuai permintaan, dan bagian yang dilepas dikembalikan. Di WSL terkini, cache berkas juga diklaim kembali secara otomatis oleh autoMemoryReclaim (bawaannya adalah dropCache), jadi “ia tetap besar” sering terselesaikan seiring waktu.⁵ Jika masih tertinggal, konfirmasikan bahwa autoMemoryReclaim belum diatur ke disabled dan bahwa pageReporting, yang bertanggung jawab mengembalikan bagian yang dilepas, belum dimatikan (atau bahwa Anda tidak berada di WSL yang lebih lama), lalu buat batas atas eksplisit dengan memory di .wslconfig atau kembalikan semuanya dengan wsl --shutdown pada batas sesi. Cara berpikir tentang membedakan kebocoran dari bukan-kebocoran sama dengan di edisi pengantar seri memori, “Apa arti “pemakaian memori” Windows sebenarnya?”.

7.3. “Ada di kontainer, jadi aman”

Kontainer terisolasi proses berbagi kernel, dan menurut kriteria Microsoft ia bukan batas keamanan.⁸ Untuk menjalankan kode yang tidak tepercaya atau spesimen, pilih isolasi yang punya batas hypervisor, seperti kontainer terisolasi Hyper-V, Windows Sandbox, atau VM khusus. Batas hypervisor, namun, bukan pengecualian menyeluruh. Pengaturan bawaan Windows Sandbox punya konektivitas jaringan diaktifkan, dan dapat memaparkan aplikasi yang tidak tepercaya ke jaringan internal.¹ Jika Anda memakainya untuk menjalankan spesimen, perkuat isolasi dengan menonaktifkan pengalihan jaringan dan papan klip di berkas konfigurasi .wsb, atau pakai VM khusus di jaringan terisolasi.

8. Ringkasan — menutup seri

Poin Bagian 3.

Keringanan VM ringan adalah hasil “berhenti menduplikasi”, bukan “melemahkan isolasi”.
WSL2 menjalankan kernel Linux sungguhan di utility VM ringan yang dikelola, dan distribusi diisolasi sebagai kontainer di dalam VM itu.³ Aturan performa adalah menaruh berkas di OS yang memakainya, dan memori tumbuh serta menyusut secara dinamis, dengan batas atas yang dapat dikendalikan di .wslconfig.⁴⁵
Windows Sandbox berbagi berkas OS host yang tidak dapat diubah lewat dynamic base image dan juga berbagi halaman fisik biner OS sasaran lewat direct map, jadi ia tidak menahan salinan Windows lengkap.² Anda tetap membutuhkan sekitar 500 MB untuk berkas yang dapat diubah, plus memori aplikasi yang Anda jalankan di dalamnya.
Mode isolasi kontainer dipilih saat start, dan sisi yang dapat Anda sebut batas keamanan adalah isolasi Hyper-V.⁷⁸

Dan jika kita menaruh seluruh seri di satu halaman, tampak seperti ini.

Bagian 1: Ada lapisan hypervisor di bawah Windows, dan OS host sendiri berjalan sebagai root partition. Arbitrase CPU dan memori (SLAT) dilakukan langsung oleh lapisan ini, dan I/O perangkat sintetis ditengahi root partition (VSP) di seberang VMBus.
Bagian 2: Lapisan itu dipakai bukan hanya untuk mengisolasi VM satu sama lain tetapi juga untuk menarik batas yang lebih kuat dari kernel (VTL) di dalam OS yang sama. Keamanan bawaan Windows 11 dibangun di atas ini.
Bagian 3: Di lapisan yang sama, memotong duplikasi-lah yang membuat “mesin virtual yang start dalam hitungan detik” mungkin. Garis isolasi dijaga, dan ia telah menjadi alat sehari-hari.

flowchart TB
    accTitle: Satu gambar seluruh seri
    accDescr: Hypervisor langsung di perangkat keras adalah Bagian 1; pemisahan VTL0 dan VTL1 di dalam Windows host adalah Bagian 2; keringanan WSL2, Sandbox, dan isolasi Hyper-V di lapisan yang sama adalah Bagian 3; kontainer terisolasi proses berbagi kernel host; Sandbox meringankan dengan berbagi, WSL2 dengan kernel yang dibangun khusus
    hw3["Perangkat keras"] --> hv3["Hypervisor (Bagian 1)"]
    hv3 --> rp3["Windows host (VTL = Bagian 2)"]
    hv3 --> lw3["WSL2, Sandbox, isolasi Hyper-V (Bagian 3)"]
    rp3 --> pc3["Kontainer process-isolation"]
    lw3 -.-> mech3["Sandbox berbagi; WSL2 kernel khusus"]

Gambar 15: Tumpuk tiga edisi dan Anda punya gambaran keseluruhan tanah di bawah Windows terkini.

Virtualisasi bukan lagi teknologi ruang server, maupun teknologi hanya untuk orang yang mendirikan VM. Di tanah di bawah Windows Anda, ia diam-diam menopang baik keamanan maupun pengalaman pengembangan — di situlah kita berada sekarang.

Area konsultasi terkait

KomuraSoft LLC menangani penyiapan lingkungan pengembangan yang memakai WSL2 dan kontainer, merancang lingkungan validasi aplikasi Windows, dan menyelidiki performa serta kompatibilitas di lingkungan tervirtualisasi.

Tautan referensi

Microsoft Learn, Windows Sandbox. Tentang Windows Sandbox yang start dalam beberapa detik sebagai VM sekali pakai dan membuang semuanya ketika ditutup; tentang menjalankan kernel terpisah dengan Microsoft hypervisor untuk mengisolasinya dari host; dan tentang konektivitas jaringan yang diaktifkan secara bawaan dan dapat dinonaktifkan di berkas konfigurasi. ↩ ↩² ↩³
Microsoft Learn, Windows Sandbox architecture. Tentang dynamic base image yang merakit image Windows lengkap dari berbagi berkas OS host yang tidak dapat diubah plus salinan bersih berkas yang dapat diubah (sekitar 500 MB setelah instalasi); tentang kontainer yang mengalokasikan secara dinamis dalam kerja sama dengan host, terhadap alokasi memori statis VM tradisional, sehingga host dapat mengklaim kembali memori; dan tentang direct map yang membuat biner OS seperti ntdll.dll memakai halaman fisik yang sama dengan host. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, What is the Windows Subsystem for Linux?. Tentang WSL2 yang menjalankan kernel Linux di dalam utility VM yang ringan; tentang setiap distribusi yang berjalan sebagai kontainer terisolasi, berbagi namespace jaringan dan kernel sambil memisahkan namespace seperti PID, mount, dan user. ↩ ↩² ↩³
Microsoft Learn, Comparing WSL Versions. Tentang kernel WSL2 yang dibangun Microsoft dari cabang Stable; tentang WSL yang didistribusikan Store yang menerima pembaruan sebagai paket terlepas dari image OS dan menerapkannya dengan wsl --update (pada distribusi in-box yang lebih lama, lewat Windows Update); tentang contoh performa seperti hingga 20x untuk ekstraksi tarball; tentang WSL1 yang lebih cepat untuk performa sistem berkas lintas-OS, jadi berkas harus ditaruh di OS yang memakainya; dan tentang memori yang tumbuh serta menyusut dengan bagian yang dilepas dikembalikan, sementara cache mungkin tidak kembali sampai VM keluar. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Advanced settings configuration in WSL. Tentang dapat mengatur plafon memori keseluruhan VM WSL2, jumlah prosesor, swap, dan pageReporting (diaktifkan secara bawaan; bertanggung jawab mendeteksi dan mengembalikan memori yang tidak terpakai) di bagian [wsl2] .wslconfig; dan tentang pengaturan eksperimental autoMemoryReclaim yang secara bawaan dropCache, sehingga memori cache diklaim kembali secara otomatis. ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Use and configure Windows Sandbox. Tentang MappedFolders di berkas konfigurasi .wsb yang dapat membagi folder host sebagai hanya-baca atau dapat ditulis. ↩
Microsoft Learn, Isolation Modes. Tentang isolasi proses kontainer Windows yang berbagi kernel dengan host dan mengisolasi lewat namespace; tentang isolasi Hyper-V yang punya yang pada dasarnya adalah kernel khusus di dalam VM yang dioptimalkan; dan tentang image yang sama yang dapat dijalankan di salah satu mode lewat flag saat start. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Secure Windows containers. Tentang hanya kontainer terisolasi hypervisor yang diperlakukan sebagai batas keamanan; tentang kontainer terisolasi proses yang tidak dianggap batas keamanan yang kokoh; dan tentang isolasi hypervisor yang harus Anda pilih dalam skenario multi-tenant adversarial. ↩ ↩² ↩³
Microsoft Learn, What is Nested Virtualization?. Tentang menjalankan kontainer terisolasi Hyper-V di dalam VM Hyper-V (satu tingkat bersarang) yang didukung dalam produksi; tentang syaratnya prosesor Intel dengan Windows Server 2016 / Windows 10 atau lebih baru, atau prosesor AMD dengan Windows Server 2022 / Windows 11 atau lebih baru, plus versi konfigurasi VM yang sesuai di masing-masing; tentang memaparkan ekstensi virtualisasi ke VM luar (ExposeVirtualizationExtensions) sebagai prasyarat; dan tentang menjalankan WSL2 di dalam VM Hyper-V yang didukung. ↩
Microsoft Learn, Windows container version compatibility. Tentang isolasi proses yang mengandaikan versi host dan image kontainer cocok; tentang isolasi Hyper-V yang dapat menjalankan image versi OS berbeda dari host; dan tentang isolasi proses di OS klien yang terbatas pada pemakaian pengembangan dan uji. ↩

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Kedalaman virtualisasi Windows (Bagian 1) — Di mana Windows Anda sebenarnya berjalan? Hypervisor dan partisi

Ketika Anda mengaktifkan Hyper-V, Windows host sendiri berjalan di atas hypervisor sebagai root partition. Artikel ini menjelaskan fondas...

Baca artikel

Kedalaman virtualisasi Windows (Bagian 2) — Memori yang bahkan kernel pun tidak bisa lihat: cara kerja VBS, HVCI, dan Credential Guard

Pada instalasi bersih ke perangkat keras yang kompatibel, VBS diaktifkan secara bawaan dan memakai hypervisor serta SLAT untuk membuat is...

Baca artikel

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Topik teknis Windows

Portal tentang pengembangan Windows, investigasi bug, dan pemanfaatan aset yang ada.

Lihat topik

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pengembangan aplikasi Windows

Aplikasi bisnis, integrasi perangkat, dan alat komunikasi, dari kebutuhan hingga pengembangan.

Lihat layanan Hubungi kami

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apakah WSL2 itu VM?: Ya. WSL2 menjalankan kernel Linux sungguhan yang dibangun Microsoft di dalam utility VM yang ringan. VM dikelola oleh WSL di belakang layar, jadi desainnya tidak pernah membuat pengguna memikirkan pengaturan VM atau menunggu boot. Setiap distribusi Linux berjalan sebagai kontainer terisolasi di dalam VM yang dikelola ini.
Mengapa operasi berkas di bawah /mnt/c lambat di WSL2?: Karena akses dari kernel Linux WSL2 ke sistem berkas sisi Windows melalui berbagi berkas yang menyeberangi batas OS. Operasi pada sistem berkas Linux (disk virtual ext4) cepat, jadi aturannya adalah menaruh berkas proyek di sisi OS yang sama dengan alat yang mengerjakannya.
Apakah pemakaian memori besar oleh proses vmmem adalah kebocoran?: Dalam sebagian besar kasus itu bukan kebocoran. Memori WSL2 tumbuh dan menyusut sesuai pemakaian, dan memori yang telah dilepas proses dikembalikan ke Windows di bawah pengaturan pageReporting, yang diaktifkan secara bawaan. Halaman cache berkas, juga, diklaim kembali secara otomatis oleh WSL terkini lewat autoMemoryReclaim di .wslconfig (bawaannya adalah dropCache). Di lingkungan di mana pengaturan ini dinonaktifkan, atau pada WSL yang lebih lama, memori dapat tertinggal sampai VM keluar; dalam kasus itu tetapkan batas atas dengan pengaturan memory, atau kembalikan dengan wsl --shutdown.
Bagaimana Windows Sandbox dapat mem-boot Windows lengkap dari beberapa ratus megabyte disk?: Lewat mekanisme yang disebut dynamic base image. Ia berbagi berkas OS yang tidak dapat diubah dari Windows yang sudah terinstal di host, dan menyimpan salinan bersih hanya dari sejumlah kecil berkas yang dapat diubah. Itu memungkinkannya merakit image lengkap yang dapat di-boot tanpa menyimpan salinan penuh Windows.
Apakah kontainer lebih aman daripada VM?: Tergantung mode isolasinya. Kontainer terisolasi proses berbagi kernel dengan host, dan Microsoft tidak menganggap ini batas keamanan yang kokoh. Ketika Anda menangani kode adversarial, Anda membutuhkan isolasi Hyper-V, yang memberi setiap kontainer kernel khusus sendiri.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.

Lihat profil Hubungi kami

Tautan publik

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Kembali ke blog