SSD Nodes Learn
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-07-24

รัน Proxmox บน VPS ได้ไหม ต้องเช็คอย่างไร

ตรวจสอบว่า VPS รองรับ Nested Virtualization หรือไม่ด้วยคำสั่ง kvm-ok เพื่อดูว่ามี flag vmx หรือ svm หรือไม่ ก่อนเริ่มติดตั้ง Proxmox หรือ KVM

คำตอบแบบสรุป

Nested virtualization คือการรัน hypervisor ภายใน virtual machine: VPS ของคุณเป็น guest อยู่แล้ว และคุณต้องการให้มันทำหน้าที่เป็น host สำหรับ guest อื่นๆ ต่อไป ฟีเจอร์นี้จะใช้งานได้ก็ต่อเมื่อ hypervisor ของผู้ให้บริการเปิดใช้งาน CPU virtualization extensions ให้กับ instance ของคุณเท่านั้น — ตรวจสอบ flag vmx (Intel) หรือ svm (AMD) ที่ /proc/cpuinfo หากไม่พบทั้งสองอย่าง การตั้งค่าใดๆ ภายใน VPS จะไม่สามารถแก้ไขปัญหานี้ได้

ข้อควรทราบเบื้องต้น: Docker ไม่จำเป็นต้องใช้ฟีเจอร์นี้ เนื่องจาก container ใช้ kernel ร่วมกับ VPS และไม่ได้เข้าถึง /dev/kvm หากเป้าหมายของคุณคือ "การรันบริการหลายอย่างใน container บน server" คุณมีสิ่งที่จำเป็นครบถ้วนแล้ว Nested virtualization จะมีความสำคัญก็ต่อเมื่อคุณต้องการ kernel ตัวที่สอง เช่น การทำ lab ด้วย Proxmox, การรัน Windows guest, Firecracker microVMs, Android emulator, การทดสอบ Kubernetes ด้วย VM จริง หรือการรัน CI runners ที่ต้อง boot image ของ VM

สิ่งที่ถูกทำ nested คืออะไร

มีทั้งหมด 3 ชั้น:

  • L0 — hypervisor ของผู้ให้บริการที่รันบน hardware โดยตรง คุณไม่สามารถเข้าถึงส่วนนี้ได้
  • L1 — VPS ของคุณ สำหรับ L0 แล้ว VPS นี้คือ guest
  • L2 — VM ที่คุณต้องการรันภายใน VPS ของคุณ

Hardware virtualization ประกอบด้วย VT-x (flag vmx) และ EPT สำหรับ Intel และ AMD-V / SVM (svm) พร้อมกับ RVI/NPT สำหรับ AMD โดย hypervisor จะใช้คำสั่งเหล่านี้เพื่อเข้าสู่ guest mode และอนุญาตให้ CPU อ่าน page tables สองชุดพร้อมกันได้

เทคโนโลยีเหล่านี้ไม่ได้ถูกออกแบบมาให้ทำงานแบบ re-entrant ดังนั้นการทำ nesting จึงเป็นการจำลอง (emulated) เมื่อ L1 เรียกใช้คำสั่ง VMX จะเกิดการ trap ไปยัง L0 ซึ่ง L0 จะต้องจัดการ shadow structures สำหรับ L2 แทน L1 แม้ว่า KVM จะทำงานส่วนนี้ได้ดี แต่ L0 จะต้องทำงานเพิ่มขึ้นในทุกครั้งที่เกิด exit ซึ่งเป็นเหตุผลที่ผู้ให้บริการต้องเลือกเปิดใช้งานแบบ opt in

เงื่อนไข 2 ข้อต้องเป็นจริงเพื่อให้ L2 ทำงานแบบ accelerated ได้:

  1. KVM module ของ L0 ต้องถูกโหลดด้วย nested=1
  2. L0 ต้องกำหนด CPU model ให้กับ VPS ของคุณโดยมี flag ดังนี้ — <cpu mode='host-passthrough'/> ใน libvirt, cpu: host ใน Proxmox และ -cpu host ใน raw QEMU หากใช้ model แบบจำลองทั่วไป (qemu64, kvm64) จะทำให้ไม่เห็น vmx แม้ว่าจะเปิดใช้งาน nesting ในระดับ global แล้วก็ตาม

