Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ১) — আপনার Windows আসলে কোথায় চলছে? হাইপারভাইজার ও পার্টিশন
· Go Komura · Windows, ভার্চুয়ালাইজেশন, Hyper-V, হাইপারভাইজার, SLAT, VMBus
Windows 11-এ System Information (msinfo32) খুললে “Virtualization-based security” ক্ষেত্রে প্রায়ই “Running” দেখা যায় — যে মেশিনে কখনো VM তৈরি করেননি সেখানেও।
তার অর্থ এই সত্য। সেই PC-এ হোস্ট Windows নিজেই ইতিমধ্যে একটি হাইপারভাইজারের উপর চলছে। “ভার্চুয়ালাইজেশন” আর শুধু Hyper-V Manager-এ VM তৈরি করা মানুষের প্রযুক্তি নয়। Windows 11-এ শর্ত পূরণ করা কনফিগারেশনে — যেমন সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টল — ভার্চুয়ালাইজেশন-ভিত্তিক নিরাপত্তা (VBS) ডিফল্টে চালু থাকে1, আর WSL2 ও Windows Sandbox দুটোই একই Windows হাইপারভাইজারের উপর গড়া। প্রতিদিন ব্যবহার করা Windows-এর তলায় ইতিমধ্যে আরও একটি সফটওয়্যার স্তর আছে।
এই সিরিজ, “Windows ভার্চুয়ালাইজেশনের গভীরতা”, সেই স্তরে কী ঘটে তা ভিত্তি থেকে অনুসরণ করে।
“Windows ভার্চুয়ালাইজেশনের গভীরতা” — সব ৩ পর্ব
১. পর্ব ১ (এই নিবন্ধ): হাইপারভাইজার ও পার্টিশন
Hyper-V চালু করলে হোস্ট Windows শেষ পর্যন্ত কোথায় চলে তা অনুসরণ করি।
২. পর্ব ২: কার্নেলও দেখতে পায় না এমন মেমরি — VBS, HVCI ও Credential Guard
অ্যাডমিনিস্ট্রেটরও কার্নেলও পড়তে পারে না এমন গোপন জিনিস Windows কোথায় রাখে তা অনুসরণ করি।
৩. পর্ব ৩: সেকেন্ডে বুট হওয়া ভার্চুয়াল মেশিন — WSL2, Windows Sandbox ও কন্টেইনার
মেমরি ও ইমেজ কীভাবে ভাগ হয় তা থেকে অনুসরণ করি কেন পূর্ণ VM ভারী হলেও WSL2 ও Sandbox হালকা।
পর্ব ১ যে প্রশ্নের উত্তর দেয় তা একটিই।
Hyper-V চালু করলে হোস্ট Windows শেষ পর্যন্ত কোথায় চলে?
উদ্দিষ্ট পাঠক সেই ডেভেলপার ও অপারেটর যারা Hyper-V, WSL2 বা Windows Sandbox ব্যবহার করেন এবং তলার কী চলছে তা যন্ত্র থেকে বুঝতে চান। পূর্বশর্ত x64 Windows 10/11 অথবা বর্তমান Windows Server (এই নিবন্ধের রিং, VT-x/AMD-V ও EPT/RVI আলোচনা x64 ধরে; Arm64 এক্সেপশন লেভেলের মতো ভিন্ন যন্ত্র ব্যবহার করে)। প্রয়োজনীয় পটভূমি কার্নেল মোড ও ইউজার মোডের পার্থক্য; VM অপারেশন অভিজ্ঞতা বা হাইপারভাইজার-ডেভেলপমেন্ট জ্ঞান দরকার নেই। কঠিনতা মাঝারি। CPU ভার্চুয়ালাইজেশন এক্সটেনশনের ধারণা ঢাকি, কিন্তু ইনস্ট্রাকশন-সেট বিস্তারে যাই না।
১. আগে উপসংহার
Hyper-V শুনলে মানুষ হয়তো ছবি তোলে “Windows-এর উপর বসা VM-চালানো সফটওয়্যার”। আসল কাঠামো উল্টো।
Hyper-V চালু করে রিবুট করার মুহূর্ত থেকে ফিজিক্যাল CPU ও মেমরি নিয়ন্ত্রণ করে হাইপারভাইজার, আর হোস্ট Windows তার উপর প্রথম, সুবিধাপ্রাপ্ত পার্টিশন — “রুট পার্টিশন” — হিসেবে চলে।
হাইপারভাইজার হার্ডওয়্যার ও OS-এর মাঝে বসা পাতলা সফটওয়্যার স্তর, যা “পার্টিশন” নামের বিচ্ছিন্ন চালনার পরিবেশ তৈরি করে এবং হার্ডওয়্যারে অ্যাক্সেস মধ্যস্থতা করে।2 হোস্ট Windows যেটিতে যায় সেটি রুট পার্টিশন; VM যেগুলিতে যায় সেগুলো চাইল্ড পার্টিশন। রুট পার্টিশন বিশেষভাবে ধরা হয় (ফিজিক্যাল ডিভাইসে সরাসরি অ্যাক্সেস আছে এবং ম্যানেজমেন্ট স্ট্যাক ধরে), কিন্তু ফিজিক্যাল CPU সরাসরি নিয়ন্ত্রণ করে না এই অর্থে চাইল্ড পার্টিশনেরই সমান অবস্থানে দাঁড়ায়।
flowchart TB
accTitle: Hyper-V চালু হওয়ার পর সামগ্রিক কাঠামো
accDescr: হাইপারভাইজার ফিজিক্যাল হার্ডওয়্যারের উপর সরাসরি বসে, আর তার উপরে হোস্ট Windows ধরা রুট পার্টিশন ও VM ধরা চাইল্ড পার্টিশন বসে
hw["ফিজিক্যাল হার্ডওয়্যার"] --> hv["হাইপারভাইজার"]
hv --> root["রুট পার্টিশন(হোস্ট Windows)"]
hv --> child1["চাইল্ড পার্টিশন(VM)"]
root -.-> stack["ভার্চুয়ালাইজেশন ম্যানেজমেন্ট স্ট্যাক ও ডিভাইস ড্রাইভার ধরে"]
চিত্র ১: Hyper-V “Windows-এর উপর VM সফটওয়্যার” নয় বরং Windows-এর তলায় যাওয়া স্তর, আর হোস্ট OS নিজেই রুট পার্টিশনের ভেতরে চলে।
ভাবতে পারেন, “চালু করার পর কিছু আলাদা মনে হয় না তো, এত বড় উল্টোপাল্টা সত্যিই ঘটেছে?” ঘটেছে। ঠিক সেজন্যই এই কাঠামো সাধারণত চোখে পড়ে না। এই নিবন্ধ এই একটি ছবি CPU, মেমরি ও ডিভাইস I/O — তিন অক্ষে খুলে দেখে।
২. CPU থেকে — রিংয়ের নিচে আরও একটি সুবিধা
২.১. রিং সুরক্ষার সংক্ষিপ্ত পুনরাবৃত্তি
x64 CPU-এর সুবিধা স্তর (রিং) আছে, আর Windows কার্নেল মোড রিং ০-এ ও ইউজার মোড রিং ৩-এ চালায়। অ্যাপ্লিকেশন হার্ডওয়্যার সরাসরি ছুঁতে পারে না কারণ রিং ৩ থেকে সুবিধাপ্রাপ্ত নির্দেশ চালানো যায় না।
তাহলে একই ফিজিক্যাল CPU-এ প্রত্যেকে রিং ০-এ চলা একাধিক OS কার্নেল নিরাপদে কীভাবে রাখবেন? প্রতিটি কার্নেল লেখা হয়েছে এই ধরে যে “আমিই CPU নিয়ন্ত্রণ করি”। সবগুলোকে রিং ০ দিলে তারা সংঘর্ষ করে; না দিলে চলবে না।
flowchart TB
accTitle: একাধিক OS কার্নেল রিং ০ চাওয়ার সমস্যা
accDescr: হোস্ট ও গেস্ট কার্নেল দুটোই রিং ০-এ পূর্ণ কর্তৃত্ব ধরে লেখা, তাই পুরোনো রিং সিঁড়ি একা একই ফিজিক্যাল CPU-এ তাদের নিরাপদে রাখতে পারে না
k1["হোস্ট কার্নেল(রিং ০ ধরে)"] --> want["ফিজিক্যাল CPU-এর নিয়ন্ত্রণ চায়"]
k2["গেস্ট কার্নেল(রিং ০ ধরে)"] --> want
want --> conflict["পুরোনো রিং এটা মেলাতে পারে না"]
conflict --> need["রিং ০-এর উপর মধ্যস্থতাকারী দরকার"]
চিত্র ২: রিং সিঁড়ি একটি OS ধরে তৈরি, তাই একাধিক কার্নেল রাখতে তার উপর আরও একটি সুবিধা দরকার।
২.২. ভার্চুয়ালাইজেশন এক্সটেনশন — হাইপারভাইজারের জন্য সংরক্ষিত মোড
এই সমস্যার সমাধান CPU-এর ভার্চুয়ালাইজেশন এক্সটেনশন (Intel VT-x/AMD-V)। Hyper-V এই বৈশিষ্ট্যযুক্ত প্রসেসর চায়।2 ভার্চুয়ালাইজেশন এক্সটেনশন পুরোনো রিং থেকে আলাদা অক্ষে “হাইপারভাইজারের চালনার মোড” ও “গেস্টের চালনার মোড” যোগ করে। এটি রিং ০-এর চেয়েও শক্তিশালী সুবিধা, কখনো ডাকনাম “রিং -১”।
- গেস্ট কার্নেল আগের মতোই রিং ০-এ চলতে থাকে। পুনর্লিখন দরকার নেই।
- তবে সেই রিং ০ “গেস্ট মোডের ভেতরের রিং ০”, আর পুরো ফিজিক্যাল CPU নিয়ন্ত্রণ করে না।
- গেস্ট হাইপারভাইজার হস্তক্ষেপ দরকার এমন নির্দিষ্ট কাজ (ইন্টারসেপ্ট হিসেবে কনফিগার করা নির্দেশ, অথবা এক্সেপশন বা ভায়োলেশন) ধরলে CPU স্বয়ংক্রিয়ভাবে নিয়ন্ত্রণ হাইপারভাইজারে সরায় (VM Exit)। হাইপারভাইজার সামলানো শেষ করলে গেস্টে ফেরে (VM Entry)। সাধারণ মেমরি অ্যাক্সেস SLAT অনুবাদ সফল থাকলে VM Exit ছাড়াই চলে যায়।
ইন্টারাপ্ট একইভাবে কাজ করে। পার্টিশন ফিজিক্যাল প্রসেসর সরাসরি ছুঁয় না; হাইপারভাইজার ইন্টারাপ্ট গ্রহণ করে প্রতিটি পার্টিশনে পাঠায়।2
flowchart TB
accTitle: গেস্ট চালনা ও VM Exit-এর প্রবাহ
accDescr: গেস্ট কার্নেল ও অ্যাপ গেস্ট মোডে রিং ০ ও রিং ৩-এ চলে; সাধারণ মেমরি অ্যাক্সেস SLAT অনুবাদ দিয়ে চলে যায়, আর কনফিগার করা ইন্টারসেপ্ট ও এক্সেপশন VM Exit ঘটিয়ে নিয়ন্ত্রণ হাইপারভাইজারে সরায়, যা পরে VM Entry দিয়ে গেস্টে ফেরে
guest["গেস্ট মোডে চলা(রিং-০ কার্নেলসহ)"] --> op{"হস্তক্ষেপ দরকার এমন কাজ?(কনফিগার করা ইন্টারসেপ্ট/এক্সেপশন)"}
op -->|না| cont["যেমন আছে তেমন চালান"]
op -->|হ্যাঁ| exitEv["VM Exit(CPU নিয়ন্ত্রণ সরায়)"]
exitEv --> hvp["হাইপারভাইজার সামলায়"]
hvp --> entry["VM Entry দিয়ে গেস্টে ফেরা"]
entry --> guest
চিত্র ৩: গেস্ট OS পুনর্লিখন ছাড়াই রিং ০-এ চলতে থাকে, আর CPU শুধু দরকারে হাইপারভাইজার ডাকে।
এই রাউন্ড ট্রিপ মেমরি সিরিজে অনুসরণ করা প্রবাহের সাথে অনেক মিলে — “পেজ ফল্টে কার্নেলে ঢোকা, তারপর একই নির্দেশে ফেরা”। CPU এক্সেপশন বা ট্রানজিশন যন্ত্র দিয়ে নিয়ন্ত্রণ আটকায়, উচ্চতর ব্যবস্থাপককে সিদ্ধান্ত নিতে দেয়, তারপর ফেরে। Windows-এর গভীরে এই আকৃতি বারবার দেখা যায়।
২.৩. Type 1 ও Type 2 — পার্থক্য কোথায় বসে
হাইপারভাইজার মোটাদাগে দুই ভাগে ভাগ: Type 1 (bare-metal), যা হার্ডওয়্যারের উপর সরাসরি চলে, আর Type 2 (hosted), যা হোস্ট OS-এর উপর চলে। Hyper-V Type 1।3 VirtualBox ও VMware Workstation (এককভাবে চালালে) Type 2 হিসেবে শ্রেণিবদ্ধ।
Type 1 শুনলে মানুষ কল্পনা করে “হোস্ট OS ছাড়া শুধু-সার্ভার কনফিগারেশন”, কিন্তু Hyper-V আলাদা। হোস্ট Windows মিলিয়ে যায় না — রুট পার্টিশনে “বাড়ি বদলায়”। Hyper-V চালু করে রিবুট করলে বুটের সময় হাইপারভাইজার আগে শুরু হয়, তারপর হোস্ট Windows তার উপর রুট পার্টিশন হিসেবে ওঠে।
flowchart TB
accTitle: Type 1 ও Type 2 হাইপারভাইজারের পার্থক্য
accDescr: Type 2-এ হোস্ট OS হার্ডওয়্যারের উপর বসে আর হাইপারভাইজার ও VM হোস্ট OS-এর উপর বসে, যেখানে Type 1 Hyper-V-এ হাইপারভাইজার হার্ডওয়্যারের উপর সরাসরি বসে আর হোস্ট OS নিজেই তার উপরের রুট পার্টিশনে যায়
subgraph t2 ["Type 2(hosted)"]
hw2["হার্ডওয়্যার"] --> hostos["হোস্ট OS"]
hostos --> hv2["হাইপারভাইজার"]
hv2 --> vm2["VM"]
end
subgraph t1 ["Type 1(Hyper-V)"]
hw1["হার্ডওয়্যার"] --> hv1["হাইপারভাইজার"]
hv1 --> root1["রুট পার্টিশন(হোস্ট OS)"]
hv1 --> vm1["VM"]
end
vm2 ~~~ hw1
চিত্র ৪: Type 2-এ হাইপারভাইজার হোস্ট OS-এর উপর বসে, যেখানে Type 1 Hyper-V-এ ক্রম উল্টো আর হোস্ট OS নিজেই এক ধাপ নিচের স্তরে বসে।
বুট টাইমলাইনে দেখলে চালু করার সময় যে পরিবর্তন ঘটে তা এমন।
flowchart TB
accTitle: Hyper-V চালু হওয়ার পর বুট ক্রম
accDescr: পাওয়ার-অনের পর বুটের সময় হাইপারভাইজার আগে শুরু হয়, তারপর হোস্ট Windows তার উপর রুট পার্টিশন হিসেবে ওঠে, আর VM, VBS ইত্যাদি তার পরে শুরু হয়
poweron["পাওয়ার অন ও বুট শুরু"] --> bhv["হাইপারভাইজার আগে শুরু"]
bhv --> broot["হোস্ট Windows রুট পার্টিশন হিসেবে শুরু"]
broot --> blater["VM, VBS, WSL2 ইত্যাদি তার উপর শুরু"]
broot -.-> feel["ব্যবহারকারীর অভিজ্ঞতা অপরিবর্তিত"]
চিত্র ৫: ক্রমের উল্টোপাল্টা লগন স্ক্রিন দেখা যাওয়ার আগেই শেষ, আর হোস্ট OS শুরু থেকেই হাইপারভাইজারের উপর ওঠে।
৩. পার্টিশন — আইসোলেশনের একক
৩.১. শুধু রুট পার্টিশনের যে ভূমিকা আছে
পার্টিশন হাইপারভাইজার যে লজিক্যাল আইসোলেশন একক দেয়।2 তবে সব পার্টিশন সমান নয়। কিছু জিনিস শুধু রুট পার্টিশনের আছে।
- ফিজিক্যাল ডিভাইসে সরাসরি অ্যাক্সেস। ডিস্ক, NIC, GPU ইত্যাদির ডিভাইস ড্রাইভার হাইপারভাইজারে নয়, রুট পার্টিশনের ভেতরের Windows-এ থাকে। Windows Server-এর Hyper-V-এ নির্দিষ্ট PCIe ডিভাইস সরাসরি চাইল্ড পার্টিশনে দেওয়ার কনফিগারেশন আছে (Discrete Device Assignment); সেক্ষেত্রে রুট সেই ডিভাইস ছেড়ে দেয় (ক্লায়েন্ট Windows-এ এটি নেই)।4
- ভার্চুয়ালাইজেশন ম্যানেজমেন্ট স্ট্যাক। VM তৈরি, শুরু ও থামানো শাসন করা VMMS (Virtual Machine Management Service), আর প্রতি-VM ওয়ার্কার প্রক্রিয়া (vmwp.exe) রুট পার্টিশনের ইউজার মোডে চলে।5 এগুলো Hyper-V-এর VM ম্যানেজমেন্ট বৈশিষ্ট্যের অংশ, তাই শুধু VBS বা WSL2-এর জন্য হাইপারভাইজার চলা হোস্টে অনুপস্থিত থাকতে পারে।
- চাইল্ড পার্টিশন তৈরির অধিকার। রুট পার্টিশন হাইপারকল API (হাইপারভাইজারে কল করার ইন্টারফেস) দিয়ে চাইল্ড পার্টিশন তৈরি করে।2
এই ডিজাইনের কারণ আছে। প্রতিটি ডিভাইস ড্রাইভার হাইপারভাইজারের ভেতরে রাখলে হাইপারভাইজার বিশাল হয় আর বাগ ও আক্রমণ প্রবেশপথ বাড়ে। হাইপারভাইজার নিজেকে CPU ও মেমরি মধ্যস্থতার ন্যূনতম কাজে আটকে রাখে, আর ডিভাইসের যত্ন রুট পার্টিশনের Windows-এর হাতে রাখে। এই ভূমিকা ভাগই Hyper-V-কে পাতলা রাখে।
flowchart TB
accTitle: রুট পার্টিশন ও চাইল্ড পার্টিশনের ভূমিকা ভাগ
accDescr: রুট পার্টিশন ভার্চুয়ালাইজেশন ম্যানেজমেন্ট স্ট্যাক ও ফিজিক্যাল ডিভাইস ড্রাইভার ধরে হাইপারকল দিয়ে চাইল্ড পার্টিশন তৈরি করে; চাইল্ড পার্টিশন সাধারণত শুধু ভার্চুয়াল ডিভাইস দেখে, আর Windows Server-এ Discrete Device Assignment-এ নির্ধারিত ডিভাইসে সরাসরি অ্যাক্সেস করে
subgraph rootp ["রুট পার্টিশন"]
vmms["VMMS ও ওয়ার্কার প্রক্রিয়া"]
drv["ফিজিক্যাল ডিভাইস ড্রাইভার"]
end
subgraph childp ["চাইল্ড পার্টিশন"]
gos["গেস্ট OS"]
vdev["সাধারণ কনফিগে শুধু ভার্চুয়াল ডিভাইস দেখা যায়"]
end
vmms -->|হাইপারকল দিয়ে তৈরি ও পরিচালনা| childp
hv2["হাইপারভাইজার(শুধু CPU ও মেমরি মধ্যস্থতা)"] --- rootp
hv2 --- childp
চিত্র ৬: ডিভাইস ড্রাইভার ও ম্যানেজমেন্ট স্ট্যাক রুট-পার্টিশন পাশে রাখাই হাইপারভাইজারকে পাতলা রাখে।
৩.২. চাইল্ড পার্টিশন থেকে দেখা জগৎ
চাইল্ড পার্টিশনের গেস্ট OS সাধারণ ভার্চুয়াল-ডিভাইস কনফিগারেশনে ফিজিক্যাল হার্ডওয়্যার সরাসরি দেখতে পায় না (একমাত্র ব্যতিক্রম আগের অনুচ্ছেদে বলা Windows Server-এ Discrete Device Assignment দিয়ে দেওয়া ডিভাইস)। যা দেখতে পায় তা ভার্চুয়াল প্রসেসর, নিজের বলে মনে হওয়া মেমরি স্পেস, আর ভার্চুয়াল ডিভাইস। ভার্চুয়াল ডিভাইসে অনুরোধ VMBus বা হাইপারভাইজার দিয়ে রুট পার্টিশনে ফরোয়ার্ড হয়।2 অন্যদিকে CPU-সময় বরাদ্দ ও SLAT দিয়ে মেমরি অনুবাদ রুট না গিয়ে হাইপারভাইজার সরাসরি সামলায়। রুট যা মধ্যস্থতা করে তা ডিভাইস I/O, সব ফিজিক্যাল সম্পদ নয়।
flowchart TB
accTitle: চাইল্ড পার্টিশন থেকে দেখা জগৎ
accDescr: গেস্ট OS যা দেখে তা ভার্চুয়াল প্রসেসর, পার্টিশন-নিজস্ব মেমরি স্পেস ও ভার্চুয়াল ডিভাইস; ভার্চুয়াল ডিভাইসে অনুরোধ VMBus ইত্যাদি দিয়ে রুট পার্টিশনে ফরোয়ার্ড হয়, CPU সময় ও মেমরি অনুবাদ হাইপারভাইজার সরাসরি সামলায়, আর Windows Server-এ Discrete Device Assignment কনফিগে শুধু নির্ধারিত ডিভাইসে সরাসরি অ্যাক্সেস হয়
gos2["গেস্ট OS(চাইল্ড)"] --> vcpu["ভার্চুয়াল প্রসেসর"]
gos2 --> rest{"মেমরি নাকি ডিভাইস?"}
rest --> gpa2["নিজস্ব মেমরি স্পেস"]
rest --> vdev2["ভার্চুয়াল ডিভাইস"]
vdev2 --> rootx["রুটে ফরোয়ার্ড"]
rootx -.-> vbus["VMBus ইত্যাদি দিয়ে"]
gos2 -.-> phys2["ফিজিক্যাল CPU, RAM, ডিভাইস"]
phys2 -.-> hid["সরাসরি দেখা যায় না"]
phys2 -.-> dda2["DDA: নির্ধারিত ডিভাইস"]
dda2 -.-> ddaN["Windows Server"]
vcpu ~~~ phys2
চিত্র ৭: সাধারণ ভার্চুয়াল-ডিভাইস কনফিগে গেস্ট যা দেখে সব ভার্চুয়াল জানালা আর ফিজিক্যালে যাওয়ার পথ মধ্যস্থতাকারী দিয়ে; শুধু Windows Server-এ DDA দিয়ে দেওয়া ডিভাইস ব্যতিক্রম।
এখানে গুরুত্বপূর্ণ: হোস্ট Windows-এ চলা অ্যাপের কাছে এই কাঠামো প্রায় স্বচ্ছ। Win32 API কল ও পেজ-ফল্ট হ্যান্ডলিং আগের মতোই রুট পার্টিশনের ভেতরের Windows কার্নেল প্রক্রিয়া করে। হাইপারভাইজার শুধু কনফিগার করা ইন্টারসেপ্ট বা এক্সেপশন ধরলে হস্তক্ষেপ করে।
৪. মেমরি থেকে — অ্যাড্রেস অনুবাদে আরও একটি স্তর যোগ হয়
৪.১. তিন ধরনের অ্যাড্রেস
মেমরি সিরিজের পর্ব ১-এ ভার্চুয়াল অ্যাড্রেস পেজ টেবিল দিয়ে ফিজিক্যাল অ্যাড্রেসে অনুবাদ হওয়ার প্রবাহ অনুসরণ করেছিলাম (“ভার্চুয়াল অ্যাড্রেস ফিজিক্যাল RAM হওয়ার মুহূর্ত”)। ভার্চুয়ালাইজড পরিবেশে সেই অনুবাদের তলায় আরও একটি স্তর যোগ হয়, আর তিন ধরনের অ্যাড্রেস থাকে।
| অ্যাড্রেস | সংক্ষেপ | কে পরিচালনা করে |
|---|---|---|
| গেস্ট ভার্চুয়াল অ্যাড্রেস | GVA | গেস্ট OS পেজ টেবিল |
| গেস্ট ফিজিক্যাল অ্যাড্রেস | GPA | গেস্ট OS যা “ফিজিক্যাল” বলে বিশ্বাস করে |
| সিস্টেম ফিজিক্যাল অ্যাড্রেস | SPA | হাইপারভাইজার (RAM-এর আসল অবস্থান) |
গেস্ট OS নিজের পেজ টেবিল দিয়ে GVA থেকে GPA অনুবাদ করে। তবে গেস্ট যে GPA দেখে তা আসল ফিজিক্যাল অ্যাড্রেস নয়; প্রতিটি পার্টিশনের নিবেদিত নিজস্ব মেমরি স্পেস।2 GPA-কে RAM-এর আসল অবস্থানে (SPA) ম্যাপ করা হাইপারভাইজারের কাজ।
৪.২. SLAT — হার্ডওয়্যারে দুই-স্তর অনুবাদ
এই দ্বিতীয়-স্তর অনুবাদ শুধু সফটওয়্যারে করলে হাইপারভাইজারকে প্রতিটি গেস্ট পেজ-টেবিল আপডেট এক এক করে অনুসরণ করতে হয়, যা পারফরম্যান্সের দিক থেকে বাস্তবসম্মত নয়। তাই CPU হার্ডওয়্যারে দ্বিতীয়-স্তর অনুবাদ টেবিল হাঁটার যন্ত্র দেয়। সেটাই SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) ও AMD RVI তার বাস্তবায়ন। বর্তমান Hyper-V SLAT-সক্ষম ৬৪-বিট প্রসেসর চায়।4
flowchart TB
accTitle: SLAT দিয়ে দুই-স্তর অ্যাড্রেস অনুবাদ
accDescr: গেস্ট ভার্চুয়াল অ্যাড্রেস গেস্ট OS পেজ টেবিল দিয়ে গেস্ট ফিজিক্যাল অ্যাড্রেসে অনুবাদ হয়, তারপর হাইপারভাইজার-পরিচালিত SLAT দিয়ে সিস্টেম ফিজিক্যাল অ্যাড্রেসে আরও অনুবাদ হয়ে আসল RAM-এ পৌঁছায়
gva["গেস্ট ভার্চুয়াল অ্যাড্রেস(GVA)"] -->|গেস্ট OS পেজ টেবিল| gpa["গেস্ট ফিজিক্যাল অ্যাড্রেস(GPA)"]
gpa -->|"SLAT(EPT/RVI অনুবাদ টেবিল)"| spa["সিস্টেম ফিজিক্যাল অ্যাড্রেস(SPA)"]
spa --> ram["ফিজিক্যাল RAM"]
gpa -.-> note["গেস্ট শুধু ফিজিক্যাল বলে বিশ্বাস করে এমন স্তর"]
চিত্র ৮: গেস্টের পেজ টেবিলের তলায় হাইপারভাইজার-পরিচালিত আরও একটি অনুবাদ টেবিল বসে, আর CPU দুটোই হার্ডওয়্যারে হাঁটে।
SLAT শুধু VM চালনার দক্ষতার জন্য থাকা বৈশিষ্ট্য নয়। পর্ব ২-এ দেখা VBS “প্রতি সুবিধা স্তরে আলাদা SLAT অনুবাদ টেবিল রাখা যায়” এই গুণকে নিরাপত্তা সীমানার উপাদান হিসেবে ব্যবহার করে। কার্নেলও দেখতে পায় না এমন মেমরি তৈরি করা যায় কারণ হাইপারভাইজার এই দ্বিতীয়-স্তর অনুবাদ ধরে। এটি পুরো সিরিজের সুতো হয়ে ওঠে, তাই একটি বিষয় মনে রাখুন: “অনুবাদ টেবিলের মালিক হাইপারভাইজার”।
৫. ডিভাইস I/O থেকে — VMBus ও দুই ধরনের ডিভাইস
৫.১. ইমিউলেটেড ডিভাইসের সীমা
চাইল্ড পার্টিশনকে ডিভাইস দেখানোর ক্লাসিক উপায় সফটওয়্যারে আসল হার্ডওয়্যার (যেমন পুরোনো IDE কন্ট্রোলার) পুরোপুরি নকল করা। গেস্ট OS-এর ইনবক্স ড্রাইভার হুবহু কাজ করে বলে সামঞ্জস্য বেশি, কিন্তু গেস্ট I/O পোর্ট ধরলেই VM Exit হয়, আর পারফরম্যান্স স্কেল হয় না।
flowchart TB
accTitle: ইমিউলেটেড ডিভাইসে I/O কেন ধীর
accDescr: গেস্ট প্রতিবার I/O পোর্ট চালালে নিয়ন্ত্রণ VM Exit দিয়ে হাইপারভাইজার পাশে সরে, ডিভাইস সফটওয়্যারে নকল হয়, গেস্টে ফেরানো হয়, তাই রাউন্ড ট্রিপ বারবার হয় ও ধীর
gio["গেস্ট I/O পোর্ট চালায়"] --> vex["VM Exit ঘটে"]
vex --> emu2["ডিভাইস সফটওয়্যারে ইমিউলেট হয়"]
emu2 --> back["VM Entry দিয়ে গেস্টে ফেরা"]
back -->|পরের পোর্ট অপারেশনে পুনরাবৃত্তি| gio
চিত্র ৯: একটি ডিস্ক অ্যাক্সেসের পেছনে এই রাউন্ড ট্রিপ অনেকবার চলে, আর সামঞ্জস্যের দাম পারফরম্যান্সে মেটে।
৫.২. VMBus ও VSP/VSC — ভার্চুয়ালাইজেশনের জন্য ডিজাইন করা দ্রুত পথ
তাই Hyper-V-এর ভার্চুয়ালাইজেশন ধরে তৈরি “সিন্থেটিক ডিভাইস” যন্ত্র আছে। তিনটি চরিত্র।2
- VMBus: পার্টিশনের মধ্যে লজিক্যাল যোগাযোগ চ্যানেল। শেয়ার্ড মেমরি ব্যবহার করা উচ্চ-গতির আন্তঃপার্টিশন যোগাযোগ দেয়।3
- VSP (Virtualization Service Provider): রুট-পার্টিশন পাশে থাকা সার্ভিস, চাইল্ড থেকে ডিভাইস অনুরোধ গ্রহণ করে রুট পাশের ডিভাইস/ব্যাকএন্ড স্ট্যাকে সেতু করে। অনুরোধ ফিজিক্যাল ডিভাইসে পৌঁছাতে পারে, অথবা ভার্চুয়াল ডিস্ক বা ভার্চুয়াল সুইচের মতো হোস্ট-পাশের ব্যাকএন্ড সামলাতে পারে।
- VSC (Virtualization Service Consumer): চাইল্ড-পার্টিশন পাশের গেস্ট OS-এ যাওয়া সিন্থেটিক ডিভাইস ড্রাইভার। VMBus দিয়ে VSP-এ অনুরোধ পাঠায়।
গেস্ট OS স্টোরেজ অনুরোধ উদাহরণ নিলে প্রবাহ এমন। গেস্ট অ্যাপের WriteFile গেস্ট কার্নেলের I/O স্ট্যাক নেমে তলায় (আসল হার্ডওয়্যারের বদলে) VSC-এ পৌঁছায়। VSC অনুরোধ VMBus-এ রেখে রুট পার্টিশনের VSP-এ দেয়, আর VSP অনুরোধ রুট-পাশের I/O স্ট্যাকে প্রবাহিত করে। ভার্চুয়াল-ডিস্ক (VHDX) কনফিগে এই লেখা হোস্টের VHDX ফাইলে লেখা হিসেবে সামলানো হয় এবং শেষে ফিজিক্যাল ডিস্কে পৌঁছায়। এই পথকে Enlightened I/O (ভার্চুয়ালাইজেশন-সচেতন I/O) বলা হয়, আর ডিভাইস-ইমিউলেশন স্তর এড়িয়ে দক্ষতা বাড়ায়।2
flowchart TB
accTitle: সিন্থেটিক ডিভাইসের I/O পথ
accDescr: চাইল্ড পার্টিশনের অ্যাপের I/O অনুরোধ গেস্ট কার্নেল দিয়ে VSC-এ পৌঁছায়, VMBus পেরিয়ে রুট পার্টিশনের VSP-এ যায়, আর VSP যে রুট-পাশের I/O স্ট্যাকে সেতু করে সেখানে ফিজিক্যাল ডিভাইস ড্রাইভার দিয়ে আসল ডিভাইসে পৌঁছাতে পারে, অথবা ভার্চুয়াল ডিস্ক বা ভার্চুয়াল সুইচের মতো হোস্ট-পাশের ব্যাকএন্ড সামলাতে পারে
app["চাইল্ড পার্টিশনের অ্যাপ"] --> gk["গেস্ট কার্নেল I/O স্ট্যাক"]
gk --> vsc["VSC(সিন্থেটিক ডিভাইস ড্রাইভার)"]
vsc -->|VMBus| vsp["VSP(রুট-পার্টিশন পাশ)"]
vsp --> rio["রুট-পাশের I/O স্ট্যাক"]
rio --> pdrv["ফিজিক্যাল ডিভাইস ড্রাইভার"]
rio --> hb["হোস্ট-পাশের ব্যাকএন্ড(ভার্চুয়াল ডিস্ক, ভার্চুয়াল সুইচ ইত্যাদি)"]
pdrv --> dev["ফিজিক্যাল ডিভাইস"]
চিত্র ১০: সিন্থেটিক ডিভাইসে গেস্ট I/O VMBus দিয়ে রুট পার্টিশনে পেরোয় এবং রুট-পাশের স্ট্যাক দিয়ে আসল ডিভাইস বা হোস্ট-পাশের ব্যাকএন্ডে পৌঁছায়।
অর্থাৎ VM-এর ডিস্ক I/O বা নেটওয়ার্কিং দ্রুত কি না শুধু গেস্ট পাশ নয়, রুট-পার্টিশন পাশের I/O স্ট্যাক ও ডিভাইস ড্রাইভারের অবস্থার উপরও নির্ভর করে। VM পারফরম্যান্স সমস্যা অনুসন্ধানে হোস্ট-পাশের পর্যবেক্ষণ অপরিহার্য কারণ পথ আসলে হোস্ট দিয়ে যায়।
flowchart TB
accTitle: ইমিউলেটেড ডিভাইস বনাম সিন্থেটিক ডিভাইস
accDescr: ইমিউলেটেড ডিভাইস আসল হার্ডওয়্যার নকল করে ইনবক্স গেস্ট ড্রাইভার চালায় কিন্তু ধীর; সিন্থেটিক ডিভাইস VMBus ধরে তৈরি নিবেদিত ড্রাইভার এবং দ্রুত
dev2{"চাইল্ড পার্টিশনকে দেখানো ডিভাইস"} --> emu["ইমিউলেটেড ডিভাইস"]
dev2 --> syn["সিন্থেটিক ডিভাইস"]
emu -.-> emuP["আসল হার্ডওয়্যার নকল; সামঞ্জস্য আগে"]
emuP -.-> emuC["প্রতি I/O-তে হস্তক্ষেপ; ধীর"]
syn -.-> synP["VMBus ঘিরে ডিজাইন; দ্রুত"]
synP -.-> synC["গেস্টে মিল ড্রাইভার দরকার"]
চিত্র ১১: দুই ধরনের ভার্চুয়াল ডিভাইসের মধ্যে ইমিউলেটেড ডিভাইস OS ইনস্টলের ঠিক পরে সামঞ্জস্য বহন করে, আর সিন্থেটিক ডিভাইস দৈনন্দিন ব্যবহারে পারফরম্যান্স বহন করে।
৬. কখনো VM ব্যবহার না করলেও এটা অন্য কারও সমস্যা নয় কেন
এখন পর্যন্ত কাঠামো “VM দাঁড় করানো মানুষের গল্প” মনে হতে পারে। তবে শুরুতে যেমন বলা, বর্তমান Windows-এ হাইপারভাইজার দৈনন্দিন জীবনের অংশ।
- ভার্চুয়ালাইজেশন-ভিত্তিক নিরাপত্তা (VBS)। Windows হাইপারভাইজার ব্যবহার করে বিচ্ছিন্ন পরিবেশ তৈরি করে সেখানে নিরাপত্তা বৈশিষ্ট্য রাখে। Windows 11-এ সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টলের মতো শর্ত পূরণ হলে ডিফল্টে চালু।1 বিস্তারিত পর্ব ২-এ।
- WSL2। হালকা ইউটিলিটি VM-এর ভেতরে আসল Linux কার্নেল চালায়।6
- Windows Sandbox। হাইপারভাইজার-বিচ্ছিন্ন ডিসপোজেবল Windows পরিবেশ।7 দুটোই পর্ব ৩-এ।
flowchart TB
accTitle: একই হাইপারভাইজারে বসা দৈনন্দিন বৈশিষ্ট্য
accDescr: শুধু Hyper-V VM নয়, ক্লিন ইনস্টলের মতো শর্ত পূরণ করা ডিভাইসে ডিফল্টে চালু VBS, প্লাস WSL2 ও Windows Sandbox, সব একই Windows হাইপারভাইজারের উপর গড়া
base["Windows হাইপারভাইজার"] --> f1["Hyper-V VM"]
base --> f2["VBS(ক্লিন ইনস্টল ইত্যাদিতে ডিফল্টে চালু)"]
base --> f3["WSL2"]
base --> f4["Windows Sandbox"]
f2 -.-> daily["কখনো VM ব্যবহার না করা PC-এও কেন চলে"]
চিত্র ১২: ভিত্তি একটি, আর এই ছবিতেই “ভার্চুয়ালাইজেশন VM ব্যবহারকারীদের গল্প” অনুমান ভেঙে যায়।
ব্যবহারে মানুষ প্রায়ই আরও একটি জিনিসে পা দেয়: তৃতীয়-পক্ষ ভার্চুয়ালাইজেশন সফটওয়্যারের সাথে সহাবস্থান। হাইপারভাইজার CPU-এর ভার্চুয়ালাইজেশন এক্সটেনশন একচেটিয়া ব্যবহার করে বলে Windows হাইপারভাইজার চলা পরিবেশে VirtualBox ইত্যাদি পুরোনো পথে (নিজে CPU-এর ভার্চুয়ালাইজেশন এক্সটেনশন ব্যবহার করে) চলতে পারে না। এর জন্য Windows Hypervisor Platform নামের পাবলিক API দেওয়া আছে, আর তৃতীয়-পক্ষ ভার্চুয়ালাইজেশন স্ট্যাক Windows হাইপারভাইজারের উপর বসে চলতে পারে।8 বর্তমান VirtualBox/VMware এই যন্ত্রের জন্য WSL2-এর সাথে সহাবস্থান করতে পারে, কিন্তু মোড বদলের সাথে আসা পারফরম্যান্স ও বৈশিষ্ট্যের পার্থক্য কখনো “Hyper-V (বা VBS) চালু করার পর ভার্চুয়ালাইজেশন সফটওয়্যার আলাদা আচরণ করতে শুরু করেছে” হিসেবে দেখা যায়।
flowchart TB
accTitle: CPU ভার্চুয়ালাইজেশন এক্সটেনশনের মালিক কে, আর তৃতীয়-পক্ষ ভার্চুয়ালাইজেশন সফটওয়্যারের পথ
accDescr: Windows হাইপারভাইজার চলতে থাকলে সে CPU ভার্চুয়ালাইজেশন এক্সটেনশন একচেটিয়া ধরে; WHP সমর্থন করা তৃতীয়-পক্ষ ভার্চুয়ালাইজেশন সফটওয়্যার Windows Hypervisor Platform দিয়ে তার উপর চলে, আর WHP সমর্থন না করা বাস্তবায়ন চলতে পারে না বা বৈশিষ্ট্য-সীমিত হয়
vt["CPU ভার্চুয়ালাইজেশন এক্সটেনশন(VT-x/AMD-V)"] --> hvon{"Windows হাইপারভাইজার চলছে?"}
hvon -->|না| direct["তৃতীয়-পক্ষ সফটওয়্যার সরাসরি ব্যবহার করতে পারে"]
hvon -->|হ্যাঁ| own["হাইপারভাইজারের একচেটিয়া ব্যবহার"]
own --> whp["Windows Hypervisor Platform"]
whp --> third["WHP-সক্ষম তৃতীয়-পক্ষ সফটওয়্যার তার উপর চলে"]
third -.-> nowhp["অক্ষম বাস্তবায়ন চলে না, বা সীমিত"]
চিত্র ১৩: ভার্চুয়ালাইজেশন এক্সটেনশনের মালিক একজন, আর হাইপারভাইজার চলতে থাকলে সহাবস্থান করতে পারে শুধু পাবলিক API (WHP) সমর্থন করা তৃতীয়-পক্ষ সফটওয়্যার।
৭. নিজে দেখুন
নিজের মেশিনে হাইপারভাইজার চলছে কি না নিশ্চিত করা যায়।
প্রথমে অ্যাডমিনিস্ট্রেটর সুবিধা ছাড়াই চালানো যায় এমন যাচাই।
# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent
# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
-ClassName Win32_DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus
VirtualizationBasedSecurityStatus VBS চালনার অবস্থা সংখ্যায় ফেরায় (২ মানে “Running”)।9
একটি সতর্কতা। HypervisorPresent শুধু বলে “আমরা হাইপারভাইজারের উপর চলছি কি না”; রুট ও চাইল্ড আলাদা করে না। VM-এর ভেতরের Windows-এ চালালেও চাইল্ড পার্টিশন হিসেবে True ফেরায়। ফিজিক্যাল PC-এর Windows-এ True হলে সেই Windows রুট পার্টিশনের ভেতরে — চালনার পরিবেশের সাথে মিলিয়ে পড়ুন।
এরপর Command Prompt থেকে ক্লাসিক।
systeminfo
আউটপুটের শেষে “Hyper-V Requirements” দেখুন। হাইপারভাইজার এখনও না চলা মেশিনে আলাদা আলাদা প্রয়োজন — SLAT সমর্থন, ভার্চুয়ালাইজেশন এক্সটেনশন চালু কি না ইত্যাদি — তালিকা হয়। হাইপারভাইজার ইতিমধ্যে চলা মেশিনে প্রয়োজনের বদলে একটি লাইন আসে: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”4 সেই একটি লাইন তাই এই বিবৃতি যে আপনার Windows কোনো হাইপারভাইজারের উপর চলছে। HypervisorPresent-এর মতো ফিজিক্যাল PC-এ “রুট পার্টিশনের ভেতরে”, অথবা VM-এর ভেতরে “চাইল্ড পার্টিশন হিসেবে” পড়তে হয়।
systeminfo-এর প্রতিটি প্রয়োজন “Yes” হলেও তা শুধু হার্ডওয়্যার পাশ প্রস্তুত মানে। Hyper-V বৈশিষ্ট্য নিজে Pro, Enterprise ও Education সংস্করণে পাওয়া যায়, Home-এ নয়।10
GUI-তে msinfo32-এর “System Summary”-এর নিচে “Virtualization-based security” সারি দেখুন। লক্ষ করুন, টাস্ক ম্যানেজারের CPU প্যানে “Virtualization: Enabled” শুধু দেখায় ফার্মওয়্যারে ভার্চুয়ালাইজেশন এক্সটেনশন চালু কি না, যা হাইপারভাইজার চলছে কি না থেকে আলাদা তথ্য।
flowchart TB
accTitle: হাইপারভাইজার চলছে কি না কীভাবে যাচাই করবেন
accDescr: systeminfo হাইপারভাইজার শনাক্ত হয়েছে বললে আপনি হাইপারভাইজারে চলছেন(ফিজিক্যাল PC-এ রুট পার্টিশনের ভেতরে); Hyper-V Requirements তালিকা এলে এখনও চলছে না তাই SLAT, VM Monitor Mode Extensions ও DEP-এর মতো প্রতিটি প্রয়োজন যাচাই করুন, কিন্তু সব Yes শুধু হার্ডওয়্যার পাশ প্রস্তুত মানে আর Hyper-V বৈশিষ্ট্যের সংস্করণ প্রয়োজনও আছে
start2["systeminfo চালান"] --> q1{"Requirements ক্ষেত্র?"}
q1 -->|Detected| running["হাইপারভাইজার চলছে"]
running -.-> runN["রুটের ভেতরে"]
runN -.-> runN2["ফিজিক্যাল PC-এ"]
q1 -->|Listed| notyet["এখনও চলছে না"]
notyet --> q2{"সব প্রয়োজন Yes?"}
q2 -->|সব Yes| can["হার্ডওয়্যার পাশ প্রস্তুত"]
can -.-> ed["Pro / Ent / Edu দরকার"]
q2 -->|কিছু No| uefi["UEFI/BIOS আইটেম যাচাই"]
চিত্র ১৪: systeminfo-এর “Hyper-V Requirements” ক্ষেত্র চালনার-অবস্থা যাচাই ও পূর্বশর্ত যাচাই দুটোই করে।
৮. ব্যবহারে এড়ানোর তিনটি ভুলপাঠ
৮.১. “আমরা Hyper-V চালু করিনি, তাই আমাদের PC-এর সাথে ভার্চুয়ালাইজেশনের কোনো যোগ নেই”
Hyper-V বৈশিষ্ট্য (ম্যানেজমেন্ট টুল ও VM চালনার পরিবেশ) চালু না করলেও VBS চালু থাকলে Windows হাইপারভাইজার চলে। ড্রাইভার সামঞ্জস্য সমস্যা, পারফরম্যান্স পরীক্ষা, বা তৃতীয়-পক্ষ ভার্চুয়ালাইজেশন সফটওয়্যারের সমস্যা অনুসন্ধান করলে বৈশিষ্ট্য চালু কি না নয় — HypervisorPresent ও VBS চালনার অবস্থা যাচাই করুন।
৮.২. “টাস্ক ম্যানেজার বলে ‘Virtualization: Enabled’, তাই Hyper-V চলছে”
সেই প্রদর্শন ফার্মওয়্যার সেটিং (VT-x/AMD-V পাওয়া যায় কি না) সম্পর্কে। হাইপারভাইজারের চালনার অবস্থা systeminfo-এর “A hypervisor has been detected” থেকে বিচার করুন। উল্টোদিকে টাস্ক ম্যানেজার “Disabled” বললে Hyper-V বা WSL2ও চালু করা যায় না, তাই আগে UEFI/BIOS সেটিংস যাচাই করুন।
flowchart TB
accTitle: সহজে গুলিয়ে ফেলা তিনটি যাচাই
accDescr: টাস্ক ম্যানেজারের Virtualization ক্ষেত্র ফার্মওয়্যার সেটিং দেখায়, Windows Features তালিকা ইনস্টল অবস্থা দেখায়, আর systeminfo বা HypervisorPresent চালনার অবস্থা দেখায়; প্রত্যেকে আলাদা প্রশ্নের উত্তর দেয়
q3{"কোন প্রশ্ন?"}
q3 --> fw{"ফার্মওয়্যার নাকি Windows?"}
q3 --> c3["হাইপারভাইজার চলছে?"]
fw --> a3["ফার্মওয়্যার এক্সটেনশন?"]
fw --> b3["Hyper-V বৈশিষ্ট্য চালু?"]
a3 -.-> a3t["টাস্ক ম্যানেজার CPU প্যান"]
b3 -.-> b3t["Windows Features UI"]
c3 -.-> c3t["systeminfo"]
c3 -.-> c3tp["HypervisorPresent"]
চিত্র ১৫: এগুলো তিনটি স্বাধীন প্রশ্ন, আর কোনো একটি প্রদর্শন থেকে অন্য দুটো অনুমান করা ভুলপাঠ।
৮.৩. “VM ধীর হলে তা গেস্ট-OS সমস্যা”
সিন্থেটিক-ডিভাইস I/O VMBus পেরিয়ে রুট পার্টিশনের VSP-এ যায় এবং রুট-পাশের ডিভাইস/ব্যাকএন্ড স্ট্যাক (ফিজিক্যাল ড্রাইভার, প্লাস ভার্চুয়াল-সুইচ ও ভার্চুয়াল-ডিস্ক প্রক্রিয়া) দিয়ে যায়। শুধু গেস্টের ভেতরের কাউন্টার দেখলে হোস্ট-পাশের স্টোরেজ বা NIC-এ বসা বাধা পাবেন না। VM পারফরম্যান্স সমস্যার নীতি দুই পাশ থেকে পর্যবেক্ষণ: গেস্ট ও হোস্ট (রুট পার্টিশন)।
৯. সারসংক্ষেপ
- Hyper-V চালু করলে হাইপারভাইজার হার্ডওয়্যারের উপর সরাসরি চলে আর হোস্ট Windows রুট পার্টিশন হিসেবে চলে।2
- গেস্ট OS কার্নেল রিং ০-এ চলতে থাকে, আর শুধু ইন্টারসেপ্ট হিসেবে কনফিগার করা কাজ ও এক্সেপশন VM Exit দিয়ে হাইপারভাইজারে যায়। সাধারণ মেমরি অ্যাক্সেস SLAT অনুবাদ দিয়ে চলে যায়।
- শুধু রুট পার্টিশন ফিজিক্যাল ডিভাইস ড্রাইভার ও ভার্চুয়ালাইজেশন ম্যানেজমেন্ট স্ট্যাক ধরে, আর হাইপারকল দিয়ে চাইল্ড পার্টিশন তৈরি করে।2
- মেমরি GVA→GPA→SPA দুই-স্তর অনুবাদ হয়ে যায়, আর দ্বিতীয় স্তর SLAT (EPT/RVI) হার্ডওয়্যারে সামলায়। বর্তমান Hyper-V SLAT চায়।4
- ডিভাইস I/O-তে VSC→VMBus→VSP সিন্থেটিক-ডিভাইস পথই প্রধান, আর পারফরম্যান্স হোস্ট-পাশের I/O স্ট্যাকের উপরও নির্ভর করে।2
- Windows 11-এ ক্লিন ইনস্টলের মতো শর্ত পূরণ করা ডিভাইসে VBS ডিফল্টে চালু থাকায় কখনো VM ব্যবহার না করা PC-এও হাইপারভাইজার চলা অস্বাভাবিক নয়।1 চালনার অবস্থা
HypervisorPresentও systeminfo দিয়ে নিশ্চিত করা যায়।
পর্ব ১-এর বড় ছবি এই একটি ডায়াগ্রামে ঘনীভূত।
flowchart TB
accTitle: পর্ব ১-এর বড় ছবি
accDescr: হাইপারভাইজার রুট পার্টিশন ও চাইল্ড পার্টিশনের তলায় বসে; CPU ভার্চুয়াল প্রসেসর শিডিউল করে বরাদ্দ হয়(VM Exit শুধু কনফিগার করা ইন্টারসেপ্ট ও এক্সেপশনে), মেমরি দুই-স্তর SLAT অনুবাদে মধ্যস্থতা হয়, সিন্থেটিক-ডিভাইস I/O VMBus দিয়ে ফরোয়ার্ড হয়ে রুট পার্টিশনের VSP সামলায়, আর ইমিউলেটেড ডিভাইস ও Discrete Device Assignment-এর অন্য পথ আছে
up["রুট + চাইল্ড পার্টিশন"] --> hvS["হাইপারভাইজার"]
hvS --> cpuS["CPU: VP শিডিউল"]
hvS --> memS["মেমরি: SLAT"]
cpuS -.-> cpuN["ইন্টারসেপ্টে VM Exit"]
memS -.-> memN["দুই-স্তর অনুবাদ"]
memS ~~~ devS
devS["ডিভাইস: VMBus I/O"] --> vspS["রুট-পাশের VSP সামলায়"]
devS -.-> devN["ইমিউলেটেড / DDA: অন্য"]
চিত্র ১৬: CPU শিডিউলিং ও মেমরি অনুবাদ হাইপারভাইজার সরাসরি সামলায় (হস্তক্ষেপেই শুধু VM Exit), আর সিন্থেটিক-ডিভাইস I/O VMBus-এর ওপারে রুট পার্টিশন (VSP) মধ্যস্থতা করে।
পর্ব ২-এ চলবে, “কার্নেলও দেখতে পায় না এমন মেমরি — VBS, HVCI ও Credential Guard“।
এই নিবন্ধের সুতো — হাইপারভাইজার SLAT অনুবাদ টেবিল ধরে — তুলে Windows কীভাবে “অ্যাডমিনিস্ট্রেটরও কার্নেলও পড়তে পারে না এমন মেমরি” তৈরি করে তা অনুসরণ করি।
সম্পর্কিত নিবন্ধ
- Windows মেমরির গভীরতা (পর্ব ১) — ভার্চুয়াল অ্যাড্রেস ফিজিক্যাল RAM হওয়ার মুহূর্ত: শুরু থেকে শেষ পর্যন্ত একটি পেজ ফল্ট
- Windows-এর “মেমরি ব্যবহার” আসলে কী বোঝায়? — Working Set, Private Bytes, Commit ও পেজ ফাইল সঠিকভাবে পড়া
- Windows Sandbox দিয়ে অ্যাপ যাচাই কীভাবে দ্রুত করবেন
- Windows প্রসেসর শিডিউলিং সেটিংস - ব্যাকগ্রাউন্ড সার্ভিস ও P/E কোর
সম্পর্কিত পরামর্শ ক্ষেত্র
KomuraSoft LLC Windows অ্যাপ্লিকেশনের যাচাই-পরিবেশ ডিজাইন, ভার্চুয়ালাইজড পরিবেশে পারফরম্যান্স অনুসন্ধান, আর ড্রাইভার ও পেরিফেরাল সামঞ্জস্য সমস্যার বিশ্লেষণ সামলায়।
- Windows অ্যাপ্লিকেশন ডেভেলপমেন্ট
- বাগ অনুসন্ধান ও মূল কারণ বিশ্লেষণ
- বিদ্যমান অ্যাসেটের পুনর্ব্যবহার ও মাইগ্রেশন
- যোগাযোগ করুন
তথ্যসূত্র
-
Microsoft Learn, Silicon assisted security। VBS হার্ডওয়্যার ভার্চুয়ালাইজেশন ব্যবহার করে Secure Kernel-কে সাধারণ OS থেকে আলাদা করা, এবং Windows 11-এর নতুন ইনস্টলে পূর্বশর্ত পূরণ করা ডিভাইসে VBS ও HVCI ডিফল্টে চালু হওয়া সম্পর্কে। ↩ ↩2 ↩3
-
Microsoft Learn, Hyper-V Architecture। হাইপারভাইজার আইসোলেশনের একক হিসেবে পার্টিশন দেওয়া; রুট পার্টিশন হাইপারকল API দিয়ে চাইল্ড পার্টিশন তৈরি করা; পার্টিশন ফিজিক্যাল প্রসেসরে সরাসরি অ্যাক্সেস ছাড়া নিজস্ব ভার্চুয়াল মেমরি স্পেসে চলা; VMBus, VSP, VSC ও Enlightened I/O-এর ভূমিকা; এবং হার্ডওয়্যার ভার্চুয়ালাইজেশন এক্সটেনশন (Intel VT/AMD-V) দরকার হওয়া সম্পর্কে। ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
-
Microsoft Learn, Hyper-V architecture (Performance Tuning)। Hyper-V Type 1 হাইপারভাইজার হওয়া, রুট পার্টিশন ফিজিক্যাল I/O ডিভাইস মালিকানা করা, এবং VMBus শেয়ার্ড মেমরি ব্যবহার করা উচ্চ-পারফরম্যান্স আন্তঃপার্টিশন যোগাযোগ দেওয়া সম্পর্কে। ↩ ↩2
-
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server। SLAT-সক্ষম ৬৪-বিট প্রসেসর ও VM Monitor Mode Extensions দরকার হওয়া; systeminfo-এর “Hyper-V Requirements” ক্ষেত্রে প্রয়োজন পূরণ হয়েছে নিশ্চিত করা যায়; হাইপারভাইজার চলতে থাকলে “A hypervisor has been detected” দেখানো; এবং Discrete Device Assignment নির্দিষ্ট ডিভাইস সরাসরি চাইল্ড পার্টিশনে দিতে পারা সম্পর্কে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview। VMMS (Virtual Machine Management Service) চাইল্ড পার্টিশনের VM-এর অবস্থা পরিচালনা করা, আর প্রতিটি VM-এর জন্য রুট পার্টিশনের ইউজার মোডে ওয়ার্কার প্রক্রিয়া (VMWP) শুরু হওয়া সম্পর্কে। ↩
-
Microsoft Learn, Comparing WSL Versions। WSL2 হালকা ইউটিলিটি VM-এর ভেতরে আসল Linux কার্নেল চালানো, এবং বর্তমান VMware ও VirtualBox-এর সাথে একসঙ্গে ব্যবহারের সতর্কতা সম্পর্কে। ↩
-
Microsoft Learn, Windows Sandbox architecture। Windows Sandbox কন্টেইনার প্রযুক্তি ও হাইপারভাইজারের আইসোলেশন মিলিয়ে হালকা Windows পরিবেশ হওয়া সম্পর্কে। ↩
-
Microsoft Learn, Windows Hypervisor Platform। তৃতীয়-পক্ষ ভার্চুয়ালাইজেশন স্ট্যাক Windows হাইপারভাইজারের উপর পার্টিশন তৈরি ও পরিচালনা করতে পারার জন্য ইউজার-মোড API দেওয়া সম্পর্কে। ↩
-
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers। Win32_DeviceGuard ক্লাসের VirtualizationBasedSecurityStatus দিয়ে VBS (ভার্চুয়াল সিকিউর মোড)-এর চালনার অবস্থা নিশ্চিত করা যায় সম্পর্কে। ↩
-
Microsoft Learn, Install Hyper-V। Hyper-V Windows 10/11 Pro বা Enterprise ইত্যাদিতে চালু করা যায়, Home সংস্করণে ইনস্টল করা যায় না সম্পর্কে। ↩
সম্পর্কিত নিবন্ধ
কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।
Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ৩) — সেকেন্ডে বুট হওয়া ভার্চুয়াল মেশিন: WSL2, Windows Sandbox ও কন্টেইনার এত হালকা কেন
WSL2 ও Windows Sandbox সেকেন্ডে শুরু হয়ে এত হালকা মনে হয় কেন? এই নিবন্ধ ডায়নামিক বেস ইমেজ ও ডাইরেক্ট ম্যাপ থেকে ডায়নামিক মেমরি বরাদ্দ...
Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ২) — কার্নেলও দেখতে পায় না এমন মেমরি: VBS, HVCI ও Credential Guard কীভাবে কাজ করে
সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টলে VBS ডিফল্টে চালু থাকে এবং হাইপারভাইজার ও SLAT দিয়ে কার্নেলের চেয়ে শক্তিশালী আইসোলেশন তৈরি কর...
Win32 থ্রেড পুল API — CreateThreadpoolWork দিয়ে থ্রেড তৈরি না করে কনকারেন্সি
নেটিভ কোডে চারদিকে CreateThread ডাকছেন? এই নিবন্ধ Vista-তে নতুন করে সাজানো Win32 থ্রেড পুল API ব্যাখ্যা করে — work, timer, wait ও io চারট...
নেমড পাইপ ব্যবহারিকভাবে — ডিজাইন থেকে নিরাপত্তা পর্যন্ত Windows-এর মানক IPC
Windows-এর মানক আন্তঃপ্রক্রিয়া যোগাযোগ নেমড পাইপের ব্যবহারিক গাইড। প্রাথমিক উৎস থেকে এই নিবন্ধ বাইট ও মেসেজ মোডের পছন্দ, একাধিক ক্লায়েন...
এলাকার নাম দিয়ে অনুসন্ধানে দৃশ্যমান হোন — ছোট ও মাঝারি ব্যবসার জন্য লোকাল SEO-এর ব্যবহারিক গাইড (এলাকা পৃষ্ঠা ও Google Business Profile)
সেসব ছোট ও মাঝারি ব্যবসার জন্য যাদের সাইট "এলাকার নাম + খাত" খুঁজলে দেখা যায় না। এই নিবন্ধ লোকাল SEO ঠিক করার ক্রম সাজায়: Google Busine...
সম্পর্কিত বিষয়
এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।
Windows-এর প্রযুক্তিগত বিষয়
Windows ডেভেলপমেন্ট, বাগ তদন্ত ও বিদ্যমান সম্পদ ব্যবহারের প্রবেশদ্বার।
এই বিষয়ের সাথে সম্পর্কিত সেবা
নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।
Windows অ্যাপ ডেভেলপমেন্ট
ব্যবসায়িক অ্যাপ, ডিভাইস ইন্টিগ্রেশন ও যোগাযোগ টুল, চাহিদা থেকে ডেভেলপমেন্ট পর্যন্ত।
প্রায়শ জিজ্ঞাসিত প্রশ্ন
এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।
- Hyper-V চালু করলে হোস্ট Windows আসলে কোথায় চলে?
- হাইপারভাইজার ফিজিক্যাল CPU ও মেমরি কীভাবে বরাদ্দ হবে তার সরাসরি নিয়ন্ত্রণ নেয়, আর হোস্ট Windows রুট পার্টিশন নামের বিশেষ পার্টিশনের ভেতরে চলে। ফিজিক্যাল ডিভাইসের নিয়ন্ত্রণ সাধারণত রুট-পার্টিশন পাশের ড্রাইভার সামলায়। রুট পার্টিশন ডিভাইস ড্রাইভার ও ভার্চুয়ালাইজেশন ম্যানেজমেন্ট স্ট্যাক ধরে, কিন্তু ফিজিক্যাল CPU-এর মালিকানা হাইপারভাইজারের।
- টাস্ক ম্যানেজারের "Virtualization: Enabled" মানে কি Hyper-V চলছে?
- না। সেই প্রদর্শন দেখায় CPU-এর ভার্চুয়ালাইজেশন এক্সটেনশন (Intel VT-x/AMD-V) ফার্মওয়্যারে চালু আছে কি না। হাইপারভাইজার সত্যিই চলছে কি না দেখতে systeminfo-তে "A hypervisor has been detected" খুঁজুন, অথবা Win32_ComputerSystem.HypervisorPresent যাচাই করুন।
- কখনো VM তৈরি না করেও হাইপারভাইজার কেন চলছে?
- Windows 11-এ শর্ত পূরণ করা ডিভাইসে — যেমন সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টল — ভার্চুয়ালাইজেশন-ভিত্তিক নিরাপত্তা (VBS) ডিফল্টে চালু থাকে, আর VBS Windows হাইপারভাইজারের উপর গড়া। WSL2 বা Windows Sandbox ব্যবহার করলেও একই কথা। VM ব্যবহারের সাথে কোনো যোগ না রেখেই হাইপারভাইজার চলা অস্বাভাবিক নয়।
- SLAT কী, আর Hyper-V-এর জন্য কেন দরকার?
- SLAT (Second Level Address Translation) সেই যন্ত্র যাতে CPU গেস্ট ফিজিক্যাল অ্যাড্রেসকে আসল ফিজিক্যাল অ্যাড্রেসে অনুবাদ করে; Intel EPT ও AMD RVI তার বাস্তবায়ন। না থাকলে হাইপারভাইজারকে সফটওয়্যারে অনুবাদ টেবিল রাখতে হতো, যা পারফরম্যান্সের দিক থেকে বাস্তবসম্মত নয়, তাই বর্তমান Hyper-V এটিকে কঠোর প্রয়োজন হিসেবে ধরে।
- Hyper-V চালু করলে VirtualBox ও VMware কি কাজ বন্ধ করবে?
- হাইপারভাইজার CPU-এর ভার্চুয়ালাইজেশন এক্সটেনশন একচেটিয়া ব্যবহার করে বলে তৃতীয়-পক্ষ হাইপারভাইজার পুরোনো পথে চলতে পারে না। তবে বর্তমান VirtualBox ও VMware-এর একটি মোড আছে যা Windows হাইপারভাইজারের উপর চলে (Windows Hypervisor Platform দিয়ে), তাই সাম্প্রতিক সংস্করণগুলো সহাবস্থান করতে পারে।