WSL2 on kenji.blog

Hyper-V vs WSL2: Membandingkan Teknologi Virtualisasi di Windows

Sun, 13 Sep 2026 07:00:00 +0900

1. Pendahuluan: Evolusi Virtualisasi di Windows

Teknologi virtualisasi pada platform Windows telah mengalami evolusi dramatis dalam beberapa dekade terakhir. Dulu, hypervisor Type 2 dari pihak ketiga (seperti VMware Workstation atau VirtualBox) menjadi arus utama. Namun, sejak Microsoft memperkenalkan “Hyper-V” di Windows Server 2008, hypervisor Type 1 mulai terintegrasi ke dalam OS desktop seperti Windows 10/11.

Dalam beberapa tahun terakhir, yang paling menarik perhatian para pengembang adalah “WSL2 (Windows Subsystem for Linux 2)”. Sementara WSL1 bergantung pada penerjemahan system call (translasi), WSL2 mengadopsi “Lightweight Utility VM” yang menerapkan teknologi Hyper-V, memberikan kompatibilitas Linux sepenuhnya serta peningkatan performa yang signifikan.

Artikel ini akan membandingkan dan menjelaskan secara mendetail dua teknologi virtualisasi kuat ini — “Hyper-V” yang berfitur lengkap dan “WSL2” yang difokuskan pada pengalaman pengembang — dari sisi arsitektur, performa (CPU, memori, I/O disk), konfigurasi jaringan, serta use case optimal beserta rincian teknis yang mendalam.

2. Teori Dasar Hypervisor dan Perbandingan Arsitektur

Untuk memahami teknologi virtualisasi, mengklasifikasikan tipe hypervisor (Virtual Machine Monitor: VMM) adalah hal yang penting.

2.1. Perbedaan antara Hypervisor Type 1 dan Type 2

Hypervisor adalah lapisan perangkat lunak yang mengabstraksi akses perangkat keras dan memungkinkan banyak OS (Guest OS) berjalan secara bersamaan di satu mesin fisik.

Type 1 (Bare-metal): Berjalan langsung di atas perangkat keras. Tidak ada konsep Host OS (walaupun secara teknis mungkin ada sistem operasi manajemen yang memiliki hak istimewa), overhead-nya sangat rendah, dan menawarkan performa serta keamanan yang tinggi. Contoh: Hyper-V, VMware ESXi, Xen.
Type 2 (Hosted): Berjalan sebagai aplikasi di atas Host OS (seperti Windows atau macOS). Karena semua akses perangkat keras harus melalui Host OS, overhead-nya menjadi lebih besar. Contoh: VMware Workstation, Oracle VirtualBox.

Hyper-V di Windows adalah hypervisor Type 1 murni. Faktanya, ketika Anda mengaktifkan Hyper-V, OS Windows yang biasa Anda gunakan juga berjalan di dalam mesin virtual khusus yang disebut “Partisi Root” (Root Partition).

2.2. Detail Arsitektur Hyper-V

Arsitektur Hyper-V menggunakan desain mikro-kernel dan didasarkan pada unit pemisahan logis yang disebut Partisi (Partition).

graph TD
A["Perangkat Keras (CPU, RAM, Disk, NIC)"] --> B["Windows Hypervisor (Ring -1)"]
B --> C["Partisi Root (OS Windows)"]
B --> D["Partisi Anak 1 (VM Windows)"]
B --> E["Partisi Anak 2 (VM Linux)"]
C --> F["VMBus (Bus Mesin Virtual)"]
D --> F
E --> F
C --> G["VID (Driver Infrastruktur Virtualisasi)"]
C --> H["VMWP.exe (Proses Pekerja)"]

Windows Hypervisor: Berjalan pada tingkat hak istimewa (privilege) CPU yang paling tinggi (Ring -1 atau VMX Root Mode), dan hanya menangani alokasi memori serta penjadwalan CPU. Tidak termasuk driver perangkat.
Partisi Root: Partisi tempat berjalannya Host OS Windows. Memiliki semua driver perangkat dan mengontrol perangkat keras secara langsung. Partisi ini juga menyediakan fungsionalitas manajemen untuk partisi anak (seperti WMI provider dan VMWP.exe).
Partisi Anak: Partisi tempat berjalannya Guest OS. Tidak memiliki akses langsung ke perangkat keras, dan mengirim permintaan I/O (Synthetic I/O) ke Partisi Root melalui bus memori bersama logis yang disebut “VMBus”.

2.3. WSL2 dan Mekanisme Lightweight Utility VM

WSL2 menggunakan teknologi dasar hypervisor Type 1 yang sama dengan Hyper-V, tetapi memanfaatkan fitur subset yang disebut “Platform Mesin Virtual” (Virtual Machine Platform: VMP), yang berbeda dari mesin virtual Hyper-V berfitur lengkap.

