ການລັນແອັບພລິເຄຊັນ x86/x86-64 ເທິງ Fedora Asahi Remix

ມີແອັບພລິເຄຊັນ x86/x86-64 ແບບເກົ່າຈຳນວນຫຼາຍທີ່ຜູ້ໃຊ້ຕ້ອງການລັນເທິງແພລັດຟອມ arm64, ລວມທັງແອັບພລິເຄຊັນ ແລະ ເກມຂອງ Windows. ເພື່ອຮອງຮັບສິ່ງນີ້ໃນ Fedora Asahi Remix, ພວກເຮົາໄດ້ຮວບຮວມຊຸດສ່ວນປະກອບທີ່ມີຢູ່ແລ້ວ ແລະ ສ່ວນປະກອບທີ່ສ້າງຂຶ້ນສະເພາະ ເພື່ອເຮັດໃຫ້ສາມາດລັນແອັບ x86/x86-64 ໂດຍກົງເທິງ arm64 Linux ໄດ້ຢ່າງບໍ່ມີບັນຫາ.

ເນື່ອງຈາກແພລັດຟອມຂອງ Apple ໃຊ້ຂະໜາດໜ້າ (page size) ແບບ 16K ແລະ ໂປຣເຊສເຊີ x86/x86-64 ໃຊ້ຂະໜາດໜ້າ 4K, ສິ່ງນີ້ຈຶ່ງເປັນເລື່ອງທີ່ຍາກເປັນພິເສດ, ເພາະວ່າໂດຍທົ່ວໄປແລ້ວແອັບ x86/x86-64 ຈະບໍ່ເຮັດວຽກເມື່ອເຈິກັບເຄີເນິນ (kernel) ຂອງໂຮສທີ່ຕ້ອງການການຈັດລຽງໜ້າແບບ 16K. ເພື່ອແກ້ໄຂບັນຫານີ້, ພວກເຮົາຈຶ່ງໃຊ້ microVM ເພື່ອລັນເຄີເນິນ Linux ແຍກຕ່າງຫາກໃນໂໝດຂະໜາດໜ້າ 4K. ເພື່ອໃຫ້ການເຮັດວຽກລາບລື່ນທີ່ສຸດ, ສະພາບແວດລ້ອມຂອງເກສ (guest) ຈຶ່ງຖືກອອກແບບໃຫ້ໃກ້ຄຽງກັບໂຮສທີ່ສຸດ, ແລະ ພວກເຮົາໃຊ້ GPU passthrough ເພື່ອໃຫ້ໄດ້ກາຟິກທີ່ມີປະສິດທິພາບສູງພາຍໃນເກສ.

ຊຸດສ່ວນປະກອບປະກອບມີດັ່ງນີ້:

  • muvm (ແພັກເກດ: muvm), ຕົວລັນ microVM ທີ່ພວກເຮົາສ້າງຂຶ້ນເອງໂດຍອີງໃສ່ libkrun. ສິ່ງນີ້ຍັງລວມເຖິງສ່ວນປະກອບສຳລັບ X11 forwarding ແລະ ການເຮັດ proxy ອຸປະກອນອິນພຸດ HID.

  • FEX-emu (ແພັກເກດ: fex-emu), ຕົວຈຳລອງ (emulator) x86/x86-64 ໃນ userspace ທີ່ມີຄວາມໄວສູງ ແລະ ເນັ້ນຄວາມຖືກຕ້ອງ.

  • Fedora FEX RootFS (ແພັກເກດ: fex-emu-rootfs-fedora), ເຊິ່ງໃຫ້ບໍລິການໄລບຣາຣີ (library) ພື້ນຖານຂອງ x86/x86-64 ທີ່ຈຳເປັນສຳລັບແອັບພລິເຄຊັນທີ່ຖືກຈຳລອງ.

  • mesa (ແພັກເກດ: mesa-fex-emu-overlay-i386 ແລະ mesa-fex-emu-overlay-x86-64), ທີ່ສ້າງຂຶ້ນສຳລັບສະຖາປັດຕະຍະກຳ x86/x86-64 ແລະ ແພັກເກດເປັນ FEX RootFS overlay. ສິ່ງນີ້ເຮັດໃຫ້ Apple GPUs ຮອງຮັບ OpenGL/OpenCL/Vulkan.

ພວກເຮົາຍັງມີ Steam wrapper ຂອງພວກເຮົາເອງທີ່ຊ່ວຍຕິດຕັ້ງ ແລະ ເປີດໃຊ້ງານ Steam ພາຍໃນ microVM ໂດຍອັດຕະໂນມັດ. ເມື່ອລັນເກມ Windows ຜ່ານ Steam, ສ່ວນປະກອບໂອເພັນຊອດ (open-source) ເຫຼົ່ານີ້ຈະເຮັດວຽກຢູ່ເບື້ອງຫຼັງ:

  • Proton, ຊຸດ Wine ທີ່ເນັ້ນໃສ່ການຫຼິ້ນເກມໂດຍສະເພາະ.

  • dxvk, ເລເຢີຕົວແປງທີ່ປ່ຽນ DirectX 8 - DirectX 11 ຂອງ Windows ໃຫ້ເປັນ Vulkan.

  • vkd3d-proton, ເລເຢີຕົວແປງທີ່ປ່ຽນ DirectX 12 ຂອງ Windows ໃຫ້ເປັນ Vulkan.

ຂອບເຂດການນຳໃຊ້

ຊຸດເຕັກໂນໂລຊີນີ້ເນັ້ນໃສ່ການລັນເກມ x86 ແລະ x86-64 ເປັນຫຼັກ, ແຕ່ກໍສາມາດໃຊ້ລັນແອັບພລິເຄຊັນທົ່ວໄປໄດ້ເຊັ່ນກັນ. ຖ້າເປັນໄປໄດ້, ທ່ານຄວນເລືອກໃຊ້ແອັບທີ່ຮອງຮັບແບບ native ແທນການໃຊ້ຕົວຈຳລອງ. ກະລຸນາອ່ານ FAQ ຫົວຂໍ້ນີ້ ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ.

ຂອບເຂດຂອງວິທີການນີ້ຈຳກັດຢູ່ທີ່ ແອັບພລິເຄຊັນ x86 ແລະ x86-64 ແບບພົກພາ (portable) ທີ່ອອກແບບມາໃຫ້ລັນຈາກໂຟນເດີ home ຂອງທ່ານ (ຫຼື ຕິດຕັ້ງໄວ້ໃນ /opt ດ້ວຍຕົວເອງ), ລວມທັງ AppImages. ມັນ ບໍ່ໄດ້ ອອກແບບມາເພື່ອລັນແອັບ x86-64 ທີ່ຕ້ອງຕິດຕັ້ງເປັນແພັກເກດລະບົບ, ເຊິ່ງຖືກສ້າງມາສຳລັບ Linux ບາງລຸ້ນໂດຍສະເພາະ ຫຼື ຕ້ອງການການຕິດຕັ້ງສ່ວນປະກອບອື່ນໆທີ່ຊັບຊ້ອນ, ຫຼື ຕ້ອງການລັນຕົວຕິດຕັ້ງໃນຖານະ root.

ໂດຍສະເພາະແລ້ວ, ສະພາບແວດລ້ອມ x86-64 ນີ້ ບໍ່ແມ່ນ ລະບົບໄຟລ໌ root ທີ່ສົມບູນໃນຕົວມັນເອງ, ແຕ່ເປັນພຽງ overlay ຂະໜາດນ້ອຍທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້ ເຊິ່ງວາງຊ້ອນຢູ່ເທິງລະບົບໄຟລ໌ root arm64 ທີ່ມີຢູ່ແລ້ວ. ນັ້ນໝາຍຄວາມວ່າທ່ານບໍ່ສາມາດປ່ຽນແປງມັນ, ຕິດຕັ້ງແພັກເກດເພີ່ມເຕີມ ແລະ ອື່ນໆໄດ້. ຈະບໍ່ມີການເຂົ້າເຖິງສິດ root ໃດໆເລີຍພາຍໃນສະພາບແວດລ້ອມ x86-64.

