Virtual machine আর hypervisor

১ · Virtualization কী — একটি যন্ত্রে অনেক কম্পিউটার

এতদিন আমরা দেখেছি একটি OS কীভাবে একটি কম্পিউটারের CPU, মেমরি আর ডিস্ক অনেকগুলো প্রসেসের মধ্যে ভাগ করে। প্রতিটি প্রসেস পায় নিজের virtual address space আর CPU-র পালা (পর্ব ৮, ৩৫)। এবার একই চিন্তা আরও এক ধাপ ওপরে: পুরো OS-গুলোকেই যদি একটি যন্ত্রে ভাগ করে চালানো যায়? একটি সার্ভারে একসাথে চলবে Ubuntu, Windows Server আর একটি পুরোনো CentOS — প্রত্যেকে ভাববে গোটা যন্ত্রটি তার একার।

এই কাজকে বলে virtualization. যে সফটওয়্যার কাজটি করে, তার নাম hypervisor বা VMM (virtual machine monitor). যে OS VM-এর ভেতরে চলে, সে guest; আর যে যন্ত্র বা OS-এর ওপর hypervisor বসে, সে host. Guest-এর চোখে আছে কিছু virtual CPU (vCPU), নির্দিষ্ট পরিমাণ “physical” মেমরি, একটি ডিস্ক আর একটি নেটওয়ার্ক কার্ড — আসলে সবই hypervisor-এর তৈরি করা ছবি।

কেন এত আগ্রহ — পাঁচটি কারণ

২ · Popek–Goldberg-এর শর্ত — কখন VMM বানানো সম্ভব

১৯৭৪ সালে Gerald Popek আর Robert Goldberg একটি ছোট কিন্তু বিখ্যাত গবেষণাপত্রে প্রশ্নটি গাণিতিকভাবে বাঁধেন: কোন ধরনের CPU-তে একটি “ভালো” VMM বানানো যায়? তাঁরা একটি ভালো VMM-এর তিনটি শর্ত দেন — যাকে বলা হয় Popek–Goldberg requirements:

এরপর তাঁরা instruction-গুলোকে ভাগ করেন। Privileged instruction সেগুলো, যা user mode-এ চালালে CPU trap করে (exception দিয়ে kernel-এ যায়), আর kernel mode-এ চালালে স্বাভাবিকভাবে চলে (পর্ব ৫, ৪৮)। Sensitive instruction সেগুলো, যা যন্ত্রের নিয়ন্ত্রণ-অবস্থা বদলায় (যেমন interrupt চালু/বন্ধ, page table-এর ঠিকানা) বা যাদের ফল নির্ভর করে CPU কোন mode-এ আছে বা মেমরির কোথায় আছে তার ওপর। সব sensitive instruction privileged হবে, এমন কোনো নিয়ম hardware-এ আপনা-আপনি নেই — সেটিই আসল প্রশ্ন।

কেন সত্য — যুক্তির খসড়া। VMM guest kernel-কে কম ক্ষমতায় (user mode-এ) চালায় আর নিজে থাকে আসল kernel mode-এ। এখন guest-এর যেকোনো instruction দুই রকমের হতে পারে:

• Sensitive নয়: এর ফল mode বা নিয়ন্ত্রণ-অবস্থার ওপর নির্ভর করে না, আর এটি নিয়ন্ত্রণ-অবস্থা বদলায়ও না। তাই সরাসরি আসল CPU-তে চালালে আসল যন্ত্রের মতোই ফল — equivalence আর efficiency দুটোই রক্ষা হয়, আর সম্পদও VMM-এর নিয়ন্ত্রণ থেকে বেরোয় না।
• Sensitive: শর্ত অনুযায়ী এটি privileged, আর guest আছে user mode-এ — তাই CPU অবশ্যই trap করবে। নিয়ন্ত্রণ যাবে VMM-এর কাছে। VMM তখন guest-এর virtual অবস্থার ওপর কাজটি অনুকরণ করে (যেমন guest-এর “interrupt বন্ধ” bit-টি নিজের টেবিলে বসায়), তারপর guest-কে পরের instruction থেকে চালায়। কোনো sensitive কাজ VMM-কে ফাঁকি দিয়ে আসল যন্ত্রে পৌঁছাতে পারে না — resource control রক্ষা হয়।

দুই ক্ষেত্রেই guest যা দেখে তা আসল যন্ত্রের সমান। উল্টো দিকটিও শিক্ষণীয়: কোনো একটি sensitive instruction যদি privileged না হয়, তবে guest সেটি চালালে trap হবে না, VMM জানতেই পারবে না, আর আসল CPU-র (user mode-এর) আচরণ guest-এর প্রত্যাশার সাথে মিলবে না। এই পদ্ধতির নাম trap-and-emulate.

পুরোনো x86 কেন শর্তটি ভাঙত

১৯৭৮ সালের 8086 থেকে আসা x86-এর নকশায় virtualization মাথায় রাখা হয়নি। ২০০০ সালে John Robin আর Cynthia Irvine-এর একটি বিশ্লেষণে Pentium-এ এমন প্রায় ১৭টি instruction চিহ্নিত হয়, যা sensitive অথচ privileged নয়। পরিচিত কয়েকটি উদাহরণ:

