Kedalaman virtualisasi Windows (Bagian 3) — VM yang siap dalam hitungan detik: apa yang membuat WSL2, Windows Sandbox, dan kontainer terasa ringan

Jika membuat VM Windows di Hyper-V Manager, boot memakan puluhan detik dan beberapa gigabyte memori dipakai secara eksklusif. Padahal di PC yang sama, mengetik wsl mengembalikan shell Linux dalam beberapa detik, dan Windows Sandbox pun membuka desktop sekali pakai dalam hitungan detik.¹

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

Pertanyaan yang dijawab edisi terakhir seri ini hanya satu.

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

Pembaca sasaran adalah pengembang dan operator yang memakai WSL2, Windows Sandbox, dan kontainer Windows untuk pengembangan serta validasi, dan ingin memahami keringanan serta kendalanya dari mekanismenya. Lingkungan prasyarat adalah Windows 10/11; mengikuti bagian Windows Sandbox membutuhkan edisi Pro, Enterprise, atau Education (Home dan Windows Server tidak punya fitur ini). Pengetahuan prasyarat adalah konsep partisi dari Bagian 1. Tingkat kesulitannya menengah.

1. Kesimpulan di muka

VM ringan menjaga garis isolasi (kernel khusus dan batas hypervisor) sambil meringankan “salinan OS tamu secara utuh”. Sandbox berbagi Windows host itu sendiri; WSL2 mengganti tamu dengan Linux kecil yang disesuaikan untuk tujuan itu; dan pada keduanya memori bukan reservasi tetap, melainkan dialokasikan dan dilepas secara dinamis bersama host.

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

flowchart TB
    accTitle: Tiga jenis berbagi yang menopang VM ringan
    accDescr: Image OS yang diduplikasi VM penuh dipotong dengan berbagi di Sandbox dan dengan mengecilkan di WSL2; memori yang alokasi tetap secara bawaan (konfigurasi memori dinamis adalah pengecualian) menjadi alokasi dan pelepasan dinamis bersama host; start diganti kernel ringan dan konfigurasi minimal; hanya batas isolasi yang tetap
    heavy["Sumber bobot VM penuh adalah duplikasi"] --> d1["Disk: salinan image OS"]
    heavy --> d2["Memori: alokasi tetap secara bawaan"]
    heavy --> d3["Start: mengulang boot penuh"]
    d1 -->|diganti| s1["Berbagi (Sandbox) atau pengecilan (WSL2)"]
    d2 -->|diganti| s2["Pinjam-meminjam dinamis dengan host"]
    d3 -->|diganti| s3["Dipersingkat dengan kernel ringan dan konfigurasi minimal"]

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

Berikutnya kita melihat WSL2, Windows Sandbox, lalu kontainer, dan jenis duplikasi mana yang masing-masing potong.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 19, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Apa yang dibawa VM penuh

Sebagai garis dasar perbandingan, berikut yang dibawa VM tradisional.

• Image OS independen. Semua berkas OS tamu ada di dalam disk virtual. Meski host punya Windows yang sama, tidak ada berbagi.
• Alokasi memori kasar. VM tradisional pada dasarnya mengalokasikan memori host dalam ukuran statis. Ada juga mekanisme seperti Hyper-V Dynamic Memory yang menaikkan dan menurunkan alokasi dalam rentang yang dikonfigurasi, tetapi sarana menyesuaikan dengan perubahan permintaan terbatas.²
• Boot penuh tujuan umum. Firmware, boot loader, dan kumpulan layanan start dengan urutan yang sama seperti 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 --> b2["Alokasi memori yang statis secara bawaan"]
    fullvm --> b3["Boot penuh tujuan umum"]
    b1 -.-> c1["Disk terpakai sebesar salinannya"]
    b2 -.-> c2["Cenderung menahan RAM termasuk yang tidak terpakai"]
    b3 -.-> c3["Start memakan puluhan detik"]

Gambar 2: Rincian biaya VM penuh dibayar bukan untuk isolasi, melainkan untuk sifat tujuan umum dan duplikasi.

