আপনার VPS কি Firecracker microVM চালাতে পারবে?

আপনার VPS কি Firecracker microVM চালাতে পারে?

আপনার VPS-এ Firecracker microVM চালানো যাবে শুধু যদি এতে /dev/kvm থাকে। Firecracker হলো KVM (kernel-based virtual machine)-এর ওপর তৈরি একটি VMM (virtual machine monitor)। KVM হলো Linux-এর ভেতরের virtualisation layer, এবং এটি CPU থেকে virtualisation instruction প্রয়োজন। VPS-এ এই instruction তখনই পাওয়া যায়, যখন provider সেগুলো আপনার guest-এ pass through করে। অধিকাংশ plan-এ তা করা হয় না।

তাই প্রথম প্রশ্নটি কোন microVM tool install করবেন, তা নয়। আপনি যে machine-এর জন্য ইতিমধ্যে অর্থ দিচ্ছেন, সেটি আদৌ একটি microVM host করতে পারে কি না, সেটিই প্রথমে জানতে হবে। এটি hosting-এর বিষয়। প্রায় এক মিনিটেই এর উত্তর পাওয়া যায়।

কিছু ইনস্টল করার আগে /dev/kvm পরীক্ষা করুন

VPS-এই এই তিনটি কমান্ড চালান।

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

microVM চালাতে সক্ষম একটি মেশিনের আউটপুট এভাবে দেখা যায়:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

প্রথম লাইনটি KVM device node নির্দেশ করে, যার মালিক kvm group। দ্বিতীয় লাইনটি জানায় যে এই মেশিন নিজেই KVM-এর অধীনে চলা একটি guest। VPS-এ এটি স্বাভাবিক এবং প্রত্যাশিত। তৃতীয় লাইনটি এমন CPU core-এর সংখ্যা গণনা করে, যেগুলো hardware virtualisation flag প্রকাশ করে: Intel-এ vmx এবং AMD-এ svm। guest-এর ভেতরে শূন্যের বেশি সংখ্যা থাকলে বোঝা যায় যে hypervisor আপনাকে nested virtualisation ব্যবহারের সুযোগ দিচ্ছে।

এরপর যাচাই করুন, আপনার user device-টি open করতে পারে কি না। এটি Firecracker-এর নিজস্ব getting started document-এ ব্যবহৃত পরীক্ষা:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

node বিদ্যমান থাকা অবস্থায় FAIL দেখা গেলে এটি hardware সমস্যা নয়, permission সমস্যা। sudo setfacl -m u:${USER}:rw /dev/kvm ব্যবহার করে নিজের user-কে access দিন, অথবা sudo usermod -aG kvm ${USER} ব্যবহার করে নিজেকে group-এ যোগ করুন এবং আবার log in করুন।

Ubuntu-তেও এমন একটি পরীক্ষা আছে, যা দুই লাইনের output-এ এসব তথ্যের সারাংশ দেখায়:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

সঠিকভাবে কাজ করা host প্রথমে INFO: /dev/kvm exists এবং পরে KVM acceleration can be used দেখায়। কাজ না করা host প্রথমে INFO: Your CPU does not support KVM extensions এবং পরে KVM acceleration can NOT be used দেখায়। Physical machine-এ এর পরিবর্তে INFO: KVM (vmx) is disabled by your BIOS দেখা যেতে পারে। Firmware-এ পরিবর্তন করে এটি ঠিক করা যায়। VPS-এ এই বার্তা বিরল, কারণ সেখানে আপনি প্রকৃত firmware পরীক্ষা করছেন না।

প্রতিটি /dev/kvm ফলাফলের অর্থ কী?

নোডটি আছে এবং flag-এর সংখ্যা শূন্যের বেশি। আপনার hardware virtualisation আছে, তাই Firecracker চলবে। Sizing section-এ যান, কারণ আপনার বাকি সীমাবদ্ধতা CPU feature নয়, memory।