• POPF: stack থেকে flags register বসায়। Kernel mode-এ এটি interrupt flag (IF) বদলাতে পারে; কম ক্ষমতার mode-এ IF বদলানোর অংশটি চুপচাপ উপেক্ষিত হয় — কোনো trap নেই। ফলে guest kernel ভাবে “interrupt চালু করলাম”, অথচ কিছুই ঘটেনি, আর VMM জানতেও পারে না।
• SGDT / SIDT: descriptor table-এর (GDT, IDT — পর্ব ৩৪) ঠিকানা পড়ে। User mode-এ চালালেও trap ছাড়াই আসল ঠিকানা ফেরত দেয় — guest দেখে VMM-এর টেবিলের ঠিকানা, নিজেরটা নয়। (পরে নিরাপত্তার কারণে নতুন CPU-তে UMIP নামে এগুলো user mode-এ আটকানোর ব্যবস্থা এসেছে।)
• PUSHF আর CS-এর মতো segment register পড়া: আসল flags আর বর্তমান privilege level (CS-এর নিচের দুই bit) ফাঁস করে দেয়, তাই guest বুঝে যায় সে আসলে ring 0-তে নেই।

তাই ২০০৫-এর আগে x86-এ বিশুদ্ধ trap-and-emulate অসম্ভব ছিল। তিনটি ভিন্ন সমাধান এসেছে — পরের অংশে।

৩ · তিনটি উত্তর — binary translation, paravirtualization আর VT-x

Xen প্রকল্পটি University of Cambridge-এ শুরু হয়, আর ২০০৩ সালের গবেষণাপত্র “Xen and the Art of Virtualization” paravirtualization-কে জনপ্রিয় করে। Linux-কে বদলানো সহজ ছিল (সোর্স খোলা), Windows-কে নয় — paravirtualization-এর সীমা এখানেই। তবে চিন্তাটি হারায়নি: আজ প্রায় প্রতিটি VM-এ ডিভাইস paravirtual (অংশ ৬-এর virtio), আর CPU-র জন্য hardware সহায়তা — দুটোর মিশ্রণ।

VT-x-এর ভেতরে: root আর non-root mode

Intel VT-x (AMD-তে একই ধরনের AMD-V, যাকে SVM-ও বলে) CPU-তে দুটি জগৎ তৈরি করে। VMX root mode-এ চলে hypervisor; non-root mode-এ চলে guest. দুই জগতেই ring 0–3 আছে — তাই guest kernel নিজের ring 0-তে থাকে, POPF-এর মতো instruction guest-এর নিজের flags-এই ঠিকঠাক কাজ করে। আর যে কাজগুলো hypervisor নিজে দেখতে চায় (I/O port, কিছু control register, CPUID, HLT, external interrupt…), সেগুলো ঘটলে CPU একটি VM exit করে। Hypervisor কাজ সেরে VM entry (VMLAUNCH/VMRESUME instruction) দিয়ে guest-কে ফেরত পাঠায়। দুই জগতের অবস্থা থাকে মেমরির একটি কাঠামোয় — VMCS (virtual machine control structure; AMD-তে VMCB). নিচের ডায়াগ্রামে একটি পূর্ণ চক্র দেখুন:

mov  al, 'A'          ; সাধারণ instruction — কোনো exit নেই
add  rbx, 1           ; আসল গতিতে চলে
mov  dx, 0x3f8        ; port নম্বর ২৫৫-এর বেশি, তাই DX-এ রাখতে হয়
out  dx, al           ; serial port-এ লেখা — hypervisor দেখতে চায়

guest-state area : RIP, RSP, RFLAGS, CR0/CR3/CR4, segment …
exit reason      : 30 (I/O instruction)
exit qualification: port 0x3f8, size 1, direction OUT
instruction len  : 1
host-state area  → এখান থেকে hypervisor-এর RIP, CR3 লোড

switch (exit_reason) {
case EXIT_IO:   vserial_write(port, guest.al);   /* 'A' লগে/কনসোলে */
                guest.rip += instr_len;          /* পরের instruction */
                break;
case EXIT_HLT:  … case EXIT_CPUID: … case EXIT_EPT_VIOLATION: …
}

CPU যাচাই করে VMCS-এর guest-state ঠিক আছে কি না
guest-এর RIP, RSP, CR3 … লোড
mode: root → non-root

mov  al, 'B'          ; guest-এর চোখে: out-টি স্বাভাবিকভাবে শেষ হয়েছে
out  dx, al           ; (DX এখনো 0x3f8) → আবার একটি VM exit

এবার একটি খেলনা VMM নিজে চালিয়ে দেখুন। একটি ছোট guest instruction-তালিকা দুইবার চালানো হচ্ছে: প্রথমবার এমন CPU-তে, যেখানে সব sensitive instruction trap করে; দ্বিতীয়বার পুরোনো x86-এর মতো, যেখানে POPF trap করে না। শেষে ফলাফল আসল যন্ত্রের (bare metal) সাথে মেলানো হয় — equivalence যাচাই।

// Toy trap-and-emulate: the guest kernel runs deprivileged; cli, mov_cr3, out, hlt
// (and popf, if the CPU makes it trap) cause VM exits that a tiny VMM emulates
const guest = [["add", 5], ["cli"], ["add", 3], ["mov_cr3", "0x2000"], ["popf", 1],
               ["out", "A"], ["add", 1], ["out", "B"], ["hlt"]];