“Lightweight Utility VM” yang digunakan di WSL2 sepenuhnya menghilangkan emulasi perangkat keras warisan (seperti BIOS virtual atau motherboard virtual) yang dimiliki oleh VM tradisional.

graph TD
A["OS Host Windows (User Space)"]
B["Sistem Berkas NTFS"]
C["Server Protokol 9P (Plan 9)"]
D["Lightweight Utility VM (Kernel Linux)"]
E["ext4.vhdx (Disk Virtual)"]
F["User Space Linux (Distribusi WSL2)"]
A --> C
C -->| Berbagi Berkas Lintas OS | D
D --> E
D --> F

Karakteristik terbesar dari WSL2 adalah kecepatan proses booting dan integrasinya yang mulus dengan Host OS. Kernel Linux melakukan booting dalam waktu kurang dari beberapa detik, dan sistem berkas di sisi Windows (NTFS) diakses melalui protokol sistem berkas jaringan 9P dari Plan 9.

3. Analisis Performa Mendalam: Sumber Daya Komputasi dan I/O

Performa mesin virtual direpresentasikan sebagai jumlah total overhead dari tiap komponen CPU, memori, dan I/O disk.

3.1. CPU dan Overhead Context Switch

Hyper-V maupun WSL2 menggunakan virtualisasi berbasis perangkat keras (Intel VT-x / AMD-V). Instruksi CPU pada dasarnya dieksekusi dengan kecepatan native, namun ketika instruksi dengan hak istimewa (privilege instructions) atau pemrosesan I/O dijalankan, terjadilah interupsi yang disebut “VM Exit”, yang menyebabkan context switch ke hypervisor.

Overhead CPU $T_{overhead}$ pada saat tersebut dapat direpresentasikan dalam model matematika berikut:

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

Di mana:

$N$: Jumlah terjadinya VM Exit per satuan waktu
$t_{vm\_exit}$: Waktu transisi dari guest ke hypervisor
$t_{hypercall\_process}$: Waktu pemrosesan I/O atau interupsi melalui VMBus
$t_{vm\_entry}$: Waktu pemulihan (return) dari hypervisor ke guest

Pada WSL2, karena tidak ada emulasi legacy (warisan), $t_{hypercall\_process}$ dioptimalkan menjadi sangat kecil. Oleh karena itu, dalam komputasi murni CPU (misalnya proses kompilasi kernel atau inferensi model machine learning), penurunan performa hanya berada dalam kisaran beberapa persen jika dibandingkan dengan lingkungan bare-metal.

3.2. Mekanisme Alokasi Memori

Dalam hal manajemen memori, terdapat perbedaan konsep desain yang jelas di antara keduanya.

Hyper-V (Dynamic Memory): Partisi Root akan mengalokasikan dan menarik kembali (reclaim) memori secara dinamis berdasarkan kebutuhan memori dari VM Guest. Namun, memori yang telah dialokasikan sebagai page cache di dalam Guest OS cenderung sulit untuk dibebaskan kecuali sistem sedang kekurangan memori.
WSL2 (Pengembalian Memori Dinamis): WSL2 memiliki mekanisme unik yang secara teratur mengembalikan (reclaim) memori yang tidak lagi dibutuhkan (termasuk cache) di dalam VM Linux ke host Windows. Pada versi awal WSL2, ada masalah di mana page cache Linux menghabiskan memori Windows (pembengkakan proses Vmmem), tetapi saat ini masalah tersebut telah diperbaiki melalui patch kernel.

3.3. Karakteristik I/O Disk (VHDX vs ext4.vhdx)

Hal yang paling sering menjadi bottleneck pada performa mesin virtual adalah I/O disk.

Latensi I/O $L_{total}$ dihitung sebagai berikut:

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

Dalam kasus Hyper-V: Guest Hyper-V pada umumnya menggunakan disk virtual dengan format VHDX. Permintaan I/O yang dikeluarkan dari sistem berkas di dalam Guest OS (ext4 atau NTFS) melewati blok driver perangkat penyimpanan VMBus (storvsc), dan diproses sebagai akses ke berkas VHDX di atas NTFS pada sisi Windows.

Dalam kasus WSL2: Distribusi Linux di WSL2 berjalan pada sistem berkas native ext4 yang dibangun di dalam berkas ext4.vhdx khusus. Operasi berkas di dalam Linux (seperti pada direktori ~) memberikan performa native yang setara dengan Hyper-V di atas. Namun, ketika mengakses berkas di sisi Windows (seperti /mnt/c/) dari Linux di WSL2, atau sebaliknya, prosesnya akan jauh berbeda. Akses lintas OS ini menggunakan 9P (Plan 9 File System Protocol).

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

Akses yang melewati protokol 9P ini memiliki overhead proses serialisasi yang besar, sehingga pada penggunaan yang melibatkan banyak operasi baca/tulis berkas berukuran kecil (contoh: menjalankan npm install atau operasi Git pada proyek Node.js yang berada di direktori Windows), performanya akan menurun secara drastis (bahkan bisa mengakibatkan penundaan/delay lebih dari 10 kali lipat). Oleh karena itu, aturan utamanya ketika menggunakan WSL2 adalah selalu menempatkan berkas proyek di sistem berkas native Linux (di bawah ~/).

