VPS-ல் Proxmox இயக்க முடியுமா? nested virtualization

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

உட்பொதிக்கப்பட்ட மெய்நிகராக்கம் என்பது ஒரு மெய்நிகர் இயந்திரத்திற்குள் இயங்கும் ஒரு ஹைப்பர்வைசர் ஆகும்: உங்கள் VPS ஏற்கனவே ஒரு கெஸ்ட் ஆகும், மேலும் அது தனக்கென கெஸ்ட்களை ஹோஸ்ட் செய்ய வேண்டும். உங்கள் வழங்குநரின் ஹைப்பர்வைசர் வெளிப்படையாக உங்கள் இன்ஸ்டன்ஸுக்கு CPU-இன் மெய்நிகராக்க நீட்டிப்புகளை வெளிப்படுத்தும் போது மட்டுமே இது செயல்படும் — Intel-க்கு vmx கொடி அல்லது AMD-க்கு svm கொடி உள்ளதா என்பதை /proc/cpuinfo கொண்டு சரிபார்க்கவும். இவற்றில் எதுவும் தெரியவில்லை என்றால், VPS-க்குள் நீங்கள் எதை உள்ளமைத்தாலும் அதை சரிசெய்ய முடியாது.

முதலில் ஒரு எதிர்பார்ப்பை தெளிவுபடுத்துகிறோம்: Docker-க்கு இதில் எதுவும் தேவையில்லை. கன்டெய்னர்கள் உங்கள் VPS கர்னலைப் பகிர்ந்து கொள்கின்றன. அவை /dev/kvm-ஐ ஒருபோதும் அணுகுவதில்லை. உங்கள் உண்மையான நோக்கம் "எனது சர்வரில் பல சேவைகளை கன்டெய்னர்களில் இயக்குவது" என்றால், தேவையானது உங்களிடம் ஏற்கனவே உள்ளது. நீங்கள் ஒரு இரண்டாவது கர்னலை விரும்பும்போது உட்பொதித்தல் முக்கியமாகிறது — ஒரு Proxmox லேப், ஒரு Windows கெஸ்ட், Firecracker microVM-கள், ஒரு Android எமுலேட்டர், உண்மையான VM-களைக் கொண்ட ஒரு Kubernetes டெஸ்ட்பெட், அல்லது VM இமேஜ்களை பூட் செய்யும் CI ரன்னர்கள்.

உண்மையில் எது உட்பொதிக்கப்படுகிறது

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

• L0 — வன்பொருளின் மீது இயங்கும் வழங்குநரின் hypervisor. இதற்கு உங்களுக்கு அணுகல் இல்லை.
• L1 — உங்கள் VPS. L0 க்கு இது ஒரு guest மட்டுமே.
• L2 — உங்கள் VPS க்குள் நீங்கள் இயக்க விரும்பும் VM.

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

இவை இரண்டும் re-entrant ஆக வடிவமைக்கப்படவில்லை. எனவே உட்பொதித்தல் emulate செய்யப்படுகிறது: L1 ஒரு VMX instruction ஐ இயக்கும்போது அது L0 க்கு trap ஆகிறது. L0 அது L1 சார்பாக L2 க்கான shadow structures ஐ பராமரிக்கிறது. KVM இதைச் சிறப்பாகச் செய்கிறது. ஆனால் ஒவ்வொரு exit மீதும் L0 கூடுதல் வேலையைச் செய்கிறது — இதுதான் காரணம் என்பதால் வழங்குநர் opt in செய்ய வேண்டும்.

ஒரு accelerated L2 க்கு இரண்டு நிபந்தனைகளும் ஒரே நேரத்தில் பூர்த்தியாக வேண்டும்:

1. L0 இன் KVM module ஆனது nested=1 உடன் load செய்யப்பட்டிருக்க வேண்டும்.
2. L0 உங்கள் VPS க்கு அந்த flag கொண்ட ஒரு CPU model தர வேண்டும் — libvirt இல் <cpu mode='host-passthrough'/>, Proxmox இல் cpu: host, raw QEMU இல் -cpu host. ஒரு generic emulated model (qemu64, kvm64) ஆனது உட்பொதித்தல் globally இயங்கினாலும் 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-ஐ கைமுறையாக ஏற்றி 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 parameter ஆனது நீங்கள் முழுமையாக சொந்தமாகக் கொண்ட ஒரு கணினியில் நீங்கள் அமைக்கும் கட்டுப்பாடாகும்:

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 தரதாரிகள் இதை ஏன் முடக்கிவைக்கிறார்கள்

• நேரடி இடம்பெயர்ப்பு. உங்களுக்கு vmx வழங்குவது என்பது அந்தக் கொடியைக் கொண்ட CPU மாதிரியை வெளிப்படுத்துவதாகும். அந்த CPU அம்சங்களைச் சார்ந்திருக்கும் விருந்தாளியை, அந்த அம்சங்கள் இல்லாத CPU கொண்ட இயந்திரத்திற்கு பாதுகாப்பாக இடம்பெயர்த்த முடியாது. வாடிக்கையாளர்களை இடம்பெயர்த்து முனைகளைக் காலியாக்கும் தரதாரி, nesting-ஐ இயக்கிய அதே கணத்தில் அந்த வசதியை இழக்கிறார்.
• தாக்குதல் மேற்பரப்பு. nested VMX/SVM பாதைகள் kernel-ன் மெய்நிகராக்க அடுக்கில் உள்ள மிகச் சிக்கலான குறியீடுகளில் சிலவாகும். அதற்கேற்ற CVE வரலாறும் உண்டு.
• L0 ஆனது KVM ஆக இருக்க வேண்டியதில்லை. systemd-detect-virt ஆனது vmware, xen அல்லது microsoft என அச்சிட்டால், nesting விதிகள் அந்த அடுக்கினுடையவை, KVM-உடையவை அல்ல.

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

libvirt உடன் ஒரு L2 கெஸ்ட்டை இயக்குதல்

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'

கிராஃபிகல் செஷன் தேவையில்லை. ஒரு சீரியல் நிறுவல் சிறிது நேரம் இயங்கும். எனவே அதை ஒரு நிலையான ஷெல்லுக்குள் தொடங்கவும். SSH இணைப்பு துண்டிக்கப்பட்டாலும் கூட ஒரு virt-install கன்சோலை இணைத்து வைக்க, VPS இல் Claude Code செஷன்களை உயிர்ப்புடன் வைக்கும் அதே tmux வொர்க்ஃப்ளோ பயன்படுகிறது. --os-variant debian13 நிராகரிக்கப்பட்டால், உங்கள் osinfo-db அந்த வெளியீட்டுக்கு முந்தையது என்று பொருள். osinfo-query os ஐ இயக்கி, இருக்கும் ஒரு பெயரைத் தேர்ந்தெடுக்கவும். --cpu host-passthrough ஆனது vmx ஐ L2 க்குள் ஃபார்வர்டு செய்கிறது. L2 தன்னுள் மீண்டும் விர்ச்சுவலைஸ் செய்ய வேண்டும் என்றால் மட்டுமே இது தேவை. virsh autostart guest1 உடன் கெஸ்ட்டை பூட்-பாதுகாப்பானதாக ஆக்கவும்.

டிஸ்க் மற்றும் NIC இல் உள்ள virtio பஸ் அலங்காரத்திற்காக இல்லை. எமுலேட் செய்யப்பட்ட IDE மற்றும் e1000 சாதனங்கள் virtio வரிசைகளை விட மிக அதிகமாக ஹைப்பர்வைசருக்குள் டிராப் ஆகும். நெஸ்டிங்கின் கீழ் ஒவ்வொரு டிராப்பும் இரண்டு முறை கட்டணம் பெறப்படுகிறது.

நெட்வொர்க்கிங்: பயிற்சிக் கையேடுகள் தவறவிடும் பகுதி

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