function run(name, popfTraps) {
  const v = { r1: 0, IF: 1, cr3: "0x1000", serial: "" };          // the guest's virtual CPU state
  let exits = 0;
  console.log(`--- ${name} ---`);
  for (const [op, x] of guest) {
    const text = (op + (x !== undefined ? " " + x : "")).padEnd(15);
    if (op === "add") { v.r1 += x; console.log(`${text} native        r1=${v.r1}`); continue; }
    if (op === "popf" && !popfTraps) {                           // sensitive, NOT privileged
      console.log(`${text} native (!!)   IF write silently ignored in ring 3, IF=${v.IF}`); continue;
    }
    exits++;                                                     // VM exit -> VMM emulates
    let what;
    if (op === "cli")     { v.IF = 0; what = "IF=0"; }
    if (op === "popf")    { v.IF = x; what = `IF=${x}`; }
    if (op === "mov_cr3") { v.cr3 = x; what = `cr3=${x}`; }
    if (op === "out")     { v.serial += x; what = `serial="${v.serial}"`; }
    if (op === "hlt")     what = "vCPU halted";
    console.log(`${text} VM EXIT #${exits}  VMM emulates: ${what}` + (op === "hlt" ? "" : "  -> VM entry"));
  }
  const bare = { r1: 9, IF: 1, cr3: "0x2000", serial: "AB" };      // same program on real ring 0
  const same = Object.keys(bare).every(k => bare[k] === v[k]);
  console.log(`exits=${exits}  final IF=${v.IF} (bare metal: 1)  equivalent? ${same ? "YES" : "NO"}`);
}
run("ISA where every sensitive instruction traps", true);
run("classic x86: POPF is sensitive but not privileged", false);

--- ISA where every sensitive instruction traps ---
add 5           native        r1=5
cli             VM EXIT #1  VMM emulates: IF=0  -> VM entry
add 3           native        r1=8
mov_cr3 0x2000  VM EXIT #2  VMM emulates: cr3=0x2000  -> VM entry
popf 1          VM EXIT #3  VMM emulates: IF=1  -> VM entry
out A           VM EXIT #4  VMM emulates: serial="A"  -> VM entry
add 1           native        r1=9
out B           VM EXIT #5  VMM emulates: serial="AB"  -> VM entry
hlt             VM EXIT #6  VMM emulates: vCPU halted
exits=6  final IF=1 (bare metal: 1)  equivalent? YES
--- classic x86: POPF is sensitive but not privileged ---
add 5           native        r1=5
cli             VM EXIT #1  VMM emulates: IF=0  -> VM entry
add 3           native        r1=8
mov_cr3 0x2000  VM EXIT #2  VMM emulates: cr3=0x2000  -> VM entry
popf 1          native (!!)   IF write silently ignored in ring 3, IF=0
out A           VM EXIT #3  VMM emulates: serial="A"  -> VM entry
add 1           native        r1=9
out B           VM EXIT #4  VMM emulates: serial="AB"  -> VM entry
hlt             VM EXIT #5  VMM emulates: vCPU halted
exits=5  final IF=0 (bare metal: 1)  equivalent? NO

৪ · Type 1 আর type 2 — hypervisor কোথায় বসে

পর্ব ২-এ নাম দুটি শুনেছেন। ১৯৭০-এর দশকে Goldberg-এর শ্রেণিবিভাগ থেকেই এই নাম এসেছে:

KVM কোন দলে? KVM (Kernel-based Virtual Machine) একটি Linux kernel module; ২০০৭ সালে Linux 2.6.20-এ যোগ হয়। Module লোড হলে Linux kernel নিজেই hypervisor হয়ে যায় — hardware-এ সরাসরি বসা, তাই অনেকে type 1 বলেন। আবার host-এ একটি পূর্ণ সাধারণ OS (Linux) চলছে, VM-গুলো সেখানে সাধারণ প্রসেস হিসেবে দেখা যায় — তাই অনেকে type 2 বলেন। আসল শিক্ষা: শ্রেণিবিভাগটি সরলীকরণ; গুরুত্বপূর্ণ প্রশ্ন হলো কোন কোড সবচেয়ে বেশি ক্ষমতায় চলে আর কতটা বড় (অর্থাৎ নিরাপত্তার ভিত কতটা ছোট)।

Linux-এ KVM + QEMU — কে কী করে

KVM শুধু CPU আর মেমরির virtualization সামলায়। বাকি “যন্ত্র” — BIOS/UEFI firmware, ডিস্ক, নেটওয়ার্ক কার্ড, USB — বানায় user space-এর একটি প্রোগ্রাম, সাধারণত QEMU (২০০৩ সালে Fabrice Bellard-এর শুরু করা emulator). প্রতিটি VM host-এর চোখে একটি QEMU প্রসেস; প্রতিটি vCPU সেই প্রসেসের একটি thread. QEMU /dev/kvm ডিভাইস ফাইল খুলে ioctl দিয়ে KVM-কে আদেশ দেয়। মূল লুপটি দেখতে এমন (সরলীকৃত, Linux-এর আসল KVM API অনুযায়ী):

int kvm  = open("/dev/kvm", O_RDWR | O_CLOEXEC);
int vm   = ioctl(kvm, KVM_CREATE_VM, 0);
void *mem = mmap(NULL, 0x200000, PROT_READ | PROT_WRITE,          /* guest-এর "RAM" */
                 MAP_SHARED | MAP_ANONYMOUS, -1, 0);
struct kvm_userspace_memory_region r = { .slot = 0, .guest_phys_addr = 0,
        .memory_size = 0x200000, .userspace_addr = (unsigned long)mem };
