VPSలో nested virtualization ఉందా? Proxmox నడుస్తుందా

సంక్షిప్త సమాధానం

Nested virtualization అంటే virtual machine లోపల hypervisor నడపడం. మీ VPS ఇప్పటికే ఒక guest. ఇప్పుడు అదే VPS లో స్వంత guest లను నడపాలనుకుంటున్నారు. మీ provider యొక్క hypervisor మీ instance కు CPU virtualization extensions ను ఉద్దేశపూర్వకంగా అందించినప్పుడు మాత్రమే ఇది పనిచేస్తుంది. /proc/cpuinfo లో vmx flag (Intel) లేదా svm (AMD) ఉందో చూడండి. రెండింటిలో ఏదీ కనిపించకపోతే, VPS లో మీరు చేసే ఏ configuration కూడా దీనిని పరిష్కరించదు.

ముందుగా ఒక ముఖ్యమైన విషయం: Docker కు వీటిలో ఏదీ అవసరం లేదు. Containers మీ VPS kernel ను పంచుకుంటాయి. అవి ఎప్పుడూ /dev/kvm ను ఉపయోగించవు. మీ అసలు లక్ష్యం "నా server పై containers లో అనేక సేవలను నడపడం" అయితే, మీ వద్ద ఇప్పటికే అవసరమైనవి ఉన్నాయి. రెండవ kernel, Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, నిజమైన VMs తో Kubernetes testbed లేదా VM images ను boot చేసే CI runners అవసరమైనప్పుడు nested virtualization ఉపయోగపడుతుంది.

వాస్తవంగా ఏది nested అవుతోంది

మూడు layers ఉన్నాయి:

• L0, physical server పై ఉన్న provider యొక్క hypervisor. దీనికి మీకు access ఉండదు.
• 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 ను traverse చేయడానికి కూడా వీటినే ఉపయోగిస్తుంది.

ఈ రెండూ re-entrant execution కోసం రూపొందించబడలేదు. అందువల్ల nesting ను emulate చేయాలి. L1 ఒక VMX instruction ను execute చేసినప్పుడు అది L0 కు trap అవుతుంది. అప్పుడు L0, L1 తరఫున L2 కోసం shadow structures ను నిర్వహిస్తుంది. KVM దీన్ని సమర్థంగా నిర్వహిస్తుంది. అయితే ప్రతి exit సమయంలో అదనపు పనిని చేసేది L0 నే. అందుకే provider దీనిని ప్రత్యేకంగా enable చేయాలి.

Accelerated L2 కోసం ఈ రెండు షరతులూ తప్పనిసరిగా నెరవేరాలి:

1. L0 యొక్క KVM module nested=1 తో load అయి ఉండాలి.
2. మీ VPS కు ఆ flag ను అందించే CPU model ను L0 ఇవ్వాలి: libvirt లో <cpu mode='host-passthrough'/>, Proxmox లో cpu: host, raw QEMU లో -cpu host. Generic emulated model (qemu64, kvm64) nesting ప్రపంచవ్యాప్తంగా enable అయి ఉన్నా 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 mode మరియు 660 గా ఉంటుంది. flag ఉన్నప్పటికీ device node లేకపోతే, module ను చేతితో load చేసి kernel log ను చదవండి:

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

ఒక file ను తరచుగా ఉటంకిస్తారు, కానీ దాని అర్థాన్ని చాలామంది తప్పుగా గ్రహిస్తారు:

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

మీ VPS లో అది మీ KVM module యొక్క setting. L2 guest మూడో స్థాయిని nest చేయగలదా లేదా అనేది ఇది నిర్ణయిస్తుంది. L0 మీ కోసం nesting ను enable చేసిందా లేదా అనే విషయాన్ని ఇది చెప్పదు. ఆ విషయానికి /proc/cpuinfo మరియు kvm-ok సమాధానం ఇస్తాయి. nested parameter ను పూర్తిగా మీ స్వంతమైన machine పై మీరు set చేస్తారు:

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 removal నిరాకరించబడుతుంది. కాబట్టి ముందుగా guests ను shut down చేయండి.

చాలా VPS హోస్టులు దీన్ని ఎందుకు నిలిపివేస్తాయి

