ஆல் Matt Connor 2026-07-14 · புதுப்பிக்கப்பட்டது 2026-08-07

VPS-ல் Proxmox அல்லது Nested Virtualization சாத்தியமா?

Q: எனது VPS nested virtualization-ஐ ஆதரிக்கிறதா என்பதை எப்படிச் சரிபார்ப்பது?

grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u கட்டளையை இயக்கி, பின் cpu-checker package-லிருந்து kvm-ok-ஐ இயக்கவும். பயன்படுத்தக்கூடிய instance-ல் vmx (Intel) அல்லது svm (AMD) வெளியீடு கிடைக்கும். kvm-ok கட்டளை KVM acceleration can be used எனத் தெரிவிக்க வேண்டும். மேலும், kvm group மற்றும் 660 mode-உடன் /dev/kvm கோப்பு இருக்க வேண்டும். இந்தக் கேள்விக்கு /sys/module/kvm_intel/parameters/nested-ஐக் கவனிக்க வேண்டாம்; அந்தக்கோப்பு உங்கள் சொந்த KVM module-ஐ விவரிக்கிறது, உங்கள் provider-ன் hypervisor உங்களுக்கு வழங்கிய வசதியை அல்ல.

Q: பெரும்பாலான VPS வழங்குநர்கள் ஏன் nested virtualization-ஐ முடக்குகிறார்கள்?

vmx-ஐ வெளிப்படுத்துவது என்பது, அந்த flag-ஐக் கொண்ட CPU model-ஐ guest-க்கு வழங்குவதாகும். அந்த CPU வசதிகளைச் சார்ந்திருக்கும் ஒரு guest-ஐ, அதே வசதிகள் இல்லாத மற்றொரு machine-க்கு live-migration செய்ய முடியாது. வாடிக்கையாளர்களை இடம் மாற்றி nodes-ஐக் காலி செய்யும் வழங்குநர்கள் இந்த வசதியைத் தவிர்க்கிறார்கள். மேலும், nested VMX/SVM code paths நீண்டகால CVE வரலாற்றைக் கொண்டுள்ளன. சில host-கள் கோரிக்கையின் பேரில் VM-க்கு இதைச் செயல்படுத்தித் தருகின்றன, மற்றவை இதை ஒரு plan வசதியாகக் குறிப்பிடுகின்றன.

பெரும்பாலான VPS நிறுவனங்கள் vmx flag-ஐ மறைக்கின்றன. kvm-ok கட்டளையைப் பயன்படுத்தி உங்கள் VPS-ல் nested virtualization வசதி உள்ளதா என்பதை ஒரு நிமிடத்தில் கண்டறியும் முறையை அறியுங்கள்.

சுருக்கமான பதில்

Nested virtualization என்பது ஒரு virtual machine-க்குள் இயங்கும் hypervisor ஆகும்: உங்கள் VPS ஏற்கனவே ஒரு guest-ஆக உள்ளது, இப்போது அதற்குள் நீங்கள் சொந்தமாக guest-களை உருவாக்க விரும்புகிறீர்கள். உங்கள் provider-ன் hypervisor, CPU-ன் virtualization extensions-ஐ உங்கள் instance-க்கு வேண்டுமென்றே வழங்கினால் மட்டுமே இது செயல்படும். /proc/cpuinfo-ஐச் சரிபார்த்து, அதில் vmx flag (Intel) அல்லது svm (AMD) உள்ளதா என்று பாருங்கள். இவை இரண்டும் இல்லை என்றால், VPS-க்குள் நீங்கள் எதை மாற்றினாலும் இது செயல்படாது.