ການນຳໃຊ້

Steam

ພຽງແຕ່ໃຊ້ຄຳສັ່ງ dnf install steam ເພື່ອຕິດຕັ້ງ Steam wrapper ຂອງພວກເຮົາ, ຈາກນັ້ນເປີດ Steam ຈາກເມນູໃນເດັສທັອບ (ຫຼື ໃຊ້ຄຳສັ່ງ steam) ເພື່ອດາວໂຫຼດ ແລະ ຕິດຕັ້ງ Steam. ລະບົບຈະຕິດຕັ້ງສ່ວນປະກອບທີ່ຈຳເປັນທັງໝົດໃຫ້ໂດຍອັດຕະໂນມັດ.

ແອັບພລິເຄຊັນອື່ນໆ

ເພື່ອຕິດຕັ້ງຊຸດຕົວຈຳລອງດ້ວຍຕົວມັນເອງ, ໃຫ້ໃຊ້ຄຳສັ່ງ dnf install fex-emu. ສິ່ງນີ້ຈະດຶງເອົາສ່ວນປະກອບທີ່ຈຳເປັນມາໃຫ້ໂດຍອັດຕະໂນມັດ.

ທ່ານຍັງບໍ່ສາມາດລັນແອັບ x86-64 ໂດຍກົງຈາກໂຮສໄດ້ໃນຕອນນີ້, ເພາະວ່າພວກມັນຕ້ອງຖືກເປີດຜ່ານ microVM. ເພື່ອເຮັດແບບນັ້ນ, ໃຫ້ລັນຄຳສັ່ງ muvm -- /path/to/executable. ທ່ານຕ້ອງໃຊ້ທີ່ຢູ່ໄຟລ໌ແບບເຕັມ (absolute path), ເພາະວ່າ muvm ຍັງບໍ່ສາມາດຈື່ໂຟນເດີທີ່ກຳລັງເຮັດວຽກຢູ່ໄດ້. ໃນສະພາບແວດລ້ອມນີ້, binfmt ຂອງເຄີເນິນຖືກຕັ້ງຄ່າໃຫ້ໃຊ້ FEX ເພື່ອລັນແອັບ x86/x86-64 ແລ້ວ, ດັ່ງນັ້ນທ່ານຄວນຈະສາມາດລັນພວກມັນໄດ້ເລີຍ.

ຖ້າແອັບພລິເຄຊັນຂອງທ່ານໃຊ້ shell script ໃນການເປີດແທນທີ່ຈະລັນໄຟລ໌ binary ໂດຍກົງ, ທ່ານຄວນລັນມັນຜ່ານ FEXBash. ຕົວຢ່າງ: ໃຊ້ muvm -- FEXBash /path/to/launcher.sh. ການເຮັດແບບນີ້ຈະຊ່ວຍໃຫ້ໝັ້ນໃຈໄດ້ວ່າ shell ຈະເຮັດວຽກໃນສະພາບແວດລ້ອມທີ່ຖືກຈຳລອງ ແລະ ຄຳສັ່ງທີ່ສຳຄັນບາງຢ່າງຈະເຮັດວຽກຄືກັບຢູ່ໃນ x86-64 ແທ້ໆ, ເຊິ່ງຈະຊ່ວຍໃຫ້ shell script ເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ.

ທ່ານຍັງສາມາດໃຊ້ muvm -- bash ເພື່ອເປີດ arm64 shell ພາຍໃນ 4K MicroVM, ຫຼື muvm -- FEXBash ເພື່ອເປີດ x86-64 shell. x86-64 shell ຈະເຮັດວຽກຄ້າຍຄືກັບ arm64 shell ແລະ ຄຳສັ່ງສ່ວນໃຫຍ່ຈະລັນເປັນ arm64 binary, ແຕ່ບາງຄຳສັ່ງ (ເຊັ່ນ ls) ຈະລັນພາຍໃຕ້ການຈຳລອງ ເຊິ່ງເຮັດໃຫ້ທ່ານ "ເຫັນ" ລະບົບໃນມຸມມອງດຽວກັບທີ່ແອັບ x86-64 ເຫັນ.

ຫຼັກການເຮັດວຽກ

muvm ສ້າງ virtual machine ທີ່ແບ່ງປັນຊັບພະຍາກອນກັບ OS ຂອງໂຮສໃຫ້ຫຼາຍທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້. ພາຍໃນ VM, ລະບົບໄຟລ໌ root ແມ່ນ ອັນດຽວກັນກັບລະບົບໄຟລ໌ root ຂອງໂຮສ, ຍົກເວັ້ນບາງຢ່າງດັ່ງນີ້:

  • /dev, /sys, ແລະ /proc ເປັນສ່ວນຕົວຂອງເກສ, ຍົກເວັ້ນ /dev/shm ທີ່ແບ່ງປັນກັບໂຮສ ເພື່ອໃຫ້ແອັບຂອງໂຮສ ແລະ ເກສ ສາມາດໃຊ້ໜ່ວຍຄວາມຈຳຮ່ວມກັນໄດ້.

  • /run ກໍເປັນສ່ວນຕົວຂອງເກສເຊັ່ນກັນ

  • ໄຟລ໌ rootfs ແລະ overlay ຂອງ FEX-emu ຖືກເມົາຕ໌ (mount) ໄວ້ພາຍໃຕ້ /run/fex-emu/, ໂດຍມີ rootfs ທີ່ລວມກັນແລ້ວຢູ່ທີ່ /run/fex-emu/rootfs.

  • /usr/share/fex-emu ແລະ /usr/local/share/fex-emu ຖືກທັບຊ້ອນດ້ວຍ tmpfs ເພື່ອໃສ່ໄຟລ໌ Config.json ຂອງ FEX ທີ່ເໝາະສົມສຳລັບໃຊ້ໃນ VM

  • ມີການເມົາຕ໌ tmpfs ໄວ້ທີ່ /tmp/.X11-unix ເພື່ອໃຫ້ X11 server sockets ເປັນສ່ວນຕົວພາຍໃນ VM

  • ລະບົບໄຟລ໌ທັງໝົດຂອງໂຮສສາມາດເຂົ້າເຖິງໄດ້ທີ່ /run/muvm-host. ຕົວຢ່າງ: ທ່ານສາມາດເຂົ້າເຖິງ /run ຂອງໂຮສໄດ້ທີ່ /run/muvm-host/run. (ໝາຍເຫດ: /run/muvm-host/dev ມີຢູ່ແທ້ ແຕ່ບໍ່ສາມາດໃຊ້ງານໄດ້ຕາມທີ່ຄາດຫວັງ. ອຸປະກອນຂອງໂຮສບໍ່ສາມາດໃຊ້ງານໄດ້ໃນເກສ.)

ນີ້ໝາຍຄວາມວ່າ /usr, /home, /etc, /opt, /var, /tmp ແລະ ໂຟນເດີອື່ນໆໃນ root ຂອງລະບົບໄຟລ໌ແມ່ນ ຖືກໃຊ້ຮ່ວມກັນລະຫວ່າງເກສ ແລະ ໂຮສ. ເກສ OS aarch64 ບໍ່ໄດ້ລັນລະບົບໄຟລ໌ root ຂອງມັນເອງ, ແຕ່ ລັນໄຟລ໌ binary ອັນດຽວກັນກັບທີ່ OS ຂອງໂຮສລັນ.

ນອກຈາກນັ້ນ, FEX ເອງກໍໃຊ້ລະບົບໄຟລ໌ທີ່ເມົາຕ໌ໄວ້ທີ່ /run/fex-emu/rootfs ເປັນ RootFS ສະເືອນຂອງມັນ. ນີ້ໝາຍຄວາມວ່າແອັບ x86/x86-64 (ແລະ ສະເພາະແອັບພວກນີ້ເທົ່ານັ້ນ) ຈະເຫັນເນື້ອໃນຂອງໂຟນເດີນັ້ນວາງຊ້ອນຢູ່ເທິງລະບົບໄຟລ໌ root. ນີ້ຄືວິທີທີ່ພວກເຮົາເຮັດໃຫ້ໄລບຣາຣີ x86/x86-64 ສາມາດໃຊ້ງານໄດ້ກັບແອັບເຫຼົ່ານັ້ນ, ໃນຂະນະທີ່ຍັງແບ່ງປັນເນື້ອໃນລະບົບໄຟລ໌ສ່ວນໃຫຍ່ຮ່ວມກັນຢູ່.