4. Struktur Jaringan: NAT, Default Switch, Bridged

Fleksibilitas fitur jaringan merupakan salah satu perbedaan besar antara Hyper-V dan WSL2.

4.1. Jaringan WSL2 (Berbasis NAT)

Secara default, jaringan WSL2 dikonfigurasi menggunakan “NAT (Network Address Translation)” yang memanfaatkan teknologi virtual switch dari Hyper-V. VM Linux secara otomatis diberikan alamat IP privat yang berbeda dari host Windows (contoh: 172.20.x.x). Telah ada mekanisme bawaan di mana host Windows akan mem-forward permintaan localhost ke layanan (port) yang berjalan di dalam WSL2, sehingga pengembang bisa menguji coba server web tanpa harus memikirkan tentang jaringan.

Baru-baru ini, WSL2 memperkenalkan mode jaringan baru bernama “Mirrored Mode” dalam versi pratinjaunya. Mode ini berupaya meningkatkan dukungan untuk IPv6 dan kompatibilitas koneksi VPN (dapat dikonfigurasi melalui .wslconfig).

4.2. Virtual Switch Hyper-V (Virtual Switch)

Hyper-V mampu membangun jaringan tingkat enterprise yang canggih. Melalui “Virtual Switch Manager”, utamanya disediakan 3 mode:

Eksternal (External): Mengikat (bind) NIC fisik dari mesin host ke virtual switch, dan memungkinkan VM Guest untuk berpartisipasi langsung di jaringan fisik (koneksi bridge). VM akan mendapatkan IP dari server DHCP di subnet yang sama dengan jaringan fisik.
Internal (Internal): Hanya mengizinkan komunikasi antara Host OS dan VM, serta antar VM. Tidak dapat keluar secara langsung ke jaringan eksternal.
Privat (Private): Hanya mengizinkan komunikasi antar VM, dan memblokir komunikasi dengan Host OS. Digunakan untuk membangun lingkungan pengujian (sandbox) yang terisolasi.

4.3. Konfigurasi Jaringan Hyper-V Tingkat Lanjut Menggunakan PowerShell

Di dalam lingkungan pengembangan atau pengujian, jika Anda ingin membangun jaringan NAT yang dikustomisasi khusus untuk VM, Anda dapat menggunakan PowerShell untuk kontrol yang lebih rinci. Berikut adalah contoh skrip untuk membuat switch virtual internal, mengkonfigurasi NAT di dalamnya, serta menyediakan akses internet bagi VM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Membuat Virtual Switch Internal
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. Mengatur Alamat IP pada NIC virtual di sisi host (IP yang menjadi Gateway)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. Konfigurasi jaringan NAT
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# Perintah untuk pengecekan
Get-NetNat

Dengan konfigurasi ini, dengan mengatur IP secara manual (misalnya 192.168.100.x) dan gateway 192.168.100.1 pada Guest Hyper-V yang ditentukan, Anda dapat membangun segmen NAT Anda sendiri yang mampu berkomunikasi dengan jaringan luar melalui host.

5. Use Case dan Panduan Praktis Pemilihan

Mempertimbangkan perbedaan arsitektur dan performa sejauh ini, mari kita tentukan dalam situasi seperti apa salah satu teknologi ini harus digunakan.

5.1. Skenario di Mana Anda Harus Memilih WSL2

WSL2 dirancang khusus untuk “meningkatkan produktivitas pengembang”. WSL2 paling ideal untuk penggunaan berikut:

Pengembangan Web dan Cloud-Native: Pengembangan kontainer menggunakan Docker Desktop (backend WSL2) atau Podman.
Penggunaan Perangkat/Alat Khusus Linux: Jika Anda sehari-hari menggunakan bash, grep, awk, sed, atau kompilator GCC dan Clang yang dikhususkan untuk Linux.
Aplikasi GUI (WSLg): Jika Anda ingin menjalankan aplikasi X11/Wayland Linux secara mulus di atas desktop Windows.
Pengembangan Machine Learning dan AI: Pembelajaran (training) TensorFlow atau PyTorch yang cepat dengan memanfaatkan fitur GPU Passthrough (NVIDIA CUDA di WSL).

Catatan: Jika Anda ingin mengkustomisasi kernel secara rinci atau membangun layanan kompleks yang sangat bergantung pada systemd (saat ini systemd telah didukung, namun dinonaktifkan secara default atau masih memiliki batasan), Anda mungkin akan menemui beberapa hambatan.

5.2. Skenario di Mana Anda Harus Memilih Hyper-V

Hyper-V ditujukan untuk “virtualisasi infrastruktur dan isolasi total”. Teknologi ini mutlak diperlukan pada penggunaan berikut:

Menjalankan VM Windows: Jika Anda ingin menjalankan berbagai versi Windows (seperti Windows Server atau Windows 10 versi lama) sebagai lingkungan pengujian.
Nested Virtualization (Virtualisasi Bersarang): Jika Anda ingin menjalankan mesin virtual lagi di dalam mesin virtual (seperti Hyper-V atau KVM). Ini sangat penting untuk lingkungan pengujian bagi engineer infrastruktur.
Kebutuhan Jaringan Tingkat Lanjut: Jika Anda perlu mengontrol konfigurasi jaringan secara ketat, seperti koneksi bridge eksternal (bergabung dengan LAN yang sama), VLAN tagging, atau alokasi multiple NIC.
Snapshot (Checkpoint): Fitur untuk menyimpan kondisi VM pada titik waktu tertentu dan dapat me-rollback seketika kapan saja. Sangat berguna untuk pengujian perangkat lunak yang merusak (destructive testing) atau analisis malware.
Alokasi Sumber Daya yang Tetap (Fixed): Jika Anda ingin menetapkan (fix) jumlah core CPU dan kapasitas memori secara ketat untuk meminimalkan dampaknya terhadap Host OS.

6. Pertimbangan Throughput I/O Menggunakan Model Matematis (Lampiran)

Sebagai system engineer, ketika ingin mengetahui batas performa I/O dari kedua teknologi, penting untuk memahami hubungan teoritis antara throughput $S$ dan block size $B$.

Throughput transfer data $S$ adalah jumlah data yang ditransfer per satuan waktu, dan dapat dimodelkan sebagai berikut:

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: Block size (Byte)
$L_{setup}$: Latensi tetap yang terkait dengan pengaturan permintaan I/O dan context switch
$R_{max}$: Bandwidth perangkat keras maksimum dalam penyalinan atau transfer perangkat

Pada akses berkas yang melalui protokol 9P WSL2, nilai $L_{setup}$ ini menjadi sangat besar (karena komunikasi socket serta serialisasi/deserialisasi protokol). Oleh karena itu, jika block size $B$ bernilai kecil (membaca/menulis banyak file kecil berukuran sekitar beberapa KB), pengaruh dari $L_{setup}$ pada penyebut (denominator) menjadi sangat dominan, yang secara drastis akan menurunkan throughput $S$. Sebaliknya, pada akses VHDX yang melewati VMBus di Hyper-V, karena $L_{setup}$ dioptimalkan hingga ke level yang hampir sama dengan interupsi perangkat keras, IOPS yang tinggi tetap dapat dipertahankan meskipun dengan blok berskala kecil.

Realitas matematis inilah yang menjadi dasar logika dari praktik terbaik (best practice): “Di WSL2, Anda tidak boleh meletakkan berkas proyek di sisi Windows”.

7. Kesimpulan: Dua Teknologi Virtualisasi yang Hidup Berdampingan

Hyper-V dan WSL2 bukanlah masalah tentang salah satunya lebih unggul dibanding yang lain, melainkan “dua solusi dengan tujuan yang berbeda”.

WSL2 adalah “alat integrasi terbaik” untuk mendobrak cangkang OS Windows dan membawa ekosistem Linux secara mulus dan cepat ke tangan pengguna Windows. Tidak berlebihan jika dikatakan bahwa ini adalah lingkungan CLI pamungkas untuk para pengembang.
Hyper-V adalah “hypervisor sejati” yang membawa kemampuan manajemen dan isolasi yang kuat ke dalam desktop, sebagaimana yang telah dikembangkan di pusat data enterprise (enterprise data center). Tidak ada yang menandinginya dalam hal membangun jaringan, pengujian OS Windows, maupun simulasi lingkungan infrastruktur.

Dalam lingkungan Windows modern, kedua teknologi ini tidak bersaing secara langsung, melainkan hidup berdampingan secara indah di atas platform VM yang sama. Dengan menggunakan masing-masing teknologi pada tempat yang tepat sesuai kebutuhan, Windows akan menjadi engineering workstation yang paling tangguh dan fleksibel di dunia.

Panduan Pengaturan Lingkungan Pengembangan Ultimate untuk WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

“WSL2 (Windows Subsystem for Linux 2)”, yang menyediakan lingkungan pengembangan native Linux di Windows, telah menjadi alat yang sangat penting dalam pengembangan perangkat lunak modern. Namun, ada perbedaan besar dalam kinerja dan pengalaman pengembangan antara menggunakannya dalam status default dan memahaminya serta menyesuaikan arsitekturnya dengan tepat.

Artikel ini membahas segala hal mulai dari penjelasan arsitektur yang menjadi inti dari WSL2, hingga pengaturan untuk memaksimalkan kinerja, membangun lingkungan terminal yang nyaman, integrasi mulus dengan Docker dan VS Code, dan pengaturan jaringan lanjutan. Kami akan menjelaskan secara menyeluruh semua langkah untuk membangun “Lingkungan Pengembangan Ultimate” yang dibutuhkan oleh insinyur profesional dalam volume lebih dari 10.000 karakter.