ตรวจสอบ VPS ของคุณภายในหนึ่งนาที

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

Instance ที่ใช้งานได้จะแสดงค่า vmx หรือ svm โดย kvm-ok จะแสดงค่า KVM acceleration can be used และ /dev/kvm จะปรากฏในรูปแบบ root:kvm mode 660 หากพบ flag แต่ไม่พบ device node ให้ทำการ load module ด้วยตนเองและตรวจสอบ kernel log:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

มีไฟล์หนึ่งที่ถูกอ้างถึงบ่อยครั้งแต่มักถูกเข้าใจผิด:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

ข้อมูลภายใน VPS ของคุณคือการตั้งค่าของ KVM module ของคุณ ซึ่งใช้กำหนดว่า L2 guest จะสามารถทำ nested virtualization ในระดับที่สามได้หรือไม่ ข้อมูลนี้ไม่ได้ระบุว่า L0 ได้เปิดใช้งาน nesting ให้คุณหรือไม่ — /proc/cpuinfo และ kvm-ok คือคำตอบสำหรับเรื่องนั้น พารามิเตอร์ nested คือค่าที่คุณต้องตั้งค่าบนเครื่องที่คุณเป็นเจ้าของโดยสมบูรณ์:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

ระบบจะไม่ยอมให้ลบ module ในขณะที่ VM กำลังทำงานอยู่ ดังนั้นควรปิด guest ก่อน

เหตุผลที่ผู้ให้บริการ VPS ส่วนใหญ่ปิดฟังก์ชันนี้ไว้

  • Live migration. การเปิดใช้งาน vmx จะทำให้ CPU model ที่มี flag นี้ถูกเปิดเผยออกมา หาก guest ต้องพึ่งพาฟีetures ของ CPU เหล่านั้น จะไม่สามารถทำ live migration ไปยังเครื่องที่ไม่มี flag ดังกล่าวได้อย่างปลอดภัย ผู้ให้บริการที่ต้องย้ายลูกค้าออกจาก node (drain nodes) จะไม่สามารถทำเช่นนั้นได้ทันทีที่เปิดใช้งาน nesting
  • Attack surface. เส้นทางของ nested VMX/SVM เป็นส่วนหนึ่งของ code ที่มีความซับซ้อนสูงใน virtualization layer ของ kernel และมีประวัติการเกิด CVE มาอย่างต่อเนื่อง
  • L0 may not be KVM. หาก systemd-detect-virt แสดงผลเป็น vmware, xen หรือ microsoft กฎการใช้งาน nesting จะขึ้นอยู่กับ stack นั้น ไม่ใช่ KVM

หาก instance ของคุณไม่มี flag นี้ ให้ติดต่อ support (บางแห่งเปิดใช้งานให้เป็นราย VM), เลือก plan ที่ระบุว่ารองรับ nesting หรือเปลี่ยนไปใช้ dedicated box เนื้อหาหลังจากนี้จะอ้างอิงจากกรณีที่เครื่องมีสิทธิ์ root และแสดงผล flag ดังกล่าว

การรัน L2 guest ด้วย libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

ไม่จำเป็นต้องใช้ graphical session การติดตั้งผ่าน serial จะใช้เวลาสักพัก ดังนั้นควรเริ่มการทำงานภายใน shell ที่มีความต่อเนื่อง: workflow ของ tmux ที่ช่วยให้ Claude Code session ทำงานต่อได้บน VPS จะช่วยให้ console virt-install ยังคงเชื่อมต่ออยู่แม้การเชื่อมต่อ SSH จะหลุดไป หาก --os-variant debian13 ถูกปฏิเสธ แสดงว่า osinfo-db ของคุณเป็นเวอร์ชันที่เก่ากว่าการ release — ให้รัน osinfo-query os และเลือกชื่อที่มีอยู่จริง --cpu host-passthrough จะทำการ forward vmx ลงไปยัง L2 ซึ่งจำเป็นเฉพาะในกรณีที่ L2 ต้องทำการ virtualize ต่อไป ให้ตั้งค่า guest ให้ boot-safe ด้วย virsh autostart guest1