কোনো নোড নেই, systemd-detect-virt থেকে kvm বা qemu প্রিন্ট হয়, এবং flag-এর সংখ্যা 0। আপনার VPS একটি virtual machine, যার host virtualisation pass through করছে না। guest-এর ভেতরে কিছু install করলেও এটি পরিবর্তন হবে না, কারণ flag-টি hypervisor আপনার জন্য তৈরি করা virtual CPU-এর বৈশিষ্ট্য। sudo modprobe kvm_intel, modprobe: ERROR: could not insert 'kvm_intel': Operation not supported সহ ব্যর্থ হয়, এবং sudo dmesg | grep -i kvm অনুপস্থিত hardware support নথিভুক্ত করে। Shared VPS plan-এ এটি সাধারণ ঘটনা। nested virtualisation সমর্থিত কি না, provider-কে জিজ্ঞাসা করুন। উত্তর না হলে আপনার প্রয়োজন ভিন্ন hosting, ভিন্ন command নয়।

systemd-detect-virt থেকে lxc, lxc-libvirt বা openvz প্রিন্ট হয়। আপনার plan container virtualisation ব্যবহার করছে, তাই আপনি host-এর kernel ভাগ করে ব্যবহার করছেন। /dev/kvm কখনও দেখা যাবে না, কারণ module load করার জন্য আপনার নিজস্ব kernel নেই। কোনো package দিয়েও এটি ঠিক করা যাবে না।

Flag আছে, কিন্তু নোড নেই। Module-টি শুধু load করা হয়নি। sudo modprobe kvm_intel চালান (AMD হলে kvm_amd) এবং আবার ls -l /dev/kvm পরীক্ষা করুন। নোড দেখা গেলে module-এর নাম /etc/modules-load.d/kvm.conf-এ লিখুন, যাতে reboot-এর পরেও এটি ফিরে আসে।

আপনি arm64 ব্যবহার করছেন। vmx এবং svm হলো x86-এর নাম, তাই কাজ করছে বা করছে না—সব arm64 machine-এ grep-এর সংখ্যা 0 হবে। arm64-এ device node এবং read ও write test-এর ফলাফলের ওপর নির্ভর করুন।

কোডিং agent-এর কাজের জন্য container নয়, microVM কেন

একটি container হলো আপনার kernel-এ চলা একটি process, যাকে namespaces ও cgroups দিয়ে সীমাবদ্ধ রাখা হয়। এখানে একটি kernel থাকে এবং সেটি আপনার নিয়ন্ত্রণে, তাই kernel-level escape হলে তা host-এ পৌঁছে যায়। একটি microVM hardware virtualisation boundary-এর ভেতরে নিজস্ব kernel চালু করে এবং আপনার host-এর সম্পূর্ণ system call surface-এর পরিবর্তে একটি ছোট emulated device model-এর সঙ্গে যোগাযোগ করে। Firecracker এই model-টি ইচ্ছাকৃতভাবে ছোট রাখে। এটাই এর মূল নকশা: emulated device কম হলে বেরিয়ে আসার পথও কম থাকে।

এই পার্থক্য coding agent-এর ক্ষেত্রে গুরুত্বপূর্ণ, কারণ agent যে code চালায়, তা আগে কেউ পড়ে দেখেনি। এটি package install করে, build script চালায় এবং কোনো কিছু ব্যর্থ হলে machine-এর গতিতে আবার চেষ্টা করে। আলাদা kernel থাকলে কোনো ভুল পদক্ষেপ এমন একটি machine-এর ক্ষতি করে, যেটি আপনি মুছে ফেলতে পারেন। অন্য কিছুর ক্ষতি হয় না।

প্রয়োজনীয়তাটি সরাসরি এই mechanism থেকেই আসে। Hardware isolation-এর জন্য hardware virtualisation প্রয়োজন, আর আপনার VPS plan-এ hardware virtualisation নাও থাকতে পারে। Container-এর জন্য এর কোনোটিই দরকার হয় না। এ কারণেই অতীতে বিক্রি হওয়া প্রতিটি plan-এ container চালানো যায়।