முதலில் ஒரு தெளிவு: Docker-க்கு இதில் எதுவுமே தேவையில்லை. Containers உங்கள் VPS kernel-ஐப் பகிர்ந்து கொள்கின்றன, அவை ஒருபோதும் /dev/kvm-ஐத் தொடுவதில்லை. உங்கள் நோக்கம் "எனது server-ல் பல சேவைகளை containers-ஆக இயக்குவது" என்றால், அதற்குத் தேவையானவை ஏற்கனவே உங்களிடம் உள்ளன. ஒரு இரண்டாவது kernel, Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, உண்மையான VM-களைக் கொண்ட Kubernetes testbed, அல்லது VM images-ஐ boot செய்யும் CI runners போன்றவற்றை நீங்கள் பயன்படுத்த விரும்பும் போது மட்டுமே nesting அவசியமாகிறது.

உண்மையில் எவை ஒன்றிற்குள் ஒன்றாக அடுக்கப்படுகின்றன (Nested)

மூன்று அடுக்குகள் உள்ளன:

L0, வன்பொருளின் (metal) மீதுள்ள provider-ன் hypervisor. இதற்கு உங்களுக்கு அணுகல் கிடையாது.
L1, உங்கள் VPS. L0-ஐப் பொறுத்தவரை இது ஒரு guest மட்டுமே.
L2, உங்கள் VPS-க்குள் நீங்கள் இயக்க விரும்பும் VM.

Hardware virtualization என்பது Intel-ல் VT-x (vmx flag) மற்றும் EPT, AMD-ல் AMD-V / SVM (svm) மற்றும் RVI/NPT ஆகியவற்றைக் குறிக்கும். ஒரு hypervisor இந்த instructions-ஐப் பயன்படுத்தி guest mode-க்குள் நுழைகிறது; மேலும் CPU ஒரே நேரத்தில் இரண்டு page tables-ஐயும் கையாள அனுமதிக்கிறது.

இவை எதுவும் re-entrant ஆக வடிவமைக்கப்படவில்லை, எனவே nesting என்பது emulate செய்யப்படுகிறது: L1 ஒரு VMX instruction-ஐ இயக்கும்போது, அது L0-க்கு trap ஆகிறது. L0, L1-க்காக L2-ன் shadow structures-ஐப் பராமரிக்கிறது. KVM இதைச் சிறப்பாகச் செய்கிறது, ஆனால் ஒவ்வொரு exit-ன் போதும் L0 கூடுதல் வேலை செய்ய வேண்டியுள்ளது. இதனால்தான் provider இதற்கு அனுமதி அளிக்க வேண்டும்.

Accelerated L2 இயங்குவதற்கு இரண்டு நிபந்தனைகள் பூர்த்தியாக வேண்டும்:

L0-ன் KVM module nested=1 உடன் ஏற்றப்பட்டிருக்க வேண்டும்.
L0 உங்கள் VPS-க்கு அந்த flag-ஐக் கொண்ட CPU model-ஐ வழங்க வேண்டும். இது libvirt-ல் <cpu mode='host-passthrough'/>, Proxmox-ல் cpu: host, raw QEMU-ல் -cpu host ஆகும். ஒரு பொதுவான emulated model (qemu64, kvm64) nesting உலகளவில் இயக்கப்பட்டிருந்தாலும் vmx-ஐ மறைத்துவிடும்.

ஒரு நிமிடத்தில் உங்கள் 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 பயன்முறையில் 660 ஆக இருக்கும். flag இருந்தாலும் device node இல்லை என்றால், module-ஐ கைமுறையாக load செய்து 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 மூன்றாவது நிலையை (nest) உருவாக்க முடியுமா என்பதைத் தீர்மானிக்கிறது. 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

VM இயங்கிக்கொண்டிருக்கும்போது module-ஐ நீக்க முடியாது, எனவே முதலில் guest-களை அணைக்கவும்.

பெரும்பாலான VPS நிறுவனங்கள் ஏன் இதை முடக்கி வைக்கின்றன

