உங்கள் VPS-ல் Firecracker microVM-களை இயக்க முடியுமா?

உங்கள் VPS-ல் Firecracker microVM-களை இயக்க முடியுமா?

உங்கள் VPS-ல் /dev/kvm வசதி இருந்தால் மட்டுமே Firecracker microVM-களை இயக்க முடியும். Firecracker என்பது Linux-ன் உள்ளே இருக்கும் KVM (kernel-based virtual machine) எனும் virtualization அடுக்கின் மீது கட்டமைக்கப்பட்ட ஒரு VMM (virtual machine monitor) ஆகும். KVM-க்கு CPU-விடமிருந்து virtualization கட்டளைகள் தேவைப்படுகின்றன. ஒரு VPS-ல், அந்த கட்டளைகளை உங்கள் provider உங்கள் guest-க்கு வழங்கினால் மட்டுமே உங்களால் பயன்படுத்த முடியும்; பெரும்பாலான திட்டங்களில் இந்த வசதி இருப்பதில்லை.

எனவே, எந்த microVM கருவியை நிறுவுவது என்பது முதல் கேள்வியல்ல. நீங்கள் ஏற்கனவே பணம் செலுத்திப் பயன்படுத்தும் அந்த machine-ல் இதை இயக்க முடியுமா என்பதே முதல் கேள்வி. இது 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 குழுவிற்குச் சொந்தமானது. இரண்டாவது வரி, இந்த இயந்திரமே KVM-ன் கீழ் இயங்கும் ஒரு guest என்பதை உணர்த்துகிறது; இது VPS சூழலில் இயல்பான மற்றும் எதிர்பார்க்கப்படும் ஒன்று. மூன்றாவது வரி, வன்பொருள் மெய்நிகராக்கக் குறியீட்டை (hardware virtualisation flag) வெளிப்படுத்தும் CPU cores-ன் எண்ணிக்கையைக் காட்டுகிறது; இது Intel-க்கு vmx மற்றும் AMD-க்கு svm ஆகும். ஒரு guest-க்குள் இந்த எண்ணிக்கை பூஜ்ஜியத்திற்கு மேல் இருந்தால், hypervisor உங்களுக்கு nested virtualisation வசதியை வழங்குகிறது என்று அர்த்தம்.

பிறகு, உங்கள் பயனர் கணக்கினால் அந்த device-ஐத் திறக்க முடிகிறதா என்று சரிபார்க்கவும். இது Firecracker-ன் அதிகாரப்பூர்வ வழிகாட்டி ஆவணத்தில் உள்ள சோதனை முறை:

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

node இருந்தாலும் FAIL பிழை ஏற்பட்டால், அது வன்பொருள் சார்ந்த பிரச்சனையல்ல, அனுமதி (permission) சார்ந்த பிரச்சனை. sudo setfacl -m u:${USER}:rw /dev/kvm கட்டளையைப் பயன்படுத்தி உங்கள் பயனருக்கு அணுகல் வழங்கவும், அல்லது sudo usermod -aG kvm ${USER} கட்டளை மூலம் உங்களை அந்த குழுவில் சேர்த்துவிட்டு மீண்டும் login செய்யவும்.

Ubuntu-வில் இதையெல்லாம் சுருக்கமாக இரண்டு வரிகளில் சரிபார்க்க ஒரு வசதி உள்ளது:

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 பதிலின் அர்த்தம் என்ன?

node உள்ளது மற்றும் flag எண்ணிக்கை பூஜ்ஜியத்திற்கு மேல் உள்ளது. உங்களிடம் hardware virtualisation வசதி உள்ளது, எனவே Firecracker இயங்கும். sizing பகுதிக்குச் செல்லவும், ஏனெனில் உங்கள் தற்போதைய கட்டுப்பாடு CPU அம்சங்களை விட memory-ஆகவே இருக்கும்.

node இல்லை, systemd-detect-virt என்பது kvm அல்லது qemu-ஐ அச்சிடுகிறது, மற்றும் flag எண்ணிக்கை 0. உங்கள் VPS என்பது ஒரு virtual machine, அதன் host virtualisation வசதியை உங்களுக்கு வழங்கவில்லை. நீங்கள் guest-க்குள் எதை நிறுவினாலும் இது மாறாது, ஏனெனில் இந்த flag என்பது hypervisor உங்களுக்காக உருவாக்கிய virtual CPU-வின் ஒரு பண்பாகும். sudo modprobe kvm_intel என்பது modprobe: ERROR: could not insert 'kvm_intel': Operation not supported உடன் தோல்வியடையும், மேலும் sudo dmesg | grep -i kvm வன்பொருள் ஆதரவு இல்லாததை பதிவு செய்யும். பகிரப்பட்ட VPS திட்டங்களில் இது பொதுவானது. உங்கள் provider-இடம் அந்தத் திட்டம் nested virtualisation-ஐ ஆதரிக்கிறதா என்று கேட்கவும். பதில் இல்லை என்றால், உங்களுக்கு வேறு கட்டளை அல்ல, வேறு hosting தேவை.