• Live migration. మీకు vmx అందించడం అంటే ఆ flag ను కలిగి ఉన్న CPU model ను expose చేయడం. ఈ CPU features పై ఆధారపడే guest ను అవి లేని CPU ఉన్న machine కు సురక్షితంగా migrate చేయలేరు. Customers ను migrate చేయడం ద్వారా nodes ను ఖాళీ చేసే host, nesting enable చేసిన వెంటనే ఈ సౌలభ్యాన్ని కోల్పోతుంది.
• Attack surface. Nested VMX/SVM paths kernel లోని virtualization layer లో అత్యంత సంక్లిష్టమైన code భాగాల్లో ఉన్నాయి. వాటికి అనుగుణంగా CVE చరిత్ర కూడా ఉంది.
• L0 KVM కాకపోవచ్చు. systemd-detect-virt, vmware, xen లేదా microsoft ను print చేస్తే, nesting నియమాలు KVM కు కాకుండా ఆ stack కు సంబంధించినవి.

మీ instance లో flag లేకపోతే support ను సంప్రదించండి. కొన్ని hosts దీన్ని ప్రతి VM కు విడిగా enable చేస్తాయి. Nesting కు స్పష్టంగా support ఉన్న plan ను ఎంచుకోండి లేదా dedicated box కు మారండి. తరువాతి భాగం flag చూపించే machine పై root access ఉందని భావిస్తుంది.

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'

గ్రాఫికల్ 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 ను L2లోకి vmx గా forward చేస్తుంది; L2 మళ్లీ virtualization చేయాల్సి ఉన్నప్పుడు మాత్రమే ఇది అవసరం. virsh autostart guest1 తో guestను boot-safeగా చేయండి.

Disk మరియు NICపై ఉన్న virtio bus కేవలం అలంకారం కాదు: emulated IDE మరియు e1000 devices, virtio queues కంటే చాలా తరచుగా hypervisorలోకి trap అవుతాయి. Nesting సమయంలో ప్రతి trapకు రెండుసార్లు ఖర్చు అవుతుంది.

నెట్‌వర్కింగ్: ట్యుటోరియల్స్‌లో తరచుగా వదిలివేసే భాగం

మీ VPS కు ఒక public IP మాత్రమే ఉంది. అలాగే తెలియని MAC addresses ను filter చేసే network fabric వెనుక అది ఉంది. దీనివల్ల రెండు పరిణామాలు ఉంటాయి.

L2 guests ను public network పై bridge చేయడం సాధారణంగా పనిచేయదు. Public NIC పై br0 ను ఉంచి, guest కు ప్రత్యేక MAC ఇవ్వండి. అప్పుడు ARP బయటకు వెళ్లడాన్ని గమనిస్తారు, కానీ తిరిగి ఏదీ రాదు. Provider యొక్క switch మీకు lease చేయని MAC నుండి వచ్చిన frames ను drop చేస్తుంది. ఇదే మీకు కనిపించే symptom అయితే bridge ను debug చేయడం ఆపండి. ఇదే కారణం.

బదులుగా NAT network ను ఉపయోగించండి. libvirt default ను అందిస్తుంది: virbr0, 192.168.122.0/24, dnsmasq leases, outbound connectivity వెంటనే పనిచేస్తాయి. Inbound traffic కోసం L1 పై TLS termination చేసి, అక్కడి నుంచి proxy చేయండి. దిగువ certificate paths Nginx పై Certbot తో Let's Encrypt certificate జారీ చేయడం నుంచి తీసుకోబడ్డాయి:

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;
    }
}

ముందుగా guest కు static lease ఇవ్వండి (virsh net-edit default). అప్పుడు ఆ proxy_pass లోని address మారకుండా ఉంటుంది.

Management interfaces ను internet కు అందుబాటులో ఉంచకండి. VNC on 5900 మరియు Proxmox web UI on 8006 loopback పై మాత్రమే ఉండాలి. వాటిని SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) ద్వారా లేదా VPS లోకి self-hosted WireGuard VPN ద్వారా చేరుకోండి. దాంతో మొత్తం 192.168.122.0/24 guest range ఒక private hop దూరంలో ఉంటుంది. Firewall ను పరిమితంగా ఉంచండి: sudo ufw allow 22,80,443/tcp, ఇంకేమీ కాదు. ufw enable చేసిన వెంటనే guests కు outbound connectivity కోల్పోతే, సాధారణ కారణం DEFAULT_FORWARD_POLICY="DROP" లోని /etc/default/ufw. దాన్ని ACCEPT గా సెట్ చేసి ufw ను reload చేయండి.