Live migration. vmx வசதியை உங்களுக்கு வழங்குவது என்பது, அந்த CPU flag-ஐக் கொண்ட ஒரு CPU மாதிரியை வெளிப்படுத்துவதாகும். அந்த CPU அம்சங்களைச் சார்ந்திருக்கும் ஒரு guest, அதே அம்சங்கள் இல்லாத மற்றொரு machine-க்கு பாதுகாப்பாக இடம்பெயர முடியாது. வாடிக்கையாளர்களை இடம்பெயரச் செய்வதன் மூலம் nodes-ஐ காலி செய்யும் ஒரு host, nesting-ஐ இயக்கும் தருணத்திலேயே அந்த வசதியை இழந்துவிடுகிறது.
Attack surface. Nested VMX/SVM பாதைகள் kernel-ன் virtualization அடுக்கில் மிகவும் சிக்கலான குறியீடுகளைக் கொண்டவை. இவற்றின் CVE வரலாறு இதற்குச் சான்றாகும்.
L0 என்பது KVM-ஆக இல்லாமல் இருக்கலாம். systemd-detect-virt கட்டளை vmware, xen அல்லது microsoft என்று காட்டினால், nesting விதிகள் அந்த stack-க்கு உரியவை, KVM-க்கு உரியவை அல்ல.

உங்கள் instance-ல் flag இல்லையா? ஆதரவு குழுவைத் தொடர்புகொள்ளுங்கள் (சில நிறுவனங்கள் VM வாரியாக இதை இயக்குகின்றன), nesting வசதி உள்ள திட்டத்தைத் தேர்வு செய்யுங்கள் அல்லது dedicated box-க்கு மாறுங்கள். இந்த வழிகாட்டியின் மீதிப் பகுதி, flag-ஐக் காட்டும் machine-ல் உங்களுக்கு root அணுகல் இருப்பதாகக் கருதுகிறது.

libvirt மூலம் L2 guest-ஐ இயக்குதல்

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 install சிறிது நேரம் எடுக்கும் என்பதால், அதை ஒரு persistent shell-க்குள் தொடங்கவும்: VPS-ல் Claude Code sessions-ஐத் தொடர்ந்து இயங்க வைக்கும் அதே tmux workflow, SSH connection துண்டிக்கப்பட்டாலும் virt-install console-ஐ இணைப்பில் வைத்திருக்கும். --os-variant debian13 நிராகரிக்கப்பட்டால், உங்கள் osinfo-db இந்த release-க்கு முந்தையது என்று அர்த்தம்; osinfo-query os-ஐ இயக்கி, ஏற்கனவே உள்ள ஒரு பெயரைத் தேர்ந்தெடுக்கவும். --cpu host-passthrough ஆனது vmx-ஐ L2-க்குள் forward செய்கிறது; L2-க்குள்ளேயே virtualization தேவைப்பட்டால் மட்டுமே இது அவசியம். virsh autostart guest1-ஐப் பயன்படுத்தி guest-ன் boot பாதுகாப்பை உறுதிப்படுத்தவும்.

Disk மற்றும் NIC-ல் உள்ள virtio bus என்பது அலங்காரத்திற்காக அல்ல: emulated IDE மற்றும் e1000 சாதனங்கள், virtio queues-ஐ விட மிக அடிக்கடி hypervisor-க்குள் trap ஆகும். Nesting முறையில் ஒவ்வொரு trap-க்கும் இருமடங்கு செயல்திறன் இழப்பு ஏற்படும்.

Networking: பயிற்சிகளில் தவிர்க்கப்படும் பகுதி

உங்கள் VPS ஒரு பொது IP-ஐக் கொண்டுள்ளது மற்றும் அறியப்படாத MAC முகவரிகளை வடிகட்டும் ஒரு கட்டமைப்பின் பின்னால் இயங்குகிறது. இதனால் இரண்டு விளைவுகள் ஏற்படுகின்றன.