systemd-detect-virt என்பது lxc, lxc-libvirt அல்லது openvz-ஐ அச்சிடுகிறது. உங்கள் திட்டம் container virtualisation, எனவே நீங்கள் host-ன் kernel-ஐப் பகிர்கிறீர்கள். /dev/kvm ஒருபோதும் தோன்றாது, ஏனெனில் module-ஐ ஏற்றுவதற்கு உங்களுக்கென்று சொந்த kernel இல்லை. எந்த package-உம் இதைச் சரிசெய்யாது.

flags உள்ளன ஆனால் node இல்லை. module இன்னும் ஏற்றப்படவில்லை. sudo modprobe kvm_intel (அல்லது AMD-யில் kvm_amd) கட்டளையை இயக்கவும், பிறகு ls -l /dev/kvm-ஐ மீண்டும் சரிபார்க்கவும். node தோன்றினால், module பெயரை /etc/modules-load.d/kvm.conf-ல் எழுதவும், அப்போதுதான் reboot-க்கு பிறகு அது மீண்டும் வரும்.

நீங்கள் arm64-ல் உள்ளீர்கள். vmx மற்றும் svm என்பவை x86 பெயர்கள், எனவே ஒவ்வொரு arm64 machine-லும் grep எண்ணிக்கை 0-ஆகவே இருக்கும், அது வேலை செய்தாலும் சரி, செய்யாவிட்டாலும் சரி. arm64-ல், device node மற்றும் read/write சோதனையை மட்டும் நம்புங்கள்.

ஏஜென்ட் பணிகளுக்கு container-க்கு பதிலாக microVM ஏன் தேவைப்படுகிறது

Container என்பது உங்கள் kernel-ல் இயங்கும் ஒரு process ஆகும்; இது namespaces மற்றும் cgroups மூலம் பிரிக்கப்பட்டிருக்கும். இதில் ஒரே ஒரு kernel மட்டுமே உள்ளது, அது உங்களுடையது என்பதால், kernel மட்டத்திலான பாதுகாப்பு மீறல் (escape) நேரடியாக host-ஐ பாதிக்கும். ஒரு microVM, வன்பொருள் மெய்நிகராக்க (hardware virtualisation) எல்லைக்குள் தனக்கென ஒரு kernel-ஐ boot செய்கிறது. இது உங்கள் host-ன் முழுமையான system call-களுடன் நேரடியாகத் தொடர்புகொள்வதற்குப் பதிலாக, சிறிய அளவிலான emulated device model-உடன் மட்டுமே பேசுகிறது. Firecracker இந்த மாதிரியை வேண்டுமென்றே சிறியதாக வைத்திருக்கிறது; இதுவே அதன் முழு வடிவமைப்பும் ஆகும்: குறைவான emulated devices இருந்தால், வெளியேறுவதற்கான வழிகளும் குறையும்.

Coding agent-ஐப் பொறுத்தவரை இந்த வேறுபாடு முக்கியமானது, ஏனெனில் ஒரு agent இயக்கும் குறியீட்டை (code) யாரும் முன்னரே வாசிப்பதில்லை. அது packages-ஐ நிறுவுகிறது, build scripts-ஐ இயக்குகிறது, ஏதேனும் தவறு நடந்தால் மிக வேகமான இயந்திர வேகத்தில் மீண்டும் முயற்சிக்கிறது. தனித்தனி kernel இருப்பதால், ஒரு தவறான செயல் நீங்கள் எளிதாக நீக்கக்கூடிய ஒரு இயந்திரத்தை மட்டுமே பாதிக்கும், மற்ற எதையும் பாதிக்காது.

