SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor

VPS-এ Nested Virtualization চালিয়ে Proxmox কি সম্ভব?

বেশিরভাগ VPS host vmx flag লুকিয়ে রাখে। এক মিনিটে kvm-ok দিয়ে পরীক্ষা করুন, তারপর KVM বা Proxmox guest চালানোর সময় দেখা exact error string মিলিয়ে নিন।

সংক্ষিপ্ত উত্তর

Nested virtualization হলো একটি virtual machine-এর ভেতরে চলা hypervisor: আপনার VPS ইতিমধ্যে একটি guest, এবং আপনি সেটির ভেতরে নিজস্ব guest চালাতে চান। এটি তখনই কাজ করে, যখন আপনার provider-এর hypervisor ইচ্ছাকৃতভাবে CPU-এর virtualization extension আপনার instance-এর কাছে প্রকাশ করে। /proc/cpuinfo-এ vmx flag (Intel) অথবা svm (AMD) আছে কি না পরীক্ষা করুন। কোনোটিই না থাকলে VPS-এর ভেতরে কোনো configuration পরিবর্তন করে এটি ঠিক করা যাবে না।

প্রথমে একটি প্রত্যাশা পরিষ্কার করা দরকার: Docker-এর জন্য এগুলোর কোনোটি প্রয়োজন হয় না। Container আপনার VPS-এর kernel share করে এবং কখনো /dev/kvm ব্যবহার করে না। প্রকৃত লক্ষ্য যদি হয় "আমার server-এ container-এর মধ্যে একাধিক service চালানো", তাহলে আপনার যা প্রয়োজন তা ইতিমধ্যেই আছে। দ্বিতীয় একটি kernel, Proxmox lab, Windows guest, Firecracker microVM, Android emulator, প্রকৃত VM-ভিত্তিক Kubernetes testbed অথবা VM image boot করা CI runner চালাতে চাইলে nesting প্রয়োজন।

আসলে কোন স্তরের মধ্যে আরেকটি স্তর চলছে

তিনটি স্তর:

  • L0, bare metal-এর ওপর থাকা 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 এই instruction ব্যবহার করে guest mode-এ প্রবেশ করে এবং CPU-কে একই সময়ে দুটি page table পড়তে দেয়।

কোনোটিই পুনরায় ব্যবহারের জন্য তৈরি নয়। তাই nesting emulation-এর মাধ্যমে চালানো হয়: L1 যখন VMLAUNCH বা VMRESUME-এর মতো VMX instruction execute করে, তখন সেটি L0-তে trap করে। L0, L1-এর হয়ে L2-এর shadow structure বজায় রাখে। VMCS shadowing সমর্থনকারী CPU-তে L1-এর VMREAD এবং VMWRITE exit ছাড়াই সম্পন্ন করা যায়। এতে এই traffic-এর বড় অংশ কমে, তবে পুরোটা নয়। KVM এটি ভালোভাবে করে, কিন্তু প্রতিটি exit-এ অতিরিক্ত কাজটি L0-ই করে। এ কারণেই provider-কে এই সুবিধা সক্রিয় করতে হয়।

L0 যখন KVM হয়, accelerated L2 চালানোর জন্য দুটি শর্তই পূরণ হতে হবে:

  1. L0-এর KVM module nested=1 সহ load করা থাকতে হবে।
  2. L0-কে এমন একটি CPU model দিয়ে আপনার VPS চালাতে হবে যাতে এই flag থাকে: libvirt-এ <cpu mode='host-passthrough'/>, Proxmox-এ cpu: host, raw QEMU-তে -cpu host। একটি generic emulated model (qemu64, kvm64) nesting globally enabled থাকলেও vmx আড়াল করে।

অন্যান্য hypervisor-এর নিজস্ব switch থাকে। উদাহরণস্বরূপ, Hyper-V তার VM-এর ভেতরে থাকা nested hypervisor-এর জন্য virtualization extension emulation করে। তবে এটি কেবল সেই VM-গুলোতে কাজ করে যেগুলোতে nesting আলাদাভাবে সক্রিয় করা হয়েছে।

