Smol machines – 1 सेकंड से कम cold start और portable virtual machine

• smolvm macOS और Linux पर चलने वाला CLI-आधारित virtual machine management tool है, जो isolated environment में software चलाने के लिए बनाया गया है
• यह sub-second (1 सेकंड से कम) cold start, elastic memory management, और single-file portability सपोर्ट करता है, जिससे तेज़ और हल्का VM execution संभव होता है
• VM, Linux kernel-आधारित microVM के रूप में चलते हैं, और .smolmachine फ़ाइल में पैकेज होकर बिना dependency के दोबारा चलाए जा सकते हैं
• hypervisor boundary isolation, SSH agent forwarding, और Smolfile-आधारित environment declaration के ज़रिए यह development और security environments को एक साथ सपोर्ट करता है
• यह Docker daemon के बिना OCI image boot करना सपोर्ट करता है, और 200ms से कम boot time व hardware-level isolation के साथ हल्के virtualization का एक विकल्प पेश करता है

---

अवलोकन

• smolvm एक CLI-आधारित virtual machine management tool है, जो isolated environment में software चलाने के लिए बनाया गया है
• यह macOS और Linux पर चलता है, और sub-second cold start, elastic memory usage, तथा portable single-file packaging सपोर्ट करता है
• हर workload, Linux kernel-आधारित microVM के रूप में चलता है और hardware-level isolation देता है
• .smolmachine फ़ाइल में पैकेज किया गया VM, समान architecture वाले प्लेटफ़ॉर्म पर बिना dependency के फिर से चलाया जा सकता है

मुख्य फीचर

• लोकल virtual machine management और execution

  • smolvm machine run कमांड से custom Linux VM चलाया जा सकता है
  • cold start 1 सेकंड से कम है, और macOS व Linux दोनों सपोर्टेड हैं
  • memory को virtio balloon के ज़रिए elastic तरीके से manage किया जाता है, जिससे host पर केवल वास्तविक उपयोग जितनी memory allocate होती है

• portable single-file packaging

  • VM state सहित .smolmachine फ़ाइल में पैक करके इसे दूसरे प्लेटफ़ॉर्म पर दोबारा बनाया जा सकता है
  • सभी dependency built-in होती हैं, इसलिए installation के बिना तुरंत चलाया जा सकता है, और boot time 200ms से कम है

• untrusted code sandboxing

  • hypervisor boundary के माध्यम से host filesystem, network, credentials को पूरी तरह अलग किया जाता है
  • डिफ़ॉल्ट network बंद रहता है, और --allow-host विकल्प से केवल खास host को अनुमति दी जा सकती है

• persistent development VM

  • machine create, start, stop कमांड से VM बनाए और manage किए जा सकते हैं
  • installed packages restart के बाद भी बने रहते हैं, इसलिए इसे development environment के रूप में उपयोग किया जा सकता है

• SSH agent forwarding

  • host का SSH agent VM के अंदर forward किया जाता है, लेकिन private key guest में कॉपी नहीं होती
  • --ssh-agent विकल्प के ज़रिए host की SSH authentication को सुरक्षित रूप से उपयोग किया जा सकता है

• Smolfile-आधारित environment declaration

  • TOML फ़ॉर्मैट के Smolfile से VM configuration declare की जा सकती है
  • image, network, init commands, volume, authentication options आदि तय करके reproducible environment configuration बनाया जा सकता है

उपयोग उदाहरण

• अस्थायी VM चलाना

  • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
  • यह एक one-off execution तरीका है, जिसमें VM बंद होते ही अपने-आप साफ़ हो जाता है

• packaged executable बनाना

  • smolvm pack create --image python:3.12-alpine -o ./python312
  • बने हुए executable से स्वतंत्र Python environment चलाया जा सकता है

• network control

  • डिफ़ॉल्ट network बंद रहता है
  • --allow-host विकल्प से केवल विशेष domain तक access दिया जा सकता है

• SSH और Git का उपयोग

  • smolvm machine run --ssh-agent --net --image alpine
  • host की SSH key को सुरक्षित रूप से उपयोग करके Git repository तक पहुँचा जा सकता है

आंतरिक संरचना और काम करने का तरीका

