ভার্চুয়াল মেশিন ও হাইপারভাইজার

Virtual machines & hypervisors

৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

ভার্চুয়াল মেশিন (VM) হলো একটি সম্পূর্ণ কম্পিউটারের সফটওয়্যার-ভিত্তিক এমুলেশন, যা নিজের সম্পূর্ণ স্বাধীন গেস্ট OS চালাতে পারে।
হাইপারভাইজার হলো সেই সফটওয়্যার স্তর যা বাস্তব হার্ডওয়্যারকে একাধিক গেস্ট OS-এর মধ্যে ভাগ করে দেয় — ঠিক যেমন L27-এর MMU একটি OS-এর জন্য মেমরি অ্যাড্রেস ভার্চুয়ালাইজ করে, হাইপারভাইজার একাধিক OS-এর জন্য পুরো মেশিনটাই ভার্চুয়ালাইজ করে।
Type 1 (বেয়ার-মেটাল) হাইপারভাইজার সরাসরি হার্ডওয়্যারে চলে (দ্রুততর, ডেটা-সেন্টারে সাধারণ); Type 2 (হোস্টেড) একটি সাধারণ হোস্ট OS-এর উপর একটি অ্যাপ্লিকেশন হিসেবে চলে (সুবিধাজনক, ব্যক্তিগত ব্যবহারে সাধারণ)।
এই পাঠ OS-ইন্টারনালসের দৃষ্টিকোণ থেকে; ব্যবহারিক ক্লাউড প্রয়োগের জন্য দেখুন ../cloud-devops/ কোর্স।

এই পাঠে যা শিখবেন

ভার্চুয়াল মেশিন ঠিক কী, এবং এটি কীভাবে একটি সম্পূর্ণ স্বাধীন OS চালাতে সক্ষম হয়
হাইপারভাইজার কী এবং এটি কীভাবে L27-এর MMU-এর মতোই একটি "ভার্চুয়ালাইজেশন ইনডিরেকশন" — শুধু মেমরির বদলে পুরো মেশিনের জন্য
Type 1 (বেয়ার-মেটাল) বনাম Type 2 (হোস্টেড) হাইপারভাইজারের পার্থক্য, সুবিধা ও ব্যবহারিক ক্ষেত্র
Python দিয়ে দুই ধরনের হাইপারভাইজারের একটি তুলনামূলক সারণি তৈরি ও প্রিন্ট করা

১ · ভার্চুয়াল মেশিন — একটি সম্পূর্ণ কম্পিউটারের এমুলেশন

ভার্চুয়াল মেশিন (VM)Virtual Machineএকটি সম্পূর্ণ কম্পিউটারের সফটওয়্যার-ভিত্তিক এমুলেশন, যা নিজের সম্পূর্ণ, স্বাধীন গেস্ট অপারেটিং সিস্টেম চালাতে সক্ষম। হলো একটি সফটওয়্যার-ভিত্তিক নির্মাণ যা একটি সম্পূর্ণ কম্পিউটারের মতো আচরণ করে — এতটাই সম্পূর্ণ যে এটি তার নিজের, সম্পূর্ণ স্বাধীন গেস্ট OS চালাতে পারে, যেন সেটি প্রকৃত হার্ডওয়্যারেই চলছে।

এই ধারণাটি cloud-devops কোর্সের কন্টেইনার-বনাম-VM পাঠেও আসে (নেওয়া থাকলে), কিন্তু এখানে আমরা এটি OS-ইন্টারনালসের দিক থেকে দেখছি — VM বাস্তবে কীভাবে সম্ভব হয় তার প্রক্রিয়াটি।

২ · হাইপারভাইজার — L27-এর MMU-এর একটি স্কেল-আপ সংস্করণ