এক মিনিটে আপনার 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-এ সেট করার control:

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-গুলো shutdown করুন। মেশিনটি Proxmox host হলে, Proxmox VE 9-এ nested virtualization সক্রিয় করা একই modprobe.d পরিবর্তনের পাশাপাশি প্রতি-VM cpu: host setting-এর পদ্ধতি ব্যাখ্যা করে, যার ফলে guest-এর ভেতরে flag-টি দৃশ্যমান হয়।

কেন অধিকাংশ VPS provider এটি নিষ্ক্রিয় রাখে

  • Live migration। আপনাকে vmx দেওয়ার অর্থ হলো এমন একটি CPU model উন্মুক্ত করা, যাতে এই flag থাকে। এই CPU feature-এর ওপর নির্ভরশীল guest-কে এমন মেশিনে নিরাপদে migrate করা যায় না, যার CPU-তে এগুলো নেই। যে host customer-দের migrate করে node খালি করে, nesting enable করার সঙ্গে সঙ্গেই সে এই সুবিধা হারায়।
  • Attack surface। Nested VMX/SVM path-গুলো kernel-এর virtualization layer-এর সবচেয়ে জটিল code-এর অন্তর্ভুক্ত। এগুলোর CVE history-ও রয়েছে।
  • L0 হয়তো KVM নয়। systemd-detect-virt চালালে যদি vmware, xen বা microsoft দেখা যায়, তাহলে nesting-এর নিয়ম KVM নয়, ওই stack নির্ধারণ করে।

আপনার instance-এ flag না থাকলে support-এর সঙ্গে যোগাযোগ করুন। কিছু provider প্রতি-VM ভিত্তিতে এটি enable করে। nesting সমর্থন document করা একটি plan বেছে নিন, অথবা dedicated box ব্যবহার করুন। পরবর্তী অংশে এমন একটি মেশিনে root access আছে ধরে নেওয়া হয়েছে, যেখানে flag-টি দেখা যায়।

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 session চালু রাখে এমন একই 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-এর জন্য নিরাপদ করুন।

Disk এবং NIC-এ virtio bus ব্যবহার করা কেবল আনুষ্ঠানিকতা নয়: emulated IDE এবং e1000 device virtio queue-এর তুলনায় অনেক বেশি বার hypervisor-এ trap করে। Nesting-এর সময় L0 নিজে যে exit সম্পন্ন করতে পারে না, তা L1-এ প্রতিফলিত হয়। সেখানে সেটি পরিচালনা করতে গিয়ে L1-এর নিজস্ব আরও exit ঘটতে পারে।

নেটওয়ার্কিং: যে অংশটি টিউটোরিয়ালগুলো এড়িয়ে যায়

আপনার VPS-এর একটি public IP আছে এবং এটি এমন একটি network fabric-এর পেছনে রয়েছে, যা অপরিচিত MAC address filter করে। এর দুটি ফল হয়।

L2 guest-কে public network-এ bridge করা সাধারণত কাজ করবে না। public NIC-এ br0 বসিয়ে guest-কে নিজস্ব MAC দিলে ARP request বের হতে দেখবেন, কিন্তু কোনো উত্তর আসবে না। কারণ provider-এর switch এমন MAC address থেকে আসা frame বাতিল করে, যেটি আপনাকে lease দেওয়া হয়নি। আপনার উপসর্গ এমন হলে bridge debug করা বন্ধ করুন; এটাই এর কারণ।