ioctl(vm, KVM_SET_USER_MEMORY_REGION, &r);
int vcpu = ioctl(vm, KVM_CREATE_VCPU, 0);
struct kvm_run *run = mmap(NULL, ioctl(kvm, KVM_GET_VCPU_MMAP_SIZE, 0),
                           PROT_READ | PROT_WRITE, MAP_SHARED, vcpu, 0);
/* … guest-এর কোড mem-এ কপি, KVM_SET_SREGS / KVM_SET_REGS দিয়ে register … */
for (;;) {
    ioctl(vcpu, KVM_RUN, 0);            /* VM entry; ফেরে এমন exit-এ যা kernel নিজে সামলায় না */
    switch (run->exit_reason) {
    case KVM_EXIT_IO:                   /* guest IN/OUT করেছে: ডিভাইস অনুকরণ — QEMU-র কাজ */
        if (run->io.direction == KVM_EXIT_IO_OUT && run->io.port == 0x3f8)
            putchar(*((char *)run + run->io.data_offset));
        break;
    case KVM_EXIT_MMIO:  /* ডিভাইসের মেমরি-ঠিকানা ছুঁয়েছে */  break;
    case KVM_EXIT_HLT:   return 0;
    default:             fprintf(stderr, "unhandled exit %d\n", run->exit_reason); return 1;
    }
}

খেয়াল করুন, অনেক exit (যেমন EPT-র page fault, CPUID, কিছু MSR) KVM kernel-এর ভেতরেই সেরে ফেলে, user space-এ ফেরেই না — তাতে খরচ কম। শুধু ডিভাইস-অনুকরণের মতো কাজে KVM_RUN ফেরে QEMU-তে। Cloud-এ QEMU-র বদলে আরও ছোট user-space VMM-ও ব্যবহার হয় (যেমন Firecracker, Cloud Hypervisor) — microVM নিয়ে পর্ব ৫২-তে।

অন্য OS-এ

PS> systeminfo | Select-String "Hyper-V"
Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.

$ sysctl kern.hv_support
kern.hv_support: 1

নিজের চোখে দেখুন — আমাদের কোড-চালানোর সার্ভার কি নিজেই VM?

এই কোর্সের runnable কোড চলে একটি অনলাইন সার্ভারের container-এ। নিচের script ভেতর থেকে কয়েকটি সূত্র দেখে: CPU-র flag, firmware-এর পরিচয় (DMI), /dev/kvm আর container-এর চিহ্ন। কোনো কিছু না পেলে script ভেঙে না পড়ে বার্তা দেয়।

echo "== 1. CPU model and virtualization flags =="
grep -m1 'model name' /proc/cpuinfo
echo "lines with vmx/svm: $(grep -c -E 'vmx|svm' /proc/cpuinfo)"
if grep -m1 -qw hypervisor /proc/cpuinfo; then
  echo "'hypervisor' flag: present (CPUID says: you are a guest)"
else
  echo "'hypervisor' flag: absent"
fi
echo "== 2. firmware (DMI) product name and vendor =="
cat /sys/class/dmi/id/product_name 2>/dev/null || echo "(not readable here)"
cat /sys/class/dmi/id/sys_vendor 2>/dev/null
echo "== 3. systemd-detect-virt =="
v=$(systemd-detect-virt 2>/dev/null); echo "vm/container: ${v:-(tool not available)}"
echo "== 4. /dev/kvm (can WE run VMs?) =="
ls -l /dev/kvm 2>/dev/null || echo "/dev/kvm: not present"
echo "== 5. container hints =="
[ -f /.dockerenv ] && echo "/.dockerenv exists" || echo "no /.dockerenv"
echo "process with PID 1: $(cat /proc/1/comm)"
dmesg 2>/dev/null | grep -i -m2 hypervisor || echo "(dmesg: no access or no match)"