তাই যখন /dev/kvm অনুপস্থিত থাকে, container-ভিত্তিক coding agent-এর জন্য disposable VM-ই সঠিক পছন্দ থাকে। এটি কেবল বিকল্প নয়, একটি বাস্তব control। এমন একটি host-এ রাখা throwaway container, যেখানে আপনার গুরুত্বপূর্ণ কোনো credential নেই, এবং সমস্যা হলে snapshot থেকে পুনরুদ্ধার করা হয়—বাস্তবে যে সমস্যাগুলো ঘটে, তার অধিকাংশই থামাতে পারে। VPS-এ coding agent চালানো-এর সরল setup-এর ক্ষেত্রেও একই কথা প্রযোজ্য। যখন কোনো agent unattended অবস্থায় ঘণ্টার পর ঘণ্টা এমন code-এর ওপর চলবে, যা আপনি review করেননি, এবং host-টি আপনার নিয়ন্ত্রণে থাকবে, তখন microVM ব্যবহার করুন।

একটি microVM agent host-এর কী প্রয়োজন

Nehemiah এই শ্রেণির একটি সাম্প্রতিক উদাহরণ: এটি Apache-2.0 লাইসেন্সের একটি daemon, যা প্রয়োজন অনুযায়ী AI-কে একটি বাস্তব Linux machine দেয়; প্রতিটি machine-এর জন্য একটি Firecracker microVM ব্যবহার করে। 10 August 2026 অনুযায়ী এর README-তে শর্তটি স্পষ্টভাবে লেখা ছিল: "/dev/kvm-সহ একটি Linux box", এবং আরও নির্দিষ্টভাবে "Ubuntu 24.04, x86_64 অথবা arm64, যেখানে /dev/kvm আছে (bare-metal অথবা nested virtualization-সহ একটি VM), এবং যেটিতে আপনি root-SSH করতে পারেন"।

এরপর এই ব্যবস্থা পরিবর্তিত হয়েছে। 11 August 2026-এ প্রকল্পটি self-serve setup documentation-এর পরিবর্তে managed-host runbook চালু করে। 11 October 2026-এ পরীক্ষা করা README-তে আর ওই requirement line বা one-command install নেই। এখন signed release artifact থেকে Latitude.sh bare-metal server-এ host provision করা হয়, যেখানে infra/latitude/provision.sh থাকে। এটি অনুমোদিত host-এর জন্য operator-পরিচালিত একটি প্রক্রিয়া, এরপর প্রকল্পটির control plane host-টিকে enroll করে। Runbook-এর canary এখনও usable /dev/kvm ছাড়া host প্রত্যাখ্যান করে। তাই requirement বাদ যায়নি। এটি bare metal-এ স্থানান্তরিত হয়েছে।

এই পরিবর্তনের আগে নথিভুক্ত setup-এ ওই box-কে লক্ষ্য করে একটি command চালানো হতো:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

বর্তমান main-এ ওই command আর কিছু install করে না। infra/setup.sh-কে descoped হিসেবে চিহ্নিত করা হয়েছে এবং প্রথম ধাপেই exit করে জানায় যে self-serve bootstrap আর সমর্থিত নয়। কোনো preflight বা install step চালানোর আগেই এটি ঘটে। README-তে বলা হয়েছে, আগের self-serve installer-গুলো এখন managed runbook-এর নির্দেশনা দেখিয়ে exit করে।

এই post-টি প্রথম যে commit-এর ভিত্তিতে লেখা হয়েছিল, সেখানে infra/setup.sh SSH-এর মাধ্যমে preflight চালিয়ে box-এর configuration সঠিক না হলে শুরুতেই থেমে যেত। Hardware সংক্রান্ত দুটি refusal message ছিল:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

এই post-এর মূল বিষয়টি প্রথম string-টিতেই আছে। আপনি ls -l /dev/kvm দিয়ে যে প্রশ্নটি করেছেন, installer-ও একই প্রশ্ন করেছিল। অধিকাংশ VPS plan-এ সেটি একই হতাশাজনক উত্তর পেত। Managed runbook-ও এই প্রশ্নটি করে।