হাইপারভাইজারHypervisor / Virtual Machine Monitorযে সফটওয়্যার স্তর VM তৈরি ও পরিচালনা করে, বাস্তব হার্ডওয়্যারকে একাধিক গেস্ট OS-এর মধ্যে বণ্টন করে দেয়। (Virtual Machine Monitor) হলো সেই সফটওয়্যার স্তর যা VM তৈরি ও পরিচালনা করে — বাস্তব, ফিজিক্যাল হার্ডওয়্যারকে একাধিক গেস্ট OS-এর মধ্যে ভাগ করে দেয়, প্রতিটি গেস্ট বিশ্বাস করে সে-ই একমাত্র এবং পুরো মেশিনটির মালিক।

L27-এর সাথে সরাসরি প্যারালাল

L27-এ MMU একটি প্রসেসের লজিক্যাল অ্যাড্রেসকে ফিজিক্যাল অ্যাড্রেসে অনুবাদ করেছিল — প্রসেসটির নিজের দৃষ্টিভঙ্গি কখনো বদলাতে হয়নি, যদিও তার প্রকৃত মেমরি অবস্থান বদলে যেতে পারত। হাইপারভাইজার ঠিক এই একই ইনডিরেকশন-নীতিটাই আরও বড় স্কেলে প্রয়োগ করে — একটি নয়, বরং পুরো মেশিনটাকেই ভার্চুয়ালাইজ করে দেয়, যাতে একাধিক সম্পূর্ণ OS একই ফিজিক্যাল হার্ডওয়্যারে নিরাপদে সহাবস্থান করতে পারে, প্রত্যেকেই নিজেকে একমাত্র মালিক ভেবে।

৩ · Type 1 বনাম Type 2 হাইপারভাইজার

Type 1 · বেয়ার-মেটাল
সরাসরি ফিজিক্যাল হার্ডওয়্যারে চলে — নিচে আলাদা কোনো "হোস্ট OS" নেই। বেশি কার্যকর, ডেটা-সেন্টার/সার্ভার/ক্লাউড পরিবেশে সাধারণ।

Type 2 · হোস্টেড
একটি সাধারণ হোস্ট OS-এর উপর সাধারণ একটি অ্যাপ্লিকেশন হিসেবে চলে (যেমন Windows/Linux ডেস্কটপের ভেতরে একটি VM চালানো)। ব্যক্তিগত/ডেভেলপমেন্ট ব্যবহারে সুবিধাজনক, কিন্তু Type 1-এর তুলনায় বাড়তি ওভারহেড থাকে।

নিচের কোড সেলে এই দুই ধরনের হাইপারভাইজারের একটি সংক্ষিপ্ত তুলনামূলক সারণি তৈরি করা হলো।

Python

# Type 1 বনাম Type 2 হাইপারভাইজার -- তুলনামূলক সারণি

hypervisor_types = {
    "type1_bare_metal": {
        "runs_on": "সরাসরি ফিজিক্যাল হার্ডওয়্যার (আলাদা হোস্ট OS নেই)",
        "typical_use_case": "ডেটা-সেন্টার, সার্ভার, ক্লাউড ইনফ্রাস্ট্রাকচার",
        "overhead": "কম -- হোস্ট OS-এর কোনো বাড়তি স্তর নেই",
    },
    "type2_hosted": {
        "runs_on": "একটি সাধারণ হোস্ট OS-এর উপর একটি অ্যাপ্লিকেশন হিসেবে",
        "typical_use_case": "ব্যক্তিগত ব্যবহার, ডেভেলপমেন্ট/টেস্টিং, একটি ডেস্কটপের ভেতরে একাধিক OS",
        "overhead": "বেশি -- হোস্ট OS + হাইপারভাইজার, দুই স্তরের মধ্য দিয়ে যেতে হয়",
    },
}

print(f"{'ধরন':<20}{'কোথায় চলে':<45}{'সাধারণ ব্যবহার':<40}{'ওভারহেড'}")
for name, info in hypervisor_types.items():
    print(f"{name:<20}{info['runs_on']:<45}{info['typical_use_case']:<40}{info['overhead']}")