L2 கெஸ்ட்களை பொது நெட்வொர்க்கில் பிரிட்ஜ் செய்வது பொதுவாக வேலை செய்யாது. br0-ஐ பொது NIC-இல் வையுங்கள். கெஸ்ட்க்கு அதன் சொந்த MAC-ஐக் கொடுயுங்கள். ARP வெளியே செல்வதைப் பார்ப்பீர்கள், ஆனால் எதுவும் திரும்பி வராது. ஏனெனில் வழங்குநரின் சுவிட்ச், அது உங்களுக்கு வழங்காத MAC-இலிருந்து வரும் ஃப்ரேம்களைக் கைவிடுகிறது. இதுதான் உங்கள் பிரச்சினையாக இருந்தால், பிரிட்ஜை டிபக் செய்வதை நிறுத்துங்கள். இதுதான் அதன் பொறிமுறை.

அதற்குப் பதிலாக NAT நெட்வொர்க்கைப் பயன்படுத்துங்கள். libvirt default-ஐ வழங்குகிறது: virbr0, 192.168.122.0/24, dnsmasq லீஸ்கள், வெளிச்செல்லும் இணைப்பு உடனடியாக வேலை செய்யும். உள்வரும் இணைப்புக்கு, L1-இல் TLS-ஐ முடித்து உள்ளே ப்ராக்ஸி செய்யவும். கீழே உள்ள சான்றிதழ் பாதைகள் 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;
    }
}

கெஸ்ட்க்கு முதலில் நிலையான லீஸ் கொடுயுங்கள் (virsh net-edit default). அப்போதுதான் அந்த proxy_pass-இல் உள்ள முகவரி நிலையாக இருக்கும்.

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

VPS-ல் Proxmox

Proxmox VE 9 அடிப்படையில் Debian 13 ஆகும். எனவே pve-no-subscription களஞ்சியத்தையும் proxmox-ve தொகுப்பையும் சேர்ப்பதன் மூலம் இதை Debian VPS-ல் நிறுவலாம். Proxmox-ன் தற்போதைய அதிகாரப்பூர்வ ஆவணங்களிலிருந்து களஞ்சியம் மற்றும் keyring வரிகளை எடுக்கவும். பழைய வலைப்பதிவு பதிவிலிருந்து நகலெடுக்கப்பட்ட URL நிறுவலைச் செயலிழக்கச் செய்யும்.

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

செயல்திறன் — நேர்மையான கூற்று

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

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

பிழை வகைகள், மற்றும் நீங்கள் காணும் சரங்கள்

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used — kvm-ok இலிருந்து. தொகுதி ஏற்றப்படவில்லை, அல்லது 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. இது அனுமதிகள், வன்பொருள் அல்ல. ls -l /dev/kvm ஆனது group kvm, mode 660 ஐ காட்ட வேண்டும்; அந்த group இல் உங்களைச் சேர்த்துக்கொண்டு புதிய login shell ஐ தொடங்கவும். ஏனெனில், ஏற்கனவே இயங்கும் session க்கு group உறுப்புரிமை பொருந்தாது.

kvm: Device or resource busy — QEMU தொடங்கும்போது. வேறொரு hypervisor தொகுதி CPU ஐ பிடித்துள்ளது: lsmod ஐ இயக்கவும், kvm_intel க்கு அருகில் vboxdrv அல்லது VMware தொகுதிகளைத் தேடவும், மேலும் நீங்கள் விரும்பாததை 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. — வழங்க முடியாத host இல் ஒரு guest KVM acceleration ஐ தேர்வு செய்துள்ளது. nesting ஐ சரிசெய்யவும், அல்லது தேர்வை நீக்கி emulation ஐ ஏற்றுக்கொள்ளவும்.

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

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

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

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

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

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

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

FAQ

VPS-ல் Docker-ஐ இயக்க நெஸ்டட் விர்ச்சுவலைசேஷன் தேவையா?

இல்லை. கன்டெய்னர்கள் உங்கள் VPS கர்னலைப் பகிர்ந்துகொள்கின்றன. அவை /dev/kvm-ஐ ஒருபோதும் திறக்காது. எனவே vmx அல்லது svm ஃபிளாக் இல்லாத சாதாரண இன்ஸ்டன்ஸ் Docker மற்றும் Docker Compose-ஐ சிக்கலின்றி இயக்கும். நெஸ்டிங் தேவைப்படுவது இரண்டாவது கர்னல் வேண்டுமென்றால் மட்டுமே: Proxmox லேப், Windows கெஸ்ட், Firecracker microVMகள், Android எமுலேட்டர், அல்லது VM இமேஜ்களை பூட் செய்யும் CI ரன்னர்கள்.