• हर workload, Hypervisor.framework(macOS) या KVM(Linux) के ऊपर independent kernel चलाता है
• यह libkrun-आधारित VMM और custom kernel(libkrunfw) का उपयोग करता है
• OCI image format सपोर्ट होने से Docker Hub, ghcr.io आदि से image सीधे लाकर चलाई जा सकती है
• Docker daemon की ज़रूरत नहीं, standard OCI image को सीधे boot किया जा सकता है
• डिफ़ॉल्ट configuration 4 vCPU, 8GiB RAM है, जिसे --cpus, --mem विकल्प से बदला जा सकता है
• vCPU threads idle होने पर hypervisor में अपने-आप sleep mode में चले जाते हैं, इसलिए over-allocation cost लगभग नहीं के बराबर है

तुलना

मद	smolvm	Containers	Colima	QEMU	Firecracker	Kata
isolation level	workload-प्रति VM	namespace (shared kernel)	namespace (single VM)	individual VM	individual VM	container-प्रति VM
boot time	<200ms	लगभग 100ms	कुछ सेकंड	15~30 सेकंड	<125ms	लगभग 500ms
architecture	library (libkrun)	daemon	VM के अंदर daemon	process	process	runtime stack
workload-प्रति VM	समर्थित	समर्थित नहीं	shared	समर्थित	समर्थित	समर्थित
macOS native	समर्थित	Docker VM के माध्यम से	krunkit-आधारित	समर्थित	समर्थित नहीं	समर्थित नहीं
SDK built-in	समर्थित	समर्थित नहीं	समर्थित नहीं	समर्थित नहीं	समर्थित नहीं	समर्थित नहीं
portable artifact	.smolmachine	daemon की ज़रूरत वाली image	समर्थित नहीं	समर्थित नहीं	समर्थित नहीं	समर्थित नहीं

प्लेटफ़ॉर्म सपोर्ट

host	guest	आवश्यकताएँ
macOS Apple Silicon	arm64 Linux	macOS 11 या बाद का
macOS Intel	x86_64 Linux	macOS 11 या बाद का (परीक्षण अधूरा)
Linux x86_64	x86_64 Linux	KVM(/dev/kvm) आवश्यक
Linux aarch64	aarch64 Linux	KVM(/dev/kvm) आवश्यक

ज्ञात सीमाएँ

• network डिफ़ॉल्ट रूप से बंद है, और केवल --net विकल्प से चालू किया जा सकता है
• केवल TCP/UDP सपोर्टेड हैं, ICMP सपोर्टेड नहीं है
• volume mount सिर्फ directory स्तर पर संभव है, single file नहीं
• macOS पर केवल Hypervisor.framework permission से signed binary ही चल सकती है
• --ssh-agent उपयोग करते समय host पर SSH agent चल रहा होना चाहिए (SSH_AUTH_SOCK सेट होना आवश्यक)

विकास संबंधी

• development guidelines docs/DEVELOPMENT.md में देखी जा सकती हैं
• यह Apache-2.0 license के तहत उपलब्ध है, और इसे @binsquare ने बनाया है

[GN⁺]

Hacker News की राय

• मैं Docker containers की जगह लेने वाली virtual machines बना रहा हूँ
  लक्ष्य है containers की usability (ergonomics) को बनाए रखते हुए 1 सेकंड से कम startup time हासिल करना
  AWS में Firecracker से जुड़ा काम करते हुए मुझे एहसास हुआ कि containers एक गैर-ज़रूरी layer हैं, और Firecracker ऐसी technology थी जिसे AWS की internal architecture के हिसाब से design किया गया था
  इसलिए मैंने खुद एक hybrid form बनाना शुरू किया जो containers के फ़ायदों और Firecracker के फ़ायदों को जोड़ती है
  राय सुनना चाहूँगा

  • यह सच में बहुत शानदार है। मैंने भी AI sandboxing solution पर शोध करते हुए Lima+Incus संयोजन से Locki बनाया था
    microVM आम तौर पर Docker या Kubernetes नहीं चला पाते, इसलिए यह एक चिंता थी
    मैं पूरे Kubernetes cluster को sandbox के अंदर रखना चाहता हूँ। क्या यह k3s चलाना भी support करता है?
  • मैं जानना चाहता हूँ कि live migration support की स्थिति क्या है
    ऐसे मिलते-जुलते systems में यह feature अक्सर गायब होता है, लेकिन cloud-native workloads के अलावा भी अभी कई environments हैं जहाँ इसकी ज़रूरत पड़ती है
    अगर यह feature जोड़ा जाए तो यह सच में एक अलग पहचान बनाने वाला point हो सकता है
  • मैं जानना चाहता हूँ कि code का कितना हिस्सा LLM/AI से लिखा गया है
  • मैंने भी कुछ ऐसा ही बनाया था — नाम है shuru.run
    Firecracker macOS पर नहीं चलता, इसलिए मैं AI apps के लिए microVM sandbox आसानी से बनाना चाहता था
    आम users के नज़रिए से Firecracker बहुत भारी है
  • 1 सेकंड से कम boot time हासिल करने के लिए सबसे कठिन design challenge क्या था, यह जानना चाहता हूँ
    और अगर उस समय को और कम करना हो, तो अभी कौन-कौन से bottlenecks हैं, यह भी जानना चाहूँगा