bus virtio บน disk และ NIC ไม่ได้มีไว้เพื่อความสวยงาม: อุปกรณ์ IDE และ e1000 แบบ emulated จะเกิดการ trap เข้าสู่ hypervisor บ่อยกว่า virtio queues และภายใต้สภาวะ nesting ทุกการ trap จะต้องเสียค่าใช้จ่าย (overhead) เป็นสองเท่า

Networking: ส่วนที่บทช่วยสอนมักข้ามไป

VPS ของคุณมี public IP เพียงหนึ่งหมายเลข และทำงานอยู่หลังระบบ fabric ที่กรอง MAC address ที่ไม่รู้จัก ผลที่ตามมามีสองประการดังนี้

การทำ Bridging L2 สำหรับ guest บน public network มักจะใช้งานไม่ได้ หากคุณตั้งค่า br0 บน public NIC และกำหนด MAC address ให้กับ guest คุณจะพบว่ามีการส่ง ARP ออกไปแต่ไม่มีข้อมูลตอบกลับ เนื่องจาก switch ของผู้ให้บริการจะทิ้ง frame จาก MAC address ที่ไม่ได้ถูกจัดสรรให้คุณ หากคุณพบอาการนี้ ให้หยุดตรวจสอบการตั้งค่า bridge เพราะนี่คือกลไกการทำงานของระบบ

ให้ใช้ NAT network แทน libvirt มาพร้อมกับ default: virbr0, 192.168.122.0/24 และ dnsmasq leases ซึ่งทำให้การเชื่อมต่อขาออกใช้งานได้ทันที สำหรับการเชื่อมต่อขาเข้า ให้ทำการ terminate TLS ที่ L1 แล้วทำ proxy เข้ามา โดยเส้นทางของ certificate ด้านล่างนี้อ้างอิงจาก การออกใบรับรอง Let's Encrypt ด้วย Certbot บน Nginx:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

ควรเริ่มจากการกำหนด static lease (virsh net-edit default) ให้กับ guest เพื่อให้หมายเลขใน proxy_pass คงที่

Management interfaces จะไม่เชื่อมต่อกับอินเทอร์เน็ต: VNC บน port 5900 และ Proxmox web UI บน port 8006 ควรใช้งานผ่าน loopback โดยเข้าถึงผ่าน SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) หรือผ่าน self-hosted WireGuard VPN เข้าสู่ VPS ซึ่งจะทำให้ช่วงหมายเลขของ guest ใน 192.168.122.0/24 อยู่ห่างออกไปเพียงหนึ่ง private hop ควรตั้งค่า firewall ให้จำกัดวงแคบ — เฉพาะ sudo ufw allow 22,80,443/tcp เท่านั้น หาก guest สูญเสียการเชื่อมต่อขาออกทันทีหลังจากเปิดใช้งาน ufw สาเหตุที่พบบ่อยคือ DEFAULT_FORWARD_POLICY="DROP" ใน /etc/default/ufw — ให้ตั้งค่าเป็น ACCEPT แล้วทำการ reload ufw

Proxmox บน VPS

Proxmox VE 9 ใช้ Debian 13 เป็นพื้นฐาน การติดตั้งบน Debian VPS ทำได้โดยการเพิ่ม repository pve-no-subscription และ package proxmox-ve โปรดคัดลอกบรรทัด repository และ keyring จากเอกสารทางการของ Proxmox เท่านั้น การใช้ URL จากบล็อกเก่าจะทำให้การติดตั้งล้มเหลว

ส่วนของ package ไม่ใช่ปัญหาหลัก Proxmox ต้องการให้ vmbr0 เชื่อมต่อแบบ bridge กับ physical NIC ซึ่งจะประสบปัญหา MAC-filtering ตามที่กล่าวไว้ข้างต้น รูปแบบที่ใช้งานได้บน VPS คือการใช้ vmbr0 แบบ NAT หรือแบบ routed โดยไม่ต้องเชื่อมต่อกับ physical port และกำหนดให้ guest อยู่ใน private range นอกจากนี้ต้องใช้ DNAT rules หรือ reverse proxy บน host สำหรับบริการที่ต้องเชื่อมต่อกับเครือข่ายสาธารณะ ในกรณีที่บริการสาธารณะเป็น container แทนที่จะเป็น VM การใช้ Traefik เพื่อจัดการหลายแอปพลิเคชันจาก Docker Compose ไฟล์เดียว สามารถทำหน้าที่จัดการ routing และออก certificate อัตโนมัติได้เช่นกัน ควรทำ snapshot /etc/network/interfaces ไว้ก่อนเสมอ เนื่องจากการกำหนดค่า bridge ที่ผิดพลาดอาจทำให้ไม่สามารถเข้าถึงเครื่องได้หากไม่มี console สำรอง