எனது VPS நெஸ்டட் விர்ச்சுவலைசேஷனை ஆதரிக்கிறதா என எப்படி சரிபார்ப்பது?

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

பெரும்பாலான VPS வழங்குநர்கள் நெஸ்டட் விர்ச்சுவலைசேஷனை ஏன் முடக்குகிறார்கள்?

vmx-ஐ வெளிப்படுத்துவது என்பது கெஸ்ட்டிற்கு அந்த ஃபிளாக் கொண்ட CPU மாடலைக் கொடுப்பதாகும். அந்த CPU அம்சங்களைச் சார்ந்த கெஸ்ட்டை அந்த அம்சங்கள் இல்லாத CPU கொண்ட இயந்திரத்திற்கு லைவ்-மைக்ரேட் செய்ய முடியாது — வாடிக்கையாளர்களை நகர்த்தி நோடுகளை காலியாக்கும் வழங்குநர் இதை இழக்கிறார். நெஸ்டட் VMX/SVM கோட் பாத்கள் பல CVE வரலாற்றையும் கொண்டுள்ளன. சில ஹோஸ்டுகள் கோரிக்கையின் பேரில் VM-க்கு இன்னும் இதை இயக்கித் தருகின்றன. வேறு சிலர் நெஸ்டிங்கை ஒரு பிளான் அம்சமாக ஆவணப்படுத்துகிறார்கள்.

எனது நெஸ்டட் VM-க்கு பப்ளிக் பிரிட்ஜில் நெட்வொர்க் இல்லை. என்ன பிரச்சினை?

வழங்குநரின் ஸ்விட்ச் தான் உங்களுக்கு லீஸ் செய்யாத MAC முகவரியிலிருந்து வரும் ஃப்ரேம்களைக் கைவிடுகிறது. எனவே பப்ளிக் NIC-உடன் பிரிட்ஜ் செய்யப்பட்ட L2 கெஸ்ட் ARP அனுப்பி எந்தப் பதிலும் பெறுவதில்லை. br0-ஐ டிபக் செய்வதை நிறுத்துங்கள் — libvirt-இன் NAT default நெட்வொர்க்கைப் பயன்படுத்துங்கள் (virbr0, 192.168.122.0/24). கெஸ்ட்டிற்கு ஸ்டாடிக் லீஸ் கொடுங்கள். பப்ளிக் ஆன எதையும் VPS-லேயே ரிவர்ஸ் ப்ராக்ஸி அல்லது DNAT விதியின் மூலம் வெளியிடுங்கள்.

நெஸ்டட் VM எவ்வளவு மெதுவாக இருக்கும்?

செலவு மெமரி அணுகலில் அல்ல, VM எக்ஸிட்களில் ஏற்படுகிறது. EPT/NPT செயலில் இருந்தால், L2-க்குள் சாதாரண ரீடு மற்றும் ரைட்கள் ஹார்ட்வேர் வேகத்தில் இயங்கும். I/O, டைமர் இன்டரப்ட்கள், MMIO மற்றும் IPI-கள் L0 ஆல் கையாளப்படுகின்றன. அவை L1 வழியாக மீண்டும் திருப்பப்படலாம். RAM-ல் ஏற்கனவே இருக்கும் தரவின் மீதான CPU-பவுண்ட் வேலை நேட்டிவ்-க்கு அருகில் தெரிகிறது. சிஸ்கால், பேக்கெட் மற்றும் டிஸ்க்-அதிகமான வொர்க்லோடுகள் ஒவ்வொரு லேயரையும் உணரும். எல்லா இடங்களிலும் virtio டிவைசுகளையும் கெஸ்ட் டிஸ்க்குகளில் cache=none-ஐயும் பயன்படுத்தவும். பின்னர் உங்கள் சொந்த வொர்க்லோடை அளவிடவும்.