বাস্তব উদাহরণ (নাম-মাত্র উল্লেখ, বিস্তারিত ../cloud-devops/ কোর্সে) — Type 1-এর উদাহরণ: VMware ESXi, Microsoft Hyper-V (সার্ভার মোডে), Xen। Type 2-এর উদাহরণ: VMware Workstation, VirtualBox, Parallels Desktop — এগুলো সবই সাধারণ ডেস্কটপ OS-এর উপর একটি অ্যাপ্লিকেশন হিসেবেই ইনস্টল হয়।

মূল কথা · Key takeaway

VM ও হাইপারভাইজার আসলে OS-এর নিজস্ব "ইনডিরেকশনের মাধ্যমে অ্যাবস্ট্রাকশন" নীতির (L01, L27) একটি স্বাভাবিক সম্প্রসারণ — একটি প্রসেসকে যেমন তার নিজস্ব মেমরির ভ্রম দেওয়া যায় (পেজিং), তেমনি একটি সম্পূর্ণ OS-কেও তার নিজস্ব সম্পূর্ণ মেশিনের ভ্রম দেওয়া যায় (হাইপারভাইজার)। L50 দেখাবে ঠিক এই একই লক্ষ্য অর্জনের একটি সম্পূর্ণ ভিন্ন, হালকা-ওজনের উপায় — কন্টেইনার।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ডেটা-সেন্টার সাধারণত Type 1 হাইপারভাইজার ব্যবহার করে, কিন্তু একজন ডেভেলপার তার ব্যক্তিগত ল্যাপটপে সাধারণত Type 2 ব্যবহার করেন কেন?

ডেটা-সেন্টারে কর্মক্ষমতা (পারফরম্যান্স) ও দক্ষতা সবচেয়ে গুরুত্বপূর্ণ — Type 1 সরাসরি হার্ডওয়্যারে চলে বলে অতিরিক্ত হোস্ট-OS স্তরের ওভারহেড থাকে না, যা শত শত VM চালানোর সময় বিশাল পার্থক্য তৈরি করে। অন্যদিকে একজন ডেভেলপারের ল্যাপটপে মূল উদ্দেশ্য থাকে সুবিধা — তিনি তার স্বাভাবিক ডেস্কটপ OS-এই কাজ চালিয়ে যেতে চান এবং মাঝে মাঝে একটি ভিন্ন OS টেস্ট করতে চান, তাই একটি সাধারণ অ্যাপ্লিকেশন হিসেবে ইনস্টল করা যায় এমন Type 2 অনেক বেশি ব্যবহারিক, যদিও কিছুটা বাড়তি ওভারহেড থাকে।

প্র ০২ হাইপারভাইজারকে "L27-এর MMU-এর একটি স্কেল-আপ সংস্করণ" বলা হলো কেন? এই তুলনাটি কোথায় ভেঙে পড়ে (অর্থাৎ, দুটো ঠিক একরকম নয় এমন কোনো দিক আছে কি)?

উভয়ই একই মূলনীতি ব্যবহার করে — একটি ইনডিরেকশন স্তর যা "ব্যবহারকারীর" (প্রসেস বা OS) দৃষ্টিভঙ্গিকে বাস্তব ফিজিক্যাল রিসোর্স থেকে বিচ্ছিন্ন করে দেয়, যাতে একাধিক ব্যবহারকারী নিরাপদে রিসোর্স ভাগ করে নিতে পারে। তবে পার্থক্য হলো স্কেল ও জটিলতায় — MMU শুধু মেমরি-অ্যাড্রেস অনুবাদ করে (একটি তুলনামূলক সহজ, হার্ডওয়্যার-ত্বরিত গণনা), অথচ হাইপারভাইজারকে CPU, মেমরি, স্টোরেজ, নেটওয়ার্ক — সবকিছুর ভার্চুয়ালাইজেশন একসাথে সামলাতে হয়, এবং প্রতিটি গেস্ট OS-এর নিজস্ব কার্নেলকেও (যা নিজেই প্রিভিলেজড অপারেশন করতে চায়, L48 দ্রষ্টব্য) নিয়ন্ত্রণে রাখতে হয় — এটি অনেক বেশি জটিল একটি সমস্যা।