1. Arsitektur WSL2 dan Evolusi dari WSL1

Untuk sepenuhnya memaksimalkan potensi WSL2, penting untuk memahami terlebih dahulu struktur internalnya. Pendekatan untuk menjalankan binari Linux di Windows sangat berbeda antara WSL generasi pertama (WSL1) dan WSL2.

WSL1: Lapisan Konversi Panggilan Sistem

WSL1 mengadopsi mekanisme untuk mengonversi (menerjemahkan) panggilan sistem Linux ke API NT Windows secara real time. Ini memiliki keuntungan berupa overhead sumber daya yang sangat kecil karena tidak menggunakan mesin virtual (VM). Namun, sulit untuk sepenuhnya meniru panggilan sistem yang kompleks seperti operasi I/O sistem file, dan menyebabkan penurunan kinerja yang drastis, terutama pada proses yang menangani sejumlah besar file kecil, seperti npm install pada Node.js atau operasi repositori Git.

WSL2: VM Utilitas Ringan dan Kernel Linux Penuh

Pada WSL2, arsitekturnya telah diperbarui, dan kernel Linux asli yang dibangun oleh Microsoft berjalan secara langsung di atas “VM Utilitas Ringan” yang menggunakan subset dari arsitektur Hyper-V. Ini menjamin kompatibilitas 100% untuk panggilan sistem dan secara dramatis meningkatkan kinerja I/O file dibandingkan dengan WSL1 dengan menggunakan disk virtual (VHDX) yang memanfaatkan sistem file ext4 native Linux.

Diagram Mermaid di bawah ini menunjukkan perbedaan struktural antara WSL1 dan WSL2.

flowchart TD
subgraph "Lingkungan OS Windows"
A["Kernel NT Windows"]
A --> F["Sistem File NTFS (Drive C:)"]
end
subgraph "Arsitektur WSL2"
B["Hypervisor Hyper-V"]
B --> C["VM Utilitas Ringan"]
C --> D["Kernel Linux (Microsoft)"]
D --> E["Ruang Pengguna Ubuntu (glibc, bash, dll.)"]
D --> G["Disk Virtual ext4 (.vhdx)"]
end
A -.->|"Berbagi File Jaringan Protokol Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

Pelajaran penting yang dapat diambil dari struktur ini adalah “Akses ke file di sisi Linux (di dalam VHDX) sangat cepat, namun akses ke file di sisi Windows (/mnt/c/) sangat lambat karena harus melalui protokol 9P”. Kode sumber proyek harus selalu ditempatkan di bawah direktori home (~) pada sisi WSL.

2. Analisis Matematika Kinerja: Mengapa WSL2 Cepat?

Mari kita evaluasi peningkatan kinerja WSL2 secara kuantitatif menggunakan model matematika. Salah satu operasi yang paling memakan waktu dalam pengembangan perangkat lunak adalah proses yang melibatkan sejumlah besar I/O file (misalnya, menginstal pustaka atau mem-build).

Total waktu eksekusi $T_{total}$ untuk suatu proses dinyatakan sebagai jumlah waktu komputasi oleh CPU $T_{compute}$ dan waktu yang dibutuhkan untuk disk I/O $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

Dalam kasus WSL1, karena ada overhead untuk mengonversi operasi sisi Linux ke operasi NTFS, waktu I/O dimodelkan sebagai berikut. Di sini, $n$ adalah jumlah operasi file, $t_{ntfs\_syscall}$ adalah waktu eksekusi panggilan sistem sisi Windows, dan $t_{trans}$ adalah overhead dari lapisan konversi.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

Di sisi lain, pada kasus WSL2, karena kernel mengeluarkan I/O secara langsung ke sistem file ext4, overheadnya hanya berupa penundaan yang sangat kecil $t_{virt}$ akibat virtualisasi.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

Pada sistem file umum, karena $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$, jika $n$ sangat besar (melakukan puluhan hingga ratusan ribu operasi file), perbedaan waktu I/O antara WSL1 dan WSL2 akan melebar secara eksponensial.

Selain itu, jika rasio overhead komputasi CPU di lingkungan virtualisasi adalah $\rho$, dengan virtualisasi berbantuan perangkat keras terbaru (Intel VT-x / AMD-V), rasio tersebut akan berada pada kisaran $\rho \approx 0.01 \sim 0.03$ (1 hingga 3%). Oleh karena itu, bahkan pada tugas komputasi murni, ia akan memberikan kinerja sebesar $97\% \sim 99\%$ yang sebanding dengan lingkungan native Linux.

3. Instalasi dan Pembangunan Fondasi

Pada Windows 10/11, instalasi WSL2 telah menjadi sangat sederhana. Cukup buka PowerShell dengan hak administrator dan jalankan perintah berikut.