L2 விருந்தினர்களை (guests) பொது நெட்வொர்க்கில் இணைப்பது (Bridging) பொதுவாக வேலை செய்யாது. பொது NIC-ல் br0-ஐ அமைத்து, விருந்தினருக்குத் தனி MAC முகவரியைக் கொடுத்தாலும், ARP கோரிக்கைகள் வெளியே செல்லும், ஆனால் பதில் வராது. உங்கள் வழங்குநரின் சுவிட்ச் (switch), உங்களுக்கு வழங்கப்படாத MAC முகவரியிலிருந்து வரும் தரவுச் சட்டங்களை (frames) நிராகரித்துவிடும். இதுவே உங்கள் சிக்கல் என்றால், பிரிட்ஜை சரிசெய்வதை நிறுத்துங்கள்; இதுவே அதன் செயல்பாட்டு முறை.

NAT நெட்வொர்க்கைப் பயன்படுத்துங்கள். libvirt default-ஐ வழங்குகிறது: virbr0, 192.168.122.0/24, dnsmasq குத்தகைகள் (leases), மற்றும் வெளிச்செல்லும் இணைப்பு உடனடியாகச் செயல்படும். உள்வரும் இணைப்புகளுக்கு, L1-ல் TLS-ஐ முடித்துவிட்டு (terminate), ப்ராக்ஸி (proxy) செய்யுங்கள். கீழே உள்ள சான்றிதழ் பாதைகள் Nginx-ல் Certbot மூலம் Let's Encrypt சான்றிதழைப் பெறுதல் என்பதிலிருந்து பெறப்பட்டவை:

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), அப்போதுதான் அந்த proxy_pass-ல் உள்ள முகவரி மாறாமல் இருக்கும்.

நிர்வாக இடைமுகங்களை (management interfaces) இணையத்தில் வைக்காதீர்கள்: 5900-ல் உள்ள VNC மற்றும் 8006-ல் உள்ள Proxmox இணைய இடைமுகம் ஆகியவை loopback-ல் இருக்க வேண்டும். இவற்றை SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) மூலமாகவோ அல்லது VPS-க்குள் சுய-ஹோஸ்ட் செய்யப்பட்ட WireGuard VPN மூலமாகவோ அணுகலாம். இது முழு 192.168.122.0/24 விருந்தினர் வரம்பையும் ஒரு தனிப்பட்ட hop தொலைவில் வைக்கும். ஃபயர்வால் (firewall) அமைப்புகளைக் குறுகியதாக வைத்திருங்கள், sudo ufw allow 22,80,443/tcp, மற்ற எதையும் அனுமதிக்க வேண்டாம். ufw-ஐ இயக்கிய பிறகு விருந்தினர்கள் வெளிச்செல்லும் இணைப்பை இழந்தால், அதற்கு பெரும்பாலும் /etc/default/ufw-ல் உள்ள DEFAULT_FORWARD_POLICY="DROP" காரணமாக இருக்கும். அதை ACCEPT என அமைத்து, ufw-ஐ மீண்டும் ஏற்றவும் (reload).

VPS-ல் Proxmox

Proxmox VE 9 என்பது அடிப்படையாக Debian 13-ஐக் கொண்டது. எனவே, pve-no-subscription repository மற்றும் proxmox-ve package-ஐச் சேர்ப்பதன் மூலம் இதை ஒரு Debian VPS-ல் நிறுவலாம். Proxmox-ன் தற்போதைய அதிகாரப்பூர்வ ஆவணங்களிலிருந்து repository மற்றும் keyring வரிகளைப் பெறவும்; பழைய வலைப்பதிவிலிருந்து நகலெடுக்கப்பட்ட URL நிறுவலைத் தோல்வியடையச் செய்யும். Proxmox-ஐ வாடகைக்கு எடுத்த வன்பொருளில் (rented hardware) நிறுவுவது சரியான முடிவா என்பதை, கீழே உள்ள நெட்வொர்க்கிங் பணிகளில் ஈடுபடுவதற்கு முன்பே தீர்மானிக்க வேண்டும். வீட்டில் உள்ள Proxmox கணினி மற்றும் வாடகை VPS-க்கு இடையிலான செலவு மற்றும் திறன் ஒப்பீடு என்ற கட்டுரை, இதற்கான மின்சாரம் மற்றும் வன்பொருள் கணக்கீடுகளை ஏற்கனவே செய்துள்ளது.