இந்தத் தேவை அதன் செயல்பாட்டு முறையிலிருந்து நேரடியாக எழுகிறது. வன்பொருள் தனிமைப்படுத்தலுக்கு (hardware isolation) வன்பொருள் மெய்நிகராக்கம் தேவை, ஆனால் உங்கள் VPS திட்டத்தில் அது கிடைக்காமல் இருக்கலாம். Container-க்கு அத்தகைய வசதி தேவையில்லை, அதனால்தான் அனைத்து VPS திட்டங்களிலும் containers இயங்குகின்றன.

எனவே, /dev/kvm இல்லாதபோது, container அடிப்படையிலான coding agent-களுக்கான disposable VM சரியான தீர்வாக இருக்கும்; இது ஒரு சமரசத் தீர்வு அல்ல, உண்மையான கட்டுப்பாட்டு முறையாகும். நீங்கள் முக்கியமாகக் கருதும் credentials இல்லாத ஒரு host-ல் இயங்கும், தவறாகச் செயல்படும்போது snapshot-லிருந்து மீட்டெடுக்கப்படும் ஒரு தற்காலிக container, பெரும்பாலான சிக்கல்களைத் தடுத்துவிடும். VPS-ல் coding agent-ஐ இயக்குதல் என்ற எளிய அமைப்பிற்கும் இதுவே பொருந்தும். ஒரு agent-ஐ நீங்கள் கவனிக்காமல் பல மணிநேரம், நீங்கள் ஆய்வு செய்யாத குறியீட்டிற்கு எதிராக இயக்கும்போது, மற்றும் அந்த 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 ஆவணங்களை நீக்கிவிட்டு, managed-host runbook-ஐ அறிமுகப்படுத்தியது. 11 October 2026 அன்று சரிபார்க்கப்பட்ட README-ல் அந்தத் தேவை குறித்த வரியோ அல்லது ஒரே கட்டளையில் நிறுவும் வசதியோ இல்லை. தற்போது hosts, கையொப்பமிடப்பட்ட release artifacts மூலம் Latitude.sh bare-metal servers-ல் infra/latitude/provision.sh கொண்டு வழங்கப்படுகின்றன. இது அங்கீகரிக்கப்பட்ட hosts-க்கான ஒரு manual, operator-run வழியாகும், இதைத் திட்டத்தின் control plane பின்னர் இணைத்துக்கொள்கிறது. அந்த runbook-ன் canary இன்னும் பயன்படுத்தக்கூடிய /dev/kvm இல்லாத host-ஐ நிராகரிக்கிறது, எனவே அந்தத் தேவை நீங்கவில்லை. அது bare metal-க்கு மாறியுள்ளது.

அந்த மாற்றத்திற்கு முன்பு, ஆவணப்படுத்தப்பட்ட setup என்பது அந்த box-ஐ இலக்காகக் கொண்ட ஒரு கட்டளையாக இருந்தது:

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

தற்போதைய main-ல் அந்தக் கட்டளை எதையும் நிறுவுவதில்லை. infra/setup.sh என்பது descoped என அடையாளப்படுத்தப்பட்டு, எந்தவொரு preflight அல்லது install படியும் தொடங்குவதற்கு முன்பே, self-serve bootstrap இனி ஆதரிக்கப்படாது என்ற செய்தியுடன் முதல் படியிலேயே வெளியேறுகிறது. முந்தைய self-serve installers இப்போது managed runbook-ஐச் சுட்டிக்காட்டி வெளியேறுவதாக README கூறுகிறது.

இந்தக் கட்டுரை எழுதப்பட்ட commit-ல், infra/setup.sh என்பது SSH வழியாக ஒரு preflight-ஐ இயக்கி, box தவறாக இருந்தால் ஆரம்பத்திலேயே நின்றுவிடும். அதன் இரண்டு hardware நிராகரிப்புச் செய்திகள் இவை:

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

அந்த முதல் string-தான் இந்தக் கட்டுரையின் மையப்பொருள். அந்த installer நீங்கள் ls -l /dev/kvm மூலம் கேட்ட அதே கேள்வியைக் கேட்டது, பெரும்பாலான VPS திட்டங்களில் அதற்கு அதே ஏமாற்றமளிக்கும் பதில்தான் கிடைத்தது. அந்த managed runbook-ம் இதையே கேட்கிறது.