এর পরিবর্তে NAT network ব্যবহার করুন। libvirt default সরবরাহ করে: virbr0, 192.168.122.0/24, dnsmasq lease এবং সঙ্গে সঙ্গে সচল outbound connectivity। Inbound traffic-এর জন্য L1-এ TLS termination করে proxy করুন। নিচের certificate path-গুলো 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 interface-গুলো Internet থেকে বিচ্ছিন্ন রাখুন: 5900-এ VNC এবং 8006-এ Proxmox web UI 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 rule সীমিত রাখুন, sudo ufw allow 22,80,443/tcp, আর কিছু নয়। ufw enable করার ঠিক পর guest-গুলো 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-এর লাইন Proxmox-এর নিজস্ব বর্তমান documentation থেকে নিন। পুরনো blog post থেকে কপি করা URL ব্যবহার করলে install ব্যর্থ হতে পারে। Rented hardware-এ আদৌ Proxmox চালানো উচিত কি না, নিচের networking configuration-এ সময় দেওয়ার আগে তা নির্ধারণ করা ভালো। বাড়ির Proxmox box এবং rented VPS-এর খরচ ও সক্ষমতার তুলনা-এ power এবং hardware-এর হিসাবসহ এই প্রশ্নের উত্তর দেওয়া হয়েছে।

Package-গুলো মূল সমস্যা নয়। Proxmox আশা করে vmbr0 একটি physical NIC-এর সঙ্গে bridge করা থাকবে। VPS-এ এটি উপরের MAC-filtering সমস্যায় সরাসরি নিয়ে যায়। VPS-এ কার্যকর configuration হলো physical port ছাড়া একটি NAT করা বা routed vmbr0, private range-এ থাকা guest, এবং public service-এর জন্য host-এ DNAT rule বা reverse proxy। Public-facing service-গুলো VM-এর বদলে container হলে, একটি Docker Compose file থেকে একাধিক app-এর সামনে Traefik ব্যবহার করা একই routing কাজ automatic certificate-সহ সম্পন্ন করে। প্রথমে snapshot /etc/network/interfaces নিন। ভুল bridge definition এমন একটি machine-এ আপনার access বন্ধ করে দিতে পারে, যার console-এ আপনার হয়তো access নেই।

কর্মক্ষমতা, সৎভাবে বলা

এক স্তরের তুলনায় nested পরিবেশ ধীর, এবং এর কারণ নির্দিষ্ট: এই খরচ সাধারণ instruction-এ নয়, exit এবং address translation-এ পড়ে। EPT/NPT থাকলে L0, L2-এর page table এবং নিজের page table একত্র করে একটি shadow table তৈরি করে। তাই TLB hit হলে hardware speed-এ কাজ চলে। TLB miss-এর খরচ বেশি। Hardware একই সঙ্গে guest-এর page table এবং shadow table অনুসরণ করে। L1 নিজের table-এ কোনো পরিবর্তন করলেই shadow table পুনরায় সামঞ্জস্য করতে L0-তে exit ঘটাতে হয়। Guest mode থেকে বেরিয়ে আসা প্রতিটি operation ব্যয়বহুল হয়। এর মধ্যে I/O, timer interrupt, MMIO এবং inter-processor interrupt রয়েছে। কারণ L2-এর exit L0 পরিচালনা করে এবং সেটি L1-এর মাধ্যমে আবার প্রতিফলিত হতে পারে। ছোট working set-এ CPU-bound কাজ native performance-এর কাছাকাছি থাকে। বড় in-memory working set-এ TLB miss-এর খরচ দিতে হয়। আর syscall, packet এবং disk I/O-নির্ভর workload-এ এই স্তরগুলোর প্রভাব স্পষ্টভাবে বোঝা যায়।

তাই সর্বত্র virtio device ব্যবহার করুন। আপনার qcow2 file এমন একটি disk-এ রয়েছে, যেটি provider আগেই virtualize করেছে। এখানে দুইটি thin-provisioning layer একটির ওপর আরেকটি রয়েছে। ফলে cache=none guest disk-এ একই block একই সময়ে দুইটি page cache-এ থাকা বন্ধ করে। এখানে কোনো benchmark number দেওয়া হলো না। আপনার নিজের 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 আপনাকে virtualization extension দিচ্ছে না। Guest-এর ভিতরে কোনো command চালিয়ে এটি পরিবর্তন করা যায় না।

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported। Kernel যে CPU শনাক্ত করছে তাতে vmx নেই। এটিও L0-এর সিদ্ধান্ত।