VPSపై Proxmox

Proxmox VE 9 లోపల Debian 13 ఆధారంగా ఉంటుంది. అందువల్ల pve-no-subscription repository మరియు proxmox-ve package ను జోడించి Debian VPS పై దీన్ని install చేయవచ్చు. Repository మరియు keyring lines ను Proxmox స్వంత ప్రస్తుత documentation నుంచి తీసుకోండి. పాత blog post నుంచి copy చేసిన URL install ను విఫలమయ్యేలా చేయవచ్చు. అద్దెకు తీసుకున్న hardware పై Proxmox ను అమలు చేయడం సముచితమా అనే విషయాన్ని ముందుగా నిర్ణయించాలి. లేకపోతే దిగువ networking పనిపై ఒక సాయంత్రం ఖర్చు చేసిన తర్వాత ఆ ప్రశ్న ఎదురవుతుంది. ఇంట్లోని Proxmox box మరియు అద్దె VPS మధ్య ఖర్చు, సామర్థ్యాల పోలికలో power మరియు hardware లెక్కలు ఇప్పటికే ఉన్నాయి.

Packages ప్రధాన సమస్య కావు. Proxmox కు vmbr0 ను physical NIC కు bridged గా అమర్చాలి. ఇది నేరుగా పై పేర్కొన్న MAC-filtering సమస్యలోకి తీసుకెళ్తుంది. VPS పై పనిచేసే నిర్మాణంలో physical port కు అనుసంధానం లేని NAT'd లేదా routed vmbr0 ఉంటుంది. Guests private range లో ఉంటాయి. Public సేవల కోసం host పై DNAT rules లేదా reverse proxy ఉపయోగించాలి. Public-facing services VMs కాకుండా containers అయితే, ఒకే Docker Compose file నుంచి అనేక apps ను ముందుండి నిర్వహించే Traefik అదే routing పనిని automatic certificates తో చేస్తుంది. ముందుగా snapshot /etc/network/interfaces తీసుకోండి. తప్పుగా రాసిన bridge definition వల్ల console అందుబాటులో లేకపోవచ్చు, దాంతో machine నుంచి మీరు lock out అవుతారు.

పనితీరు: వాస్తవాన్ని స్పష్టంగా చెప్పడం

ఒకే స్థాయి వర్చువలైజేషన్‌తో పోలిస్తే nested వర్చువలైజేషన్ నెమ్మదిగా ఉంటుంది. దీనికి కారణం సాధారణంగా అనిపించే విషయం కాదు: ఖర్చు memory access పై కాదు, exits పై పడుతుంది. EPT/NPT అందుబాటులో ఉంటే, L0, L2 కోసం shadow page tables నిర్వహిస్తుంది. సాధారణ memory reads hardware వేగంతోనే నడుస్తాయి. Guest mode నుంచి బయటకు వచ్చే ప్రతి operation ఖరీదైనది. ఇందులో I/O, timer interrupts, MMIO, inter-processor interrupts ఉన్నాయి. ఎందుకంటే L2 exit ను L0 నిర్వహించాలి; అది తిరిగి L1 ద్వారా ప్రతిబింబించబడవచ్చు. ఇప్పటికే RAMలో ఉన్న డేటాపై CPU-bound పని native పనితీరుకు దగ్గరగా ఉంటుంది. కానీ syscalls, packets, disk I/O ఆధారంగా ఎక్కువగా నడిచే పనిలో ఈ layers ప్రభావం స్పష్టంగా కనిపిస్తుంది.

అందువల్ల అన్ని చోట్ల virtio devices ఉపయోగించండి. మీ qcow2 file, provider ఇప్పటికే virtualize చేసిన disk పై ఉంటుంది. అక్కడ రెండు thin-provisioning layers ఒకదానిపై ఒకటి ఉంటాయి. ఫలితంగా cache=none వల్ల guest diskలోని ఒకే blocks రెండు page cachesలో ఒకేసారి ఉండకుండా నిరోధించవచ్చు. ఇక్కడ benchmark సంఖ్యలు ఇవ్వడం లేదు. మీ స్వంత instanceలో, మీ స్వంత workloadను కొలవండి.