Preflight সফল হলে এটি পুরো box-এ install করত: Firecracker এবং তার jailer, একটি Go toolchain, একটি guest kernel ও root filesystem, একটি Python guest image, browser-সহ একটি ঐচ্ছিক desktop image, এবং nehemiahd.service ও boring-net.service নামে দুটি systemd unit। Health check ব্যর্থ হলে /healthz didn't return ok দেখানো হতো। SKIP_DESKTOP=1 desktop image বাদ দিত; ওই তারিখের README অনুযায়ী image-টি build করতে প্রায় 8 মিনিট লাগত। বর্তমান main থেকে এসব step, message বা switch-এর কোনোটিই আর চলে না। Daemon নিজে এখনও default হিসেবে port 8080-এ সাড়া দেয়।

এই কমান্ডটি পেস্ট করার আগে সতর্কতাগুলো পড়ুন

এটি নতুন host-এ root SSH চেয়েছিল। Self-serve installer-টি root হিসেবে system package, systemd unit এবং network configuration লিখেছিল। Unsupported commit-টি চালাতেই হলে এমন একটি machine বেছে নিন, যেটি প্রয়োজনে সম্পূর্ণ নতুন করে তৈরি করতে আপনি প্রস্তুত। ইতিমধ্যে আপনার site চালাচ্ছে এমন server-এ এটি চালাবেন না।

Daemon-টি default হিসেবে 0.0.0.0:8080-এ bind করে। যে কেউ ওই port-এ পৌঁছাতে পারলে machine তৈরি করতে পারে, এবং সেই machine-গুলো host-কে দেওয়া model key ব্যবহার করে। Authentication বাধ্যতামূলক করতে NEHEMIAH_TOKEN সেট করুন। অথবা NEHEMIAH_ADDR=127.0.0.1:8080 সেট করুন; daemon-টি -addr 127.0.0.1:8080-ও গ্রহণ করে। এতে daemon-টি শুধু 127.0.0.1-এ bind করবে এবং ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP দিয়ে tunnel-এর মাধ্যমে এতে পৌঁছাতে পারবেন। পুরোনো installer-এর BIND_LOCALHOST=1 switch daemon পড়ে না। তাই ওই script-এর বাইরে এটি কোনো কাজ করে না। Box-এ থাকা অন্য যেকোনো secret-এর মতো এই key-ও সতর্কতার সঙ্গে সংরক্ষণ করুন। AI agent-এর বাইরে secret রাখার মতো।

প্রতিটি machine হলো Internet access-সহ একটি computer, যেখানে agent আগে থেকেই install করা থাকে। README-তে guest-এর ভেতরে node, python এবং git-এর পাশে claude, codex, cursor এবং pi তালিকাভুক্ত আছে। Project বলছে, guest-গুলো egress firewall-এর পেছনে থাকে এবং isolation boundary কার্যকর। তবু guest নকশা অনুযায়ী network-এ পৌঁছাতে পারে, কারণ package fetch করতে না-পারা coding agent কোনো কাজে আসে না। Air gap আছে ধরে নেওয়ার বদলে এটির জন্য আগে থেকেই পরিকল্পনা করুন।

কোনো tagged release নেই। 11 October 2026 অনুযায়ী repository-তে কোনো tag বা release নেই। তাই main clone করলে ওই সকালে repository-তে যোগ হওয়া code-ই পাবেন, এবং বর্তমানে সেটি managed-only code। একটি নির্দিষ্ট commit pin করুন। নিচের commit-টি হলো 10 August 2026-এ এই post লেখার সময় ব্যবহৃত commit। Self-serve installer প্রত্যাহার করার আগের দিন এটি ব্যবহার করা হয়েছিল, তাই এর infra/setup.sh এখনও install করে। Project এখন আর ওই path support করে না। তাই server-এ root হিসেবে script চালানোর আগে এটি পড়ুন:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

Repository-টি June 2026-এর শেষে তৈরি হয়েছিল এবং ছয় সপ্তাহ পর self-serve install প্রত্যাহার করা হয়। তাই এটিকে এমন নতুন software হিসেবে বিবেচনা করুন, যার supported path আপনার অজান্তে পরিবর্তিত হতে পারে। আরও নতুন কিছু pull করার আগে README এবং runbook আবার পড়ুন। কারণ আপনি যে বিষয়টির অনুমোদন দিচ্ছেন, তা হলো একটি machine-এ root access; কোনো library version bump নয়।