Preflight-க்கு அப்பால், அது ஒரு முழுமையான box install ஆகும்: Firecracker மற்றும் அதன் jailer, ஒரு Go toolchain, ஒரு guest kernel மற்றும் root filesystem, ஒரு Python guest image, browser கொண்ட ஒரு optional desktop image, மற்றும் nehemiahd.service மற்றும் boring-net.service எனப் பெயரிடப்பட்ட இரண்டு systemd units. தோல்வியுற்ற health check ஒன்று /healthz didn't return ok-ஐ அச்சிட்டது, மேலும் SKIP_DESKTOP=1 desktop image-ஐத் தவிர்த்தது; அந்தத் தேதியிட்ட README-ன் படி அதை உருவாக்க சுமார் 8 நிமிடங்கள் ஆனது. அந்தப் படிகள், செய்திகள் அல்லது switches எதுவுமே தற்போதைய main-ல் இயங்குவதில்லை. அந்த daemon, இயல்பாகவே port 8080-ல் பதிலளிக்கிறது.

அந்தக் கட்டளையை நகலெடுக்கும் முன் எச்சரிக்கைகளைப் படிக்கவும்

இது புதிய host-ல் root SSH அணுகலைக் கோரியது. இந்த self-serve installer, system packages, systemd units மற்றும் network configuration ஆகியவற்றை root பயனர் மூலம் எழுதியது. அந்த ஆதரவற்ற commit-ஐ நீங்கள் எப்படியும் இயக்க விரும்பினால், உங்கள் தளம் இயங்கும் server-ல் செய்யாமல், முழுமையாக மீண்டும் உருவாக்கத் தயாராக இருக்கும் ஒரு machine-ல் மட்டும் செய்யவும்.

இந்த daemon இயல்பாக 0.0.0.0:8080-ல் bind ஆகும். அந்த port-ஐ அணுகும் எவரும் புதிய machine-களை உருவாக்க முடியும், மேலும் அந்த machine-கள் நீங்கள் host-க்கு வழங்கிய model key-ஐப் பயன்படுத்தும். அங்கீகாரத்தைக் கோர NEHEMIAH_TOKEN-ஐ அமைக்கவும், அல்லது NEHEMIAH_ADDR=127.0.0.1:8080-ஐ அமைக்கவும் (daemon -addr 127.0.0.1:8080-ஐயும் ஏற்கும்), இதன் மூலம் அது 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-க்கு வெளியே அது எந்தச் செயல்பாட்டையும் செய்யாது. இந்த key-க்கு, AI agents-ல் ரகசியங்களை எவ்வாறு பாதுகாப்பது என்பதில் உள்ளவாறு, server-ல் உள்ள மற்ற ரகசியங்களைப் போலவே அதே பாதுகாப்பை வழங்க வேண்டும்.

ஒவ்வொரு machine-ம் இணைய அணுகல் மற்றும் முன்கூட்டியே நிறுவப்பட்ட agents கொண்ட ஒரு கணினியாகும். README கோப்பில் guest-க்குள் node, python மற்றும் git ஆகியவற்றுடன் claude, codex, cursor மற்றும் pi ஆகியவை பட்டியலிடப்பட்டுள்ளன. இந்தத் திட்டம், guest-கள் ஒரு egress firewall-க்கு பின்னால் இருப்பதாகக் கூறுகிறது, மேலும் அந்த isolation boundary உண்மையானது. ஒரு coding agent-ஆல் package-களைப் பதிவிறக்க முடியாவிட்டால் அது பயனற்றது என்பதால், வடிவமைப்பின்படி guest இன்னும் network-ஐ அணுகுகிறது. எனவே, air gap இருப்பதாகக் கருதாமல், அதற்கேற்ப திட்டமிடுங்கள்.

இதில் tagged release எதுவும் இல்லை. 11 October 2026 நிலவரப்படி, இந்த repository-ல் tags அல்லது releases எதுவும் இல்லை. எனவே, main-ஐ clone செய்யும்போது அன்று காலை என்ன code இருந்ததோ அதுவே உங்களுக்குக் கிடைக்கும், இன்று அது managed-only code மட்டுமே. ஒரு குறிப்பிட்ட commit-ஐ pin செய்யவும். கீழே கொடுக்கப்பட்டுள்ள commit, 10 August 2026 அன்று இந்த இடுகை எழுதப்பட்டபோது இருந்தது; இது self-serve installer நீக்கப்படுவதற்கு முந்தைய நாள் என்பதால், அதன் infra/setup.sh இன்னும் இயங்குகிறது. இந்தத் திட்டம் அந்தப் பாதையை இனி ஆதரிக்காது, எனவே உங்கள் 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 வசதியை நீக்கிவிட்டது. எனவே, இது புதிய மென்பொருள் என்பதையும், அதன் ஆதரவு முறை எப்போது வேண்டுமானாலும் மாறலாம் என்பதையும் கவனத்தில் கொள்ளுங்கள். புதிய எதையும் pull செய்வதற்கு முன், README மற்றும் runbook-ஐ மீண்டும் படிக்கவும்; ஏனெனில் நீங்கள் அனுமதிப்பது ஒரு library version மாற்றத்தை அல்ல, மாறாக ஒரு machine-க்கான root அணுகலை.