Ini bukan cacat; ini harga sifat tujuan umum bahwa “apa pun bisa dimasukkan ke tamu”. Untuk pemakaian seperti menjalankan Linux lama di samping Windows Server, sifat tujuan umum itulah nilainya. Namun untuk pemakaian “ingin menjalankan OS yang sama (atau yang sudah ditentukan) dengan host, sekarang juga, untuk pengembangan atau validasi”, sebagian besar menjadi beban yang terbuang. VM ringan menurunkan beban itu dengan mempersempit tujuan.

3. WSL2 — utility VM dengan kernel yang disesuaikan untuk tujuannya

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 produk khusus. Itu kernel Linux yang Microsoft bangun dari cabang Stable, sudah disetel ukuran dan kinerjanya untuk WSL2. Pada WSL distribusi Microsoft Store yang kini menjadi standar, kernel diperbarui bersama paket WSL sendiri dan diterapkan dengan wsl --update (pada distribusi in-box yang lebih lama, lewat Windows Update).⁴ Karena kernel sungguhan, kompatibilitas system call lengkap, dan alat seperti Docker berjalan apa adanya.
• VM-nya di belakang layar. Pembuatan, start, dan penghentian VM dikelola 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. Namespace jaringan dan kernel dibagi, 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 meski beberapa distribusi dipasang, VM-nya tetap satu.

Saat wsl diketik, sisi belakangnya seperti ini.

flowchart TB
    accTitle: Dari menjalankan perintah wsl hingga shell kembali dalam beberapa detik
    accDescr: Jika utility VM belum berjalan ketika wsl dieksekusi, VM ringan dan kernel Linux di-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 VM yang sudah berjalan apa adanya"]
    bootvm --> shell["Shell kembali di dalam kontainer"]
    reuse --> shell

Gambar 4: Isi waktu tunggu hanyalah start VM seminimal mungkin; efek menurunkan beban boot penuh tampak di sini.

3.2. I/O berkas: di sisi mana ditaruh, hasilnya lain sama sekali

Dalam pembicaraan kinerja WSL2, lokasi berkas selalu muncul.

• Operasi terhadap berkas di sisi Linux (disk virtual ext4) cepat. Kernel Linux menangani sistem berkasnya sendiri secara langsung; ada laporan percepatan hingga 20 kali dibanding WSL1 untuk ekstraksi tarball, dan 2–5 kali untuk git clone atau npm install.⁴
• Operasi terhadap berkas di sisi Windows (/mnt/c dan semacamnya) menjadi lambat karena melewati berbagi berkas yang menyeberangi batas OS. Kinerja antar sistem berkas OS adalah satu-satunya item utama di mana WSL2 kalah dari WSL1.⁴

Maka prinsipnya: “taruh berkas proyek di sisi OS yang sama dengan alat yang mengerjakannya”. ⁴ Repositori yang dikerjakan alat build Linux ditaruh di sisi Linux; solusi yang di-build Visual Studio ditaruh di sisi Windows.

flowchart TB
    accTitle: Percabangan jalur I/O berkas WSL2
    accDescr: Percabangan bahwa akses ke disk virtual ext4 sisi Linux cepat karena kernel Linux mengaksesnya langsung, sedangkan akses ke berkas sisi Windows lambat karena melewati berbagi yang menyeberangi batas OS
    io["Operasi berkas di dalam WSL2"] --> place{"Berkas di sisi mana?"}
    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 dibanding WSL1)"]
    p9 --> slow["Cenderung lambat"]
    slow -.-> fix["Cara: taruh berkas di OS yang memakainya"]

Gambar 5: Yang lambat bukan WSL2 melainkan jalurnya, jadi memindahkan lokasi sering membuat masalah kinerja hilang.

3.3. Memori: bertambah, berkurang, tetapi tidak selalu dikembalikan seluruhnya

