- Quickemu เป็น wrapper สำหรับ QEMU ที่เมื่อเลือกระบบปฏิบัติการที่จะรันแล้ว จะจัดการการตั้งค่าที่จำเป็นสำหรับการสร้างเครื่องเสมือนโดยอัตโนมัติ ทำให้สร้างและรัน VM ของ Windows, macOS และ Linux ได้อย่างรวดเร็ว
quickget จะดาวน์โหลด อิมเมจ OS จาก upstream ของระบบปฏิบัติการที่ต้องการโดยอัตโนมัติและสร้างไฟล์ตั้งค่า VM ส่วน quickemu จะตรวจจับฮาร์ดแวร์และรัน VM ด้วยการตั้งค่าที่เหมาะสมกับคอมพิวเตอร์เครื่องนั้น- เป้าหมายแรกเริ่มคือทำให้การทดสอบ Linux distribution ทำได้รวดเร็ว โดยสามารถเก็บ VM และค่าตั้งไว้ในตำแหน่งที่ต้องการ เช่น ที่เก็บข้อมูล USB ภายนอกหรือโฮมไดเรกทอรี และไม่ต้องใช้ สิทธิ์ยกระดับ ในการรัน
- ปัจจุบันรองรับ ระบบปฏิบัติการเกือบ 1000 รุ่น รวมถึง macOS, Windows, BSD ส่วนใหญ่, FreeDOS, Haiku, KolibriOS, OpenIndiana, ReactOS และอื่นๆ
- ทำงานบนโฮสต์ Linux และ macOS และมีฟีเจอร์ที่จำเป็นต่อการใช้งาน VM เช่น SPICE, การแชร์ไฟล์, QEMU Guest Agent, VirGL, USB passthrough, port forwarding, เสียง, การบูตแบบ EFI และ Legacy BIOS
Quickemu ทำอะไร
- Quickemu เป็น wrapper ที่ครอบ QEMU ไว้ โดยจะจัดการการตั้งค่าที่จำเป็นสำหรับการสร้างเครื่องเสมือนโดยอัตโนมัติ
- ผู้ใช้เพียงเลือกระบบปฏิบัติการที่จะรัน และไม่จำเป็นต้องกำหนดตัวเลือกการตั้งค่าจำนวนมากด้วยตนเอง
- มีเครื่องมือหลักอยู่ 2 ตัว
quickget: ดาวน์โหลด upstream OS ของระบบปฏิบัติการที่ต้องการโดยอัตโนมัติและสร้างไฟล์ตั้งค่า VMquickemu: ตรวจสอบฮาร์ดแวร์ของโฮสต์ แล้วรันเครื่องเสมือนด้วยการตั้งค่าที่เหมาะสมที่สุดสำหรับคอมพิวเตอร์เครื่องนั้น
จุดเริ่มต้นของโครงการและขอบเขตปัจจุบัน
- เป้าหมายแรกเริ่มคือทำให้ การทดสอบ Linux distribution ทำได้อย่างรวดเร็ว
- สามารถบันทึก VM และค่าตั้งไว้ในตำแหน่งที่ต้องการได้ เช่น ที่เก็บข้อมูล USB ภายนอกหรือโฮมไดเรกทอรี
- การรันเครื่องเสมือนไม่ต้องใช้ สิทธิ์ยกระดับ
- ปัจจุบันขอบเขตรองรับได้ขยายจาก Linux distribution ไปสู่ macOS, Windows, BSD ส่วนใหญ่ และระบบปฏิบัติการที่ไม่ใช่ Linux
- ตัวอย่างระบบที่รองรับ ได้แก่ FreeDOS, Haiku, KolibriOS, OpenIndiana, ReactOS
ระบบปฏิบัติการและโฮสต์ที่รองรับ
- โฮสต์รองรับ Linux และ macOS
- ระบบปฏิบัติการฝั่ง guest รวมถึง
- macOS Sequoia, Sonoma, Ventura, Monterey, Big Sur, Catalina, Mojave
- Windows 10 และ 11 รวม TPM 2.0
- Windows Server 2022, 2019, 2016
- Ubuntu และ Ubuntu flavour อย่างเป็นทางการทั้งหมด
- BSD ส่วนใหญ่และระบบปฏิบัติการที่ไม่ใช่ Linux อีกหลายตัว
- รองรับ guest แบบ ARM64 จึงสามารถรัน VM แบบ aarch64 ได้
- บนโฮสต์ ARM จะรันแบบ native
- บนโฮสต์ x86_64 จะรันแบบ emulation
- จำนวนรุ่นของระบบปฏิบัติการที่รองรับมี เกือบ 1000 รุ่น
ฟีเจอร์ของ VM
- รองรับ SPICE แบบเต็มรูปแบบ รวมถึงการแชร์คลิปบอร์ดระหว่างโฮสต์/guest
- วิธีแชร์ไฟล์รองรับหลายแบบตามระบบปฏิบัติการของ guest
- VirtIO-webdavd: แชร์ไฟล์สำหรับ guest Linux และ Windows
- VirtIO-9p: แชร์ไฟล์สำหรับ guest Linux และ macOS
- Samba: แชร์ไฟล์สำหรับ guest Linux, macOS, Windows โดยโฮสต์ต้องติดตั้ง
smbd ไว้
- รองรับ QEMU Guest Agent ทำให้เข้าถึงเอเจนต์ระดับระบบผ่านคำสั่ง QMP มาตรฐานได้
- ด้านกราฟิกและอุปกรณ์ รองรับ VirGL acceleration, USB device passthrough และ smartcard passthrough
- รวมฟีเจอร์ด้านเครือข่ายและอินพุต/เอาต์พุตด้วย
- การทำ SSH port forwarding ไปยัง guest โดยอัตโนมัติ
- network port forwarding
- เสียงแบบ full-duplex
- การรองรับอักษรเบรลล์
- การบูตแบบ EFI ทั้งที่มีหรือไม่มี SecureBoot
- การบูตแบบ Legacy BIOS
ขั้นตอนเริ่มต้นอย่างรวดเร็ว
- หลังจาก ติดตั้ง Quickemu แล้ว สามารถสร้างและรัน VM ได้ใน 2 ขั้นตอน
- ใช้
quickget เพื่อดาวน์โหลดอิมเมจ ISO และสร้างไฟล์ตั้งค่า VM
quickget nixos unstable minimal
- ใช้
quickemu เพื่อเริ่ม VM โดยใช้ไฟล์ตั้งค่าที่ quickget สร้างไว้
quickemu --vm nixos-unstable-minimal.conf
- หากรัน
quickget โดยไม่ใส่อาร์กิวเมนต์ จะเห็นรายการระบบปฏิบัติการที่รองรับทั้งหมด
เอกสารและแหล่งอ้างอิง
- วิกิครอบคลุมวิธีเริ่มต้น การตั้งค่าขั้นสูง และวิธีใช้งาน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อก่อนตอนต้องจัดการโฮสต์ VM หลายตัวที่ต่างกันกับ VM ในเครื่องจำนวนมาก ก็ใช้ตัวนี้มาตลอด
ต้องรู้ศัพท์พื้นฐานเกี่ยวกับ VM อยู่บ้าง แต่ทำให้นึกถึง GUI แบบเก่าที่อัดแน่นด้วยฟีเจอร์และพลัง
ถ้าความต้องการของคุณเรียบง่าย หรือยังไม่คุ้นกับฝั่ง VM มากนัก Gnome Boxes ใช้แบ็กเอนด์เดียวกันแต่ให้ GUI ที่สะอาดตา ความเรียบง่ายทำให้ความยืดหยุ่นลดลง แต่ข้อดีคือถ้าภายหลังต้องปรับการตั้งค่าที่ Boxes ไม่เปิดให้เห็น ก็สามารถเปิด VM ของ Gnome Boxes ด้วย virt-manager ได้
เมื่อรันบนระบบระยะไกลผ่าน SSH มันจะ “X forwarding” คอนโซล QEMU มายังเซสชัน Wayland ในเครื่องของ Fedora
ตอนแรกคิดว่ามันรันในโหมด headless แต่พอมีหน้าต่างเด้งขึ้นมาก็ประหลาดใจทีเดียว :)
ทำให้จินตนาการได้ว่าถ้าการตั้งค่าถูกแยกออกจากซอฟต์แวร์ที่ถูกตั้งค่านั้นจะเป็นอย่างไร แทนที่จะต้องเรียนรู้วิธีที่โปรแกรม UI แต่ละตัวประดิษฐ์ล้อขึ้นมาใหม่ ก็เลือกใช้ ตัวจัดการการตั้งค่า ที่ชอบได้
สิ่งที่ใกล้เคียงที่สุดตอนนี้คือไฟล์ตั้งค่าแบบข้อความ โปรแกรมทุกตัวที่ใช้แนวทางนี้ต้องเลือกภาษาและตำแหน่งจัดเก็บของตัวเอง
ไอเดียที่ช่วงนี้คิดบ่อยคือ ชั้นตัวกลางการตั้งค่า ใช้ภาษา/รูปแบบใดก็ได้ที่ต้องการสำหรับ UI ตั้งค่าที่ผู้ใช้เห็น แล้วใช้ข้อมูลนั้นเป็นแหล่งความจริงเดียวเพื่อสร้างไฟล์ตั้งค่าที่ซอฟต์แวร์จะอ่าน
มีฟังก์ชันจัดการที่มีประโยชน์อย่างการเริ่ม/หยุดตามไฟล์ตั้งค่า หรือการเข้าถึงคอนโซลแบบ serial แต่สิ่งเหล่านี้ก็ทำเองด้วยเชลล์สคริปต์ได้ง่ายมาก การจัดการสตอเรจของ libvirt ยืดยาวและซับซ้อนอย่างน่ากลัว แต่กลับจัดการ thin LV หรือ ZFS ได้ไม่ดีด้วยซ้ำ
ถ้าต้องการรันตามแนวทางองค์กรมาตรฐานและไม่คิดจะเรียนรู้ซอฟต์แวร์พื้นฐานอย่าง QEMU หรือ shell หรือไม่ได้จำเป็นต้องใช้ฟีเจอร์ก้ำกึ่งบางอย่างของ libvirt ขอแนะนำให้ใช้ QEMU บน KVM โดยตรงและใช้สคริปต์ของตัวเอง คุณจะได้เรียนรู้ QEMU มากกว่าการใช้ Python wrapper ที่ไม่ค่อยดี และมีสิทธิ์ควบคุมระบบมากขึ้น
อีกอย่าง IBM/Red Hat ดูเหมือนจะทิ้ง virt-manager ไปโดยปริยายแล้ว โดยผลักไปทางเว็บอินเทอร์เฟซใหม่อย่าง Copilot
Quickemu น่าสนใจกว่า เพราะไม่ต้องเสียเวลาเรียนรู้ UI ขนาดใหญ่ซับซ้อน แค่ดูตัวอย่างสั้น ๆ แล้วเปิด VM ใหม่ได้ทันที
เครื่องมือนี้ดาวน์โหลดไฟล์ใด ๆ จากอินเทอร์เน็ต แล้วนำ checksum ไปเทียบกับไฟล์ใด ๆ อีกไฟล์หนึ่งบนอินเทอร์เน็ต[2]
ไม่ใช่แนวปฏิบัติด้านความปลอดภัยที่ดีที่สุด วิธีที่ถูกต้องคือคอมมิตคีย์ GPG ของผู้พัฒนาดิสโทรไว้ในรีโพซิทอรี แล้วตรวจสอบไฟล์ทั้งหมดด้วยคีย์นั้น
ทั้งนี้ไม่ได้ตั้งใจจะลดคุณค่าความพยายามของโปรเจกต์นี้ในการค้นหา flag ที่ถูกต้องเพื่อส่งให้ QEMU สำหรับบูต OS หลายตัว
[1] https://news.ycombinator.com/item?id=28797129
[2] https://github.com/quickemu-project/quickemu/blob/0c8e1a5205...
แถมยังเพิ่มการตรวจสอบว่าแฮชตรงกัน ซึ่งคนส่วนใหญ่ไม่ได้ทำด้วยซ้ำ
สมัย FTP checksum กับ GPG เป็นสิ่งจำเป็น ใน HTTP/TCP การลองใหม่กับการจัดการ checksum เป็นหน้าที่ของ TCP ทำให้ความจำเป็นของ GPG ยิ่งมากขึ้น แต่เพราะการโจมตีแบบคนกลาง ทั้งสองอย่างก็ยังจำเป็นอยู่
แต่ถ้าเป็น HTTPS แล้ว ทำไมยังสำคัญอยู่? HTTPS ไม่ได้ทำหน้าที่แทนการตรวจสอบทั้งสองอย่างและการยืนยันลายเซ็นหรือ
หวังว่าความสนใจจาก Hacker News ในปีนี้จะเป็นแรงผลักดันให้มีใครสักคนทำการตรวจสอบลายเซ็นสำหรับ Linux
0. https://mac.getutm.app/
https://docs.getutm.app/installation/ios/
ตัวอย่าง Alma Linux ล่าสุดเป็นดังนี้
$ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattendedดื่มกาแฟสักแก้วกลับมา ก็จะมี Alma Linux VM ที่ติดตั้งเสร็จแล้วกำลังทำงานอยู่ รายการ OS ที่รองรับจะแตกต่างกันไปตามเวอร์ชันของ libvirt และตรวจสอบได้ด้วยคำสั่งต่อไปนี้
$ osinfo-query osถ้าต้องการอิมเมจดิสก์ของ Fedora 39 ก็มี virt-builder ด้วย
$ virt-builder fedora-39ภายหลังสามารถนำเข้าไปยัง libvirt ด้วย
virt-install --importได้virt-install ดาวน์โหลด ISO ให้อัตโนมัติไหม? ถ้าลองทำจะได้ข้อความแบบนี้
$ virt-install --name alma9 --memory 1536 --vcpus 1 --disk path=$PWD/alma9.img,size=20 --cdrom alma9.iso --unattendedERROR Validating install media 'alma9.iso' failed: Must specify storage creation parameters for non-existent path '/home/foo/alma9.iso'.ยังไม่ชัดเจนว่าผลลัพธ์นี้จะออกมาอย่างไร เช่น hostname จะเป็นอะไร ดิสก์จะถูกแบ่งพาร์ทิชันอย่างไร จะติดตั้งแพ็กเกจอะไรบ้าง และ timezone กับ layout แป้นพิมพ์จะถูกตั้งเป็นอะไร เป็นต้น
ถ้าจะทำแบบนี้ต้องติดตั้ง libosinfo-bin
ความสะดวกของเครื่องมือแบบนี้ยอดเยี่ยมมาก แต่ถ้ารวมสคริปต์หลักสองตัวเข้าด้วยกันก็มีประมาณ Bash 5000 บรรทัด
อยากตรวจดูก่อนรัน แต่ก็ไม่อยากอ่าน Bash 5000 บรรทัด
ไม่รู้ว่าจะโน้มน้าวได้ไหม แต่ก่อนรันได้ลองอ่านสคริปต์ Bash แล้ว และมันมีโครงสร้างค่อนข้างดี ฟังก์ชันถูกแบ่งตามความสามารถอย่างเหมาะสม ชื่อตัวแปรก็สมเหตุสมผล มีคอมเมนต์ที่เป็นประโยชน์ ไม่มี control flow แปลก ๆ หรือการเรียกแบบอ้อม ๆ และใช้คำสั่งที่อ่านยากให้น้อยที่สุด จัดว่าเป็นหนึ่งในสคริปต์เชลล์ที่อ่านง่ายที่สุดเท่าที่เคยเห็นมา
ถ้าคิดถึงสิ่งที่สคริปต์นี้ทำจริง ๆ โค้ดที่ค่อนข้างตรงไปตรงมาก็สมเหตุสมผล แก่นของมันคือการรันคำสั่งหนึ่งเพื่อเริ่ม QEMU โค้ดที่เหลือคือการตรวจระบบโลคัลว่าจะส่งอาร์กิวเมนต์อะไรให้คำสั่งนั้น หรือดาวน์โหลดไฟล์บางไฟล์เมื่อจำเป็น
ไม่ได้หมายความว่าควรรันแบบหลับหูหลับตา แต่ปกติเกณฑ์ที่เราใช้เลือกซอฟต์แวร์ที่จะรันไม่ได้ขึ้นอยู่กับว่าเราคุ้นเคยกับซอร์สโค้ดหรือไม่
“You are a linux guru, and you have extensive experience with bash and all forms of unix/linux. I am going to be pasting a large amount of code in a little bit at a time. Every time I paste code and send it to you, you are going to add it to the previous code and ask me if I am done. When I am done we are going to talk about the code, and you are going to help me break it down and understand what is going on. If you understand you will ask me to start sending code, otherwise ask me any questions before you ask for the code.”
เคยใช้วิธีนี้กับโค้ดที่สั้นกว่านี้ แต่ก็ยังต่ำกว่า 1000 บรรทัดและเกินขีดจำกัดพรอมป์อยู่ ผลออกมาค่อนข้างดี ยอมรับว่าช่วงนี้ ChatGPT ขี้เกียจลง และบางครั้งต้องระบุให้ชัดว่าอย่าขี้เกียจ ขอ output ทั้งหมดตามที่ร้องขอ แต่โดยรวมแล้วอธิบายโค้ดได้ค่อนข้างดี
วลี “หลายตาทำให้บั๊กทั้งหมดตื้นขึ้น” สำหรับผู้ใช้บางคนดูเหมือน cliché ที่ทำให้หยุดคิดได้ เหมือนคิดว่าเปิดเผยให้ตรวจสอบได้ก็น่าจะโอเค แล้วนึกภาพว่ามีกองทัพผู้ตรวจสอบโค้ดคอยตรวจทุกอย่างอยู่ แต่ในความเป็นจริงกลับคาดหวังด้านเจตนาร้ายมากกว่าด้านเจตนาดี
ฝั่ง Windows มี utility สำหรับ tweak ระบบมาอย่างต่อเนื่องหลายสิบปีแล้ว มันดึงดูดคนที่เชื่อว่านักพัฒนาจาก “บริษัทใหญ่” ไม่มีแรงจูงใจจะรีดประสิทธิภาพระบบให้สุด และทิ้งตัวเลือกง่าย ๆ ที่เป็นประโยชน์กับทุกคนไว้หลัง quick setting หรือ registry tweak บางอย่าง นึกถึง TronScript ที่เห็นเป็นครั้งคราว ซึ่งเมื่อดูประวัติและการมีส่วนร่วมแล้วก็ดูจะผ่านการทดสอบกลิ่นได้ จึงมองว่าโอเค แต่ภายใต้ชื่อ automation มันซ่อนรายละเอียดและทำให้ผู้ใช้คาดหวังว่ามันจะตัดสินใจแทนได้ดี จะขุดลงไปตรวจสอบและเรียนรู้ว่าอะไรเกิดขึ้นและทำไมก็ได้ แต่สำหรับหลายคนโดยเนื้อแท้แล้วมันก็ไม่ต่างจากไบนารี
ข้อดีคือเครื่องมือส่วนใหญ่แบบนี้มีฐานผู้ใช้จำกัด จึงไม่ค่อยคุ้มที่จะเจาะ หากแบรนด์ใดถูกใช้มากพอ ก็อาจเกิดสถานการณ์แบบ Piriform CCleaner ที่ถูกฝัง backdoor ในปี 2017 ได้
ดูน่าสนใจดี แต่ช่วยบอกได้ไหมว่ามันมีข้อดีอะไรสำหรับคนที่ใช้ Ubuntu แล้วรันแค่ Windows 11 ผ่าน VirtualBox เป็นครั้งคราว?
บน Linux ขอแนะนำ Incus/LXD อย่างยิ่ง การรัน VM ทำได้ง่ายแบบนี้
หลังจากรันแล้ว เข้าถึง shell ได้ดังนี้
Incus/LXD รองรับ system container ด้วย
สิ่งหนึ่งที่ผมชอบแต่แทบไม่มีใครพูดถึงคือ systemd-nspawn ให้รัน
docker create --name ubuntu ubuntu:22.04แล้วใช้docker export ubuntuสร้างไฟล์ tar จาก Docker image ใดก็ได้จากนั้นแตกไฟล์ไปไว้ที่
/var/lib/machines/ubuntuก็พอ ต้องเลือก image ที่มี systemd อยู่ หรือไม่ก็ติดตั้ง systemd ภายในคอนเทนเนอร์ สุดท้ายเข้าไปด้วยmachinectl start ubuntuและmachinectl shell ubuntusystemd-nspawn เรียบง่ายและเบามาก แถมจำลองเครื่อง Linux จริงได้ดีมาก หากนำ root partition ใดก็ได้ที่ใช้ systemd มาบูตด้วย systemd-nspawn ก็จะทำงานได้ตามนั้น
มี ตัวเลขการเปลี่ยนแปลงด้านประสิทธิภาพ เมื่อเทียบกับการรัน VM แบบธรรมดาไหม? ปกติผมรัน Linux guest บน Linux host และมักผิดหวังกับประสิทธิภาพของ guest
ผมไม่เคยลองศึกษาเรื่องการจูนประสบการณ์ใช้งาน VM เลย เลยสงสัยว่าตัวเองพลาดไปแค่ไหน เร็วขึ้น 5%? หรือ 100%?
รันแบบเนทีฟบน Arm หรือก็คือ Apple Silicon ได้ไหม? แล้ว macOS เวอร์ชันล่าสุดเป็นอย่างไร? มีการเร่งความเร็วกราฟิกไหม? เครือข่ายจัดการอย่างไร?
อยากรู้ว่าแตกต่างจาก Proxmox อย่างไร และสามารถทำซ้ำการปรับแต่งที่ทำตรงนี้ด้วยตนเองใน สภาพแวดล้อม Proxmox ของผมได้ไหม
Quickemu ดูเหมือนจะมุ่งเป้าไปที่การใช้งานบนเดสก์ท็อปเป็นหลัก