ইনস্টলারকে দোষ দেওয়ার আগে KVM কাজ করছে কি না যাচাই করুন

সেটআপ ব্যর্থ হলে এবং KVM-এর কারণে সমস্যা হচ্ছে কি না জানতে চাইলে Firecracker আলাদাভাবে পরীক্ষা করুন। এগুলো upstream থেকে ডাউনলোড করার ধাপ:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

সংস্করণ দেখালে প্রমাণ হয় যে binary-টি আপনার architecture-এর সঙ্গে সামঞ্জস্যপূর্ণ এবং চালানো যাচ্ছে। এতে KVM access প্রমাণ হয় না। তাই এর সঙ্গে আগে উল্লেখ করা /dev/kvm-এ read ও write test চালান। এই দুই পরীক্ষার ফল একসঙ্গে দেখলে hosting সমস্যা এবং packaging সমস্যা আলাদা করা যায়। ফলে এমন installer debug করতে হয় না, যা আসলে সঠিকভাবেই কাজ করছিল।

বেশ কয়েকটি microVM চালাতে কত সার্ভার রিসোর্স দরকার?

প্রতিটি microVM-এ একটি পূর্ণ guest kernel এবং আপনি নির্ধারণ করা পরিমাণ memory থাকে। মেশিন চালু থাকা পর্যন্ত সেই memory বরাদ্দ থাকে। তাই একসঙ্গে যতগুলো guest চালাতে চান এবং প্রতিটি guest-এর আকার—এই দুই ভিত্তিতে host-এর আকার নির্ধারণ করুন। নিচের হিসাবগুলো গাণিতিক হিসাব, পরিমাপ করা ফল নয়। একটি headless guest-এর জন্য 1 GB এবং browser-সহ একটি desktop guest-এর জন্য 2 GB ধরা হয়েছে। host নিজের জন্য, daemon এবং image build-এর জন্য অতিরিক্ত 3 GB সংরক্ষণ করে। এটি daemon-এর default reserve (NEHEMIAH_MEM_RESERVE_MB, 3072 MB)। এই reserve কমে যাবে এমন নতুন machine daemon চালু করতে দেয় না। তাই আকারে ছোট host memory শেষ হওয়ার বদলে capacity সীমায় পৌঁছে যায়।

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 4
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 7
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 11
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 19
  }
]

একসঙ্গে একটি headless machine চালাতে প্রায় 4 GB দরকার। KVM সরবরাহকারী মাঝারি আকারের একটি VPS এই পরিমাণ memory দিতে পারে। চারটি machine-এর জন্য দরকার 7 GB। 8টি desktop machine চালালে একই হিসাব অনুযায়ী, এক GB disk গণনায় নেওয়ার আগেই, 19 GB দরকার।

Disk হলো সেই resource, যার পরিকল্পনা অনেকেই করেন না। host-এ guest kernel, একটি base root filesystem, প্রতিটি guest flavour-এর জন্য একটি image এবং প্রতিটি চলমান machine-এর জন্য একটি snapshot সংরক্ষিত হয়। Browser-সহ desktop image-টিই বড়। README-তে disk-এর কোনো পরিমাণ দেওয়া নেই। তাই অনুমানের ওপর নির্ভর না করে প্রথম build চলার সময় df -h / monitor করুন।

এই কারণেই “কোন VPS-এ Firecracker চালানো যায়?” প্রশ্নের সৎ উত্তর প্রায়ই হয় “অন্য শ্রেণির machine”। Bare metal-এ মাঝখানে hypervisor না থাকায় প্রয়োজনীয় CPU flag সরাসরি পাওয়া যায়। VPS এবং dedicated server-এর মধ্যে নির্বাচন-এ এই trade-off ব্যাখ্যা করা হয়েছে। কিছু provider virtual plan-এ nested virtualisation সক্রিয় করে। অর্থ পরিশোধের আগে এটি কীভাবে নিশ্চিত করবেন, তা VPS-এ nested virtualisation-এ দেখানো হয়েছে। Hardware যদি আগে থেকেই আপনার থাকে, hypervisor-এর দিক থেকে একই প্রশ্নের উত্তর হলো plain VPS-এর তুলনায় Proxmox।