ເມື່ອ muvm ເລີ່ມເຮັດວຽກ, ມັນຈະລົງທະບຽນ FEX ເປັນ binfmt provider, ດັ່ງນັ້ນແອັບ x86/x86-64 ຈະຖືກລັນຜ່ານມັນໂດຍອັດຕະໂນມັດ. ເມື່ອເລີ່ມຕົ້ນ, FEX ຈະກວດສອບວ່າແພລັດຟອມ Apple Silicon ຮອງຮັບ TSO ຫຼື ບໍ່ (ເຖິງແມ່ນວ່າຈະຢູ່ໃນ VM ກໍຕາມ), ແລະ ຈະເປີດໃຊ້ງານມັນໂດຍອັດຕະໂນມັດເພື່ອໃຫ້ການຈຳລອງໄວ ແລະ ຖືກຕ້ອງຂຶ້ນ.

ຈຸດເມົາຕ໌ (Mountpoints) ໃນໂຮສຈະຖືກສົ່ງຕໍ່ໄປຫາເກສ ເມື່ອມີການເຂົ້າເຖິງຄັ້ງທຳອິດ ໂດຍອັດຕະໂນມັດ. ສິ່ງນີ້ຊ່ວຍໃຫ້ແອັບໃນເກສແຍກແຍະລະບົບໄຟລ໌ທີ່ແຕກຕ່າງກັນໄດ້ຢ່າງຖືກຕ້ອງ. ຖ້າທ່ານມີພາທິຊັນທີ່ເມົາຕ໌ໄວ້ໃນໂຮສທີ່ /mnt/steam ແລະ ທ່ານລັນຄຳສັ່ງ mount ໃນເກສ, ທ່ານຈະບໍ່ເຫັນມັນໃນຕອນທຳອິດ. ແຕ່ຖ້າທ່ານລັນ ls /mnt/steam ແລ້ວລັນ mount ອີກຄັ້ງ, ລາຍການເມົາຕ໌ຈະປະກົດຂຶ້ນມາເອງ. ນີ້ແມ່ນເລື່ອງປົກກະຕິ ແລະ ເປັນໄປຕາມທີ່ອອກແບບໄວ້!

ບັນຫາທີ່ພົບ

ປະສິດທິພາບຍັງບໍ່ດີປານໃດ

ເນື່ອງຈາກໂຄງການນີ້ຍັງຢູ່ໃນໄລຍະເລີ່ມຕົ້ນ, ພວກເຮົາຈຶ່ງເນັ້ນໃສ່ຄວາມຖືກຕ້ອງໃນການເຮັດວຽກສຳລັບເວີຊັນທຳອິດ. ການປັບປຸງປະສິດທິພາບຈະມີຂຶ້ນໃນອະນາຄົດ. ພວກເຮົາຮູ້ແລ້ວວ່າຕ້ອງປ່ຽນແປງຈຸດໃດແດ່ເພື່ອໃຫ້ປະສິດທິພາບດີຂຶ້ນຢ່າງເຫັນໄດ້ຊັດ, ແລະ ພວກເຮົາກຳລັງເລັ່ງເຮັດວຽກໃນສ່ວນນັ້ນຢູ່!

ສຳລັບເກມ Windows DX8-DX11 ພາຍໃຕ້ Proton, ທ່ານອາດຈະລອງໃຊ້ WineD3D ແທນ DXVK. WineD3D ໃຊ້ OpenGL ເປັນເບື້ອງຫຼັງແທນ Vulkan, ເຊິ່ງ ອາດຈະ ໃຫ້ປະສິດທິພາບທີ່ດີກວ່າ ຍ້ອນການປັບແຕ່ງໃນໄດຣເວີ OpenGL ຂອງພວກເຮົາທີ່ຍັງບໍ່ມີໃນ Vulkan. ເພື່ອເປີດໃຊ້ງານ, ໃຫ້ປ່ຽນ launch options ໃນ Steam ເປັນ PROTON_USE_WINED3D=1 %command%. ໝາຍເຫດວ່າ DXVK ມັກຈະຮອງຮັບເກມໄດ້ດີກວ່າ, ສະນັ້ນມັນເປັນການແລກປ່ຽນກັນ. ບອກໃຫ້ພວກເຮົາຮູ້ແດ່ວ່າເກມໃດເຮັດວຽກໄດ້ດີກວ່າເມື່ອໃຊ້ຕົວໃດ!

ເກມ 32-ບິດ ເກົ່າໆອາດຈະລັນຊ້າຫຼາຍຖ້າມັນໃຊ້ງານໜ່ວຍຄິດໄລ່ເລກທົດສະນິຍົມ 80-ບິດ x87 ຫຼາຍ, ເພາະວ່າການເຮັດວຽກເຫຼົ່ານີ້ຕ້ອງຖືກຈຳລອງດ້ວຍຊອບແວເພື່ອຄວາມເຂົ້າກັນໄດ້ທີ່ສົມບູນ (ບັນຫາດຽວກັນນີ້ກໍເກີດຂຶ້ນກັບ Rosetta ໃນ macOS). ທ່ານສາມາດລັນເກມເຫຼົ່ານີ້ດ້ວຍການຈຳລອງເລກທົດສະນິຍົມ 64-ບິດ ແບບຮາດແວ ເຊິ່ງຈະມີຄວາມຖືກຕ້ອງໜ້ອຍກວ່າແຕ່ໄວຫຼາຍ. ເພື່ອເຮັດແບບນັ້ນ, ໃຫ້ປ່ຽນ launch options ໃນ Steam ເປັນ FEX_X87REDUCEDPRECISION=1 %command%. ໂໝດນີ້ອາດຈະເຮັດໃຫ້ເກີດບັນຫາເລັກນ້ອຍໃນບາງເກມຍ້ອນຄວາມຖືກຕ້ອງທີ່ຫຼຸດລົງ, ແຕ່ເກມສ່ວນໃຫຍ່ຄວນຈະເຮັດວຽກໄດ້ປົກກະຕິ (ແລະ ໄວຂຶ້ນຫຼາຍ).

VM ໃຊ້ RAM ຫຼາຍ

ເພື່ອໃຫ້ແອັບໃນເກສສາມາດໃຊ້ RAM ຈຳນວນຫຼາຍໄດ້ (ຕາມທີ່ເກມສະໄໝໃໝ່ຕ້ອງການ), ໂດຍປົກກະຕິ muvm ຈະອະນຸຍາດໃຫ້ເກສໃຊ້ RAM ໄດ້ສູງສຸດ 80% ຂອງລະບົບ. ສິ່ງນີ້ຍັງໝາຍຄວາມວ່າ RAM ບາງສ່ວນຈະຖືກໃຊ້ໂດຍ page cache ຂອງເກສ, ເຊິ່ງເຮັດໃຫ້ເຫັນໃນໂຮສວ່າ VM ກຳລັງໃຊ້ RAM ສ່ວນໃຫຍ່ຂອງລະບົບ. muvm ສາມາດຫຼຸດການໃຊ້ page cache ຂອງເກສລົງໄດ້ເມື່ອ RAM ຂອງໂຮສເລີ່ມເຫຼືອໜ້ອຍ, ດັ່ງນັ້ນຖ້າທ່ານໃຊ້ RAM ໃນໂຮສຫຼາຍຂຶ້ນ, VM ກໍຄວນຈະຫຼຸດການໃຊ້ງານລົງຕາມນັ້ນ (ຕາບໃດທີ່ມັນສາມາດປ່ອຍ cache RAM ທີ່ບໍ່ໄດ້ໃຊ້ງານອອກໄດ້).