ประสิทธิภาพตามความเป็นจริง

Nested virtualization มีความเร็วต่ำกว่าแบบ single-level โดยมีสาเหตุหลักที่เฉพาะเจาะจงคือ: ภาระงานไม่ได้อยู่ที่การเข้าถึงหน่วยความจำ แต่อยู่ที่การเกิด exits เมื่อมีการใช้งาน EPT/NPT แล้ว L0 จะรักษา shadow page tables สำหรับ L2 ทำให้การอ่านหน่วยความจำปกติทำงานด้วยความเร็วระดับ hardware ส่วนการทำงานที่มีค่าใช้จ่ายสูงคือทุกการดำเนินการที่ออกจาก guest mode เช่น I/O, timer interrupts, MMIO และ inter-processor interrupts เนื่องจาก L2 exit จะต้องถูกจัดการโดย L0 และอาจต้องส่งผ่านไปยัง L1 อีกทอดหนึ่ง งานที่ใช้ CPU เป็นหลักบนข้อมูลที่มีอยู่ใน RAM แล้วจะมีประสิทธิภาพใกล้เคียงกับ native แต่การทำงานใดๆ ที่เน้นการใช้ syscall, packet และ disk I/O จะได้รับผลกระทบจากจำนวน layer ที่เพิ่มขึ้น

ดังนั้น: ควรใช้ virtio devices ในทุกส่วน และไฟล์ qcow2 ของคุณจะถูกเก็บไว้บน disk ที่ผู้ให้บริการได้ทำ virtualization ไว้แล้ว ซึ่งเป็นการซ้อนทับกันของ thin-provisioning สองชั้น โดยที่ cache=none บน guest disk จะช่วยป้องกันไม่ให้ block ชุดเดียวกันถูกเก็บไว้ใน page cache สองแห่งพร้อมกัน ทั้งนี้ไม่มีตัวเลข benchmark ในที่นี้: โปรดวัดผลจาก workload ของคุณบน instance ของคุณเอง

Failure modes, and the strings you will see

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used จาก kvm-ok โมดูลอาจไม่ได้ถูกโหลด หรือ flag ไม่ได้ถูกเปิดใช้งาน ให้ตรวจสอบ /proc/cpuinfo เป็นอันดับแรก

kvm: disabled by bios ใน dmesg หากเป็นเครื่อง bare metal ให้เปิดใช้งาน VT-x/SVM ใน firmware หากเป็น VPS หมายความว่า L0 ไม่ได้ส่งต่อ extensions ให้ และการตั้งค่าใดๆ ใน guest จะไม่สามารถแก้ไขปัญหานี้ได้

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported CPU ที่ kernel ตรวจพบไม่มี vmx ซึ่งเป็นผลมาจากการตัดสินใจของ L0

Could not access KVM kernel module: Permission denied ปัญหาเกิดจากสิทธิ์การเข้าถึง ไม่ใช่ฮาร์ดแวร์ ตรวจสอบ ls -l /dev/kvm เพื่อดูว่าอยู่ใน group kvm และ mode 660 หรือไม่ หากไม่ใช่ ให้เพิ่ม user ของคุณลงใน group ดังกล่าว แล้วเริ่มการใช้งาน shell ใหม่ เนื่องจากสมาชิกใน group จะมีผลกับ session ที่เริ่มขึ้นใหม่เท่านั้น

kvm: Device or resource busy เมื่อเริ่มทำงาน QEMU มี hypervisor อื่นใช้งาน CPU อยู่ ให้รัน lsmod เพื่อตรวจสอบ vboxdrv หรือ module ของ VMware ควบคู่กับ kvm_intel แล้วทำการ unload module ที่ไม่ต้องการออก

/var/run/libvirt/libvirt-sock: No such file or directory จาก virsh daemon หยุดทำงาน ให้ใช้คำสั่ง sudo systemctl enable --now libvirtd