Could not access KVM kernel module: Permission denied। এটি hardware-এর সমস্যা নয়, permission-এর সমস্যা। ls -l /dev/kvm-এ group kvm এবং mode 660 দেখা উচিত। নিজেকে ওই group-এ যোগ করুন এবং নতুন login shell চালু করুন, কারণ ইতিমধ্যে চলমান session-এ group membership প্রয়োগ হয় না।

QEMU চালু করার সময় kvm: Device or resource busy দেখা গেলে, অন্য একটি hypervisor module CPU দখলে রেখেছে। lsmod চালান। vboxdrv অথবা VMware module-গুলোর পাশাপাশি kvm_intel আছে কি না দেখুন। আপনি যে module ব্যবহার করতে চান না, সেটি unload করুন।

virsh থেকে /var/run/libvirt/libvirt-sock: No such file or directory। Daemon বন্ধ আছে: sudo systemctl enable --now libvirtd।

Proxmox: KVM virtualisation configured, but not available. এমন একটি host-এ guest-এর KVM acceleration চালু করা হয়েছে, যে host এটি দিতে পারে না। Nested virtualization ঠিক করুন, অথবা সেটি untick করে emulation গ্রহণ করুন।

Android emulator: x86_64 emulation currently requires hardware acceleration! আবার /dev/kvm পরীক্ষা করুন। সাধারণত এটি group membership-এর সমস্যা।

কোনো error নেই, কিন্তু সবকিছু অত্যন্ত ধীর। Accelerator flag ছাড়া QEMU TCG, অর্থাৎ software emulator-এ fallback করে। এটি সঠিকভাবে কাজ করে, কিন্তু ধীর। কয়েক সেকেন্ডের 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 ধার করা যায় না।

এটি পরিচালনা করা: backup, upgrade এবং সীমাবদ্ধতা

Backup। চলমান guest-এর qcow2 কপি করলে অসামঞ্জস্যপূর্ণ image তৈরি হওয়ার ঝুঁকি থাকে, কারণ আপনি পড়ার সময় guest-টি লিখতে থাকে। হয় virsh shutdown guest1 চালিয়ে virsh domstate guest1-এ shut off দেখা পর্যন্ত অপেক্ষা করুন (shutdown command ফিরে আসতে পারে, যদিও guest তখনও বন্ধ হচ্ছে), তারপর কপি করুন; অথবা একটি external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) নিন। এতে আপনি স্থির base কপি করার সময় write-গুলো overlay-তে চলে যায়। এরপর virsh blockcommit guest1 vda --active --pivot দিয়ে পরিবর্তনগুলো base-এ একীভূত করুন। কপিগুলো VPS-এর বাইরে সংরক্ষণ করুন। একই disk-এ রাখা snapshot কোনো disk failure থেকে সুরক্ষা দেয় না।

Upgrade। apt full-upgrade নতুন kvm_intel/kvm_amd module ইনস্টল করে, কিন্তু reboot না করা পর্যন্ত চলমান kernel পুরোনো module-ই ব্যবহার করে। আগের kernel ইনস্টল রাখা উচিত এবং প্রতিটি kernel পরিবর্তনের পরে kvm-ok আবার চালান। তাহলে vmx ছাড়া host ফিরে এলে আবার কাজ করার জন্য মাত্র একটি boot entry নির্বাচন করলেই হবে।

এটি যেখানে আর scale করে না। একটি public IP থাকলে প্রতিটি L2 service proxy অথবা L1-এ থাকা DNAT rule-এর মাধ্যমে Internet-এ পৌঁছায়। Live migration এখানে সম্ভব নয়। CPU contention হলে nested exit path-ই প্রথমে প্রভাবিত হয়। একাধিক guest-সহ hypervisor এমন একটি machine, যার RAM আপনি ইতিমধ্যে বরাদ্দ করে ফেলেছেন। Fixed allocation-এর বাইরে nested VM overcommit করে সমস্যার সমাধান করতে পারে না। কোনো lab এই সীমা ছাড়িয়ে গেলে সমাধান আরও বড় nested stack নয়। সমাধান হলো একটি dedicated box, যেখানে আপনি L0 এবং এই সীমাবদ্ধতাগুলোর কোনোটিই প্রযোজ্য নয়।