Server খরচের সস্তা অংশও বটে। কোনো machine agent-কে দিলে সেটি চলার পুরো সময় model token ব্যবহার করে। তাই idle microVM memory খরচ করে, আর ব্যস্ত microVM memory-এর পাশাপাশি API খরচও করে। 1 GB plan host ধারণ করতে পারবে না। Host ধারণ করতে পারে এমন plan-ও key-এর খরচ বহন করতে পারবে না।

FAQ

আমার VPS Firecracker চালাতে পারে কি না কীভাবে পরীক্ষা করব?

VPS-এ ls -l /dev/kvm, systemd-detect-virt এবং grep -cE '\b(vmx|svm)\b' /proc/cpuinfo চালান। kvm group-এর মালিকানাধীন একটি device node এবং শূন্যের বেশি flag count থাকলে Firecracker চালানো যাবে। node না থাকা এবং count 0 হলে hypervisor virtualisation pass through করছে না। cpu-checker package-এর sudo kvm-ok এটি KVM acceleration can NOT be used দিয়ে নিশ্চিত করে। arm64-এ count উপেক্ষা করুন, কারণ vmx এবং svm হলো x86-এর নাম।

আমার VPS-এর ভেতর থেকে কি nested virtualisation চালু করতে পারি?

না। nested virtualisation host থেকে চালু করা হয়, hypervisor-এর নিজস্ব kernel module-এ সেট করা হয়, এবং আপনাকে দেওয়া virtual processor-এ CPU flag হিসেবে এটি guest-এ পৌঁছায়। guest-এর ভেতরে sudo modprobe kvm_intel, modprobe: ERROR: could not insert 'kvm_intel': Operation not supported ফেরত দেয়, কারণ virtual CPU-তে ব্যবহার করার মতো VMX নেই। আপনার বিকল্প হলো এমন provider বেছে নেওয়া, যে plan-এ nested virtualisation দেয়, অথবা এমন machine ব্যবহার করা যেখানে hypervisor আপনার নিয়ন্ত্রণে থাকে।

coding agent-কে sandbox করার জন্য কি container যথেষ্ট?

অনেক ক্ষেত্রে যথেষ্ট। container আপনার kernel share করে, তাই kernel-level escape হলে host-এ পৌঁছানো সম্ভব। তবে মূল্যবান credential না থাকা machine-এ disposable container ব্যবহার করলে বাস্তবে আপনার মুখোমুখি হওয়া বেশিরভাগ ঝুঁকি দূর হয়। agent যদি দীর্ঘ সময় unattended অবস্থায় unreviewed code নিয়ে কাজ করে এবং আপনি তাকে /dev/kvm-সহ একটি host দিতে পারেন, তখন microVM বেছে নিন। তা সম্ভব না হলে, প্রতিটি task-এর পরে ধ্বংস করে দেওয়া container এমন microVM-এর চেয়ে ভালো, যেটি আপনি কখনো boot করাতেই পারেন না।

microVM agent host-এর কত RAM প্রয়োজন?

guest-এর size থেকে হিসাব শুরু করুন। 1 GB RAM-এর একটি headless guest এবং host-এর জন্য 3 GB reserve মিলিয়ে মোট প্রায় 4 GB প্রয়োজন। 2 GB করে 8টি desktop guest-এর জন্য প্রায় 19 GB প্রয়োজন। Disk আলাদা বিষয় এবং এর প্রয়োজন সহজেই কম ধরে নেওয়া হয়, কারণ host-এ kernel, root filesystem, প্রতিটি guest flavour-এর জন্য একটি image এবং প্রতিটি চলমান machine-এর জন্য একটি snapshot সংরক্ষিত থাকে।