• यह project कई unikernel implementations जैसा लगता है — जैसे Unikraft

  • Unikraft के अंदरूनी हिस्सों के बारे में ज़्यादा नहीं जानता क्योंकि वह open source नहीं है
    लेकिन Smol Machines कोई unikernel implementation नहीं है, बल्कि Linux kernel का slimmed-down version है
    इसलिए यह ज़्यादातर software के साथ अच्छी compatibility देता है

• self-contained binaries बनाने की feature JVM apps को GraalVM Native से भी आसान तरीके से package करने का तरीका लगती है
  उदाहरण command:
  smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
  → Python 3.12.x पूरी तरह isolated state में चलता है, pyenv/venv/conda की ज़रूरत नहीं होती

  • यह Electron जैसा concept है
    जैसे Electron web apps को browser के साथ ship करता है, वैसे ही Smol Machines software को Linux VM के साथ package करता है
    इससे dependency management और compatibility issues से बचा जा सकता है
    व्यक्तिगत रूप से मुझे अच्छा लगेगा अगर Codex या Claude Code जैसे tools भी इसी तरह distribute किए जाएँ
  • लगभग हर किसी ने कभी न कभी “development environment खराब कर देने” का अनुभव किया होगा
    यह उस समस्या को हल करने के लिए ‘distributable machine’ का concept है
    एक बार setup ठीक से हो जाए, तो इसे किसी के साथ भी तुरंत share और run किया जा सकता है

• मैं जानना चाहता हूँ कि .smolmachine file digital signatures और self-attestation support करती है या नहीं
  क्या यह Sylabs के signing/verification docs की तरह काम कर सकती है?

• मैं जानना चाहता हूँ कि zeroboot के ideas लागू करके इसे और तेज़ बनाया जा सकता है या नहीं

• comparison table सच में बहुत अच्छी बनी है
  शुरुआत में लगा, “यह तो Firecracker जैसा है,” लेकिन table देखकर differences बहुत साफ़ दिखे
  देखना आसान था, और कुल मिलाकर यह बहुत प्रभावशाली काम है

  • धन्यवाद

• मैंने CLI docs में alpine और python:3.12-alpine images देखीं, और मैं जानना चाहता हूँ कि ये कहाँ से आती हैं
  क्या ये Docker registry जैसी किसी जगह से ली जाती हैं, built-in हैं, या smolfile से सीधे बनाई जाती हैं?
  क्या Ubuntu images भी हैं?
  अगर memory/CPU hot resize feature जुड़ जाए तो अच्छा होगा, और यह customer-by-customer backend infrastructure orchestration में भी काम आ सकता है

• ज़्यादातर open source projects Docker Compose से containers उठाते हैं, लेकिन Smol Machines microVM के अंदर Docker support नहीं करता
  और Vagrant जैसे nested VM भी support नहीं करता, यह थोड़ी कमी लगती है

  • Docker support की योजना है। अगली release में ज़रूरी kernel flags वाला compatible kernel distribute करने का plan है
  • चूँकि Vagrant local पर VM चलाता है, इसलिए शायद nesting की ज़रूरत पड़ती है
    इसके बदले trampoline approach से इसे Vagrant VM के sibling VM की तरह चलाने का सुझाव देता हूँ

• क्या आप संक्षेप में बता सकते हैं कि Docker sandbox की जगह Smol Machines इस्तेमाल करने की मुख्य वजह क्या है?

• यह सच में शानदार नतीजा है। बधाई