Proxmox: KVM virtualisation configured, but not available. มีการเลือกใช้งาน KVM acceleration ใน guest บน host ที่ไม่รองรับ ให้แก้ไขเรื่อง nesting หรือยกเลิกการเลือกใช้งานเพื่อใช้การจำลองแบบ emulation แทน

Android emulator: x86_64 emulation currently requires hardware acceleration! เกิดปัญหา /dev/kvm อีกครั้ง ซึ่งมักเกี่ยวข้องกับเรื่อง group

ไม่พบข้อผิดพลาด แต่การทำงานช้ามาก QEMU ที่ไม่มี accelerator flag จะเปลี่ยนไปใช้ TCG ซึ่งเป็น software emulator การทำงานจะถูกต้องแต่ล่าช้ามาก จากเดิมที่ใช้เวลา boot เพียงไม่กี่วินาทีอาจกลายเป็นหลายนาที ให้ระบุ -accel kvm โดยตรง เพื่อให้ QEMU แจ้งข้อผิดพลาดแทนการทำงานแบบ emulation อย่างเงียบๆ

Guest หายไปขณะกำลังทำงาน ตรวจสอบ Out of memory: Killed process ... qemu-system-x86_64 ใน dmesg เนื่องจาก L2 guest คือ process หนึ่งบน L1 และ OOM killer จะจัดการเหมือน process ทั่วไป โดย RAM ของ L2 จะถูกหักจากหน่วยความจำที่ L1 ได้รับการจัดสรรไว้เท่านั้น ไม่สามารถขอยืมจาก host ได้

การใช้งาน: การสำรองข้อมูล, การอัปเกรด, และข้อจำกัด

การสำรองข้อมูล. การคัดลอกไฟล์ qcow2 ของ guest ที่กำลังทำงานอยู่จะทำให้ image เสียหาย คุณต้องใช้ virsh shutdown guest1 และคัดลอก หรือใช้การทำ external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) เพื่อให้การเขียนข้อมูลใหม่ถูกส่งไปยัง overlay ในขณะที่คุณคัดลอก base image ที่ไม่มีการเปลี่ยนแปลง จากนั้นจึงรวมข้อมูลกลับด้วย virsh blockcommit ควรส่งไฟล์ที่คัดลอกแล้วออกไปนอก VPS เพราะการเก็บ snapshot ไว้ใน disk ชุดเดียวกันไม่สามารถป้องกันความเสียหายจาก hardware ได้

การอัปเกรด. apt full-upgrade จะติดตั้ง module kvm_intel/kvm_amd เวอร์ชันใหม่ แต่ kernel ที่กำลังทำงานอยู่จะยังคงใช้เวอร์ชันเดิมจนกว่าคุณจะ reboot ควรติดตั้ง kernel เวอร์ชันก่อนหน้าไว้เสมอ และรัน kvm-ok ทุกครั้งที่มีการเปลี่ยน kernel หาก host กลับมาทำงานโดยไม่มี vmx จะสามารถแก้ไขให้กลับมาใช้งานได้โดยการเพิ่ม boot entry เพียงรายการเดียว

ข้อจำกัดในการขยายระบบ. การมี public IP เพียงหนึ่งหมายเลข หมายความว่าทุก service ใน L2 จะต้องเข้าถึงโลกภายนอกผ่าน proxy หรือกฎ DNAT บน L1 ฟีเจอร์ Live migration ไม่สามารถใช้งานได้ หากเกิด CPU contention เส้นทาง nested exit จะได้รับผลกระทบเป็นอันดับแรก สำหรับ hypervisor ที่มี guest หลายตัว หน่วยความจำ RAM จะถูกใช้งานไปจนเกือบหมดแล้ว เนื่องจาก nested VM ไม่สามารถทำ overcommit เพื่อแก้ปัญหาการจัดสรรทรัพยากรแบบคงที่ได้ เมื่อระบบ lab มีขนาดใหญ่เกินกว่าที่กำหนด วิธีแก้ไม่ใช่การเพิ่มชั้นของ nested stack แต่คือการใช้เครื่อง dedicated ซึ่งคุณจะมีสถานะเป็น L0 และกฎทั้งหมดนี้จะไม่ถูกนำมาใช้

FAQ

จำเป็นต้องใช้ nested virtualization เพื่อรัน Docker บน VPS หรือไม่?