KVM சரியாக இயங்குவதை உறுதி செய்தல்

நிறுவல் (installer) தோல்வியுற்றால், 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 அணுகலை உறுதிப்படுத்தாது என்பதால், முன்னதாகக் குறிப்பிட்ட /dev/kvm-ல் உள்ள read மற்றும் write சோதனையை இதனுடன் சேர்த்துச் செய்யவும். இவை இரண்டையும் இணைத்துச் சோதிப்பதன் மூலம், hosting சிக்கலா அல்லது packaging சிக்கலா என்பதைப் பிரித்தறியலாம். இது சரியாகச் செயல்படும் installer-ஐத் தேவையற்ற முறையில் பிழைதிருத்தம் செய்வதிலிருந்து உங்களைக் காக்கும்.

பல microVM-களுக்கு எவ்வளவு server திறன் தேவை?

ஒவ்வொரு microVM-மும் ஒரு guest kernel-ஐயும், நீங்கள் ஒதுக்கும் memory-யையும் கொண்டிருக்கும். அந்த machine இயங்கும் வரை அந்த memory ஒதுக்கீடு செய்யப்பட்டிருக்கும். எனவே, 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 அனுமதிக்காது. எனவே, போதிய memory இல்லாத சூழலில், host-ன் கொள்ளளவு எட்டப்பட்டவுடன் புதிய machine தொடங்குவது தடுக்கப்படும்.