ສຳລັບເຄື່ອງທີ່ມີ RAM ໜ້ອຍ (16GB ຫຼື ຕ່ຳກວ່າ), ພວກເຮົາແນະນຳວ່າບໍ່ຄວນລັນແອັບພລິເຄຊັນທີ່ກິນຊັບພະຍາກອນຫຼາຍໃນໂຮສຂະນະທີ່ກຳລັງໃຊ້ VM. ພວກເຮົາບໍ່ແນະນຳໃຫ້ລັນເກມທີ່ຊັບຊ້ອນໃນເຄື່ອງທີ່ມີ RAM 8GB.

ເພື່ອເບິ່ງການໃຊ້ RAM ຂອງ VM ໃນຂະນະທີ່ມັນກຳລັງເຮັດວຽກ, ໃຫ້ໃຊ້ຄຳສັ່ງ muvm -ti -- free. ທ່ານຍັງສາມາດລັນ muvm -ti -- htop (ຖ້າທ່ານຕິດຕັ້ງ htop ໄວ້) ເພື່ອເບິ່ງຂໍ້ມູນທີ່ລະອຽດກວ່າ, ຫຼື ໃຊ້ເຄື່ອງມືກວດສອບລະບົບອື່ນໆທີ່ທ່ານຕ້ອງການ.

ຖ້າທ່ານຕ້ອງການຈຳກັດການໃຊ້ RAM ສູງສຸດຂອງ MicroVM, ທ່ານສາມາດຕັ້ງຄ່າການຈອງ RAM ໃຫ້ເກສໄດ້ດ້ວຍພາຣາມິເຕີ muvm --mem=SIZE.

ຂ້ອຍບໍ່ສາມາດເຂົ້າເຖິງສື່ທີ່ເມົາຕ໌ໄວ້ພາຍໃຕ້ /run/media ໃນ VM ໄດ້

ສິ່ງນີ້ຍັງບໍ່ສາມາດເຮັດວຽກໄດ້ (ເຖິງແມ່ນວ່າຈະຜ່ານ /run/muvm-host/run/media ກໍຕາມ) ເພາະວ່າ libkrun ຍັງບໍ່ຮອງຮັບ POSIX ACL ໃນຕອນນີ້. ທ່ານຕ້ອງເມົາຕ໌ດິດທີ່ທ່ານຕ້ອງການໃຊ້ໃນ VM ດ້ວຍຕົວເອງ, ເຊັ່ນ: ໄວ້ພາຍໃຕ້ /mnt.

ຄຳຖາມທີ່ພົບເລື້ອຍ (FAQ)

ສິ່ງນີ້ຄືກັບ Rosetta ໃນ macOS ບໍ່?

ນີ້ຄືສິ່ງທີ່ໃກ້ຄຽງກັບ Rosetta ທີ່ສຸດເທົ່າທີ່ພວກເຮົາຈະເຮັດໄດ້! ຂໍ້ແຕກຕ່າງຫຼັກຄື Rosetta ຫຼີກລ່ຽງບັນຫາຂະໜາດໜ້າ (page size) ໂດຍການອາໄສການຮອງຮັບຂະໜາດໜ້າຫຼາຍແບບຂອງເຄີເນິນ XNU ສຳລັບໂປຣເຊສຂອງຜູ້ໃຊ້, ມັນຈຶ່ງບໍ່ຈຳເປັນຕ້ອງໃຊ້ VM. ໃນທາງທິດສະດີ, ການເຮັດໃຫ້ Linux ຮອງຮັບຂະໜາດໜ້າຫຼາຍແບບນັ້ນບໍ່ແມ່ນເລື່ອງທີ່ເປັນໄປບໍ່ໄດ້, ແຕ່ມັນເປັນໂຄງການທີ່ໃຫຍ່ຫຼາຍ ແລະ ອາດຕ້ອງໃຊ້ເວລາຫຼາຍປີກວ່າຈະສຳເລັດ, ແລະ ຍັງບໍ່ແນ່ໃຈວ່າການປ່ຽນແປງດັ່ງກ່າວຈະຖືກຍອມຮັບເຂົ້າໃນເຄີເນິນຫຼັກ (upstream) ຫຼື ບໍ່ (ແມ່ນແຕ່ການເລືອກຂະໜາດໜ້າຕອນບູດພາຍໃນເຄີເນິນດຽວ Linux ກໍຍັງບໍ່ມີເລີຍ!).

ນອກຈາກເລື່ອງຂະໜາດໜ້າແລ້ວ, FEX ແລະ Rosetta ແມ່ນເຕັກໂນໂລຊີທີ່ທຽບເທົ່າກັນ (ທັງສອງແມ່ນຕົວຈຳລອງ, ເຖິງແມ່ນວ່າການຕະຫຼາດຂອງ Apple ຈະເຮັດໃຫ້ທ່ານເຊື່ອເປັນຢ່າງອື່ນກໍຕາມ). ທັງ FEX ແລະ Rosetta ຕ່າງກໍໃຊ້ຄຸນສົມບັດພິເສດຂອງ CPU Apple Silicon ທີ່ສຳຄັນທີ່ສຸດສຳລັບປະສິດທິພາບການຈຳລອງ x86/x86-64 ນັ້ນຄື: ໂໝດ TSO. ຍ້ອນຄຸນສົມບັດນີ້, FEX ຈຶ່ງສາມາດໃຫ້ການຈຳລອງ x86/x86-64 ທີ່ໄວ ແລະ ຖືກຕ້ອງເທິງລະບົບ Apple Silicon.

ເປັນຫຍັງບໍ່ໃຊ້ເຄີເນິນໂຮສແບບ 4K ໄປເລີຍ?

ເຖິງແມ່ນວ່າລະບົບ Apple Silicon ຈະຮອງຮັບໜ້າ CPU ແບບ 4K, ແຕ່ຮາດແວສ່ວນທີ່ເຫຼືອ (IOMMUs, GPU) ເຮັດວຽກດ້ວຍໜ້າແບບ 16K ເທົ່ານັ້ນ. ເຄີເນິນ Linux ເຮັດວຽກໄດ້ບໍ່ດີໃນສະພາບແວດລ້ອມນີ້ ເພາະໂດຍທົ່ວໄປແລ້ວມັນຈະສົມມຸດວ່າຂະໜາດໜ້າ CPU ຕ້ອງໃຫຍ່ກວ່າ ຫຼື ເທົ່າກັບຂະໜາດໜ້າ IOMMU. ໃນອະດີດ ພວກເຮົາເຄີຍມີແພັດ (patch) ເຄີເນິນເພື່ອໃຫ້ມັນເຮັດວຽກໄດ້ບາງສ່ວນ, ແຕ່ມັນກໍມີບັກ ແລະ ບໍ່ສົມບູນ, ພວກເຮົາຈຶ່ງຍົກເລີກວິທີນັ້ນໄປ. ເຖິງແມ່ນວ່າມັນຈະເຮັດວຽກໄດ້ດີ, ການລັນທັງລະບົບດ້ວຍໜ້າ 4K ກໍສົ່ງຜົນກະທົບຕໍ່ປະສິດທິພາບຢ່າງເຫັນໄດ້ຊັດ, ພວກເຮົາຈຶ່ງບໍ່ມີທາງປ່ອຍເຄີເນິນ 4K ເປັນຄ່າເລີ່ມຕົ້ນ. ດັ່ງນັ້ນ, ການລັນແອັບ x86/x86-64 ຈະກາຍເປັນເລື່ອງທີ່ຍຸ້ງຍາກເພາະຜູ້ໃຊ້ຕ້ອງມາປ່ຽນເຄີເນິນ ແລະ ບູດເຄື່ອງໃໝ່ດ້ວຍຕົວເອງ.

ເປັນຫຍັງບໍ່ໃຊ້ box64?