Pemakaian memori WSL2 (terlihat sebagai proses vmmem di Task Manager) bukan reservasi tetap; ia bertambah dan berkurang sesuai pemakaian. Memori yang dilepas proses dikembalikan otomatis ke Windows di bawah pengaturan pageReporting yang aktif secara bawaan.⁵ Halaman yang ditahan sebagai cache berkas, dulu, tidak kembali ke Windows sampai VM berakhir.⁴ Pada WSL terkini, pengaturan eksperimental autoMemoryReclaim di .wslconfig (bawaan dropCache) juga menarik cache secara otomatis.⁵ Di lingkungan yang menyetel ini ke disabled, atau pada WSL lama, cache sesi panjang bisa tertahan sampai VM berakhir dan menekan memori host.

flowchart TB
    accTitle: Alur bertambah-berkurangnya memori WSL2 dan pengembaliannya
    accDescr: Permintaan di dalam WSL2 menaikkan pemakaian memori VM; bagian yang dilepas proses dikembalikan ke Windows di bawah pageReporting yang aktif secara bawaan; cache berkas ditarik otomatis oleh autoMemoryReclaim secara bawaan; pada pengaturan yang menonaktifkan ini atau WSL lama, ia tertahan sampai VM berakhir, dan shutdown wsl mengembalikan semuanya
    grow["Permintaan memori di dalam WSL2 naik"] --> vm["Pemakaian vmmem naik"]
    vm --> freed{"Halaman itu sudah dilepas?"}
    freed -->|"Proses melepaskan (saat pageReporting aktif)"| ret["Dikembalikan otomatis ke Windows"]
    freed -->|Ditahan sebagai cache berkas| amr["autoMemoryReclaim menarik otomatis (bawaan)"]
    amr -.-> old2["Pada pengaturan dinonaktifkan atau WSL lama, tertahan sampai VM berakhir"]
    old2 --> sd["wsl --shutdown mengembalikan semuanya"]

Gambar 6: Yang tampak “hanya bertambah” terutama adalah bagian cache (jika pageReporting dinonaktifkan, bagian yang dilepas proses pun tertahan), jadi kenali jalur pengembalian sebelum menyimpulkan kebocoran.

Jika ingin menyatakan batas atas secara eksplisit, memori, jumlah CPU, dan swap VM secara keseluruhan dapat dikontrol di %UserProfile%\.wslconfig.⁵

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

Setelah mengubah pengaturan, restart VM dengan wsl --shutdown agar berlaku. Alokasi dinamis semacam “batas atas ditentukan pengaturan, pemakaian aktual mengikuti permintaan” ini, pada Windows Sandbox berikutnya, diterapkan lebih jauh.

4. Windows Sandbox — “memakai lagi” Windows host

4.1. Dynamic base image: Windows lengkap dengan 500 MB

Windows Sandbox adalah desktop Windows sekali pakai yang diisolasi hypervisor. Jika ditutup, semuanya hilang, dan berikutnya start dalam hitungan detik dari keadaan bersih.¹

Yang aneh lebih dulu adalah disk. Meski bisa mem-boot Windows lengkap, base image Sandbox hanya sekitar 500 MB setelah instalasi, dan 30 MB terkompresi saat didistribusikan.² Rahasianya ada pada dynamic base image.

• Sebagian besar berkas OS tidak berubah (immutable), sehingga milik host dapat dibagi apa adanya.
• Sejumlah kecil berkas yang bisa berubah (mutable) tidak dapat dibagi, jadi salinan bersih disimpan di dalam base image.
• Saat start, berkas host yang tidak berubah + salinan berkas yang bisa berubah digabung menjadi image Windows lengkap.²

Artinya Sandbox menggunakan ulang Windows yang sudah terpasang di host untuk start, tanpa mengunduh atau menyimpan salinan Windows.

flowchart TB
    accTitle: Susunan dynamic base image
    accDescr: Berkas OS yang tidak berubah dari Windows host dibagi, hanya berkas yang bisa berubah yang disimpan sebagai salinan bersih di base image, dan keduanya digabung menjadi image Windows lengkap Sandbox
    hostw["Windows host secara utuh"] --> imm["Berkas OS yang tidak berubah (mayoritas)"]
    hostw --> mut["Berkas OS yang bisa berubah (minoritas)"]
    imm -->|dibagi apa adanya| img["Image start Sandbox"]
    mut -->|menyimpan salinan bersih| img
    img --> boot["Start sebagai Windows lengkap"]
    img -.-> size["Yang perlu disimpan hanya sekitar 500 MB"]

