AWS เพิ่มการรองรับ nested virtualization

 (github.com/aws)
3 คะแนน โดย GN⁺ 2026-02-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อ AWS SDK for Go v2 ได้รับการอัปเดต ก็มีการเพิ่ม ความสามารถในการรันเครื่องเสมือนอีกตัวภายในเครื่องเสมือน
  • ฟีเจอร์ใหม่นี้ทำให้ สามารถรัน nested VM ได้แม้บน EC2 instance ที่ไม่ใช่ bare metal
  • การขยาย การรองรับ nested virtualization บน AWS EC2 จะเป็นพื้นฐานที่ช่วยเพิ่ม การใช้ประโยชน์ของชั้น virtualization ในสภาพแวดล้อมการพัฒนาและการทดสอบ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-13
ความเห็นจาก Hacker News
  • ตอนนี้สามารถรัน Firecracker หรือ microVM อื่น ๆ ได้โดยตรงภายใน AWS VM แล้ว ถือว่าเป็นการเปลี่ยนแปลงครั้งใหญ่
    ก่อนหน้านี้ถ้าจะทำแบบนี้ต้องใช้ bare-metal instance ที่มีราคาแพง
    อนึ่ง GCP รองรับ nested virtualization มานานแล้ว
    • รอคอมเมนต์แบบนี้อยู่เลย microVM อย่าง Firecracker นี่แหละคือตัวอย่างการใช้งานที่ดี
      การตั้งค่าสภาพแวดล้อมทดสอบหรือพัฒนาได้ง่ายก็เป็นข้อดีอีกอย่าง
      nested virtualization ไม่ได้หมายถึงแค่ VM เต็มรูปแบบเท่านั้น
    • อยากรู้ว่า อัตราการลดลงของประสิทธิภาพ ในสภาพแวดล้อมแบบนี้อยู่ที่ประมาณเท่าไร
  • มีการเพิ่มการรองรับ nested virtualization เข้าไปใน SDK หลักแล้ว
    ในรีเจียน us-west-2 สามารถเห็นตัวเลือก “Nested Virtualization” ได้แล้ว และใช้งานได้กับ instance type M8id / C8id / R8id
    สำหรับโซลูชัน sandbox แบบ micro-VM อย่าง E2B ที่ผมมีส่วนร่วมด้วย นี่เป็นข่าวใหญ่มาก
  • มีใครอธิบายได้ไหมว่าทำไมเรื่องนี้ถึงสำคัญมากขนาดนั้น?
    ตอนก่อนหน้านี้ที่ผมลอง nested virtualization รู้สึกว่ามันไม่ค่อยมีประโยชน์นอกจากระดับ PoC
    • มีประโยชน์มากในแง่ของการแยกการทำงาน
      มีโซลูชันคอนเทนเนอร์แบบอิง VM จำนวนมาก เช่น Kata Containers, gVisor, Firecracker
      ตัวอย่างเช่น สามารถแยก pod ของ Kubernetes ในระดับ VM ได้
      นอกจากนี้ยังทำให้ live migration ระหว่าง EC2 instance เป็นไปได้ จึงดูแลงานที่รันต่อเนื่องได้ง่ายขึ้น
      ในสภาพแวดล้อม CI/CD ก็สะดวกขึ้นมาก เพราะสามารถ build และทดสอบ system image ได้โดยตรงบน EC2
      GCP, VMWare, KVM ต่างก็มีความสามารถนี้มานานแล้ว เลยเสียดายที่ EC2 เพิ่งตามมาทันตอนนี้
    • ตอนนี้สามารถรัน VM ภายใน AWS instance ที่ถูกกว่ามากได้แล้ว โดยไม่จำเป็นต้องใช้ bare-metal ทั้งเครื่อง
      มีประโยชน์อย่างยิ่งกับงานอย่าง network simulation ที่จำลองฮาร์ดแวร์เครือข่ายด้วย QEMU
  • ให้ความรู้สึกเหมือน AWS เพิ่งมาถึงปี 2018 ตอนนี้เอง
    • ใช่ เป็นเรื่องที่ค่อนข้างธรรมดามาก
      ผมใช้สิ่งนี้บนฮาร์ดแวร์ผู้บริโภคทั่วไปที่บ้านผ่าน libvirt มานานแล้ว
      เรียกได้ว่า AWS เพิ่งตามฟีเจอร์เก่า ๆ นี้ทัน
  • สงสัยว่าฟีเจอร์นี้จะมีประโยชน์กับ openclaw หรือพวก agent ด้วยไหม
    • ทำได้อยู่ แต่ถ้าเป็นการ deploy จริง ผมน่าจะเลือกวิธี build image ด้วย nix มากกว่า nested virtualization
  • อยากเห็น ตัวเลขประสิทธิภาพ ในสภาพแวดล้อม nested virtualization โดยเฉพาะผลกับงานที่เน้น IO
  • โดยทั่วไปอยากรู้ว่าผลกระทบต่อประสิทธิภาพของ nested virtualization อยู่ประมาณไหน
    น่าจะมี MMU overhead ซ้อนกันหลายชั้น
    • ขึ้นอยู่กับ workload และวิธีการ implement
      งาน CPU ล้วนแทบไม่ต่าง แต่ IO อาจ แทบไม่ต่างเลยหรือแย่มากก็ได้ แล้วแต่วิธี implement
      เหตุการณ์อย่าง trap/vmexit ต้องผ่านเพิ่มอีกหนึ่งชั้น
    • ถ้าจำไม่ผิด คำสั่ง virtualization ไม่ได้ถูกซ้อนกันตรง ๆ แต่ทำงานแบบ ร่วมมือกับ ฮาร์ดแวร์ virtualization ภายนอก
      ไม่แน่ใจว่า implementation ของ AWS ใช้วิธีนี้หรือเปล่า
    • ในทางปฏิบัติโดยรวมแล้วมี ประสิทธิภาพลดลงราว 5~15%
  • รู้สึกว่าสำหรับ แอป legacy น่าจะมีต้นทุนสูง
  • ในที่สุดก็มาเสียที ตื่นเต้นมาก