[
  {
    "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 வசதி கொண்ட ஒரு mid-size VPS-ல் இதை இயக்க முடியும். நான்கு machine-களுக்கு 7 GB தேவைப்படும். 8 desktop machine-களை இயக்கினால், disk பயன்பாட்டைக் கணக்கிடுவதற்கு முன்பே 19 GB தேவைப்படும்.

Disk பயன்பாடு என்பது யாரும் முன்கூட்டியே திட்டமிடாத ஒன்று. Host ஒரு guest kernel, ஒரு base root filesystem, ஒவ்வொரு guest flavour-க்கும் ஒரு image மற்றும் இயங்கும் ஒவ்வொரு machine-க்கும் ஒரு snapshot ஆகியவற்றைச் சேமிக்கும். Browser கொண்ட desktop image பெரிய அளவிலானது. README-ல் disk பயன்பாடு குறித்த விவரங்கள் இல்லாததால், ஒரு யூகத்தை நம்புவதை விட முதல் build-ன் போது df -h /-ஐக் கவனிக்கவும்.

இதனால்தான் "Firecracker-ஐ இயக்க எந்த VPS சிறந்தது" என்ற கேள்விக்கு, "வேறு வகையான machine" என்பதே உண்மையான பதிலாக இருக்கும். Bare metal server-களில் hypervisor குறுக்கீடு இல்லாமல் CPU flags நேரடியாகக் கிடைக்கும்; இது VPS மற்றும் dedicated server-க்கு இடையிலான தேர்வு குறித்த முடிவில் முக்கியமானது. சில providers virtual plans-ல் nested virtualisation வசதியை வழங்குகிறார்கள்; பணம் செலுத்தும் முன் அதை எவ்வாறு உறுதி செய்வது என்பதை VPS-ல் nested virtualisation விளக்குகிறது. உங்களிடம் ஏற்கனவே hardware இருந்தால், Proxmox மற்றும் சாதாரண VPS ஒப்பீடு என்பது hypervisor பக்கத்திலிருந்து கேட்கப்படும் அதே கேள்வியாகும்.

Server-ன் விலை ஒரு பகுதி மட்டுமே. நீங்கள் ஒரு agent-க்கு வழங்கும் ஒவ்வொரு machine-ம் இயங்கும் வரை model tokens-ஐச் செலவழிக்கும். எனவே, ஒரு idle microVM memory-யை மட்டும் செலவழிக்கும், ஆனால் இயங்கிக்கொண்டிருக்கும் ஒரு microVM memory மற்றும் API spend ஆகிய இரண்டையும் செலவழிக்கும். 1 GB plan-ல் host-ஐ இயக்க முடியாது. Host-ஐ இயக்கக்கூடிய ஒரு plan-ல் கூட, API key-க்கான செலவு தனி.

FAQ

எனது VPS-ல் Firecracker-ஐ இயக்க முடியுமா என்பதை எவ்வாறு சரிபார்ப்பது?

VPS-ல் ls -l /dev/kvm, systemd-detect-virt மற்றும் grep -cE '\b(vmx|svm)\b' /proc/cpuinfo கட்டளைகளை இயக்கவும். kvm குழுவிற்குச் சொந்தமான ஒரு device node மற்றும் பூஜ்ஜியத்திற்கு மேலான flag எண்ணிக்கை இருந்தால், Firecracker-ஐ இயக்க முடியும் என்று அர்த்தம். node விடுபட்டு, எண்ணிக்கை 0 ஆக இருந்தால், hypervisor virtualisation-ஐ அனுமதிக்கவில்லை என்று பொருள்; இதை cpu-checker தொகுப்பில் உள்ள sudo kvm-ok கட்டளை KVM acceleration can NOT be used மூலம் உறுதிப்படுத்தும். arm64 கட்டமைப்பில், இந்த எண்ணிக்கையைப் புறக்கணிக்கவும், ஏனெனில் vmx மற்றும் svm ஆகியவை x86 சார்ந்த பெயர்கள்.

எனது VPS-க்குள் nested virtualisation-ஐ என்னால் செயல்படுத்த முடியுமா?

முடியாது. Nested virtualisation என்பது host-ஆல், அதன் hypervisor kernel module-ல் செயல்படுத்தப்படுவது. இது உங்களுக்கு வழங்கப்பட்ட virtual processor-ல் ஒரு CPU flag-ஆகவே வந்து சேரும். Guest-க்குள், sudo modprobe kvm_intel கட்டளையை இயக்கினால் modprobe: ERROR: could not insert 'kvm_intel': Operation not supported என்று வரும், ஏனெனில் virtual CPU-விடம் பயன்படுத்த VMX வசதி இல்லை. உங்கள் விருப்பங்கள்: nested virtualisation வசதியுள்ள plan-ஐ வழங்கும் provider-ஐத் தேர்ந்தெடுப்பது அல்லது நீங்களே hypervisor-ஐக் கட்டுப்படுத்தும் ஒரு machine-ஐப் பயன்படுத்துவது.

ஒரு coding agent-ஐ sandbox செய்ய container போதுமானதா?

பெரும்பாலான நேரங்களில் ஆம். ஒரு container உங்கள் kernel-ஐப் பகிர்ந்து கொள்கிறது, எனவே kernel level escape ஏற்பட்டால் அது host-ஐப் பாதிக்கும். ஆனால், முக்கியமான credentials இல்லாத ஒரு machine-ல் disposable container-ஐப் பயன்படுத்துவது நீங்கள் எதிர்கொள்ளும் பெரும்பாலான அபாயங்களைக் குறைக்கும். ஒரு agent நீண்ட நேரம் கவனிக்கப்படாமல், சரிபார்க்கப்படாத code-க்கு எதிராக இயங்கும்போது, மற்றும் அதற்கு /dev/kvm வசதியுள்ள host-ஐ வழங்க முடிந்தால், microVM-ஐத் தேர்ந்தெடுக்கவும். அது முடியாதபோது, ஒவ்வொரு பணிக்கும் பிறகு அழிக்கும் ஒரு container, உங்களால் boot செய்ய முடியாத microVM-ஐ விடச் சிறந்தது.

ஒரு microVM agent host-க்கு எவ்வளவு RAM தேவை?

Guest-ன் அளவிலிருந்து தொடங்கவும். 1 GB அளவுள்ள ஒரு headless guest-க்கு, 3 GB host reserve-உடன் சேர்த்து மொத்தம் 4 GB தேவைப்படும். தலா 2 GB அளவுள்ள 8 desktop guest-களுக்கு சுமார் 19 GB தேவைப்படும். Disk அளவு என்பது தனிப்பட்டது மற்றும் அதைத் தவறாகக் கணக்கிடுவது எளிது, ஏனெனில் host ஒரு kernel, root filesystems, ஒவ்வொரு guest வகைக்குமான ஒரு image மற்றும் இயங்கும் ஒவ்வொரு machine-க்குமான ஒரு snapshot ஆகியவற்றைச் சேமித்து வைக்கிறது.