FAQ

Docker একটি VPS-এ চালাতে কি nested virtualization প্রয়োজন?

না। Container আপনার VPS kernel শেয়ার করে এবং কখনো /dev/kvm খোলে না। তাই vmx বা svm flag ছাড়া একটি সাধারণ instance-এ Docker এবং Docker Compose ভালোভাবেই চলে। দ্বিতীয় একটি kernel চালাতে চাইলে তবেই nesting প্রয়োজন হয়। যেমন Proxmox lab, Windows guest, Firecracker microVM, Android emulator অথবা VM image boot করা CI runner-এর ক্ষেত্রে।

আমার 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 থাকবে। এছাড়া /dev/kvm উপস্থিত থাকবে এবং তার group হবে kvm ও mode হবে 660। এই প্রশ্নের ক্ষেত্রে /sys/module/kvm_intel/parameters/nested উপেক্ষা করুন। ওই file-এ আপনার নিজের KVM module-এর বিবরণ থাকে, provider-এর hypervisor আপনার জন্য কী expose করেছে তার নয়।

অধিকাংশ VPS provider nested virtualization নিষ্ক্রিয় রাখে কেন?

vmx expose করার অর্থ হলো guest-কে ওই flag-সহ একটি CPU model দেওয়া। এসব CPU feature-এর ওপর নির্ভরশীল guest এমন কোনো machine-এ live-migrate করা যায় না, যার CPU-তে ওই feature নেই। Provider-রা node খালি করতে customer-দের এক machine থেকে অন্য machine-এ সরিয়ে দেয়। তাই তাদের এই সুবিধা ত্যাগ করতে হয়। Nested VMX/SVM code path-গুলোরও দীর্ঘ CVE history রয়েছে। কিছু host এখনও অনুরোধের ভিত্তিতে প্রতি-VM হিসেবে এটি enable করে। অন্যরা nesting-কে plan feature হিসেবে উল্লেখ করে।

আমার nested VM-এ public bridge-এ network নেই। সমস্যা কী?

Provider-এর switch এমন একটি MAC address থেকে আসা frame drop করে, যা সে আপনাকে lease দেয়নি। তাই public NIC-এর সঙ্গে bridge করা L2 guest ARP পাঠালেও কোনো উত্তর পায় না। br0 debug করা বন্ধ করুন। পরিবর্তে libvirt-এর NAT default network ব্যবহার করুন (virbr0, 192.168.122.0/24)। Guest-কে একটি static lease দিন। Public service VPS-এর নিজস্ব reverse proxy অথবা DNAT rule-এর মাধ্যমে প্রকাশ করুন।

একটি nested VM কতটা ধীর হয়?

এই overhead VM exit এবং address translation-এ পড়ে। EPT/NPT সক্রিয় থাকলে L2-এর ভেতরের instruction এবং TLB hit hardware speed-এ চলে। কিন্তু TLB miss হলে অতিরিক্ত page table হাঁটতে হয়। I/O, timer interrupt, MMIO এবং IPI L0 পরিচালনা করে এবং সেগুলোকে L1-এর মধ্য দিয়ে আবার পাঠাতে হতে পারে। ছোট working set-এ CPU-bound কাজ native performance-এর কাছাকাছি থাকে। বড় in-memory working set এবং syscall-, packet- ও disk-heavy workload-এ প্রতিটি layer-এর প্রভাব বোঝা যায়। সব জায়গায় virtio device ব্যবহার করুন এবং guest disk-এ cache=none দিন। এরপর আপনার নিজের workload মেপে দেখুন।