వైఫల్య పరిస్థితులు, మీరు చూడబోయే సందేశాలు

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 వర్తించదు.

QEMU ప్రారంభమైనప్పుడు kvm: Device or resource busy కనిపిస్తుంది. మరో hypervisor module CPUను పట్టుకుని ఉంది. lsmod ను అమలు చేసి, kvm_intel పక్కన vboxdrv లేదా VMware modules ఉన్నాయా చూడండి. మీకు అవసరం లేని moduleను 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. acceleration అందించలేని hostపై ఒక guestకు KVM acceleration ప్రారంభించబడింది. nestingను సరిచేయండి లేదా దాన్ని untick చేసి emulationను అంగీకరించండి.

Android emulator: x86_64 emulation currently requires hardware acceleration! మళ్లీ /dev/kvm. సాధారణంగా ఇది group సమస్యే.

ఎలాంటి error కనిపించదు, కానీ ప్రతిదీ చాలా నెమ్మదిగా ఉంటుంది. accelerator flag లేకుండా నడిచే QEMU, దాని software emulator అయిన TCGకు fallback అవుతుంది. ఇది సరిగానే పనిచేస్తుంది, కానీ నెమ్మదిగా ఉంటుంది. సెకన్లలో పూర్తయ్యే boot, నిమిషాలు పడే bootగా మారుతుంది. -accel kvm ను స్పష్టంగా ఇవ్వండి. అప్పుడు QEMU నిశ్శబ్దంగా emulation చేయకుండా errorతో ఆగుతుంది.

ఒక guest నడుస్తుండగానే అదృశ్యమవుతుంది. dmesg లో Out of memory: Killed process ... qemu-system-x86_64 కోసం చూడండి. L2 guest అనేది L1లోని ఒక process. OOM killer దానిని ఇతర processల మాదిరిగానే పరిగణిస్తుంది. L2 RAM, L1కు కేటాయించిన స్థిరమైన allocation నుంచే వస్తుంది. host నుంచి అదనపు RAMను అప్పుగా తీసుకోదు.

దీనిని నిర్వహించడం: బ్యాకప్‌లు, అప్‌గ్రేడ్‌లు, పరిమితులు

బ్యాకప్‌లు. నడుస్తున్న guest యొక్క qcow2 ను కాపీ చేస్తే image corrupt అవుతుంది. ముందుగా virsh shutdown guest1 చేసి కాపీ చేయండి. లేదా external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) తీసుకోండి. అప్పుడు మీరు కాపీ చేస్తున్న స్థిరమైన base పై writes overlay కు మళ్లుతాయి. తరువాత virsh blockcommit తో వాటిని తిరిగి base లో కలపండి. కాపీలను VPS వెలుపలికి పంపండి. అదే disk పై ఉన్న snapshot ఎటువంటి వైఫల్యం నుంచి రక్షించదు.

అప్‌గ్రేడ్‌లు. apt full-upgrade కొత్త kvm_intel/kvm_amd modules ను install చేస్తుంది. అయితే reboot చేసే వరకు నడుస్తున్న kernel పాత modules నే ఉపయోగిస్తుంది. మునుపటి kernel ను install చేసి ఉంచండి. ప్రతి kernel మార్పు తర్వాత kvm-ok ను మళ్లీ అమలు చేయండి. vmx లేకుండా host తిరిగి ప్రారంభమైనా, పనిచేసే స్థితికి తీసుకురావడానికి మరో boot entry మాత్రమే అవసరం అవుతుంది.

ఇది ఎక్కడ scale కావడం ఆగుతుంది. ఒకే public IP ఉంటే, ప్రతి L2 service proxy లేదా L1 పై ఉన్న DNAT rule ద్వారా ప్రపంచానికి చేరుతుంది. Live migration అందుబాటులో ఉండదు. CPU contention ఉన్నప్పుడు nested exit path పై ప్రభావం ముందుగా కనిపిస్తుంది. అనేక guests ఉన్న hypervisor అంటే దాని RAM ఇప్పటికే పూర్తిగా కేటాయించబడిన machine అని అర్థం. nested VMs fixed allocation నుంచి బయటపడటానికి overcommit చేయలేవు. Lab దీనికంటే పెద్దదైతే, పరిష్కారం మరింత పొడవైన nested stack కాదు. మీరు L0 గా ఉండే dedicated box ను ఉపయోగించాలి. అప్పుడు ఈ పరిమితులు ఏవీ వర్తించవు.