Gambar 7: Bukan “memiliki Windows satu lagi”, melainkan “merakit dari Windows host” — itulah bentuk berhenti menduplikasi disk.

Karena susunan ini, siklus hidup berikut bisa terjadi. Yang dibuang adalah keadaan lokal di dalam Sandbox. Jika folder yang dapat ditulis dipetakan dari host lewat berkas konfigurasi .wsb, perubahan ke sana tetap ada di sisi host.⁶

flowchart TB
    accTitle: Siklus hidup Windows Sandbox
    accDescr: Saat start, Windows bersih tersedia dalam hitungan detik; setelah validasi atau eksperimen aplikasi, menutup membuang semua keadaan di dalam Sandbox sehingga berikutnya mulai dari keadaan bersih lagi; tetapi perubahan ke folder host yang dipetakan sebagai dapat ditulis tetap ada
    launch["Start (beberapa detik)"] --> clean["Windows bersih"]
    clean --> work["Validasi atau eksperimen aplikasi"]
    work --> close2["Tutup"]
    close2 --> discard["Buang semua keadaan di dalam Sandbox"]
    discard -.-> mapped["Perubahan ke folder yang dipetakan sebagai dapat ditulis tetap ada di host"]
    discard -->|start berikutnya| launch

Gambar 8: Bisa kembali bersih setiap kali karena bagian yang bisa berubah adalah salinan sekali pakai; membuang adalah bagian dari desain.

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

Bukan hanya disk; RAM juga dibagi. Karena Sandbox menjalankan image OS yang sama dengan host, untuk biner OS dipakai teknik bernama “direct map” yang menggunakan 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 mengekspos rahasia host, jejak memori yang jauh lebih kecil daripada VM tradisional tercapai.²

