எனது 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 வீதம் இது செயல்படுகிறது. இதன் README கோப்பு, எந்தவித தயக்கமும் இன்றி அதன் தேவையை இவ்வாறு குறிப்பிடுகிறது: "/dev/kvm கொண்ட ஒரு Linux box", இன்னும் துல்லியமாகச் சொன்னால் "Ubuntu 24.04, x86_64 அல்லது arm64, மற்றும் /dev/kvm (bare-metal, அல்லது nested virtualization வசதி கொண்ட VM) இதில் நீங்கள் root-SSH மூலம் நுழைய முடியும்".

ஆவணப்படுத்தப்பட்ட 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

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

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

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

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

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

இந்த daemon இயல்பாக 0.0.0.0:8080-ல் இயங்குகிறது. அந்த port-ஐ அணுகும் எவரும் புதிய machine-களை உருவாக்க முடியும், மேலும் அந்த machine-கள் நீங்கள் installer-க்கு வழங்கிய model key-ஐப் பயன்படுத்தும். அங்கீகாரத்தை (authentication) கட்டாயமாக்க NEHEMIAH_TOKEN-ஐ அமைக்கவும், அல்லது BIND_LOCALHOST=1-ஐ அமைப்பதன் மூலம் daemon-ஐ 127.0.0.1-ல் மட்டும் இயங்கச் செய்து, ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP வழியாக tunnel மூலம் அணுகவும். இந்த key-ஐ server-ல் உள்ள மற்ற ரகசியங்களைப் போலவே பாதுகாக்க வேண்டும், இது குறித்து keeping secrets out of AI agents பகுதியில் விரிவாகக் காணலாம்.

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

இதில் tagged release எதுவும் இல்லை. 10 August 2026 நிலவரப்படி, இந்த repository-ல் tags எதுவும் இல்லை. எனவே, main-ஐ clone செய்யும்போது, அன்று காலை வரை பதிவேற்றப்பட்ட மாற்றங்களே உங்களுக்குக் கிடைக்கும். ஒரு குறிப்பிட்ட commit-ஐப் பயன்படுத்தவும் (pin), உங்கள் server-ல் root உரிமையுடன் இயங்கும் முன் script-ஐப் படிக்கவும்:

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

இந்த repository ஜூன் 2026 இறுதியில் உருவாக்கப்பட்டது, எனவே இதை ஒரு புதிய மென்பொருளாகக் கருதவும். ஒவ்வொரு முறை update செய்த பிறகும் infra/setup.sh-ஐ மீண்டும் படிக்கவும்; ஏனெனில் நீங்கள் அனுமதிப்பது ஒரு 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-களுக்கும் தனக்கென 2 GB-யை ஒதுக்கி வைத்துக்கொள்ளும்.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

ஒரு நேரத்தில் ஒரு headless machine-க்கு சுமார் 3 GB தேவைப்படும்; KVM வசதி கொண்ட ஒரு நடுத்தர அளவு VPS-ல் இதை இயக்க முடியும். நான்கு machine-களுக்கு 6 GB தேவைப்படும். 8 desktop machine-களை இயக்கினால், இதே கணக்கீட்டின்படி, disk பயன்பாட்டைக் கணக்கிடுவதற்கு முன்பே 18 GB தேவைப்படும்.

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

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

Server என்பது செலவின் ஒரு பகுதி மட்டுமே. நீங்கள் ஒரு agent-க்கு வழங்கும் ஒவ்வொரு machine-ம் அது இயங்கும் வரை model tokens-ஐச் செலவழிக்கும். எனவே, ஒரு idle microVM memory-யைச் செலவழிக்கும், அதே சமயம் ஒரு busy 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 குழுவிற்குச் சொந்தமான ஒரு 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-ஆல், அதன் சொந்த 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 வசதியுள்ள திட்டத்தை வழங்கும் provider-ஐத் தேர்ந்தெடுப்பது அல்லது நீங்களே hypervisor-ஐக் கட்டுப்படுத்தும் ஒரு machine-ஐப் பயன்படுத்துவது.

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

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

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

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