மென்பொருள் தொகுப்புகளை (packages) நிறுவுவது கடினமான காரியம் அல்ல. Proxmox ஒரு இயற்பியல் NIC-உடன் இணைக்கப்பட்ட vmbr0-ஐ எதிர்பார்க்கிறது, இது மேலே குறிப்பிட்ட MAC-filtering சிக்கலுக்கு இட்டுச் செல்லும். VPS-ல் செயல்படக்கூடிய அமைப்பு, இயற்பியல் போர்ட் இல்லாத NAT அல்லது routed vmbr0 ஆகும். இதில் விருந்தினர் கணினிகள் (guests) ஒரு தனிப்பட்ட வரம்பில் (private range) இருக்கும்; பொது அணுகலுக்கு DNAT விதிகள் அல்லது host-ல் ஒரு reverse proxy பயன்படுத்தப்படும். பொதுமக்களுக்கான சேவைகள் VM-களாக இல்லாமல் container-களாக இருந்தால், ஒரே Docker Compose கோப்பிலிருந்து பல செயலிகளை நிர்வகிக்கும் Traefik தானியங்கிச் சான்றிதழ்களுடன் அதே routing பணியைச் செய்கிறது. தொடங்குவதற்கு முன் /etc/network/interfaces snapshot எடுக்கவும்: தவறான bridge வரையறை, console அணுகல் இல்லாத கணினியிலிருந்து உங்களை வெளியேற்றிவிடும்.

செயல்திறன் குறித்த உண்மை நிலை

Nested virtualization, single-level அமைப்பை விட மெதுவானது. இதற்கான காரணம் தெளிவானது: நினைவக அணுகல் (memory access) இதில் சிக்கலல்ல, மாறாக VM-லிருந்து வெளியேறும் (exits) நிகழ்வுகளே செயல்திறனைப் பாதிக்கின்றன. EPT/NPT வசதி இருக்கும்போது, L0 ஆனது L2-க்காக shadow page tables-ஐ பராமரிக்கிறது, இதனால் சாதாரண நினைவக வாசிப்புகள் வன்பொருள் வேகத்திலேயே இயங்குகின்றன. ஆனால், guest mode-ஐ விட்டு வெளியேறும் ஒவ்வொரு செயல்பாடும், அதாவது I/O, timer interrupts, MMIO, மற்றும் inter-processor interrupts போன்றவை அதிக செலவுமிக்கவை. ஏனெனில், ஒரு L2 exit நிகழ்வை L0 கையாள வேண்டும், அது மீண்டும் L1 வழியாக பிரதிபலிக்கப்படலாம். RAM-ல் ஏற்கனவே உள்ள தரவுகளைக் கொண்டு CPU-bound வேலைகளைச் செய்யும்போது, அது native வேகத்திற்கு நெருக்கமாக இருக்கும். ஆனால், syscalls, packets மற்றும் disk I/O அதிகம் தேவைப்படும் எந்தவொரு பணியும் இந்த அடுக்குகளின் சுமையை உணர்த்தும்.

எனவே: எல்லா இடங்களிலும் virtio சாதனங்களைப் பயன்படுத்தவும். உங்கள் qcow2 கோப்பு, ஏற்கனவே provider-ஆல் virtualize செய்யப்பட்ட வட்டில் இருக்கும்போது, இரண்டு thin-provisioning அடுக்குகள் ஒன்றன் மேல் ஒன்றாக அமைகின்றன. அத்தகைய சூழலில், guest disk-ல் உள்ள cache=none, ஒரே தரவுத் தொகுதிகள் இரண்டு page caches-ல் ஒரே நேரத்தில் இருப்பதைத் தவிர்க்கிறது. இங்கு எந்தவொரு benchmark எண்களும் வழங்கப்படவில்லை: உங்கள் சொந்த instance-ல், உங்கள் பணிச்சுமைக்கு ஏற்ப நீங்களே அளவீடு செய்து கொள்ளவும்.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used - kvm-ok-லிருந்து வரும் செய்தி. ஒன்று, module ஏற்றப்படவில்லை அல்லது flag வெளிப்படுத்தப்படவில்லை. முதலில் /proc/cpuinfo-ஐச் சரிபார்க்கவும்.