1
2
3
4
5
6


# WSL2 dan Ubuntu akan diinstal secara default
wsl --install

# Jika Anda ingin menentukan distribusi tertentu
# Dapat diperiksa dengan wsl --list --online
wsl --install -d Ubuntu-24.04

Setelah penginstalan dan melalui proses restart, Anda akan diminta untuk mengatur nama pengguna dan kata sandi UNIX saat pertama kali dijalankan. Pengguna ini terpisah dari pengguna Windows dan hanya valid di dalam WSL.

Jika Anda sudah menggunakan WSL1, konversikan ke WSL2 dengan perintah berikut.

1
2
3
4
5


# Mengonversi distribusi yang ada ke WSL2
wsl --set-version Ubuntu 2

# Menjadikan WSL2 sebagai versi default untuk distribusi yang akan ditambahkan di masa mendatang
wsl --set-default-version 2

4. Rahasia Kontrol Sumber Daya: .wslconfig dan wsl.conf

Salah satu jebakan terbesar di WSL2 adalah “konsumsi memori tak terbatas (pembengkakan proses Vmmem)”. Karena WSL2 menggunakan cache halaman dari kernel Linux, setiap kali I/O dilakukan, ia akan memakan memori host (Windows) tanpa batas. Untuk mencegah hal ini, perlu dilakukan pembatasan sumber daya melalui file konfigurasi.

File konfigurasi WSL2 dibagi menjadi dua: .wslconfig yang memengaruhi Windows secara keseluruhan, dan wsl.conf yang memengaruhi internal setiap distribusi.

4.1. .wslconfig (Sisi Windows)

Buat file di direktori profil pengguna Windows (C:\Users\<Nama Pengguna>\.wslconfig) untuk mengontrol alokasi sumber daya ke VM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<Nama Pengguna>\.wslconfig
[wsl2]
# Jumlah memori maksimum yang dialokasikan untuk VM. Disarankan sekitar 50% hingga 75% dari total memori host
memory=16GB

# Jumlah core CPU yang digunakan (Jika dihilangkan, semua core akan digunakan)
processors=8

# Ukuran file swap
swap=8GB

# Lokasi penyimpanan file swap (Jika ingin menghemat ruang di drive C)
# swapfile=D:\\wsl\\swap.vhdx

# Aktifkan penerusan localhost (Untuk mengakses WSL melalui localhost dari sisi Windows)
localhostForwarding=true

# Secara otomatis melepaskan memori (Hanya Windows 11)
# Secara dinamis melepaskan cache halaman untuk mencegah pembengkakan Vmmem
autoMemoryReclaim=dropcache

[experimental]
# Fitur jaringan lanjutan tersedia pada Windows 11 22H2 dan lebih baru
# Hal ini memungkinkan dukungan IPv6 dan berbagi alamat IP yang sama antara WSL dan Windows
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Sisi Linux)

Edit /etc/wsl.conf di dalam WSL untuk mengontrol perilaku khusus distribusi.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (Diedit di dalam WSL)
[network]
# Nonaktifkan pembuatan /etc/resolv.conf yang dibuat secara otomatis saat WSL dijalankan
# Berguna jika Anda ingin mengatur DNS kustom (misalnya: 8.8.8.8)
generateResolvConf=false

# Atur nama host kustom
hostname=WSL-DevNode

[automount]
# Pengaturan saat memasang drive Windows
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Ubah titik pemasangan (mount point) drive C dari /mnt/c ke /c (untuk mempersingkat jalur)
root=/

[boot]
# Aktifkan systemd (WSL 0.67.6 atau lebih baru)
# Ini memungkinkan snap dan berbagai daemon (seperti Docker) untuk berjalan secara native
systemd=true

[user]
# Pengguna default untuk login
default=kenji

Untuk menerapkan pengaturan ini, Anda perlu menjalankan wsl --shutdown di PowerShell untuk menghentikan sepenuhnya VM WSL sebelum menghidupkannya kembali.

5. Lingkungan Terminal Ultimate: Zsh + Powerlevel10k

Produktivitas tidak akan meningkat jika Anda tetap menggunakan bash bawaan. Kami akan membangun prompt terkuat dengan menggabungkan Zsh, yang menawarkan fitur pelengkapan otomatis dan visibilitas yang kuat, dengan tema super cepat “Powerlevel10k”.

5.1. Pengenalan dan Pengaturan Windows Terminal

Instal “Windows Terminal” dari Microsoft Store. Buka pengaturan JSON (settings.json), tetapkan profil default ke WSL (Ubuntu), dan ubah font menjadi Nerd Font untuk pengembangan (misalnya: HackGen Console NF atau MesloLGS NF).

5.2. Menginstal Zsh dan Oh My Zsh

Jalankan perintah berikut di terminal WSL.

1
2
3
4
5
6


# Memperbarui paket dan menginstal Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Menjalankan skrip instalasi Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Menginstal Powerlevel10k dan Plugin