FAQ

Docker ను VPS పై నడపడానికి nested virtualization అవసరమా?

లేదు. Containers మీ VPS kernel ను పంచుకుంటాయి మరియు ఎప్పుడూ /dev/kvm ను తెరవవు. అందువల్ల vmx లేదా svm flag లేని సాధారణ instance పై Docker మరియు Docker Compose సరిగ్గా నడుస్తాయి. రెండవ kernel అవసరమైనప్పుడు మాత్రమే nesting ఉపయోగపడుతుంది. ఉదాహరణకు Proxmox lab, Windows guest, Firecracker microVMs, Android emulator లేదా VM images ను boot చేసే CI runners కోసం ఇది అవసరం.

నా VPS nested virtualization కు మద్దతు ఇస్తుందో ఎలా తనిఖీ చేయాలి?

ముందుగా grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u ను run చేయండి. తరువాత cpu-checker package నుంచి kvm-ok ను run చేయండి. ఉపయోగించగల instance vmx (Intel) లేదా svm (AMD) ను చూపిస్తుంది. kvm-ok, KVM acceleration can be used ను report చేస్తుంది. /dev/kvm, kvm group మరియు 660 mode తో ఉంటుంది. ఈ ప్రశ్నకు /sys/module/kvm_intel/parameters/nested ను పరిగణించవద్దు. ఆ file మీ స్వంత KVM module ను వివరిస్తుంది; provider యొక్క hypervisor మీకు అందించిన సామర్థ్యాన్ని కాదు.

ఎక్కువ VPS providers nested virtualization ను ఎందుకు disable చేస్తారు?

vmx ను expose చేయడం అంటే ఆ flag ఉన్న CPU model ను guest కు అందించడం. ఆ CPU features పై ఆధారపడే guest ను, అవి లేని CPU ఉన్న machine కు live-migrate చేయలేరు. Provider customer instances ను తరలించడం ద్వారా nodes ను ఖాళీ చేస్తే, ఆ సౌలభ్యాన్ని వదులుకోవాలి. Nested VMX/SVM code paths కు కూడా చాలా కాలంగా CVE history ఉంది. కొన్ని hosts ఇప్పటికీ అభ్యర్థనపై ప్రతి VM కు దీన్ని enable చేస్తాయి. మరికొన్ని providers nesting ను plan feature గా document చేస్తాయి.

నా nested VM కి public bridge పై network లేదు. సమస్య ఏమిటి?

Provider switch, మీకు lease చేయని MAC address నుంచి వచ్చిన frames ను drop చేస్తుంది. అందువల్ల public NIC పై bridge చేసిన L2 guest ARP పంపినా, తిరిగి ఎలాంటి సమాధానం అందదు. br0 ను debug చేయడం ఆపండి. దాని బదులుగా libvirt యొక్క NAT default network (virbr0, 192.168.122.0/24) ను ఉపయోగించండి. Guest కు static lease ఇవ్వండి. Public services ను VPS లోనే reverse proxy లేదా DNAT rule ద్వారా publish చేయండి.

Nested VM ఎంత నెమ్మదిగా ఉంటుంది?

ఖర్చు VM exits పై పడుతుంది, memory access పై కాదు. EPT/NPT active గా ఉన్నప్పుడు L2 లోని సాధారణ reads మరియు writes hardware speed తోనే నడుస్తాయి. అయితే I/O, timer interrupts, MMIO మరియు IPIs ను L0 handle చేయాలి. అవి L1 ద్వారా తిరిగి పంపబడవచ్చు. RAM లో ఇప్పటికే ఉన్న data పై CPU-bound పని native పనితీరుకు దగ్గరగా ఉంటుంది. Syscall-, packet- మరియు disk-heavy workloads ప్రతి layer ప్రభావాన్ని చూపిస్తాయి. అన్ని చోట్ల virtio devices ఉపయోగించండి. Guest disks పై cache=none ఉపయోగించి, తరువాత మీ స్వంత workload ను కొలవండి.