box64 ແລະ FEX-Emu ມີວິທີການຈຳລອງທີ່ແຕກຕ່າງກັນ, ໂດຍ FEX-Emu ເນັ້ນຄວາມຖືກຕ້ອງຫຼາຍກວ່າ (ແຕ່ຕ້ອງມີການຕັ້ງຄ່າທີ່ຊັບຊ້ອນກວ່າ) ໃນຂະນະທີ່ box64 ເນັ້ນການໃຊ້ງານທີ່ງ່າຍກວ່າ (ເຊັ່ນການລັນບາງແອັບພລິເຄຊັນໂດຍກົງເທິງເຄີເນິນ 16K ໂດຍບໍ່ຕ້ອງໃຊ້ VM ໂດຍໃຊ້ເຕັກນິກບາງຢ່າງ). ພວກເຮົາເລືອກ FEX-Emu ສຳລັບຊຸດເຕັກໂນໂລຊີຂອງພວກເຮົາ ເພາະພວກເຮົາເຊື່ອວ່າມັນຈະຮອງຮັບແອັບໄດ້ຫຼາຍກວ່າດ້ວຍວິທີການຂອງມັນ, ແຕ່ທັງສອງກໍມີປະໂຫຍດໃນແບບຂອງຕົນເອງ. box64 ຖືກ ແພັກເກດໄວ້ໃນ Fedora ແລ້ວ, ພວກເຮົາຈຶ່ງສະໜັບສະໜູນໃຫ້ຜູ້ໃຊ້ລອງໃຊ້ມັນເບິ່ງ (ທັງແບບ native ແລະ ພາຍໃນ muvm) ແລ້ວບອກໃຫ້ພວກເຮົາຮູ້ແດ່ວ່າມັນເປັນແນວໃດເມື່ອທຽບກັນ!

ແອັບ x86-64 ຫຼື x86 ຂອງຂ້ອຍຂາດໄລບຣາຣີລະບົບບາງຢ່າງ, ຂ້ອຍຄວນເຮັດແນວໃດ?

RootFS ທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້ຂອງພວກເຮົາມີໄລບຣາຣີ x86-64 ແລະ x86 ພື້ນຖານຈຳນວນຫຼາຍ, ແຕ່ພວກເຮົາບໍ່ສາມາດໃສ່ໄລບຣາຣີທຸກອັນທີ່ມີໃນໂລກລົງໄປໄດ້. ທ່ານສາມາດເບິ່ງລາຍການແພັກເກດໄດ້ ທີ່ນີ້.

ຖ້າໄລບຣາຣີທີ່ຂາດໄປນັ້ນເປັນໄລບຣາຣີທົ່ວໄປທີ່ບໍ່ມີສ່ວນປະກອບອື່ນໆທີ່ຊັບຊ້ອນ ແລະ ບໍ່ເຮັດໃຫ້ RootFS ມີຂະໜາດໃຫຍ່ເກີນໄປ, ກະລຸນາສົ່ງ PR ໄປທີ່ repo ຕາມລິ້ງຂ້າງເທິງ ເພື່ອໃຫ້ພວກເຮົາເພີ່ມມັນເຂົ້າໃນ RootFS ເວີຊັນຕໍ່ໆໄປ. ກະລຸນາລະບຸນຳວ່າແອັບໃດຕ້ອງການໄລບຣາຣີນັ້ນ ແລະ ເປັນຫຍັງພວກເຮົາຈຶ່ງຄວນເພີ່ມມັນເຂົ້າໄປ.

ຖ້າແອັບຂອງທ່ານຕ້ອງການເຟຣມເວີກ (framework) ທີ່ຊັບຊ້ອນ (ເຊັ່ນ Qt) ຫຼື ໄລບຣາຣີສະເພາະທາງ, ສະແດງວ່າແອັບນັ້ນບໍ່ໄດ້ຖືກສ້າງມາໃຫ້ເປັນແອັບແບບ "ພົກພາ (portable)" ແລະ ອາດຈະບໍ່ເຮັດວຽກໄດ້ທັນທີໃນທຸກລະບົບ. ເພື່ອແກ້ໄຂບັນຫານີ້, ທ່ານສາມາດດາວໂຫຼດໄລບຣາຣີທີ່ຂາດໄປດ້ວຍຕົວເອງ, ແຕກໄຟລ໌ລົງໃນໂຟນເດີ home ຂອງທ່ານ, ແລະ ໃຊ້ LD_LIBRARY_PATH ເພື່ອໃຫ້ແອັບຫາພວກມັນເຫັນ. ທ່ານສາມາດໃຊ້ຄຳສັ່ງຕໍ່ໄປນີ້ເພື່ອດາວໂຫຼດ RPM ຂອງ x86-64 ຈາກ Fedora arm64 ຂອງທ່ານ:

ຈາກນັ້ນທ່ານສາມາດໃຊ້ `rpmdev-extract` ເພື່ອແຕກເນື້ອໃນຂອງ RPM ອອກມາ, ແລ້ວຕັ້ງຄ່າ `LD_LIBRARY_PATH` ຕາມຄວາມເໝາະສົມ.

ນອກຈາກນັ້ນ ທ່ານຍັງສາມາດນຳ RPM ມາເຮັດເປັນ overlay ໃນ RootFS ທີ່ມີຢູ່ໄດ້, ແຕ່ວິທີນີ້ຖືວ່າເປັນຂັ້ນຕອນສຳລັບຜູ້ໃຊ້ລະດັບສູງ. ເມື່ອທ່ານມີໄຟລ໌ RPM ແລ້ວ, ທ່ານສາມາດປ່ຽນມັນໃຫ້ເປັນ erofs image ໄດ້ດ້ວຍຄຳສັ່ງເຫຼົ່ານີ້:

``` rpm2archive -n mypackage.rpm mkfs.erofs --tar=f mypackage.rpm.erofs mypackage.rpm.tar ```

ຈາກນັ້ນ, ທ່ານສາມາດລັນ `muvm` ດ້ວຍຕົວເອງໂດຍໃຊ້ erofs images ພື້ນຖານ ແລະ erofs image ຂອງທ່ານວາງຊ້ອນຢູ່ເທິງ ແບບນີ້:

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 \ <ໃສ່ arguments ຂອງ muvm ຂອງທ່ານຢູ່ບ່ອນນີ້>

ສິ່ງນີ້ຈະນຳແພັກເກດເສີມໄປວາງຊ້ອນເທິງ RootFS ທີ່ FEX ໃຊ້. ກະລຸນາຈື່ໄວ້ວ່າວິທີນີ້ອາດຈະເຮັດວຽກໄດ້ ຫຼື ບໍ່ໄດ້ຕາມທີ່ຄາດຫວັງ, ແລະ ບໍ່ຖືວ່າເປັນວິທີການທີ່ໄດ້ຮັບການສະໜັບສະໜູນຢ່າງເປັນທາງການ.

=== Steam ແຈ້ງວ່າ steamwebhelper ແຄຣັດ (crash), ຂ້ອຍຄວນເຮັດແນວໃດ?

ພຽງແຕ່ປ່ອຍໃຫ້ມັນເລີ່ມໃໝ່, ແລ້ວມັນກໍຄວນຈະເຮັດວຽກໄດ້ໃນຄັ້ງທີສອງ. Steam ມີການຕັ້ງເວລາໝົດອາຍຸ (timeout) ສຳລັບ steamwebhelper, ແລະ ເມື່ອລັນພາຍໃຕ້ການຈຳລອງ, ການເລີ່ມຕົ້ນອາດຈະຊ້າຈົນໝົດເວລາ. ບັນຫານີ້ມັກຈະເກີດຂຶ້ນສະເພາະຕອນເປີດໃຊ້ງານຄັ້ງທຳອິດ (cold startup) ເທົ່ານັ້ນ.

=== ຂ້ອຍບໍ່ສາມາດດາວໂຫຼດ ຫຼື ລັນບາງເກມໃນ Steam ໄດ້

ໃຫ້ກວດເບິ່ງວ່າໄດ້ເປີດໃຊ້ Steam Play ສຳລັບທຸກເກມແລ້ວ ຫຼື ບໍ່. ໂດຍໄປທີ່ Menu > Settings > Compatibility > Enable Steam Play for all other titles. ເມື່ອເປີດແລ້ວໃຫ້ເລີ່ມ Steam ໃໝ່.

=== ການກົດປຸ່ມຄີບອດເຮັດໃຫ້ທັດສແພດ (touchpad) ຢຸດຕອບສະໜອງ