“Beberapa pemakai berbagi halaman fisik yang sama” — ini gagasan yang sama dengan berbagi DLL lewat objek section ( “Objek section dan copy-on-write” ) yang dilacak di Bagian 3 seri memori. 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, sehingga pemakaian memori berkurang
    happ["Aplikasi 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["Duplikasi RAM untuk bagian OS menjadi tidak perlu"]

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

4.3. Pinjam-meminjam memori: lebih seperti proses daripada VM

Terhadap alokasi memori statis VM tradisional, teknologi kontainer yang menjadi fondasi Sandbox memutuskan pembagian sumber daya secara dinamis bersama host. Jika host kekurangan memori, memori dapat ditarik dari kontainer dengan cara yang sama seperti dari proses biasa.² Hyper-V Dynamic Memory juga menaikkan dan menurunkan alokasi ke VM dalam rentang yang dikonfigurasi, tetapi Sandbox melangkah lebih jauh: ia berbagi di lapangan yang sama dengan pengelolaan memori host.

flowchart TB
    accTitle: Koordinasi memori host dan Sandbox
    accDescr: VM tradisional pada dasarnya memakai ukuran statis secara eksklusif dan sarana penyesuaiannya terbatas, sedangkan Sandbox menjadi sasaran penarikan sesuai tekanan memori host dan berbagi memori di lapangan yang sama dengan proses biasa
    pressure["Tekanan memori host naik"] --> from{"Ditarik dari mana?"}
    from --> proc["Working Set proses biasa"]
    from --> sbx["Bagian yang dipakai Sandbox (kontainer)"]
    proc --> relief["Memori bebas diamankan"]
    sbx --> relief
    relief -.-> contrast["Pada VM tradisional, sarana penyesuaian terbatas"]

Gambar 10: Dalam pinjam-meminjam memori, Sandbox berdiri di sisi proses, bukan VM, dan menyerahkan ketika host tertekan.

Di Bagian 1 dikatakan bahwa “kinerja VM juga bergantung pada sisi host”, tetapi pada VM ringan satu langkah lebih jauh: pembagian memori itu sendiri adalah kerja bersama dengan host. Sandbox terasa bukan “perangkat lunak virtualisasi yang berat” melainkan “satu aplikasi lagi” berkat koordinasi ini.

Prosedur konkret memakai Sandbox untuk validasi aplikasi bisnis dibahas di artikel sebelumnya, “Membangun lingkungan validasi aplikasi bisnis dengan Windows Sandbox”. Artikel ini adalah sisi mekanisme di bawahnya.

5. Kontainer — di mana garis isolasi ditarik

5.1. Isolasi proses dan isolasi Hyper-V

Kontainer Windows punya dua mode isolasi saat dijalankan. Image-nya sama; dipilih dengan flag saat start.⁷

• Isolasi proses: beberapa kontainer berbagi kernel dengan host, dan diisolasi lewat virtualisasi per namespace — sistem berkas, registri, port jaringan, ruang process ID, namespace Object Manager, dan sebagainya. Cara ini hampir sama dengan kontainer Linux.
• Isolasi Hyper-V: setiap kontainer berjalan di dalam VM yang sangat dioptimalkan, dan pada dasarnya punya kernel khusus. Karena ada VM, isolasi tingkat perangkat keras masuk di antara kontainer dan host.⁷

Isolasi lewat namespace dapat disebut versi menyeluruh dari teknik “menampilkan entitas lain di bawah API yang sama” yang dilihat di artikel virtualisasi registri (“Pengalihan dan virtualisasi registri Windows”).

flowchart TB
    accTitle: Perbandingan isolasi proses dan isolasi Hyper-V
    accDescr: Pada isolasi proses kontainer berbagi kernel dengan host dan diisolasi lewat namespace, sedangkan pada isolasi Hyper-V setiap kontainer punya kernel khusus di dalam VM yang dioptimalkan
    subgraph pi ["Isolasi proses"]
        c1["Kontainer A"] --> sk1["Kernel yang dibagi 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: Meski image kontainer sama, apakah garis isolasi ditarik di atas kernel atau kernel dipisah utuh, dapat dipilih saat start.

5.2. Mana yang boleh disebut “batas keamanan”

Perbedaan dua mode ini tidak berhenti pada kinerja. Microsoft tidak menganggap kontainer isolasi proses sebagai batas keamanan yang kokoh. Yang dipelihara (termasuk penanganan kerentanan) sebagai batas keamanan adalah kontainer isolasi hypervisor, dan dalam skenario multi-tenant yang bersifat adversarial, isolasi Hyper-V yang seharusnya dipilih.⁸

VBS yang dilihat di Bagian 2 juga dirancang dengan premis “kernel bisa ditembus” lalu mundur ke batas hypervisor. Di dunia kontainer, kriteria yang sama berlaku. Garis untuk mengurung kode yang tidak dipercaya ditarik di batas hypervisor, bukan di dalam berbagi kernel.

flowchart TB
    accTitle: Tingkat kepercayaan kode yang dijalankan dan cara memilih isolasi
    accDescr: Jika beban kerja dipercaya, pilih isolasi proses untuk kepadatan dan kinerja; jika kode tidak dipercaya atau milik pihak lain, pilih batas hypervisor seperti kontainer isolasi Hyper-V, Windows Sandbox dengan konfigurasi dikeraskan (jaringan dinonaktifkan, dll.), atau VM terisolasi
    trust{"Kode itu bisa dipercaya?"} -->|Bisa| dens["Isolasi proses (utamakan kepadatan dan kecepatan)"]
    trust -->|Tidak bisa / kode pihak lain| bound["Pilih batas hypervisor"]
    bound --> opt1["Kontainer isolasi Hyper-V"]
    bound --> opt2["Sandbox dengan konfigurasi dikeraskan atau VM terisolasi"]

Gambar 12: Mode isolasi adalah soal keamanan sebelum soal kinerja; tingkat kepercayaan menentukan di mana garis ditarik.

Omong-omong, jika kontainer isolasi Hyper-V dijalankan di dalam VM Hyper-V, hypervisor menjadi dua tingkat — nested virtualization. Nested satu tingkat didukung juga di produksi pada lingkungan yang memenuhi syarat (host dengan prosesor Intel: Windows 10/Windows Server 2016 atau lebih baru; prosesor AMD: Windows 11/Windows Server 2022 atau lebih baru, plus versi konfigurasi VM yang sesuai masing-masing), dan selain itu mengandaikan pengaturan yang memaparkan fitur bantuan virtualisasi ke VM luar (ExposeVirtualizationExtensions pada Set-VMProcessor untuk Hyper-V). Konfigurasi menjalankan WSL2 di dalam VM didukung dengan cara yang sama.⁹ Apakah WSL2 atau Docker bisa dipakai di VM pengembangan di cloud juga ditentukan oleh apakah ukuran dan pengaturan VM itu memaparkan nested virtualization.

flowchart TB
    accTitle: Struktur nested virtualization
    accDescr: Di atas hypervisor host fisik ada VM cloud, dan di dalamnya hypervisor satu tingkat lagi (nested yang didukung hanya satu tingkat) berjalan untuk menopang WSL2 atau kontainer isolasi Hyper-V
    phys3["Hypervisor host fisik"] --> cvm["VM cloud (mesin pengembangan)"]
    cvm --> nhv["Hypervisor di dalam VM (nested tingkat 1)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Kontainer isolasi Hyper-V"]
    nhv -.-> limit["Nested yang didukung hanya satu tingkat"]

Gambar 13: wsl berjalan di dalam VM cloud karena nested virtualization satu tingkat ditopang secara resmi.

5.3. Spektrum isolasi dan keringanan

Jika yang sudah dibahas disusun pada satu sumbu, hasilnya seperti berikut.

flowchart TB
    accTitle: Spektrum kekuatan isolasi dan keringanan
    accDescr: Kontainer isolasi proses paling ringan tetapi berbagi kernel; WSL2, Sandbox, dan kontainer isolasi Hyper-V adalah VM ringan dengan kernel khusus (Sandbox diringankan lewat berbagi host, WSL2 lewat kernel khusus); VM penuh paling berat tetapi tujuan umum
    ax["Ringan ← → Berat"] ~~~ p1
    p1["Kontainer isolasi proses (berbagi kernel)"] --> p2["WSL2, Sandbox, isolasi Hyper-V (VM ringan dengan kernel khusus)"]
    p2 --> p3["VM penuh (apa pun berjalan; membawa semua duplikasi)"]
    p1 -.-> n1["Batas: namespace"]
    p2 -.-> n2["Batas: hypervisor"]
    p3 -.-> n3["Batas: hypervisor + independensi penuh"]

Gambar 14: Kelompok VM ringan adalah solusi tengah yang menjaga batas hypervisor sambil memotong duplikasi; cara memotongnya terbagi: Sandbox dengan berbagi, WSL2 dengan kernel khusus.

6. Mengamati sendiri

Keringanan dan berbagi dapat diamati di mesin sendiri.

Waktu start dan naik-turunnya memori (WSL2). Buka Task Manager, lalu coba jalankan berikut.

# Waktu start yang terasa (pertama kali start VM, kedua kali dan seterusnya lebih cepat)
Measure-Command { wsl -e true }

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

# Mengakhiri seluruh VM dan melihat memori dikembalikan
wsl --shutdown

Jika build besar atau operasi berkas dijalankan di dalam WSL2, vmmem tumbuh, dan dengan wsl --shutdown pengembalian sekaligus dapat diamati.

Perbedaan kecepatan menurut lokasi berkas (WSL2). Taruh repositori yang sama di sisi Linux (~/repo) dan sisi Windows (/mnt/c/repo), lalu bandingkan waktu git status atau proses ekstraksi; selisih di pasal 3.2 terlihat sebagai angka.

Pengetahuan prasyarat direct map (Sandbox). Start Sandbox, lalu lihat kenaikan memori di Task Manager host. Kenaikan yang jauh lebih kecil daripada yang dibayangkan dari “Windows satu lagi” menunjukkan efek berbagi. Untuk menggali rincian memori sisi host lebih jauh, artikel alat Sysinternals yang merangkum cara memakai RAMMap dan VMMap (“Cara memakai Process Explorer, Handle, dan VMMap”) dapat dijadikan rujukan. Namun alat-alat itu melihat klasifikasi proses atau memori fisik sisi host; mereka tidak mengamati berbagi dengan tamu secara langsung.

Mode isolasi kontainer (Docker/kontainer Windows). Jika ada lingkungan kontainer Windows, start image yang sama dengan docker run --isolation=process dan --isolation=hyperv, lalu bandingkan waktu start dan tampilan di Task Manager (pada isolasi proses, proses di dalam kontainer terlihat di daftar proses host); posisi garis isolasi terasa.⁷ Namun isolasi proses mengandaikan versi host dan image cocok, dan di OS klien terbatas pada pemakaian pengembangan serta uji. Isolasi Hyper-V mengizinkan kombinasi yang lebih luas, jadi bandingkan pada kombinasi yang kompatibel.¹⁰

7. Tiga salah baca yang ingin dihindari di praktik

7.1. “WSL2 itu lambat”

Yang lambat bukan WSL2, melainkan jalur I/O berkas yang menyeberangi batas OS. Hanya memindahkan proyek ke sisi Linux sering membuat rasanya lain sama sekali.⁴ Sebaliknya, menaruh berkas yang disentuh alat Windows di sisi Linux juga merugikan dengan alasan yang sama. Putuskan dengan “taruh di OS yang sama dengan yang memakai”.

7.2. “vmmem membesar adalah kebocoran memori”

Memori WSL2 bertambah dan berkurang sesuai permintaan, dan bagian yang dilepas dikembalikan. Pada WSL terkini, cache berkas juga ditarik otomatis oleh autoMemoryReclaim (bawaan dropCache), jadi “tetap besar” sering mereda seiring waktu.⁵ Jika masih tertahan, periksa apakah autoMemoryReclaim tidak disetel ke disabled, apakah pageReporting yang mengembalikan bagian yang dilepas tidak dinonaktifkan (atau apakah WSL-nya lama), lalu nyatakan batas atas dengan memory di .wslconfig, atau kembalikan semuanya dengan wsl --shutdown di batas sesi. Cara memilah apakah itu kebocoran sama dengan pengantar seri memori, “Apa yang diwakili ‘pemakaian memori’ Windows”.

7.3. “Sudah dimasukkan kontainer, jadi aman”

Kontainer isolasi proses berbagi kernel, dan menurut kriteria Microsoft itu bukan batas keamanan.⁸ Untuk menjalankan kode atau sampel yang tidak dipercaya, pilih isolasi yang punya batas hypervisor: kontainer isolasi Hyper-V, Windows Sandbox, atau VM khusus. Namun batas hypervisor bukan surat bebas tanggung jawab. Pengaturan bawaan Windows Sandbox mengaktifkan koneksi jaringan, sehingga aplikasi yang tidak dipercaya bisa terpapar ke jaringan internal.¹ Jika dipakai untuk menjalankan sampel, perkuat isolasi dengan menonaktifkan pengalihan jaringan atau clipboard lewat berkas konfigurasi .wsb, atau pakai VM khusus di jaringan terisolasi.

8. Ringkasan — menutup seri

Poin Bagian 3.

• Keringanan VM ringan bukan hasil “melemahkan isolasi”, melainkan hasil “berhenti menduplikasi”.
• WSL2 menjalankan kernel Linux sungguhan di utility VM ringan yang dikelola, dan distribusi dipisah sebagai kontainer di dalam VM.³ Prinsip kinerja adalah menaruh berkas di OS yang memakainya, dan memori bertambah-berkurang secara dinamis dengan batas atas yang dapat dikontrol di .wslconfig.⁴⁵
• Windows Sandbox tidak membawa salinan Windows secara utuh: dynamic base image membagi berkas OS host yang tidak berubah, dan direct map juga membagi halaman fisik biner OS yang menjadi sasaran.² Sekitar 500 MB berkas yang bisa berubah, plus memori aplikasi yang dijalankan di dalamnya, tetap diperlukan secara terpisah.
• Mode isolasi kontainer dipilih saat start, dan yang boleh disebut batas keamanan adalah sisi isolasi Hyper-V.⁷⁸

Jika seluruh seri dirangkum dalam satu lembar, hasilnya seperti ini.

• Bagian 1: Di bawah Windows ada lapisan hypervisor, dan OS host sendiri berjalan sebagai root partition. Mediasi CPU dan memori (SLAT) dilakukan lapisan ini secara langsung; I/O perangkat sintetis diantarai root partition (VSP) di ujung VMBus.
• Bagian 2: Lapisan itu dipakai bukan hanya untuk isolasi antar VM, tetapi juga untuk menarik batas yang lebih kuat daripada kernel (VTL) di dalam OS yang sama. Keamanan bawaan Windows 11 dibangun di atas ini.
• Bagian 3: Di atas lapisan yang sama, “VM yang start dalam hitungan detik” terbentuk dengan memotong duplikasi. Garis isolasi tetap terjaga, dan ia menjadi alat sehari-hari.

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

Gambar 15: Jika tiga bagian ditumpuk, keseluruhan pijakan Windows saat ini terlihat.

Virtualisasi bukan lagi teknologi ruang server, atau teknologi hanya bagi orang yang mendirikan VM. Di pijakan Windows Anda, ia menopang keamanan dan pengalaman pengembangan secara sunyi — itulah posisi saat ini.

Artikel terkait

• Kedalaman virtualisasi Windows (Bagian 1) — Di mana Windows Anda sebenarnya berjalan: hypervisor dan partisi
• Kedalaman virtualisasi Windows (Bagian 2) — Memori yang bahkan kernel pun tidak melihat: mekanisme VBS, HVCI, dan Credential Guard
• Kedalaman memori Windows (Bagian 3) — Objek section dan copy-on-write
• Membangun lingkungan validasi aplikasi bisnis dengan Windows Sandbox
• Pengalihan dan virtualisasi registri Windows

Area konsultasi terkait

KomuraSoft LLC menangani penyiapan lingkungan pengembangan yang memakai WSL2 dan kontainer, perancangan lingkungan validasi aplikasi Windows, serta penyelidikan kinerja dan kompatibilitas di lingkungan virtualisasi.

• Pengembangan aplikasi Windows
• Investigasi bug dan analisis penyebab
• Pemanfaatan aset yang ada dan dukungan migrasi
• Hubungi kami

Tautan referensi

Artikel terkait

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

Topik terkait

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

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

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. Pengelolaan VM dilakukan WSL di belakang layar, sehingga desainnya tidak membuat pengguna memikirkan pengaturan VM atau menunggu boot. Setiap distribusi Linux berjalan sebagai kontainer terisolasi di dalam VM yang dikelola itu.

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

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

Apakah pemakaian memori besar oleh proses vmmem itu kebocoran?

Dalam banyak kasus itu bukan kebocoran. Memori WSL2 bertambah dan berkurang sesuai pemakaian, dan memori yang dilepas proses dikembalikan ke Windows di bawah pengaturan pageReporting yang aktif secara bawaan. Bagian cache berkas, pada WSL terkini, juga ditarik otomatis oleh autoMemoryReclaim di .wslconfig (bawaan dropCache). Di lingkungan yang menonaktifkan pengaturan ini, atau pada WSL lama, memori bisa tertahan sampai VM berakhir; dalam kasus itu tetapkan batas atas dengan pengaturan memory, atau kembalikan dengan wsl --shutdown.

Bagaimana Windows Sandbox bisa mem-boot Windows lengkap hanya dengan beberapa ratus MB disk?

Lewat mekanisme bernama dynamic base image. Ia berbagi berkas OS yang tidak berubah dari Windows yang sudah terpasang di host, dan menyimpan salinan bersih hanya untuk sejumlah kecil berkas yang bisa berubah. Dengan itu, image lengkap yang bisa di-boot disusun tanpa menyimpan salinan penuh Windows.

Apakah kontainer lebih aman daripada VM?

Tergantung mode isolasinya. Kontainer isolasi proses berbagi kernel dengan host, dan Microsoft tidak menganggap ini batas keamanan yang kokoh. Jika menangani kode yang bersifat adversarial, pilih 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.