Kami akan memperkenalkan plugin (penyorotan sintaksis dan pelengkapan otomatis input) untuk lebih meningkatkan Zsh, serta tema Powerlevel10k.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Edit ~/.zshrc untuk mengaktifkan tema dan plugin.

1
2
3
4
5


# Perubahan pada ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Tambahkan ke array plugin
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Simpan dan jalankan source ~/.zshrc, panduan konfigurasi Powerlevel10k (p10k configure) akan dimulai. Ikuti petunjuk di layar untuk menyesuaikan prompt Anda sendiri (gaya prompt, ada/tidaknya ikon, informasi yang ditampilkan, dll.). Nama cabang dan status Git, versi Node.js, waktu eksekusi perintah, dll. akan ditampilkan secara real-time, sehingga secara dramatis meningkatkan efisiensi pengembangan Anda.

6. VS Code Remote - Integrasi Mulus dengan WSL

Dalam pengembangan menggunakan WSL2, ekstensi “Remote - WSL” adalah mekanisme yang memungkinkan akses mulus ke file di dalam WSL dari IDE (Visual Studio Code) yang diinstal pada sisi Windows.

Penjelasan Arsitektur

Diagram urutan di bawah ini menunjukkan bagaimana VS Code berkomunikasi dengan WSL2.

sequenceDiagram
autonumber
participant U as "Pengembang"
participant V as "UI VS Code (Windows)"
participant S as "Server VS Code (WSL2)"
participant F as "Sistem File ext4 (WSL2)"
U->>V: "Ketik `code .` di Terminal WSL"
V->>S: "Membangun Koneksi RPC melalui Vsock"
Note over V,S: Berkomunikasi menggunakan Hyper-V socket alih-alih TCP/IP
S->>F: "Membaca File Sumber / Menjalankan Linter"
F-->>S: "Mengembalikan Data & Analisis"
S-->>V: "Mengalirkan hasil Language Server ke UI"
V-->>U: "Menampilkan penyorotan sintaksis & kesalahan"

VS Code di sisi Windows hanya berfungsi sebagai “klien tipis (UI)”, dan semua tugas berat seperti Language Server, debugger, dan eksekusi terminal diproses oleh “VS Code Server” di sisi WSL. Hal ini memungkinkan lingkungan yang bersih hanya di sisi WSL tanpa perlu menginstal Node.js atau Python di sisi Windows.

Pengaturan VS Code yang Wajib

Instal “WSL” (ms-vscode-remote.remote-wsl) dari “Extensions” di VS Code. Setelah itu, cukup pindah ke direktori proyek di terminal WSL dan jalankan code ., dan VS Code di sisi Windows akan diluncurkan dengan direktori tersebut terbuka.

Poin Penting (Masalah Kode Baris Baru): Kode baris baru berbeda antara Windows dan Linux (Windows menggunakan CRLF, Linux menggunakan LF). Saat mengembangkan di WSL, pastikan untuk mengatur pengaturan core.autocrlf Git dan pengaturan default file VS Code ke LF. Jika Anda mengabaikan hal ini, Anda akan diganggu oleh kesalahan misterius saat menjalankan skrip shell atau kontainer Docker.

1
2


# Pengaturan kode baris baru Git di sisi WSL
git config --global core.autocrlf input

Tambahkan juga hal berikut ini ke settings.json (pengaturan remote) di VS Code.

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Optimasi Docker Desktop dan Integrasi WSL2

Ada dua pendekatan utama untuk menggunakan Docker di lingkungan WSL2.

Menginstal Docker Desktop for Windows dan mengaktifkan fitur integrasi WSL2.
Menginstal langsung Docker Engine Native di dalam WSL2 (seperti Ubuntu).

Pendekatan 1: Docker Desktop (Direkomendasikan)

Ini sering kali direkomendasikan karena mudah dikelola dengan GUI dan akses transparan ke kontainer antara Windows dan WSL. Periksa hal-hal berikut dari Pengaturan (Settings) Docker Desktop.

Centang General -> Use the WSL 2 based engine.
Centang Resources -> WSL Integration -> Enable integration with my default WSL distro dan nyalakan tombol geser untuk distribusi (Ubuntu) yang Anda gunakan.

Ini memungkinkan Anda menjalankan perintah docker langsung dari terminal WSL2, dan komunikasi dengan daemon Docker akan dialihkan melalui VM ringan khusus (docker-desktop dan docker-desktop-data) yang dikelola oleh Docker Desktop.

Pendekatan 2: Pengenalan Langsung Docker Engine Native

Jika Anda memiliki batasan jaringan perusahaan (seperti menghindari versi berbayar Docker Desktop) atau ingin mengurangi overhead kinerja hingga batas ekstrem, aktifkan systemd di /etc/wsl.conf lalu instal Docker sebagai server Ubuntu murni.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Kutipan dari prosedur instalasi resmi Docker di WSL2 Ubuntu dengan systemd diaktifkan
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Menambahkan repositori
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Menambahkan pengguna saat ini ke grup docker (untuk menjalankan tanpa sudo)
sudo usermod -aG docker $USER