ไม่จำเป็น เนื่องจาก container ใช้ kernel ร่วมกับ VPS และไม่เปิดใช้งาน /dev/kvm ดังนั้น instance ปกติที่ไม่มี flag vmx หรือ svm สามารถรัน Docker และ Docker Compose ได้อย่างสมบูรณ์ การทำ nesting จะจำเป็นเฉพาะเมื่อคุณต้องการ kernel ตัวที่สอง เช่น การทำ lab ด้วย Proxmox, การรัน Windows guest, Firecracker microVMs, Android emulator หรือ CI runners ที่ต้อง boot image ของ VM

จะตรวจสอบได้อย่างไรว่า VPS ของฉันรองรับ nested virtualization หรือไม่?

รันคำสั่ง grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u ตามด้วย kvm-ok จาก package cpu-checker หากใช้งานได้ระบบจะแสดงผล vmx (Intel) หรือ svm (AMD) โดย kvm-ok จะรายงานค่า KVM acceleration can be used และหากมีไฟล์ /dev/kvm พร้อม group kvm และ mode 660 แสดงว่ารองรับ สำหรับคำถามนี้ให้ข้าม /sys/module/kvm_intel/parameters/nested ไป เนื่องจากไฟล์ดังกล่าวอธิบายถึง KVM module ของตัวเครื่องเอง ไม่ใช่สิ่งที่ hypervisor ของผู้ให้บริการเปิดให้ใช้งาน

ทำไมผู้ให้บริการ VPS ส่วนใหญ่จึงปิดการใช้งาน nested virtualization?

การเปิดใช้งาน vmx หมายถึงการส่งมอบ CPU model ที่มี flag ดังกล่าวให้แก่ guest ซึ่ง guest ที่ต้องพึ่งพาฟีเจอร์ CPU เหล่านั้นจะไม่สามารถทำ live-migration ไปยังเครื่องที่ไม่มีฟีเจอร์ดังกล่าวได้ ผู้ให้บริการที่ต้องย้ายลูกค้าไปมาเพื่อบริหารจัดการ node จึงไม่เปิดฟีเจอร์นี้ นอกจากนี้ code path ของ nested VMX/SVM ยังมีประวัติการเกิด CVE มาอย่างยาวนาน ผู้ให้บริการบางรายอาจเปิดใช้งานให้เป็นราย VM ตามคำขอ และบางรายอาจระบุว่า nesting เป็นฟีเจอร์เสริม (add-on feature)

VM ที่ทำ nested ไว้ไม่มีเครือข่ายบน public bridge เกิดจากสาเหตุใด?

Switch ของผู้ให้บริการจะตัด frame จาก MAC address ที่ไม่ได้ถูกจัดสรรให้คุณ ดังนั้น guest ที่ทำ L2 bridge บน public NIC จะส่ง ARP ไปแล้วไม่ได้รับสัญญาณตอบกลับ ให้หยุดตรวจสอบ br0 และเปลี่ยนไปใช้ NAT network default ของ libvirt (virbr0, 192.168.122.0/24) แทน โดยกำหนด static lease ให้แก่ guest และใช้วิธี publish ข้อมูลสาธารณะผ่าน reverse proxy หรือกฎ DNAT บนตัว VPS เอง

VM ที่ทำ nested จะช้าลงเท่าใด?

ประสิทธิภาพที่ลดลงเกิดจาก VM exits ไม่ใช่การเข้าถึงหน่วยความจำ เมื่อเปิดใช้งาน EPT/NPT การอ่านและเขียนข้อมูลทั่วไปภายใน L2 จะทำงานด้วยความเร็วระดับ hardware ในขณะที่ I/O, timer interrupts, MMIO และ IPIs จะถูกจัดการโดย L0 และอาจต้องส่งผ่าน L1 งานที่เน้นการประมวลผล CPU (CPU-bound) บนข้อมูลที่อยู่ใน RAM จะมีประสิทธิภาพใกล้เคียงกับ native แต่ workload ที่เน้น syscall, packet และ disk จะได้รับผลกระทบจากทุก layer แนะนำให้ใช้ virtio devices ในทุกส่วนและใช้ cache=none บน guest disks จากนั้นจึงทำการวัดผลตามลักษณะงานของคุณเอง

#nested-virtualization#kvm#proxmox#vps#qemu#libvirt