ບັນຫານີ້ເກີດຈາກຟີເຈີ "Disable while typing" (ປິດການໃຊ້ງານຂະນະພິມ) ຂອງທັດສແພດ. ທ່ານສາມາດປິດມັນໄດ້ໃນການຕັ້ງຄ່າ touchpad/input ຂອງເດັສທັອບຂອງທ່ານ.

=== ຂ້ອຍສາມາດລັນແອັບ Windows ຢູ່ນອກ Steam ໄດ້ບໍ່?

ໃນຕອນນີ້ ພວກເຮົາຢັງບໍ່ຮອງຮັບການລັນແອັບ Windows ຢູ່ນອກ Steam ເພາະວ່າ Wine ທີ່ບໍ່ແມ່ນລຸ້ນ Proton ຍັງບໍ່ທັນເຮັດວຽກເທິງ Fedora. ພວກເຮົາກຳລັງແກ້ໄຂ https://github.com/FEX-Emu/FEX/pull/4225[ບັນຫາຂອງ FEX] ຢູ່, ແລະ ຄາດວ່າຈະຮອງຮັບໄດ້ໃນໄວໆນີ້.

ໃນລະຫວ່າງນີ້ ທ່ານສາມາດໃຊ້ Proton ຂອງ Steam ເພື່ອລັນແອັບ Windows ທີ່ບໍ່ແມ່ນຂອງ Steam ໂດຍກົງຜ່ານ Steam ໄດ້.

=== ຂ້ອຍສາມາດລັນແອັບ Linux ແບບ x86-64/x86 ໄດ້ບໍ່?

ໂດຍທົ່ວໄປແລ້ວເກມ Linux ແບບ native ຄວນຈະເຮັດວຽກພາຍໃຕ້ muvm ໄດ້, ຕາບໃດທີ່ພວກມັນມີໄລບຣາຣີຄົບໃນຕົວເອງ ແລະ ບໍ່ຕ້ອງການໄລບຣາຣີລະບົບທີ່ຊັບຊ້ອນ (ພວກເຮົາມີໄລບຣາຣີພື້ນຖານໃຫ້ຫຼາຍພໍສົມຄວນ ແຕ່ບໍ່ໄດ້ມີທຸກຢ່າງ).

=== ຮອງຮັບ Wayland ບໍ່?

ໃນຕອນນີ້ ຍັງບໍ່ຮອງຮັບ Wayland ພາຍໃນ VM. ເນື່ອງຈາກແອັບ x86/x86-64 ສ່ວນໃຫຍ່ທີ່ຄົນຕ້ອງການລັນແມ່ນແອັບ X11, ພວກເຮົາຈຶ່ງເນັ້ນໃສ່ການຮອງຮັບ X11 ກ່ອນ. ນັ້ນໝາຍຄວາມວ່າທ່ານຍັງບໍ່ສາມາດລັນແອັບ Wayland ແບບ native ພາຍໃນ VM ໄດ້ໃນຕອນນີ້. ແນ່ນອນວ່າເດັສທັອບຂອງໂຮສກໍຍັງເປັນ Wayland ຄືເກົ່າ, ແລະ ການຮອງຮັບ X11 ແມ່ນເຮັດຜ່ານ XWayland.

=== ຂ້ອຍສາມາດເຂົ້າເຖິງຮາດແວຈາກແອັບພລິເຄຊັນທີ່ລັນໃນ microVM ໄດ້ບໍ່?

ເນື່ອງຈາກ VM ບໍ່ໄດ້ສົ່ງຕໍ່ຮາດແວໃດໆຂອງໂຮສນອກຈາກ GPU ແລະ ລະບົບໄຟລ໌ສະເືອນ, ທ່ານຈຶ່ງບໍ່ສາມາດໃຊ້ແອັບທີ່ຕ້ອງການການເຂົ້າເຖິງຮາດແວໂດຍກົງໄດ້. ພວກເຮົາໃຊ້ software passthrough ສຳລັບອິນເຕີເຟສຕໍ່ໄປນີ້:

- ໂປຣໂຕຄໍ X11 (ຈໍສະແດງຜົນ, ຄີບອດ, ເມົ້າ)
- ຈອຍເກມ (Gamepads) ຜ່ານ hid/uinput passthrough
- ການຮັບສົ່ງສຽງຜ່ານ PulseAudio socket protocol footnote:[ສິ່ງນີ້ເຮັດວຽກຮ່ວມກັບ PipeWire ທີ່ລັນເທິງໂຮສດ້ວຍ pipewire-pulse ເຊິ່ງຖືກຕິດຕັ້ງມາໃຫ້ແລ້ວ. ທ່ານ *ບໍ່ຈຳເປັນ* ແລະ ບໍ່ຄວນຕິດຕັ້ງ PulseAudio ແບບເຕັມຮູບແບບ ເພາະມັນຈະເຮັດໃຫ້ການຮອງຮັບລຳໂພງຂອງທ່ານມີບັນຫາ!]

ພວກເຮົາກຳລັງສຶກສາຄວາມເປັນໄປໄດ້ໃນການສົ່ງຕໍ່ PipeWire ເຊິ່ງຈະຊ່ວຍໃຫ້ສາມາດໃຊ້ເວັບແຄມ (webcam) ພາຍໃນ VM ໄດ້.

=== ຂ້ອຍສາມາດໃຊ້ລະບົບພິມພາສາ (IMEs) ໃນແອັບພລິເຄຊັນພາຍໃນ microVM ໄດ້ບໍ່?

ທ່ານສາມາດໃຊ້ລະບົບພິມພາສາແບບ _xim_ ດັ້ງເດີມທີ່ໃຊ້ໃນ X11 ໄດ້. muvm ຄວນຈະຖືກຕັ້ງຄ່າ environment variables ໃຫ້ເໝາະສົມເພື່ອໃຫ້ໃຊ້ງານກັບແອັບ Qt ແລະ GTK ໄດ້ (ໂດຍການໂຫຼດປລັກອິນ "xim"), ຕາບໃດທີ່ລະບົບພິມພາສາໃນໂຮສຂອງທ່ານຮອງຮັບມັນ. ພວກເຮົາໄດ້ທົດສອບສິ່ງນີ້ດ້ວຍ _fcitx5_ ແລະ Steam ເທິງ KDE Plasma ແລ້ວ.

ໃນອະນາຄົດ ເມື່ອຮອງຮັບ Wayland passthrough ແລ້ວ, ກົນໄກການພິມຂອງ Wayland ແບບ native ກໍຄວນຈະເຮັດວຽກຮ່ວມກັບລະບົບພິມພາສາຂອງໂຮສໄດ້ (ຜ່ານປລັກອິນທີ່ຊ່ວຍວ່າ "wayland"). ພວກເຮົາຍັງບໍ່ມີແຜນທີ່ຈະຮອງຮັບການພິມທີ່ບໍ່ຜ່ານ window system (ເຊັ່ນປລັກອິນ "ibus" ແລະ "fcitx" ໂດຍກົງ) ເພາະມັນຕ້ອງໃຊ້ໄລບຣາຣີ x86-64 ສຳລັບທຸກໆລະບົບພິມພາສາໃນ RootFS ຂອງພວກເຮົາ ແລະ ຍັງຕ້ອງເຮັດ proxy ໂປຣໂຕຄໍສະເພາະຂອງພວກມັນນຳອີກ ເຊິ່ງເປັນເລື່ອງທີ່ເຮັດໄດ້ຍາກຫຼາຍ.

=== ສິ່ງນີ້ຄືກັບ VM ຂອງ Qemu/libvirt/UTM/Parallels/VMWare/VirtualBox/ອື່ນໆ ບໍ່?