== 1. CPU model and virtualization flags ==
model name	: AMD EPYC-Rome Processor
lines with vmx/svm: 0
'hypervisor' flag: present (CPUID says: you are a guest)
== 2. firmware (DMI) product name and vendor ==
[a cloud host's product name]
[a cloud host's company name]
== 3. systemd-detect-virt ==
vm/container: (tool not available)
== 4. /dev/kvm (can WE run VMs?) ==
/dev/kvm: not present
== 5. container hints ==
no /.dockerenv
process with PID 1: podman-init
(dmesg: no access or no match)

একই প্রশ্ন সরাসরি CPU-কে করা যায় CPUID instruction দিয়ে। Leaf 1-এর ECX register-এর bit 31 “hypervisor present” bit; থাকলে leaf 0x40000000 থেকে hypervisor নিজের নাম জানায়।

#include <stdio.h>
#include <string.h>
#include <cpuid.h>

static void vendor_at(unsigned int leaf) {      /* hypervisor's own CPUID leaves */
    unsigned int a, b, c, d;
    char v[13];
    __cpuid(leaf, a, b, c, d);
    memcpy(v, &b, 4); memcpy(v + 4, &c, 4); memcpy(v + 8, &d, 4);
    v[12] = '\0';
    printf("leaf 0x%x: vendor \"%s\", max leaf 0x%x\n", leaf, v, a);
}

int main(void) {
    unsigned int a, b, c, d;
    __get_cpuid(1, &a, &b, &c, &d);
    int hv = (c >> 31) & 1;                     /* leaf 1, ECX bit 31 */
    printf("leaf 1 ECX bit 31 (hypervisor present): %d\n", hv);
    printf("leaf 1 ECX bit 5  (Intel VMX visible) : %d\n", (c >> 5) & 1);
    if (__get_cpuid(0x80000001, &a, &b, &c, &d))
        printf("leaf 0x80000001 ECX bit 2 (AMD SVM)  : %d\n", (c >> 2) & 1);
    if (!hv) {
        printf("hypervisor: not found (bare metal, or a hidden hypervisor)\n");
        return 0;
    }
    printf("hypervisor: found\n");
    vendor_at(0x40000000);
    vendor_at(0x40000100);   /* KVM moves here when it also offers Hyper-V */
    return 0;
}

leaf 1 ECX bit 31 (hypervisor present): 1
leaf 1 ECX bit 5  (Intel VMX visible) : 0
leaf 0x80000001 ECX bit 2 (AMD SVM)  : 0
hypervisor: found
leaf 0x40000000: vendor "Microsoft Hv", max leaf 0x40000005
leaf 0x40000100: vendor "KVMKVMKVM", max leaf 0x40000101

৫ · মেমরির virtualization — shadow page table থেকে EPT

প্রসেসের জন্য OS অনুবাদ করে virtual → physical (পর্ব ৩২–৩৩)। VM-এ একটি স্তর বেশি। Guest OS নিজের page table বানায়: guest virtual (gVA) → guest physical (gPA). কিন্তু guest-এর “physical” মেমরি আসল নয় — hypervisor সেটিকে host-এর কোনো ফ্রেমে রেখেছে: gPA → host physical (hPA). আসল CPU-কে শেষ পর্যন্ত hPA দিতে হবে। দুটি উপায় এসেছে।

পর্ব ৩৩-এর “আরও গভীরে” অংশে সংখ্যাটি শুনেছিলেন — ২৪. এবার হিসাবটি ধাপে ধাপে দেখি। ধরুন guest আর host দুটিই x86-64-এর চার স্তরের page table ব্যবহার করে, কোনো cache বা TLB-তে কিছু নেই। মূল কথা: guest-এর টেবিলগুলো নিজেও guest-physical মেমরিতে থাকে, তাই প্রতিটি guest-টেবিল পড়ার আগে তার ঠিকানাটিকেও host-এর টেবিল দিয়ে অনুবাদ করতে হয়। এই হাঁটার নাম two-dimensional page walk.

1 gCR3 (gPA) → host walk → read guest L4 entry2 gL4 entry (gPA of L3) → host walk → read gL33 gL3 entry (gPA of L2) → host walk → read gL24 gL2 entry (gPA of L1) → host walk → read gL15 gL1 entry = data gPA → host walk → hPA6 read the data; TLB ← (gVA → hPA)

Huge page কেন VM-এ আরও জরুরি: host যদি 2 MiB page ব্যবহার করে, host-এর টেবিল এক স্তর কমে (m = ৩): (৪ + ১)(৩ + ১) − ১ = ১৯. দুই দিকেই 2 MiB হলে (৩ + ১)(৩ + ১) − ১ = ১৫. উল্টো দিকে, পাঁচ স্তরের paging (পর্ব ৩৩) দুই দিকে চালু থাকলে (৫ + ১)(৫ + ১) − ১ = ৩৫. তাই cloud-এ host-এর দিকে huge page প্রায় নিয়মিত ব্যবস্থা। আর tagged TLB-র কারণে (AMD-V-তে শুরু থেকেই ASID, Intel-এ ২০০৮-এর দিকে VPID) VM বদলালেও TLB পুরো খালি করতে হয় না।

৬ · I/O-র virtualization — অনুকরণ, virtio আর সরাসরি ডিভাইস

CPU আর মেমরির পরে আসে ডিস্ক, নেটওয়ার্ক কার্ড, GPU. এখানে তিনটি মূল পথ, আর প্রত্যেকটি গতি, নমনীয়তা আর নিরাপত্তার মধ্যে আলাদা আপস করে।

৭ · মেমরি overcommit, snapshot আর clone

৬৪ GB RAM-এর একটি সার্ভারে কি ৮ GB করে দশটি VM চালানো যায়? যায় — যদি সবাই একসাথে পুরো মেমরি না ছোঁয়। একে বলে VM-স্তরের overcommit, পর্ব ৩৫-এর প্রসেস-স্তরের overcommit-এরই বড় রূপ। ২০০২ সালে Carl Waldspurger-এর VMware ESX বিষয়ক বিখ্যাত গবেষণাপত্রে নিচের প্রথম দুটি কৌশল জনপ্রিয় হয়:

• Ballooning: Guest-এর ভেতরে একটি ছোট driver (“বেলুন”) থাকে। Host-এর মেমরি কম পড়লে hypervisor বেলুন ফোলাতে বলে — driver guest-এর কাছে মেমরি চেয়ে নেয় (guest নিজের নিয়মে cache ফেলে বা swap করে দেয়), আর সেই page-গুলো hypervisor-কে ফেরত দেয়। সুবিধা: কোন page ফেলা নিরাপদ, সেটা guest নিজেই সবচেয়ে ভালো জানে। এটি memory ballooning; Linux-এ virtio-balloon.
• Page sharing: দশটি VM-এ একই Ubuntu চললে অনেক page হুবহু এক (একই kernel কোড, একই library, শূন্যে ভরা page). Hypervisor বিষয়বস্তু মিলিয়ে এমন page-এর একটিমাত্র কপি রাখে, শুধু-পড়ার অনুমতিতে; কেউ লিখলে copy-on-write. Linux-এ এর নাম KSM (Kernel Same-page Merging). নিরাপত্তার দিক থেকে সতর্কতা: মেলানো page-এ লিখতে বেশি সময় লাগে — সেই সময় মেপে অন্য VM-এর তথ্যের আভাস পাওয়ার গবেষণা দেখানো হয়েছে, তাই অনেক cloud ভিন্ন গ্রাহকের মধ্যে এটি বন্ধ রাখে।
• Host-স্তরে swapping: শেষ উপায় — hypervisor নিজেই guest-এর page ডিস্কের swap-এ পাঠায়। Guest জানে না কোন page বাইরে, তাই সে হয়তো ঠিক সেই page-টিই নিজে swap করতে চাইবে — দুইবার ডিস্ক। এজন্য এটি ধীর, শেষ ভরসা।

$ cat /sys/kernel/mm/ksm/run /sys/kernel/mm/ksm/pages_sharing
1
183402                      # এতগুলো page একটি কপি ভাগ করে চলছে
$ virsh setmem web01 4G --live      # balloon দিয়ে চলন্ত VM-এর মেমরি 4 GiB-এ নামানো

Snapshot আর clone. VM-এর পুরো অবস্থা আসলে কয়েকটি ফাইল: ডিস্ক-image, কনফিগারেশন, আর (চাইলে) মেমরি আর ডিভাইসের অবস্থা। VM snapshot সেই মুহূর্তের ছবি; qcow2-এর মতো ফরম্যাটে এটি copy-on-write — পরের লেখাগুলো নতুন স্তরে যায়, পুরোনো ছবি অক্ষত থাকে (পর্ব ৪৪-এর COW file system-এর মতো চিন্তা)। ঝুঁকিপূর্ণ আপডেটের আগে snapshot, ভুল হলে ফিরে যাওয়া। Clone: একটি “golden image” থেকে অনেক VM, প্রতিটি নিজের পাতলা স্তর নিয়ে — শ্রেণিকক্ষের ৪০টি ল্যাব-VM কয়েক সেকেন্ডে। সতর্কতা: clone-এর ভেতরে hostname, SSH host key, machine-id, এমনকি random-সংখ্যার বীজও এক থেকে যায় — চালুর আগে সেগুলো নতুন করে বানাতে হয় (Linux-এ cloud-init বা virt-sysprep, Windows-এ sysprep). আর snapshot ব্যাকআপ নয় — একই ডিস্কে থাকে, ডিস্ক গেলে সবই যায়।

$ qemu-img snapshot -c before-upgrade web01.qcow2       # snapshot তৈরি
$ qemu-img create -f qcow2 -b golden.qcow2 -F qcow2 lab07.qcow2   # পাতলা clone
$ qemu-img info lab07.qcow2 | grep backing
backing file: golden.qcow2

৮ · Live migration — চলন্ত VM-কে অন্য যন্ত্রে সরানো

একটি সার্ভারের হার্ডওয়্যার বদলাতে হবে, কিন্তু তার ওপর চলছে একটি ব্যাংকের অনলাইন সেবার VM. বন্ধ করা যাবে না। Live migration-এ VM চলতে চলতেই তার মেমরি, CPU-র অবস্থা আর ডিভাইসের অবস্থা নেটওয়ার্ক দিয়ে আরেকটি যন্ত্রে সরানো হয়; ব্যবহারকারী বড়জোর এক মুহূর্তের থমকানো টের পান। ডিস্ক সাধারণত আগে থেকেই ভাগ করা স্টোরেজে (SAN/NAS, পর্ব ৪০) থাকে, তাই সরাতে হয় মূলত মেমরি। ২০০৩ সালে VMware-এর VMotion আর ২০০৫ সালে Xen-এর গবেষণাপত্র “Live Migration of Virtual Machines” এই পদ্ধতিকে মূলধারায় আনে।

ধাপগুলো: (১) গন্তব্যে একটি খালি VM তৈরি, (২) উৎসে dirty page-এর হিসাব রাখা শুরু (EPT-র dirty bit বা লেখা-নিষেধ করে), (৩) প্রথম রাউন্ডে পুরো মেমরি পাঠানো, (৪) প্রতি রাউন্ডে শুধু আগের রাউন্ডে বদলানো page পাঠানো, (৫) বাকি অংশ যথেষ্ট ছোট হলে stop-and-copy: VM থামিয়ে বাকি page আর CPU/ডিভাইসের অবস্থা পাঠানো, (৬) গন্তব্যে VM চালু, নেটওয়ার্কে ঘোষণা যে ঠিকানাটি এখন নতুন যন্ত্রে। থামা থেকে চালু পর্যন্ত সময়টি downtime.

হিসাব — কখন শেষ হবে

ধরুন মেমরি M, নেটওয়ার্কের গতি B, আর VM প্রতি সেকেন্ডে D পরিমাণ নতুন মেমরি “নোংরা” করে। প্রথম রাউন্ডে M পাঠাতে লাগে M/B সেকেন্ড, সেই সময়ে নোংরা হয় D × M/B. তাই প্রতিটি রাউন্ডের পরিমাণ আগেরটির r = D/B গুণ। r < 1 হলে পরিমাণ গুণোত্তর ধারায় কমে; মোট পাঠানো ডেটা প্রায় M/(1 − r), মোট সময় প্রায় M/(B − D). r ≥ 1 হলে কখনো কমবে না — dirty rate নেটওয়ার্কের গতির চেয়ে কম না হলে pre-copy শেষ হয় না. একটি পূর্ণ উদাহরণ: M = ৪০০০ MB (প্রায় ৪ GB), B = ১০০০ MB/s (মোটামুটি ১০ Gbit/s লিংক), D = ২০০ MB/s, আর ৫০ MB-এর নিচে নামলে থামানো হবে।

1 round 0: send all 4000 MB (VM keeps running)2 round 1: send pages dirtied in round 03 round 2: send pages dirtied in round 14 left ≤ 50 MB → pause VM, stop-and-copy5 resume on destination, announce new location

এবার একই হিসাব একটি calculator-এ, তিনটি ভিন্ন dirty rate দিয়ে। শর্ত: বাকি ৫০ MB-এর নিচে নামলে বা ৬টি রাউন্ড হয়ে গেলে থামানো হবে, আর এক রাউন্ডে মোট মেমরির বেশি নোংরা হতে পারে না।

// Pre-copy live migration: copy all memory, then re-copy what got dirty, until small enough
function migrate(memMB, dirtyMBps, bwMBps, stopMB = 50, maxRounds = 6) {
  console.log(`--- memory ${memMB} MB, dirty ${dirtyMBps} MB/s, link ${bwMBps} MB/s ---`);
  let toSend = memMB, total = 0, time = 0, round = 0;
  while (toSend > stopMB && round < maxRounds) {
    const t = toSend / bwMBps;                       // seconds this round takes
    const dirtied = Math.min(memMB, dirtyMBps * t);  // pages written meanwhile (max = all memory)
    console.log(`round ${round}: send ${toSend.toFixed(1).padStart(7)} MB in ${t.toFixed(3)} s,` +
                ` dirtied meanwhile ${dirtied.toFixed(1)} MB`);
    total += toSend; time += t; toSend = dirtied; round++;
  }
  const down = toSend / bwMBps;                      // stop-and-copy: the VM is paused
  total += toSend; time += down;
  console.log(`stop-and-copy: pause VM, send ${toSend.toFixed(1)} MB -> downtime ${(down * 1000).toFixed(0)} ms`);
  console.log(`total sent ${total.toFixed(1)} MB (${(total / memMB).toFixed(2)}x memory), total time ${time.toFixed(3)} s` +
              (round === maxRounds ? "  [round limit hit before reaching " + stopMB + " MB]" : ""));
}
migrate(4000, 200, 1000);    // dirty rate is 20% of bandwidth -> converges fast
migrate(4000, 1200, 1000);   // writes faster than the link -> never converges
migrate(4000, 600, 1000);    // 60%: shrinks slowly -> round limit, longer pause

--- memory 4000 MB, dirty 200 MB/s, link 1000 MB/s ---
round 0: send  4000.0 MB in 4.000 s, dirtied meanwhile 800.0 MB
round 1: send   800.0 MB in 0.800 s, dirtied meanwhile 160.0 MB
round 2: send   160.0 MB in 0.160 s, dirtied meanwhile 32.0 MB
stop-and-copy: pause VM, send 32.0 MB -> downtime 32 ms
total sent 4992.0 MB (1.25x memory), total time 4.992 s
--- memory 4000 MB, dirty 1200 MB/s, link 1000 MB/s ---
round 0: send  4000.0 MB in 4.000 s, dirtied meanwhile 4000.0 MB
round 1: send  4000.0 MB in 4.000 s, dirtied meanwhile 4000.0 MB
round 2: send  4000.0 MB in 4.000 s, dirtied meanwhile 4000.0 MB
round 3: send  4000.0 MB in 4.000 s, dirtied meanwhile 4000.0 MB
round 4: send  4000.0 MB in 4.000 s, dirtied meanwhile 4000.0 MB
round 5: send  4000.0 MB in 4.000 s, dirtied meanwhile 4000.0 MB
stop-and-copy: pause VM, send 4000.0 MB -> downtime 4000 ms
total sent 28000.0 MB (7.00x memory), total time 28.000 s  [round limit hit before reaching 50 MB]
--- memory 4000 MB, dirty 600 MB/s, link 1000 MB/s ---
round 0: send  4000.0 MB in 4.000 s, dirtied meanwhile 2400.0 MB
round 1: send  2400.0 MB in 2.400 s, dirtied meanwhile 1440.0 MB
round 2: send  1440.0 MB in 1.440 s, dirtied meanwhile 864.0 MB
round 3: send   864.0 MB in 0.864 s, dirtied meanwhile 518.4 MB
round 4: send   518.4 MB in 0.518 s, dirtied meanwhile 311.0 MB
round 5: send   311.0 MB in 0.311 s, dirtied meanwhile 186.6 MB
stop-and-copy: pause VM, send 186.6 MB -> downtime 187 ms
total sent 9720.1 MB (2.43x memory), total time 9.720 s  [round limit hit before reaching 50 MB]

৯ · Nested virtualization আর VM-এর নিরাপত্তা

VM-এর ভেতরে VM. Nested virtualization-এ একটি guest নিজেই hypervisor চালায় — যেমন cloud-এর VM-এ Android emulator বা অন্য VM চালিয়ে পরীক্ষা, বা Windows-এর VBS চালু থাকা একটি Windows guest. VT-x-এ “VM-এর ভেতরে VMX” সরাসরি নেই, তাই নিচের hypervisor (L0) ভেতরের hypervisor-এর (L1) প্রতিটি VMX instruction ধরে অনুকরণ করে, আর L1-এর VMCS-কে নিজের একটি VMCS-এ মিলিয়ে L2-কে চালায় — IBM-এর “Turtles” প্রকল্পের (২০১০) কাজ এর ভিত্তি। প্রতিটি L2 exit অনেকগুলো L1 exit-এ পরিণত হতে পারে, তাই খরচ বেশি; নতুন CPU-তে VMCS shadowing-এর মতো সহায়তা এই খরচ কমায়। আমাদের কোড-সার্ভারে vmx/svm না থাকার মানে এই সুবিধা সেখানে বন্ধ।

Isolation কতটা শক্ত? VM-এর সীমানা container-এর সীমানার চেয়ে মোটা, কারণ আক্রমণকারীকে guest-এর kernel পেরিয়েও hypervisor-এর ছোট interface (exit-এর ধরন, hypercall, অনুকরণ করা ডিভাইস) ভাঙতে হয়। তবু সীমানা অভেদ্য নয়। VM escape মানে guest-এর ভেতর থেকে hypervisor বা host-এ কোড চালাতে পারা — cloud-এর সবচেয়ে গুরুতর ঘটনা, কারণ একটি যন্ত্রে অনেক গ্রাহক। একটি পরিচিত উদাহরণ ২০১৫ সালের “VENOM” (CVE-2015-3456): QEMU-র অনুকরণ করা পুরোনো floppy-ডিস্ক controller-এর একটি buffer overflow, যা অনেক VM-এ ব্যবহার না হলেও ডিফল্টভাবে উপস্থিত ছিল। শিক্ষা আক্রমণের কৌশল নয়, প্রতিরক্ষার নকশা:

• অপ্রয়োজনীয় অনুকরণ করা ডিভাইস (floppy, পুরোনো sound card, USB) বাদ দেওয়া — ছোট device model = কম বাগের জায়গা
• QEMU-কে কম ক্ষমতায় চালানো: আলাদা user, seccomp ফিল্টার, আর SELinux/AppArmor-এর নীতি (libvirt-এর sVirt) — যাতে QEMU ভাঙলেও host-এর ক্ষতি সীমিত থাকে (পর্ব ৪৯-এর sandbox)
• Hypervisor, QEMU, host kernel আর CPU microcode নিয়মিত হালনাগাদ করা
• Passthrough-এ IOMMU চালু আছে কি না যাচাই করা (Linux-এ dmesg | grep -i -e DMAR -e IOMMU)
• ভিন্ন গ্রাহক বা ভিন্ন আস্থার VM একই physical core-এর SMT ভাইবোনে না বসানো, প্রয়োজনে KSM বন্ধ রাখা

Side channel. একই CPU, cache আর TLB ভাগ করা মানে এক VM অন্য VM-এর কাজের সূক্ষ্ম পার্শ্বপ্রতিক্রিয়া মাপতে পারে — side channel. ২০১৮ সালের Spectre, Meltdown আর বিশেষ করে L1TF (“Foreshadow”) cloud-এ গুরুতর ছিল; প্রতিকার হিসেবে hypervisor VM entry-তে L1 cache খালি করে, কোনো কোনো ক্ষেত্রে SMT বন্ধ করা হয়, আর ভিন্ন গ্রাহককে ভিন্ন core দেওয়া হয় (core scheduling). আরেকটি নতুন দিক confidential computing (AMD SEV, Intel TDX): VM-এর মেমরি CPU নিজেই এনক্রিপ্ট করে, যাতে hypervisor বা cloud-এর কর্মীরাও তা পড়তে না পারেন — হুমকির মডেল উল্টে যায়, hypervisor-ও তখন “অবিশ্বস্ত”।

১০ · AI-এর যুগে virtualization-এর কাজ

VM বানানো, KVM সেটআপ, “VT-x is disabled” error — এসব প্রশ্নে AI দ্রুত উত্তর দেয়। কিন্তু AI জানে না আপনার CPU Intel না AMD, আপনি Windows-এ Hyper-V চালু রেখেছেন কি না, বা আপনি নিজেই একটি cloud VM-এর ভেতরে কি না। তাই উত্তরগুলো প্রায়ই “ঠিক, কিন্তু ভুল যন্ত্রের জন্য”।

AI-এর virtualization-পরামর্শ যাচাইয়ের চেকলিস্ট

• কমান্ডটি আমার CPU-নির্মাতা (Intel/AMD/ARM), OS আর distro-র জন্য কি না মিলিয়েছি
• আমি নিজেই VM বা container-এর ভেতরে কি না আগে দেখে নিয়েছি (hypervisor flag, systemd-detect-virt)
• অনুমতির সমস্যায় chmod 666/777 নয়, group আর least privilege দিয়ে সমাধান করেছি
• সংখ্যা-নির্ভর উত্তর (walk-এর খরচ, migration-এর সময়, overcommit-এর অনুপাত) নিজে হাতে বা ছোট script-এ হিসাব করে মিলিয়েছি
• নিরাপত্তা-ব্যবস্থা (VBS, SELinux, IOMMU) বন্ধ করার আগে বিকল্প খুঁজেছি আর ঝুঁকি লিখে রেখেছি
• Production-এ বদলানোর আগে একটি পরীক্ষার VM-এ snapshot নিয়ে চালিয়ে দেখেছি — আর মনে রেখেছি snapshot ব্যাকআপ নয়