Setelah restart, systemctl start docker akan berfungsi persis seperti di lingkungan Linux native dan menawarkan kinerja yang tinggi.

8. Integrasi Kunci SSH: Otentikasi Mulus di Windows dan WSL

Saat melakukan kloning SSH dari Git atau koneksi SSH ke server jarak jauh, mengelola kunci SSH secara terpisah di sisi Windows dan sisi WSL sangatlah merepotkan. Untuk menyeimbangkan antara keamanan dan kenyamanan, kami akan mengonfigurasi jembatan untuk menghubungkan agen SSH (atau manajer kata sandi seperti 1Password) yang berjalan di Windows ke sisi WSL.

Di sini, kita akan membahas pendekatan yang paling aman dan modern, yaitu menggunakan fitur agen SSH 1Password atau OpenSSH Authentication Agent dari Windows dan meneruskannya ke soket domain UNIX WSL2 menggunakan npiperelay atau socat.

Penerusan Soket ssh-agent

Biasanya, agen SSH yang disediakan sebagai Named Pipe (pipa bernama) di Windows perlu dikonversi ke file soket di sisi WSL. Anda dapat menggunakan wsl-ssh-agent atau fitur yang disediakan oleh 1Password untuk membuatnya lebih mudah.

Di layar pengaturan 1Password, aktifkan “Developer” -> “Gunakan Agen SSH”. Selanjutnya, tambahkan pengaturan berikut ke ~/.zshrc atau ~/.bashrc di sisi WSL untuk mengikat soket secara otomatis saat login.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Menambahkan ke ~/.zshrc (Contoh jika menggunakan Agen SSH 1Password)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Jika soket tidak ada atau proses tidak terikat saat WSL dijalankan, teruskan menggunakan socat dan npiperelay
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Memulai socat di latar belakang dan menghubungkan Named Pipe di sisi Windows ke soket UNIX di sisi WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

*Anda harus menginstal npiperelay.exe dan menambahkannya ke path di sisi Windows terlebih dahulu.

Setelah pengaturan ini selesai, ketika Anda menjalankan ssh-add -l dari terminal WSL, daftar kunci publik dari kunci SSH yang terdaftar di 1Password atau di sisi Windows akan ditampilkan. Dengan demikian, Anda dapat lolos otentikasi dengan aman tanpa harus menyalin file kunci privat ke dalam WSL.

9. Pemeliharaan: Optimasi (Kompaksi) VHDX yang Membengkak

Salah satu kelemahan terbesar WSL2 adalah bahwa “ukuran file dari disk virtual di sisi Windows (.vhdx) tidak menyusut secara otomatis bahkan jika Anda menghapus image Docker atau menghapus file”. Jika Anda terus mengembangkan untuk jangka waktu yang lama, file ext4.vhdx dapat membengkak hingga puluhan atau ratusan GB.

Untuk mengosongkan ruang disk, Anda perlu mengoptimalkan (Compact) VHDX dari sisi Windows secara berkala.

Pertama, matikan WSL sepenuhnya.
1

wsl --shutdown
Buka PowerShell dengan hak administrator, dan jalankan perintah diskpart di bawah ini, atau perintah Optimize-VHD dari modul Hyper-V (yang terakhir hanya dapat digunakan jika Hyper-V diaktifkan).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Jika modul Hyper-V tersedia
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# Jika menggunakan diskpart
diskpart
# Masukkan secara interaktif dalam prompt di bawah ini
DISKPART> select vdisk file="C:\Users\<Nama Pengguna>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

Dengan melakukan operasi ini secara berkala, Anda bisa memulihkan ruang kosong di drive C yang terbuang percuma.

10. Penutup

WSL2 telah sepenuhnya melampaui batasan sebagai “sekadar bonus Linux yang berjalan di Windows”, dan telah berevolusi menjadi platform pengembangan yang kuat yang tidak kalah, atau bahkan lebih baik dari mesin macOS atau mesin Linux native.

Dengan menerapkan semua pengaturan yang dijelaskan dalam artikel ini (optimasi sumber daya dengan .wslconfig, peningkatan terminal dengan Zsh + Powerlevel10k, akses transparan dengan VS Code Remote, serta integrasi SSH dan pemeliharaan VHDX), Anda akan dapat melengkapi “Lingkungan Pengembangan Ultimate” yang bebas stres, cepat, dan aman.

Meskipun membutuhkan sedikit upaya untuk menyiapkan lingkungan tersebut, begitu Anda menetapkan pengaturannya, produktivitas rekayasa perangkat lunak Anda akan meningkat secara dramatis di masa mendatang. Kami harap Anda mengeksplorasi penyesuaian lebih lanjut berdasarkan panduan ini sesuai dengan proyek dan preferensi Anda.