ບໍ່ຄື, muvm ບໍ່ໄດ້ເຮັດວຽກຄືກັບ VM ແບບດັ້ງເດີມທີ່ລັນທັງລະບົບ. ເຖິງວ່າມັນຈະໃຊ້ KVM ເປັນເບື້ອງຫຼັງເພື່ອໃຫ້ການຈຳລອງມີປະສິດທິພາບ, ແຕ່ແນວຄິດນັ້ນແຕກຕ່າງຈາກ VM ທົ່ວໄປທີ່ລັນ OS ແຍກຕ່າງຫາກຢ່າງສິ້ນເຊີງ. ເຄີເນິນຂອງເກສແມ່ນ https://github.com/containers/libkrunfw[ເຄີເນິນພິເສດ] ທີ່ຖືກປັບແຕ່ງໃຫ້ເລີ່ມເຮັດວຽກໄດ້ໃນເສີດວິນາທີ, ແລະ VM monitor ກໍສົ່ງຕໍ່ລະບົບໄຟລ໌ຂອງໂຮສໄປໃຫ້ເກືອບທັງໝົດ. ບໍ່ມີການສົ່ງຕໍ່ຮາດແວລະດັບຕ່ຳ (ເຊັ່ນ USB) ແຕ່ພວກເຮົາເນັ້ນໃສ່ການສົ່ງຕໍ່ໂປຣໂຕຄໍຊອບແວລະດັບສູງແທນ ເຊັ່ນ X11/Wayland. VM ນີ້ບໍ່ໄດ້ລັນລະບົບ init ຂອງມັນເອງ, ມີພຽງແຕ່ໂຄ້ດເລີ່ມຕົ້ນເລັກນ້ອຍເທົ່ານັ້ນ. ນັ້ນໝາຍຄວາມວ່າສະພາບແວດລ້ອມໃນ VM ຈະໃຫ້ຄວາມຮູ້ສຶກຄືກັບ OS ຂອງໂຮສເລີຍ, ພຽງແຕ່ປ່ຽນຈາກຂະໜາດໜ້າ 16K ມາເປັນ 4K ເທົ່ານັ້ນ.

=== ບຣາວເຊີ (Browser) ເຮັດວຽກໃນ VM ໄດ້ບໍ່?

ໄດ້, ແຕ່ພວກມັນຈະເຮັດວຽກໃນໂໝດ X11. ແນວໃດກໍຕາມ ມີຂໍ້ຄວນລະວັງຄື: *ບຣາວເຊີທີ່ລັນໃນເກສບໍ່ສາມາດສື່ສານກັບບຣາວເຊີທີ່ລັນຢູ່ນອກເກສໄດ້, ແລະ ມັນອັນຕະລາຍຫຼາຍທີ່ຈະລັນໂປຣໄຟລ໌ (profile) ບຣາວເຊີອັນດຽວກັນທັງໃນເກສ ແລະ ໂຮສພ້ອມກັນ*.

ເພື່ອຫຼີກລ່ຽງບັນຫາເຫຼົ່ານີ້, muvm ໄດ້ຕັ້ງຄ່າ environment variable ເພື່ອບັງຄັບໃຫ້ Firefox ໃຊ້ໂປຣໄຟລ໌ແຍກຕ່າງຫາກເມື່ອເປີດໃນ VM. ນີ້ໝາຍຄວາມວ່າແອັບພລິເຄຊັນທີ່ຕ້ອງເປີດບຣາວເຊີ (ເຊັ່ນການເຂົ້າສູ່ລະບົບ ຫຼື ເບິ່ງເອກະສານ) ຈະເຮັດວຽກໄດ້ຕາມປົກກະຕິ, ແຕ່ Firefox ຈະຖືກເປີດດ້ວຍໂປຣໄຟລ໌ໃໝ່ທີ່ບໍ່ມີຂໍ້ມູນ cookies, ປະຫວັດການທ່ອງເວັບ ແລະ ອື່ນໆຂອງທ່ານ.

CAUTION: ຖ້າທ່ານເປີດໂປຣໄຟລ໌ບຣາວເຊີອັນດຽວກັນໃນເກສ ແລະ ໂຮສພ້ອມກັນ, ຂໍ້ມູນໂປຣໄຟລ໌ຂອງທ່ານອາດຈະເສຍຫາຍໄດ້. ຖ້າບຣາວເຊີຫຼັກຂອງທ່ານບໍ່ແມ່ນ Firefox ແລະ ທ່ານກຳລັງໃຊ້ແອັບທີ່ອາດຈະເປີດບຣາວເຊີຫຼັກຂອງທ່ານໂດຍບໍ່ຕັ້ງໃຈ, ພວກເຮົາແນະນຳໃຫ້ປິດໜ້າຕ່າງບຣາວເຊີທັງໝົດກ່ອນໃຊ້ muvm ຫຼື ຕັ້ງຄ່າແຍກໂປຣໄຟລ໌ດ້ວຍຕົວເອງ.

=== ຂ້ອຍສາມາດໃຊ້ຄຳສັ່ງ sudo ພາຍໃນ VM ໄດ້ບໍ່?

ເນື່ອງຈາກ VM monitor ລັນດ້ວຍຕົວຕົນຜູ້ໃຊ້ຂອງທ່ານເອງ, ມັນຈຶ່ງບໍ່ສາມາດໄດ້ຮັບສິດ root ໄດ້. "root" ພາຍໃນ VM ກໍຍັງຄົງມີສິດເທົ່າກັບຜູ້ໃຊ້ຂອງທ່ານເທົ່ານັ້ນ, ດັ່ງນັ້ນການໃຊ້ sudo ຈຶ່ງບໍ່ມີປະໂຫຍດ (ແລະ ຄວາມຈິງແມ່ນມັນໃຊ້ບໍ່ໄດ້). ພວກເຮົາແນະນຳໃຫ້ຕິດຕັ້ງຊອບແວທີ່ທ່ານຕ້ອງການໃຊ້ກັບ muvm+FEX ໄວ້ພາຍໃຕ້ໂຟນເດີ home ຂອງທ່ານ. ສຳລັບຊອບແວທີ່ຖືກອອກແບບມາໃຫ້ຕິດຕັ້ງໃນ /opt ຫຼື ບ່ອນອື່ນໆ, ພວກເຮົາແນະນຳໃຫ້ຕິດຕັ້ງໃນ OS ໂຮສດ້ວຍຕົວເອງກ່ອນ, ແລ້ວຈຶ່ງລັນແອັບນັ້ນຜ່ານ muvm.

ຖ້າທ່ານຕ້ອງການເຂົ້າເຖິງ root shell ພາຍໃນ VM ເພື່ອການກວດສອບ (debug), ທ່ານສາມາດລັນ `muvm -tip 3335 +++--+++ bash`. ກະລຸນາຈື່ໄວ້ວ່າ ເຖິງແມ່ນວ່າຈະເປັນ "root", ທ່ານກໍບໍ່ສາມາດແກ້ໄຂໄຟລ໌ລະບົບສ່ວນໃຫຍ່ທີ່ເປັນຂອງ root ໄດ້, ແລະ ໄຟລ໌ໃດໆທີ່ທ່ານສ້າງຂຶ້ນກໍຈະຍັງເປັນຂອງຜູ້ໃຊ້ປົກກະຕິຂອງທ່ານ. root shell ມີປະໂຫຍດຫຼັກໆໃນການເຮັດ `strace` ໂປຣເຊສອື່ນ ຫຼື ປ່ຽນການຕັ້ງຄ່າເຄີເນິນ ຫຼື ເຄືອຂ່າຍໃນເກສ (ແຕ່ການປ່ຽນແປງເຫຼົ່ານີ້ຈະຫາຍໄປເມື່ອປິດ VM).

=== ແອັບພລິເຄຊັນພາຍໃນ VM ສາມາດສື່ສານກັບແອັບພລິເຄຊັນຢູ່ນອກ VM ໄດ້ບໍ່?

ການສື່ສານສ່ວນໃຫຍ່ຈະຈຳກັດຢູ່ທີ່ລະບົບໄຟລ໌ຂອງໂຮສ. VM ໃຊ້ໂຟນເດີ home ຮ່ວມກັນກັບໂຮສ (ແລະ ລະບົບໄຟລ໌ສ່ວນໃຫຍ່), ດັ່ງນັ້ນໄຟລ໌ໃດໆທີ່ທ່ານສ້າງໃນຝັ່ງໜຶ່ງກໍຈະເຫັນໃນອີກຝັ່ງໜຶ່ງ.