kvm: disabled by bios - dmesg-ல் வரும் செய்தி. Bare metal-ல், firmware-ல் VT-x/SVM toggle-ஐ மாற்றவும். VPS-க்குள் இருந்தால், L0 உங்களுக்கு extensions-ஐ வழங்கவில்லை என்று பொருள்; guest-ல் நீங்கள் எதை மாற்றினாலும் இது மாறாது.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. உங்கள் kernel பார்க்கும் CPU-ல் vmx இல்லை; இதுவும் L0-ன் முடிவாகும்.

Could not access KVM kernel module: Permission denied. இது வன்பொருள் (hardware) தொடர்பானதல்ல, அனுமதிகள் (permissions) தொடர்பான சிக்கல். ls -l /dev/kvm-ல் group kvm, mode 660 இருக்க வேண்டும்; உங்களை அந்த group-ல் சேர்த்துவிட்டு, புதிய login shell-ஐத் தொடங்கவும். ஏனெனில், ஏற்கனவே இயங்கும் session-க்கு group membership பொருந்தாது.

kvm: Device or resource busy - QEMU தொடங்கும் போது வரும் செய்தி. மற்றொரு hypervisor module CPU-ஐத் தன்வசம் வைத்துள்ளது: lsmod-ஐ இயக்கி, kvm_intel-க்கு அருகில் vboxdrv அல்லது VMware modules உள்ளதா என்று பார்க்கவும். உங்களுக்குத் தேவையில்லாததை unload செய்யவும்.

/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 வசதியை வழங்க முடியாத host-ல், ஒரு guest-க்கு அந்த வசதி தேர்வு செய்யப்பட்டுள்ளது. Nesting-ஐச் சரிசெய்யவும் அல்லது அதைத் தேர்வு நீக்கம் செய்துவிட்டு emulation-ஐப் பயன்படுத்தவும்.

Android emulator: x86_64 emulation currently requires hardware acceleration! - மீண்டும் /dev/kvm, இது பெரும்பாலும் group தொடர்பான சிக்கலாகும்.

பிழை ஏதுமில்லை, ஆனால் வேகம் மிகக் குறைவாக உள்ளது. Accelerator flag இல்லாத QEMU, அதன் software emulator ஆன TCG-க்கு மாறிவிடும். இது சரியாகச் செயல்படும், ஆனால் மிக மெதுவாக இருக்கும். சில வினாடிகளில் முடிய வேண்டிய boot, பல நிமிடங்கள் எடுக்கும். -accel kvm-ஐத் தெளிவாகக் குறிப்பிடவும்; அப்போதுதான் QEMU அமைதியாக emulate செய்வதற்குப் பதிலாக, பிழையைக் காட்டி நின்றுவிடும்.

இயங்கிக் கொண்டிருக்கும்போதே guest மறைந்துவிடுதல். dmesg-ல் Out of memory: Killed process ... qemu-system-x86_64 உள்ளதா என்று பார்க்கவும். L2 guest என்பது L1-ல் ஒரு process ஆகும்; எனவே OOM killer அதை மற்ற process-களைப் போலவே கருதும். L2 RAM என்பது L1-ன் நிலையான ஒதுக்கீட்டிலிருந்து பெறப்படுகிறது, host-லிருந்து கடன் வாங்க முடியாது.

இயக்கம்: பேக்கப்கள், மேம்படுத்தல்கள், வரம்புகள்

