Menjalankan aplikasi x86/x86-64 pada Fedora Asahi Remix
Ada banyak sekali aplikasi warisan x86/x86-64 yang ingin dijalankan oleh pengguna di platform arm64, termasuk aplikasi Windows dan game. Untuk mendukung hal ini di Fedora Asahi Remix, kami telah mengintegrasikan serangkaian komponen yang sudah ada dan khusus untuk memungkinkan aplikasi x86/x86-64 dijalankan secara transparan langsung di Linux arm64.
Karena platform Apple menggunakan ukuran halaman 16K secara default dan prosesor x86/x86-64 menggunakan ukuran halaman 4K, hal ini menjadi cukup rumit, karena aplikasi x86/x86-64 umumnya tidak berfungsi saat dijalankan pada kernel host yang memerlukan penyelarasan halaman 16K. Untuk mengatasi hal ini, kami menggunakan microVM untuk menjalankan kernel Linux guest yang sepenuhnya terpisah dalam mode ukuran halaman 4K. Untuk menjaga agar proses ini berjalan sehalus mungkin, lingkungan guest dirancang sedekat mungkin dengan lingkungan host, dan kami menggunakan GPU passthrough konteks asli untuk mendapatkan kinerja grafis tinggi di dalam lingkungan guest.
Tumpukan terdiri dari komponen-komponen berikut:
-
muvm (paket:
muvm), runner microVM khusus kami yang didasarkan pada libkrun. Ini juga mencakup komponen untuk pengalihan X11 dan proksi perangkat masukan HID. -
FEX-emu (paket:
fex-emu), emulator x86/x86-64 berbasis ruang pengguna yang cepat dan berfokus pada keakuratan. -
Fedora FEX RootFS (paket:
fex-emu-rootfs-fedora), yang menyediakan dependensi perpustakaan umum x86/x86-64 untuk digunakan oleh aplikasi yang diemulasikan. -
mesa (paket:
mesa-fex-emu-overlay-i386danmesa-fex-emu-overlay-x86-64), dibangun untuk arsitektur x86/x86-64 dan dikemas sebagai overlay FEX RootFS. Ini menyediakan dukungan OpenGL/OpenCL/Vulkan untuk GPU Apple.
Kami juga memiliki Steam wrapper yang mengotomatiskan proses instalasi dan peluncuran Steam di dalam stack microVM. Saat menjalankan game Windows menggunakan Steam, komponen open-source ini digunakan di belakang layar:
-
Proton, sebuah distribusi Wine yang ditujukan untuk gaming.
-
dxvk, lapisan terjemahan yang mengonversi antarmuka pemrograman aplikasi (API) Windows DirectX 8 hingga DirectX 11 ke Vulkan.
-
vkd3d-proton, lapisan terjemahan yang mengubah antarmuka pemrograman aplikasi (API) Windows DirectX 12 menjadi Vulkan.
Ruang lingkup
Tumpukan teknologi ini terutama ditujukan untuk menjalankan game x86 dan x86-64, tetapi juga dapat digunakan untuk menjalankan aplikasi produktivitas non-game. Jika memungkinkan, sebaiknya gunakan alternatif asli daripada emulasi. Silakan baca entri FAQ ini untuk informasi lebih lanjut.
Ruang lingkup solusi ini terbatas pada aplikasi x86 dan x86-64 yang portabel yang dimaksudkan untuk dijalankan dari direktori home Anda (atau, paling jauh, dibongkar secara manual ke dalam /opt oleh pengguna), termasuk AppImages. Solusi ini tidak dimaksudkan untuk menjalankan aplikasi x86-64 yang harus diinstal sebagai paket sistem, yang dibangun untuk distribusi Linux tertentu, atau memerlukan instalasi dependensi sistem yang kompleks, atau yang memerlukan menjalankan installer khusus sebagai root.
Secara khusus, lingkungan x86-64 bukan sebuah filesystem root yang berdiri sendiri, melainkan overlay minimal yang bersifat immutable di atas filesystem root arm64 Anda yang sudah ada. Artinya, Anda tidak dapat melakukan perubahan, menginstal paket tambahan, dan sebagainya. Tidak ada akses root sama sekali di dalam lingkungan x86-64 ini.
Penggunaan
Steam
Cukup gunakan perintah dnf install steam untuk menginstal wrapper Steam kami, lalu jalankan Steam dari launcher desktop Anda (atau perintah steam) untuk mengunduh dan menginstal Steam. Ini akan menginstal semua dependensi yang diperlukan secara otomatis.
Aplikasi lain
Untuk menginstal stack emulasi secara terpisah, gunakan perintah dnf install fex-emu. Perintah ini akan secara otomatis menginstal dependensi yang diperlukan.
Anda tidak dapat menjalankan aplikasi x86-64 secara langsung dari host (belum), karena aplikasi tersebut harus dijalankan dari microVM. Untuk melakukannya, jalankan perintah muvm -- /path/to/executable. Anda harus menggunakan jalur absolut, karena muvm saat ini tidak mempertahankan direktori kerja saat ini. Dalam lingkungan ini, dukungan binfmt kernel sudah dikonfigurasi untuk menggunakan FEX untuk menjalankan aplikasi x86/x86-64, jadi Anda seharusnya dapat menjalankannya langsung.
Jika aplikasi Anda menggunakan skrip shell peluncur alih-alih menjalankan biner utamanya secara langsung, Anda harus menjalankannya melalui FEXBash. Misalnya, gunakan muvm -- FEXBash /path/to/launcher.sh. Dengan cara ini, shell akan berjalan dalam lingkungan emulasi dan beberapa perintah shell kritis akan berperilaku seperti pada aplikasi x86-64, sehingga skrip shell lebih mungkin berfungsi sesuai yang diharapkan.
Anda juga dapat menggunakan muvm -- bash untuk meluncurkan shell arm64 di dalam 4K MicroVM, atau muvm -- FEXBash untuk meluncurkan shell x86-64. Shell x86-64 akan berperilaku serupa dengan shell arm64, dan sebagian besar perintah akan dijalankan sebagai biner arm64, tetapi beberapa perintah (seperti ls) akan dijalankan dalam mode emulasi, yang memungkinkan Anda “melihat” dunia seperti yang dilakukan oleh aplikasi x86-64.
Bagaimana cara kerjanya
muvm membuat mesin virtual yang berbagi sebanyak mungkin dengan sistem operasi host. Di dalam VM, sistem berkas root adalah sama dengan sistem berkas root host, dengan pengecualian sebagai berikut:
-
/dev,/sys, dan/procbersifat privat bagi guest, kecuali/dev/shmyang dibagikan dengan host, memungkinkan aplikasi host dan aplikasi guest untuk berbagi memori secara konsisten. -
/runjuga bersifat pribadi bagi guest -
Citra rootfs dan overlay FEX-emu dipasang di bawah
/run/fex-emu/, dengan rootfs overlay gabungan tersedia di/run/fex-emu/rootfs. -
Direktori
/usr/share/fex-emudan/usr/local/share/fex-emudi-overmount menggunakan tmpfs guna menyisipkan berkasConfig.jsondari FEX yang telah disesuaikan untuk penggunaan di dalam mesin virtual (VM) -
Sebuah tmpfs juga di-mount pada
/tmp/.X11-unix, sehingga soket server X11 bersifat privat untuk VM -
Seluruh tampilan sistem berkas host tersedia di
/run/muvm-host, termasuk mount yang ditumpangkan (overlaid). Misalnya, Anda dapat mengakses direktori/runhost di/run/muvm-host/run. (Catatan: /run/muvm-host/dev memang ada, tetapi tidak akan berfungsi seperti yang mungkin Anda harapkan. Perangkat milik host tidak tersedia di dalam guest.)
Ini berarti bahwa /usr, /home, /etc, /opt, /var, /tmp, dan direktori lain di sistem berkas root Anda dibagikan antara guest dan host. Sistem operasi guest aarch64 tidak menjalankan sistem berkas rootnya sendiri, melainkan menjalankan biner yang sama persis dengan yang dijalankan oleh sistem operasi host.
Selain itu, FEX sendiri menggunakan sistem berkas yang dipasang di /run/fex-emu/rootfs sebagai RootFS virtualnya. Ini berarti bahwa aplikasi x86/x86-64 (dan hanya aplikasi tersebut) akan melihat isi direktori tersebut ditimpa di atas sistem berkas root. Inilah cara kami membuat perpustakaan x86/x86-64 tersedia bagi aplikasi-aplikasi tersebut, sambil tetap berbagi sebagian besar isi sistem berkas.
Saat muvm dimulai, ia mendaftarkan FEX sebagai penyedia binfmt, sehingga aplikasi x86/x86-64 akan dijalankan secara transparan melalui FEX. Saat startup, FEX akan mendeteksi bahwa dukungan TSO tersedia di platform Apple Silicon (bahkan di dalam VM), dan secara otomatis mengaktifkannya untuk emulasi yang lebih cepat dan akurat.
Titik mount di host akan diteruskan ke guest saat pertama kali diakses, secara otomatis. Hal ini memungkinkan aplikasi guest untuk membedakan sistem berkas yang berbeda, yang menjaga semantik perangkat/inode tetap benar. Jika Anda memiliki partisi yang dipasang di host pada /mnt/steam dan Anda menjalankan perintah mount di dalam sistem guest, Anda tidak akan melihatnya pada awalnya. Jika Anda menjalankan ls /mnt/steam dan kemudian menjalankan mount lagi, mount tersebut akan secara otomatis ditambahkan ke daftar mount. Ini normal dan berfungsi sesuai yang diharapkan!
|
Masalah yang diketahui
Kinerja tidak terlalu baik
Karena proyek ini masih berada pada tahap awal, kami memprioritaskan akurasi dan kestabilan untuk rilis awal. Optimalisasi performa akan dilakukan secara bertahap. Kami telah mengidentifikasi sejumlah perubahan yang diperkirakan dapat meningkatkan performa secara signifikan, dan saat ini kami sedang aktif mengerjakannya!
Untuk game Windows DX8-DX11 yang dijalankan melalui Proton, Anda bisa mencoba menggunakan WineD3D sebagai alternatif dari DXVK. WineD3D menggunakan OpenGL sebagai backend-nya alih-alih Vulkan, dan mungkin memberikan performa yang lebih baik berkat optimasi pada driver OpenGL kami yang tidak tersedia di Vulkan. Untuk mengaktifkannya, ubah opsi peluncuran Steam menjadi PROTON_USE_WINED3D=1 %command%. Perlu dicatat bahwa DXVK umumnya memiliki kompatibilitas yang lebih baik, jadi ini adalah pilihan dengan pertukaran (trade-off). Beri tahu kami gime mana saja yang berjalan lebih baik dengan salah satu backend!
Game 32-bit yang lebih lama mungkin berjalan sangat lambat jika banyak menggunakan unit floating-point x87 80-bit, karena operasi tersebut harus diemulasikan melalui perangkat lunak demi kompatibilitas penuh (masalah serupa juga terjadi pada Rosetta di macOS). Anda dapat menjalankan game-game ini dengan emulasi floating-point 64-bit berbasis perangkat keras, yang memang kurang akurat tetapi jauh lebih cepat. Untuk mengaktifkannya, ubah opsi peluncuran Steam menjadi: FEX_X87REDUCEDPRECISION=1 %command%. Mode ini mungkin menimbulkan masalah kecil pada beberapa game akibat pengurangan akurasi, namun sebagian besar game seharusnya tetap berjalan dengan baik (dan jauh lebih cepat).
VM menggunakan banyak RAM
Untuk memungkinkan aplikasi guest menggunakan jumlah RAM yang besar (seperti yang dibutuhkan oleh beberapa game modern), secara default muvm mengizinkan guest untuk menggunakan hingga 80% dari RAM sistem. Hal ini juga berarti sebagian dari RAM tersebut akan digunakan oleh cache halaman guest, sehingga terlihat bagi host seolah-olah VM menggunakan sebagian besar RAM sistem. muvm memiliki kemampuan untuk mengurangi penggunaan page cache guest saat tekanan memori di host meningkat, sehingga jika penggunaan memori di host bertambah, VM akan menyesuaikan dan mengurangi penggunaannya (selama cache yang tidak digunakan masih dapat dibuang).
Pada mesin dengan ukuran RAM yang lebih kecil (16GB atau kurang), kami menyarankan untuk tidak menjalankan aplikasi host yang berat saat VM sedang digunakan. Kami tidak menyarankan untuk menjalankan game yang kompleks pada mesin dengan 8GB RAM.
Untuk memeriksa penggunaan memori VM saat sedang berjalan, gunakan perintah muvm -ti -- free. Anda juga dapat menjalankan muvm -ti -- htop (jika Anda telah menginstal htop) untuk mendapatkan informasi yang lebih rinci, atau ganti dengan alat informasi sistem pilihan Anda.
Jika Anda ingin membatasi penggunaan memori maksimum MicroVM, Anda dapat mengonfigurasi alokasi RAM guest menggunakan parameter muvm --mem=SIZE.
Saya tidak dapat mengakses media yang di-mount di /run/media di dalam VM
Ini tidak berfungsi (bahkan melalui /run/muvm-host/run/media) karena dukungan POSIX ACL yang belum tersedia di libkrun saat ini. Anda harus secara manual me-mount semua disk yang ingin digunakan di dalam VM, misalnya di bawah /mnt.
Pertanyaan yang Sering Diajukan
Apakah ini seperti Rosetta di macOS?
Ini adalah pendekatan yang paling mendekati Rosetta yang bisa kami capai! Perbedaan utamanya adalah Rosetta menghindari masalah ukuran halaman (page size) dengan memanfaatkan dukungan multiple page size pada kernel XNU untuk proses pengguna, sehingga tidak memerlukan VM. Meskipun secara teori memungkinkan untuk membuat Linux mendukung ukuran halaman campuran (mixed page sizes), proyek semacam itu akan sangat besar dan kemungkinan memerlukan waktu bertahun-tahun untuk diselesaikan. Selain itu, belum jelas apakah perubahan semacam itu akan diterima di upstream (Linux bahkan belum mendukung pemilihan ukuran halaman saat boot dalam satu kernel!).
Selain permasalahan ukuran halaman (page size), FEX dan Rosetta adalah teknologi yang sebanding (keduanya merupakan emulator, terlepas dari apa yang diklaim oleh pemasaran Apple). Baik FEX maupun Rosetta sama-sama memanfaatkan fitur unik pada CPU Apple Silicon yang sangat penting untuk performa emulasi x86/x86-64: mode TSO (Total Store Ordering). Berkat fitur ini, FEX dapat menghadirkan emulasi x86/x86-64 yang cepat dan akurat di sistem Apple Silicon.
Mengapa tidak menggunakan kernel host 4K saja?
Meskipun sistem Apple Silicon mendukung halaman CPU 4K, perangkat keras lainnya (seperti IOMMU dan GPU) hanya berjalan dengan halaman 16K. Kernel Linux tidak bekerja dengan baik dalam lingkungan seperti ini, karena secara umum mengasumsikan bahwa ukuran halaman CPU setidaknya sama besar atau lebih besar dari ukuran halaman IOMMU. Di masa lalu, kami sempat mencoba beberapa patch kernel untuk membuatnya bekerja sebagian, namun hasilnya buggy dan tidak lengkap, sehingga pendekatan tersebut akhirnya kami tinggalkan. Kalaupun berhasil berjalan dengan baik, menjalankan seluruh sistem dengan halaman 4K tetap memiliki dampak performa yang terukur, jadi kami tidak akan pernah mengirimkan kernel 4K sebagai default. Karena itu, menjalankan aplikasi x86/x86-64 akan mengharuskan pengguna untuk mengganti kernel secara manual dan me-reboot sistem, yang jelas merepotkan.
Mengapa tidak box64?
box64 dan FEX-Emu memiliki pendekatan yang berbeda dalam emulasi, dengan FEX-Emu berfokus pada akurasi yang lebih baik secara default (tetapi memerlukan pengaturan yang lebih kompleks) sementara box64 bertujuan untuk mencakup lebih banyak kasus penggunaan “out of the box” (seperti menjalankan subset aplikasi langsung pada kernel 16K tanpa VM menggunakan beberapa trik). Kami memilih FEX-Emu untuk stack kami karena kami yakin pendekatan ini akan memiliki kompatibilitas yang lebih tinggi, tetapi keduanya memiliki kegunaannya masing-masing. box64 tersedia dalam paket di Fedora, jadi kami mendorong pengguna untuk mencobanya (baik secara native maupun di dalam muvm) dan beri tahu kami bagaimana perbandingannya!
Aplikasi x86-64 atau x86 saya kekurangan beberapa perpustakaan sistem, apa yang harus saya lakukan?
Sistem File Root (RootFS) kami yang immutable berisi kumpulan besar perpustakaan x86-64 dan x86 yang umum digunakan sebagai dependensi, tetapi kami tidak dapat menyertakan setiap perpustakaan yang mungkin ada. Anda dapat melihat daftar paket di di sini.
Jika pustaka yang hilang merupakan pustaka yang relatif sederhana dan umum, tidak memiliki dependensi yang kompleks (atau sangat sedikit), serta tidak akan menambah ukuran RootFS kami secara signifikan, silakan ajukan pull request (PR) ke repositori yang ditautkan di atas agar kami dapat mempertimbangkan untuk menyertakannya dalam rilis RootFS berikutnya. Pastikan untuk mencantumkan aplikasi apa yang membutuhkan pustaka tersebut, serta alasan mengapa menurut Anda pustaka itu layak untuk disertakan.
Jika aplikasi Anda membutuhkan kerangka kerja yang kompleks (seperti Qt) atau pustaka yang tidak umum atau bersifat khusus (niche), maka aplikasi tersebut tidak dibangun sebagai aplikasi "portabel" dan memang tidak diharapkan dapat langsung berjalan di sebagian besar sistem tanpa penyesuaian. Untuk mengatasi masalah ini, Anda dapat mengunduh pustaka-pustaka yang hilang secara manual, mengekstraknya ke direktori home, lalu menggunakan LD_LIBRARY_PATH agar aplikasi dapat menemukannya. Anda dapat menggunakan perintah berikut untuk mengunduh paket RPM x86-64 dari instalasi Fedora berbasis arm64 Anda:
Setelah itu, Anda dapat menggunakan `rpmdev-extract` untuk mengekstrak isi dari file RPM tersebut, lalu mengonfigurasi `LD_LIBRARY_PATH` sesuai kebutuhan agar aplikasi dapat menemukan pustaka yang diperlukan.
Anda juga dapat menimpa (overlay) paket RPM ke dalam RootFS yang sudah ada, meskipun hal ini tergolong fitur tingkat lanjut. Setelah Anda memiliki file RPM, Anda bisa mengonversinya menjadi image erofs dengan perintah berikut:
``` rpm2archive -n mypackage.rpm mkfs.erofs --tar=f mypackage.rpm.erofs mypackage.rpm.tar ```
Kemudian, Anda dapat menjalankan `muvm` secara manual dengan image dasar erofs dan image erofs kustom Anda di atasnya, seperti ini:
muvm \ -f /usr/share/fex-emu/RootFS/default.erofs \ -f /usr/share/fex-emu/overlays/mesa-x86_64.erofs \ -f /usr/share/fex-emu/overlays/mesa-i386.erofs \ -f mypackage.rpm.erofs \ <your muvm arguments here>
Langkah ini akan melakukan overlay paket tambahan ke dalam RootFS yang digunakan oleh FEX. Harap diingat bahwa metode ini mungkin tidak selalu bekerja sesuai harapan, dan tidak dianggap sebagai solusi yang didukung secara resmi.
=== Steam mengatakan steamwebhelper mengalami crash, apa yang harus saya lakukan?
Cukup biarkan Steam memulai ulang, dan seharusnya akan berfungsi pada percobaan kedua. Steam memiliki batas waktu (timeout) untuk steamwebhelper, dan saat dijalankan melalui emulasi, proses awalnya cukup lambat hingga batas waktu tersebut habis. Masalah ini biasanya hanya terjadi saat cold startup (saat pertama kali menjalankan Steam setelah sistem dinyalakan).
=== Saya tidak dapat mengunduh/menjalankan beberapa game di Steam
Pastikan Steam Play diaktifkan untuk semua game. Opsi ini dapat ditemukan di Menu > Pengaturan > Kompatibilitas > Aktifkan Steam Play untuk semua judul lainnya. Restart Steam setelah diaktifkan.
=== Menekan tombol membuat touchpad berhenti merespons
Hal ini disebabkan oleh fitur “Nonaktifkan saat mengetik” pada touchpad. Anda dapat menonaktifkannya di pengaturan touchpad/input untuk lingkungan desktop Anda.
=== Bisakah saya menjalankan aplikasi Windows di luar Steam?
Saat ini, kami tidak mendukung menjalankan aplikasi Windows di luar Steam karena Wine non-Proton belum berfungsi di Fedora. Kami sedang bekerja untuk menyelesaikan masalah FEX (https://github.com/FEX-Emu/FEX/pull/4225), jadi kami berharap dapat mendukung ini dalam waktu dekat.
Sementara itu, Anda dapat menggunakan Proton dari Steam untuk menjalankan aplikasi Windows non-Steam secara langsung dari Steam.
=== Apakah saya dapat menjalankan aplikasi Linux x86-64/x86?
Game Linux asli umumnya dapat berjalan di bawah muvm, asalkan game tersebut bersifat mandiri dan tidak bergantung pada perpustakaan sistem host yang kompleks (kami menyediakan berbagai dependensi umum, tetapi tidak semua dependensi yang ada).
=== Apakah Wayland didukung?
Wayland saat ini tidak didukung di dalam VM. Karena sebagian besar aplikasi x86/x86-64 legacy yang ingin dijalankan oleh pengguna adalah aplikasi X11, kami fokus pada dukungan X11 terlebih dahulu. Ini berarti Anda tidak dapat menjalankan aplikasi Wayland asli di dalam VM saat ini. Tentu saja, desktop host tetap merupakan desktop Wayland, dan dukungan X11 disediakan oleh XWayland.
=== Apakah saya dapat mengakses perangkat keras dari aplikasi yang berjalan di dalam microVM?
Karena VM tidak melewati perangkat keras host apa pun selain GPU dan sistem berkas virtual, Anda tidak dapat menggunakan aplikasi yang memerlukan akses langsung ke perangkat keras. Kami menggunakan passthrough perangkat lunak untuk antarmuka berikut:
- Protokol X11 (layar, keyboard, mouse)
- Pengontrol game melalui passthrough HID/UINPUT
- Pengelolaan suara melalui protokol soket PulseAudio footnote:[Ini berfungsi dengan PipeWire yang berjalan di host dengan pipewire-pulse, yang telah diinstal secara default. Anda *tidak* perlu dan tidak boleh menginstal PulseAudio yang sebenarnya, karena hal itu akan merusak dukungan speaker Anda!]
Kami sedang meneliti kemungkinan menggunakan PipeWire, yang akan memungkinkan penggunaan webcam di dalam VM.
=== Apakah saya dapat menggunakan metode input (IMEs) dalam aplikasi di dalam microVM?
Anda dapat menggunakan sistem metode input klasik _xim_ yang digunakan di X11. muvm seharusnya sudah mengatur variabel lingkungan yang diperlukan agar ini dapat berfungsi pada aplikasi Qt dan GTK (dengan memuat plugin "xim"), selama kerangka kerja metode input yang Anda gunakan di sistem host mendukungnya. Kami telah menguji ini dengan _fcitx5_ dan Steam yang dijalankan di KDE Plasma.
Di masa mendatang, setelah Wayland passthrough didukung, mekanisme input asli Wayland seharusnya dapat bekerja dengan kerangka kerja metode input apa pun di sistem host (melalui plugin yang biasanya disebut "wayland"). Saat ini tidak ada rencana untuk mendukung metode input yang tidak berbasis sistem jendela (seperti plugin "ibus" dan "fcitx" langsung), karena hal tersebut akan mengharuskan kami menyertakan pustaka bersama (shared library) x86-64 untuk semua metode input yang mungkin dalam sistem virtual x86-64 yang bersifat tidak dapat diubah (immutable), serta memerlukan proxying protokol khusus mereka (yang secara praktik tidak memungkinkan dilakukan).
=== Apakah ini seperti VM Qemu/libvirt/UTM/Parallels/VMWare/VirtualBox/dll.?
Tidak, muvm tidak bekerja seperti VM sistem penuh (whole-system virtual machine) tradisional. Meskipun muvm juga menggunakan KVM sebagai backend untuk virtualisasi yang efisien, konsepnya sangat berbeda dari VM tradisional yang menjalankan sistem operasi guest secara terpisah. Kernel guest-nya adalah https://github.com/containers/libkrunfw[kernel khusus] yang dioptimalkan untuk proses booting yang berlangsung dalam waktu sangat singkat, dan VM monitor meneruskan sistem berkas host hampir apa adanya. Tidak ada passthrough perangkat keras tingkat rendah (seperti USB), melainkan fokus pada passthrough protokol perangkat lunak tingkat tinggi seperti X11 atau Wayland. VM ini tidak menjalankan sistem init mandiri, hanya kode inisialisasi minimal. Artinya, lingkungan dalam VM akan "terasa" hampir sama dengan OS host dari sudut pandang aplikasi, hanya saja menggunakan ukuran halaman 4K, bukan 16K.
=== Apakah browser berfungsi di dalam mesin virtual (VM) guest?
Ya, tetapi aplikasi tersebut akan berjalan dalam mode X11. Namun, ada satu catatan penting: *instansi browser di dalam guest tidak dapat berkomunikasi dengan instansi browser di luar guest, dan sangat berisiko menjalankan profil browser yang sama di guest dan host secara bersamaan*.
Untuk menghindari masalah ini, muvm mengatur variabel lingkungan agar Firefox menggunakan profil khusus saat dijalankan di dalam VM. Dengan begitu, aplikasi yang membuka browser (misalnya untuk login atau dokumentasi) tetap akan berfungsi sebagaimana mestinya, namun Firefox akan dijalankan dengan profil terpisah yang tidak memiliki akses ke cookie, riwayat, dan data pribadi Anda lainnya.
CAUTION: Jika Anda menjalankan profil browser yang sama secara bersamaan di guest dan host, data profil Anda berisiko rusak. Jika browser default Anda bukan Firefox, dan Anda menjalankan aplikasi yang diemulasikan yang mungkin membuka browser default secara tidak sengaja, kami sangat menyarankan untuk menutup semua jendela browser terlebih dahulu sebelum menggunakan muvm, atau secara manual mengatur profil browser yang terpisah.
=== Apakah saya bisa menggunakan sudo di dalam VM?
Karena monitor VM berjalan dengan identitas pengguna Anda sendiri, ia tidak dapat memperoleh hak akses root. "root" di dalam VM tetap hanya memiliki hak akses pengguna Anda sendiri, sehingga penggunaan sudo tidak relevan (dan memang tidak akan berfungsi). Kami merekomendasikan untuk menginstal perangkat lunak yang ingin Anda gunakan dengan muvm+FEX di bawah direktori home Anda. Untuk perangkat lunak yang dirancang untuk diinstal di bawah /opt atau sejenisnya, kami merekomendasikan untuk melakukan langkah-langkah instalasi secara manual di sistem operasi host, dan lalu cukup menjalankan aplikasinya melalui muvm.
Jika Anda memerlukan akses ke shell root di dalam VM untuk tujuan debugging, Anda dapat menjalankan perintah `muvm -tip 3335 +++--+++ bash`. Perlu diingat bahwa, meskipun Anda memiliki akses root, Anda tidak dapat memodifikasi sebagian besar file sistem yang dimiliki oleh root, dan semua file yang Anda buat akan sebenarnya dimiliki oleh identitas pengguna non-root Anda. Shell root terutama berguna untuk melakukan hal-hal seperti `strace` proses lain atau mengubah pengaturan kernel guest atau konfigurasi jaringan (tetapi perubahan ini tidak akan bertahan setelah VM di-restart).
=== Apakah aplikasi yang berada di dalam VM dapat berkomunikasi dengan aplikasi di luar VM?
Komunikasi sebagian besar terbatas pada sistem berkas host. Mesin virtual (VM) berbagi direktori home Anda (dan sebenarnya sebagian besar sistem berkas) dengan host, sehingga semua berkas yang Anda buat di satu sisi akan terlihat di sisi lain.
Berkat virtiofs-DAX, komunikasi memori bersama (`/dev/shm`) juga tersedia antara aplikasi guest dan aplikasi host. Fitur ini digunakan, misalnya, oleh kode pengalihan X11.
Anda juga dapat berbagi audio antara aplikasi host dan guest menggunakan dukungan pengalihan PulseAudio. Misalnya, Anda dapat merekam audio guest dengan menggunakan aplikasi perekaman di host dan merekam dari perangkat sistem “Monitor”. Anda juga dapat mengonfigurasi sumber/tujuan virtual di host menggunakan mekanisme PipeWire standar, dan mengarahkan aplikasi guest untuk menggunakan sumber/tujuan tersebut untuk input/output audio guna mendapatkan rute dan pemrosesan audio kustom. Perlu dicatat bahwa protokol PipeWire asli tidak diteruskan, hanya protokol PulseAudio yang lebih terbatas (tetapi lebih sering digunakan oleh aplikasi). Aplikasi ALSA didukung melalui plugin `pulse`.
Jika Anda menggunakan host compositor yang mendukung XWayland video bridging (seperti KDE Plasma / KWin), Anda dapat melakukan screen sharing / screen capture dari VM, termasuk layar host penuh dan jendela Wayland. Pastikan aplikasi yang Anda jalankan mendukung penangkapan layar/jendela “klasik” XComposite. Saat Anda memulai berbagi layar, Anda dapat langsung memilih jendela aplikasi X11, atau memilih jendela virtual “Xwayland Video Bridge”. Saat Anda melakukannya, KDE akan secara otomatis meminta Anda untuk memilih jendela atau layar yang ingin Anda bagikan.
=== Mengapa saya memiliki lebih sedikit inti CPU di dalam VM?
Secara default, `muvm` mengalokasikan sebanyak mungkin CPU sesuai dengan jumlah inti performa (performance cores) pada mesin host Anda, dan mengikat vCPU tersebut ke inti performa fisik. Karena penjadwal CPU host tidak memiliki akses ke penjadwal CPU guest, hal ini memastikan kinerja yang konsisten. Anda dapat mengubah perilaku ini dengan opsi `muvm --cpu-list=CPU_LIST`.
=== Bagaimana cara menggunakan drive eksternal sebagai folder perpustakaan Steam?
Ikuti langkah-langkah berikut untuk menyiapkan drive eksternal untuk Steam:
. Format drive eksternal Anda menggunakan sistem berkas asli Linux seperti ext4.
+
NOTE: FAT32, exFAT, dan sistem berkas lainnya yang tidak mendukung izin Linux tidak akan berfungsi.
. Mount drive Anda secara manual di bawah direktori yang dapat diakses oleh muvm, seperti `/mnt/steam`.
+
NOTE: Kami merekomendasikan untuk me-mount drive secara manual (misalnya `sudo mount /dev/sdX1 /mnt/steam`, di mana `sdX1` adalah berkas perangkat drive Anda). Jika Anda mengonfigurasi drive untuk dipasang secara otomatis menggunakan `/etc/fstab`, maka sistem Anda tidak akan boot jika drive tersebut tidak terhubung.
+
NOTE: Titik mount default untuk drive yang dipasang melalui lingkungan desktop (udisks) saat ini tidak berfungsi.
. Pastikan bahwa sistem berkas root dapat diakses oleh pengguna biasa Anda:
+
`sudo chown $\{USER}: /mnt/steam`
. Buat folder kosong bernama `steamapps` di root direktori mount:
+
`mkdir /mnt/steam/steamapps`
. Jalankan Steam seperti biasa
. Klik tab Library, lalu klik ikon roda gigi (pengaturan)
. Pilih *Storage* pada menu sebelah kiri, klik kotak kombinasi di bagian atas panel, dan pilih *Add Drive*.
. Buka drive mountmount Anda (`/mnt/steam`), sehingga folder yang terlihat di jendela daftar pemilihan file hanyalah folder `steamapps` yang kosong di dalamnya, lalu (tanpa melakukan pemilihan tambahan) klik tombol *Select*.
Sekarang Anda seharusnya dapat memilih lokasi unduhan baru, menjadikannya sebagai lokasi default, dan mengunduh game ke sana.
Want to help? Learn how to contribute to Fedora Docs ›