প্র ০৩ উপরের কোড সেলের সারণিতে যদি একটি তৃতীয় এন্ট্রি যোগ করতেন — "কন্টেইনার" (পরবর্তী পাঠ L50-এর বিষয়) — তার "overhead" মান কী হতো এবং কেন তা এই দুটোর চেয়ে ভিন্ন হবে বলে আপনার ধারণা?

কন্টেইনারের ওভারহেড এই দুটোর চেয়েও কম হতো, কারণ এটি হোস্ট OS-এর কার্নেলই সরাসরি শেয়ার করে — আলাদা কোনো গেস্ট OS বুট করার প্রয়োজন হয় না (Type 1/Type 2 উভয়ই একটি সম্পূর্ণ গেস্ট OS বুট করে)। এই পাঠের পরের অংশ (L50) ঠিক এই কারণেই কন্টেইনারকে "OS-লেভেল ভার্চুয়ালাইজেশন" বলে — এটি সম্পূর্ণ আলাদা মেশিনের ভ্রম তৈরি করে না, বরং একই কার্নেলের মধ্যে বিচ্ছিন্নতার ভ্রম তৈরি করে, যা অনেক সস্তা।

অনুশীলন

পরীক্ষা করুন: উপরের কোড সেলে hypervisor_types-এ একটি নতুন কী যোগ করুন — "type1_bare_metal"-এর জন্য "boot_time": "কয়েক সেকেন্ড (শুধু হাইপারভাইজার নিজেই, তারপর গেস্ট OS বুট)" — এবং প্রিন্ট লুপে এটি যোগ করে দেখুন আউটপুট কেমন হয়।

নতুন কী শুধু type1_bare_metal-এ যোগ করলে type2_hosted-এর ডিকশনারিতে এই কী থাকবে না — তাই লুপে সরাসরি info['boot_time'] অ্যাক্সেস করলে type2_hosted-এর জন্য KeyError আসবে। এটি ব্যবহারিকভাবে দেখায় কেন তুলনামূলক সারণির জন্য সব এন্ট্রিতে একই সেট কী থাকা প্রয়োজন, অথবা .get(key, "N/A")-এর মতো নিরাপদ অ্যাক্সেস ব্যবহার করা উচিত।
চিন্তা করুন: একটি গেস্ট OS যখন হাইপারভাইজারের অধীনে চলে, তখন সেই গেস্ট OS-এর নিজস্ব কার্নেল কি এখনও L48-এর অর্থে "রিং ০"-এ চলছে বলে বিশ্বাস করে? বাস্তবে তার প্রকৃত প্রিভিলেজ লেভেল কী হতে পারে?

হ্যাঁ — গেস্ট OS-এর কার্নেল এখনও বিশ্বাস করে সে রিং ০-এ চলছে (এটিই ভার্চুয়ালাইজেশনের পুরো বিভ্রমের সৌন্দর্য — গেস্ট OS-কে কোনো কোড পরিবর্তন করতে হয় না)। কিন্তু বাস্তবে হাইপারভাইজার প্রায়ই গেস্ট কার্নেলকে প্রকৃত রিং ০-এর চেয়ে কম প্রিভিলেজড একটি স্তরে চালায়, এবং যখনই গেস্ট কার্নেল সত্যিকারের প্রিভিলেজড অপারেশন করতে চায়, হাইপারভাইজার তা আটকে/অনুবাদ করে নিরাপদে সম্পন্ন করে দেয় — এই কারণেই L48-এ উল্লেখিত "রিং -১"-এর ধারণাটি আসে, যেখানে হাইপারভাইজার নিজেই আসল সর্বোচ্চ প্রিভিলেজ ধরে রাখে।