பேக்கப்கள். இயங்கிக்கொண்டிருக்கும் guest-ன் qcow2 கோப்பை அப்படியே நகலெடுத்தால் அது சிதைந்த (corrupt) பிம்பமாகவே இருக்கும். எனவே, virsh shutdown guest1 கட்டளையைப் பயன்படுத்தி நிறுத்திவிட்டு நகலெடுக்கவும், அல்லது ஒரு external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) எடுக்கவும். இவ்வாறு செய்யும்போது, நீங்கள் base கோப்பை நகலெடுக்கும் வரை, புதிய தரவுகள் அனைத்தும் overlay-க்குச் செல்லும். நகலெடுத்த பிறகு, virsh blockcommit மூலம் அதை மீண்டும் இணைக்கவும். இந்த நகல்களை VPS-க்கு வெளியே பாதுகாப்பான இடத்திற்கு மாற்றவும்; ஒரே வட்டில் எடுக்கப்படும் snapshot எந்தப் பாதுகாப்பையும் வழங்காது.

மேம்படுத்தல்கள். apt full-upgrade கட்டளையானது புதிய kvm_intel/kvm_amd தொகுதிகளை நிறுவும், ஆனால் நீங்கள் reboot செய்யும் வரை இயங்கும் kernel பழைய தொகுதிகளையே பயன்படுத்தும். முந்தைய kernel-ஐ நீக்காமல் வைத்திருக்கவும், ஒவ்வொரு kernel மாற்றத்திற்குப் பிறகும் kvm-ok கட்டளையை மீண்டும் இயக்கவும். vmx இல்லாமல் ஒரு host மீண்டும் தொடங்கினால், ஒரு boot entry-ஐ மாற்றுவதன் மூலம் அதை மீண்டும் சரிசெய்ய முடியும்.

எங்கு இது முடிவுக்கு வருகிறது. ஒரு public IP இருக்கும்போது, ஒவ்வொரு L2 service-ம் ஒரு proxy அல்லது L1-ல் உள்ள DNAT விதி மூலமே உலகளாவிய இணையத்தை அடைய முடியும். இதில் Live migration சாத்தியமில்லை. CPU பயன்பாடு அதிகரிக்கும்போது, nested exit path-ல் தான் முதலில் வேகம் குறையும். பல guest-களைக் கொண்ட ஒரு hypervisor-ன் RAM ஏற்கனவே ஒதுக்கப்பட்டுவிட்டதால், nested VM-கள் தங்களுக்கு ஒதுக்கப்பட்ட நிலையான நினைவகத்திற்கு மேல் கூடுதலாகப் பயன்படுத்த முடியாது. ஒரு ஆய்வகம் இந்த அளவைத் தாண்டி வளரும்போது, nested stack-ஐ உயர்த்துவது தீர்வாகாது; அதற்குப் பதிலாக, நீங்கள் L0 நிலையில் இருக்கும் ஒரு பிரத்யேக server-க்கு மாறுவதே சரியான தீர்வாகும். அங்கு இந்த நிபந்தனைகள் எதுவும் பொருந்தாது.

FAQ

VPS-ல் Docker-ஐ இயக்க nested virtualization தேவையா?

இல்லை. Containers உங்கள் VPS kernel-ஐப் பகிர்ந்து கொள்கின்றன, அவை ஒருபோதும் /dev/kvm-ஐத் திறப்பதில்லை. எனவே, vmx அல்லது svm flag இல்லாத சாதாரண instance-ல் Docker மற்றும் Docker Compose-ஐச் சிறப்பாக இயக்கலாம். Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, அல்லது VM images-ஐ boot செய்யும் CI runners போன்றவற்றுக்கு இரண்டாவது kernel தேவைப்படும்போது மட்டுமே nesting அவசியமாகிறது.

எனது VPS nested virtualization-ஐ ஆதரிக்கிறதா என்பதை எப்படிச் சரிபார்ப்பது?

grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u கட்டளையை இயக்கி, பின் cpu-checker package-லிருந்து kvm-ok-ஐ இயக்கவும். பயன்படுத்தக்கூடிய instance-ல் vmx (Intel) அல்லது svm (AMD) வெளியீடு கிடைக்கும். kvm-ok கட்டளை KVM acceleration can be used எனத் தெரிவிக்க வேண்டும். மேலும், kvm group மற்றும் 660 mode-உடன் /dev/kvm கோப்பு இருக்க வேண்டும். இந்தக் கேள்விக்கு /sys/module/kvm_intel/parameters/nested-ஐக் கவனிக்க வேண்டாம்; அந்தக்கோப்பு உங்கள் சொந்த KVM module-ஐ விவரிக்கிறது, உங்கள் provider-ன் hypervisor உங்களுக்கு வழங்கிய வசதியை அல்ல.

பெரும்பாலான VPS வழங்குநர்கள் ஏன் nested virtualization-ஐ முடக்குகிறார்கள்?

vmx-ஐ வெளிப்படுத்துவது என்பது, அந்த flag-ஐக் கொண்ட CPU model-ஐ guest-க்கு வழங்குவதாகும். அந்த CPU வசதிகளைச் சார்ந்திருக்கும் ஒரு guest-ஐ, அதே வசதிகள் இல்லாத மற்றொரு machine-க்கு live-migration செய்ய முடியாது. வாடிக்கையாளர்களை இடம் மாற்றி nodes-ஐக் காலி செய்யும் வழங்குநர்கள் இந்த வசதியைத் தவிர்க்கிறார்கள். மேலும், nested VMX/SVM code paths நீண்டகால CVE வரலாற்றைக் கொண்டுள்ளன. சில host-கள் கோரிக்கையின் பேரில் VM-க்கு இதைச் செயல்படுத்தித் தருகின்றன, மற்றவை இதை ஒரு plan வசதியாகக் குறிப்பிடுகின்றன.

எனது nested VM-ல் public bridge வழியாக network கிடைக்கவில்லை. என்ன தவறு?

வழங்குநரின் switch, உங்களுக்கு ஒதுக்கப்படாத MAC address-லிருந்து வரும் frames-ஐ நிராகரிக்கிறது. எனவே, public NIC-ல் இணைக்கப்பட்ட L2 guest அனுப்பும் ARP கோரிக்கைகளுக்குப் பதில் கிடைக்காது. br0-ஐப் பிழைதிருத்தம் செய்வதை நிறுத்திவிட்டு, libvirt-ன் NAT default network-ஐப் பயன்படுத்தவும் (virbr0, 192.168.122.0/24). guest-க்கு static lease வழங்கி, பொதுவான சேவைகளை reverse proxy அல்லது VPS-ல் உள்ள DNAT rule வழியாக வெளியிடவும்.

nested VM எவ்வளவு மெதுவாக இருக்கும்?

இதன் வேகம் memory access-ஐப் பொறுத்ததல்ல, VM exits-ஐப் பொறுத்தது. EPT/NPT செயல்பாட்டில் இருக்கும்போது, L2-க்குள் நடக்கும் சாதாரண reads மற்றும் writes வன்பொருள் வேகத்தில் இயங்கும். ஆனால் I/O, timer interrupts, MMIO மற்றும் IPI-கள் L0 மூலம் கையாளப்பட்டு L1 வழியாகத் திரும்ப வேண்டியிருக்கும். RAM-ல் ஏற்கனவே உள்ள தரவுகளைக் கொண்டு செய்யப்படும் CPU-bound வேலைகள் native வேகத்திற்கு நெருக்கமாக இருக்கும். ஆனால் syscall, packet மற்றும் disk சார்ந்த வேலைகளில் ஒவ்வொரு அடுக்கின் தாக்கமும் தெரியும். எல்லா இடங்களிலும் virtio devices மற்றும் guest disks-ல் cache=none-ஐப் பயன்படுத்தவும், பிறகு உங்கள் பணிச்சுமையை அளவிடவும்.

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