ຍ້ອນ virtiofs-DAX, ການສື່ສານຜ່ານໜ່ວຍຄວາມຈຳຮ່ວມ (`/dev/shm`) ຈຶ່ງສາມາດໃຊ້ໄດ້ລະຫວ່າງແອັບໃນເກສ ແລະ ໂຮສ. ສິ່ງນີ້ຖືກໃຊ້ໃນລະຫັດ X11 forwarding ເປັນຕົ້ນ.

ນອກຈາກນັ້ນ ທ່ານຍັງສາມາດແບ່ງປັນສຽງລະຫວ່າງແອັບໃນໂຮສ ແລະ ເກສໄດ້ໂດຍໃຊ້ PulseAudio forwarding. ຕົວຢ່າງ: ທ່ານສາມາດອັດສຽງຈາກເກສໂດຍໃຊ້ແອັບອັດສຽງໃນໂຮສ ແລະ ເລືອກອັດຈາກອຸປະກອນ "Monitor" ຂອງລະບົບ. ທ່ານຍັງສາມາດຕັ້ງຄ່າ virtual sinks/sources ໃນໂຮສໂດຍໃຊ້ PipeWire ແລະ ສັ່ງໃຫ້ແອັບໃນເກສໃຊ້ພວກມັນເພື່ອຈັດການສຽງຕາມທີ່ຕ້ອງການ. ໝາຍເຫດວ່າໂປຣໂຕຄໍ PipeWire ແບບ native ຈະບໍ່ຖືກສົ່ງຕໍ່, ຈະມີພຽງແຕ່ PulseAudio ເທົ່ານັ້ນ. ແອັບທີ່ໃຊ້ ALSA ຈະໄດ້ຮັບການຮອງຮັບຜ່ານປລັກອິນ `pulse`.

ຖ້າທ່ານໃຊ້ host compositor ທີ່ຮອງຮັບ XWayland video bridging (ເຊັ່ນ KDE Plasma / KWin), ທ່ານຈະສາມາດແບ່ງປັນໜ້າຈໍ ຫຼື ອັດວິດີໂອໜ້າຈໍຈາກ VM ໄດ້, ລວມທັງໜ້າຈໍໂຮສທັງໝົດ ແລະ ໜ້າຕ່າງ Wayland. ໃຫ້ແນ່ໃຈວ່າແອັບທີ່ທ່ານໃຊ້ຮອງຮັບການຈັບພາບໜ້າຕ່າງແບບ "classic" XComposite. ເມື່ອທ່ານເລີ່ມແບ່ງປັນໜ້າຈໍ, ທ່ານຈະສາມາດເລືອກໜ້າຕ່າງແອັບ X11 ໂດຍກົງ ຫຼື ເລືອກໜ້າຕ່າງສະເືອນ "Xwayland Video Bridge". ເມື່ອທ່ານເຮັດແບບນັ້ນ, KDE ຈະຖາມທ່ານເອງວ່າຕ້ອງການແບ່ງປັນໜ້າຕ່າງ ຫຼື ໜ້າຈໍໃດແທ້ໆ.

=== ເປັນຫຍັງຂ້ອຍຈຶ່ງເຫັນຈຳນວນ CPU core ໃນ VM ໜ້ອຍກວ່າຕົວຈິງ?

ໂດຍປົກກະຕິ, `muvm` ຈະສົ່ງຕໍ່ CPU ຕາມຈຳນວນ performance cores ທີ່ມີໃນເຄື່ອງໂຮສຂອງທ່ານ ແລະ ຈະລັອກ vCPUs ເຫຼົ່ານັ້ນໄວ້ກັບ performance cores ແທ້ໆ. ເນື່ອງຈາກ CPU scheduler ຂອງໂຮສບໍ່ສາມາດເຫັນການເຮັດວຽກຂອງເກສໄດ້, ການເຮັດແບບນີ້ຈະຊ່ວຍໃຫ້ປະສິດທິພາບຄົງທີ່. ທ່ານສາມາດປ່ຽນແປງຄ່ານີ້ໄດ້ດ້ວຍຕົວເລືອກ `muvm --cpu-list=CPU_LIST`.

=== ຂ້ອຍຈະໃຊ້ໄດຣເວີພາຍນອກ (external drive) ເປັນໂຟນເດີໄລບຣາຣີຂອງ Steam ໄດ້ແນວໃດ?

ເຮັດຕາມຂັ້ນຕອນເຫຼົ່ານີ້ເພື່ອຕັ້ງຄ່າໄດຣເວີພາຍນອກສຳລັບ Steam:

. ຟໍແມັດ (Format) ໄດຣເວີພາຍນອກຂອງທ່ານໃຫ້ເປັນລະບົບໄຟລ໌ຂອງ Linux ເຊັ່ນ ext4.
+
NOTE: FAT32, exFAT ແລະ ລະບົບໄຟລ໌ອື່ນໆທີ່ບໍ່ຮອງຮັບສິດການເຂົ້າເຖິງ (permissions) ຂອງ Linux ຈະໃຊ້ວຽກບໍ່ໄດ້.

. ເມົາຕ໌ໄດຣເວີຂອງທ່ານດ້ວຍຕົວເອງພາຍໃຕ້ໂຟນເດີທີ່ muvm ສາມາດເຂົ້າເຖິງໄດ້ ເຊັ່ນ `/mnt/steam`.
+
NOTE: ພວກເຮົາແນະນຳໃຫ້ເມົາຕ໌ໄດຣເວີດ້ວຍຕົວເອງ (ເຊັ່ນ: `sudo mount /dev/sdX1 /mnt/steam`). ຖ້າທ່ານຕັ້ງຄ່າໃຫ້ເມົາຕ໌ອັດຕະໂນມັດຜ່ານ `/etc/fstab`, ລະບົບຂອງທ່ານຈະບູດບໍ່ຂຶ້ນຖ້າບໍ່ໄດ້ສຽບໄດຣເວີນັ້ນໄວ້.
+
NOTE: ຈຸດເມົາຕ໌ເລີ່ມຕົ້ນສຳລັບໄດຣເວີທີ່ເມົາຕ໌ຜ່ານເດັສທັອບ (udisks) ຈະຍັງໃຊ້ງານບໍ່ໄດ້ໃນຕອນນີ້.

. ກວດເບິ່ງໃຫ້ແນ່ໃຈວ່າລະບົບໄຟລ໌ root ນັ້ນສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜູ້ໃຊ້ປົກກະຕິ:
+
`sudo chown $\{USER}: /mnt/steam`

. ສ້າງໂຟນເດີເປົ່າຊື່ວ່າ `steamapps` ໄວ້ທີ່ root ຂອງໄດຣເວີທີ່ເມົາຕ໌:
+
`mkdir /mnt/steam/steamapps`

. ເປີດ Steam ຕາມປົກກະຕິ

. ຄລິກທີ່ແທັບ Library, ຈາກນັ້ນຄລິກທີ່ໄອຄອນຮູບເຟືອງ (settings)

. ເລືອກ *Storage* ຢູ່ເມນູເບື້ອງຊ້າຍ, ຄລິກທີ່ກ່ອງລາຍການດ້ານເທິງຂອງແຜງ, ແລ້ວເລືອກ *Add Drive*.

. ເລືອກໄປທີ່ບ່ອນທີ່ເມົາຕ໌ໄດຣເວີຂອງທ່ານ (`/mnt/steam`), ເຊິ່ງທ່ານຄວນຈະເຫັນພຽງແຕ່ໂຟນເດີ `steamapps` ທີ່ວ່າງເປົ່າຢູ່ນັ້ນ, ຈາກນັ້ນ (ໂດຍບໍ່ຕ້ອງເລືອກຫຍັງຕື່ມ) ໃຫ້ຄລິກທີ່ປຸ່ມ *Select*.

ຕອນນີ້ທ່ານຄວນຈະສາມາດເລືອກບ່ອນດາວໂຫຼດໃໝ່, ຕັ້ງໃຫ້ເປັນຄ່າເລີ່ມຕົ້ນ ແລະ ດາວໂຫຼດເກມລົງໃນນັ້ນໄດ້ແລ້ວ.

Want to help? Learn how to contribute to Fedora Docs ›