smol-machines/smolvmपोर्टेबल, हल्का, स्व-निहित वर्चुअल मशीन।
डिफ़ॉल्ट रूप से आइसोलेशन के साथ सॉफ़्टवेयर शिप और चलाएँ।
यह एक CLI टूल है जो आपको निम्न की अनुमति देता है:
# इंस्टॉल करें (macOS + Linux)
curl -sSL https://smolmachines.com/install.sh | bash
# कोडिंग एजेंटों के लिए — इंस्टॉल करें + सभी कमांड खोजें
curl -sSL https://smolmachines.com/install.sh | bash && smolvm --help
या GitHub Releases से डाउनलोड करें, और इसे ~/.local/share/ में रखें।
Windows: windows-x86_64 रिलीज़ डाउनलोड करें (इसमें krun.dll + libkrunfw.dll शामिल हैं), इसे अनज़िप करें, और smolvm.exe चलाएँ। Windows Hypervisor Platform (WHP) सुविधा सक्षम होना आवश्यक है।
# एक अस्थायी VM में कमांड चलाएँ (बाहर निकलने के बाद साफ़ हो जाता है)
smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"
# इंटरैक्टिव शेल
smolvm machine run --net -it --image alpine -- /bin/sh
# VM के अंदर: apk add sl && sl && exit
एक Smolfile TOML में एक मशीन घोषित करता है — यह Dockerfile या cloud-init फ़ाइल के समकक्ष है, लेकिन पूरे VM के लिए: इमेज, संसाधन, नेटवर्क नीति, माउंट, पोर्ट, और सेटअप कमांड एक ही चेक-इन फ़ाइल में।
image = "python:3.12-alpine"
net = true
cpus = 4
memory = 4096
ports = ["8000:8000", "5173-5180:5173-5180"]
volumes = ["./src:/app"]
init = ["pip install -r /app/requirements.txt"]
[network]
allow_hosts = ["api.stripe.com", "pypi.org"]
[auth]
ssh_agent = true
smolvm machine create --name myvm -s Smolfile # या --smolfile <PATH>
smolvm machine start --name myvm
पोर्ट मैपिंग एकल पोर्ट ("8080"), एक स्पष्ट मैपिंग ("8080:80"), या समान-लंबाई वाले एक-से-एक रेंज ("5173-5180:5173-5180") स्वीकार करती है। एक मशीन अधिकतम 64 ठोस मैपिंग प्रकाशित कर सकती है।
अज्ञात कुंजियों को अनदेखा करने के बजाय अस्वीकार कर दिया जाता है, इसलिए एक टाइपो क्रिएट समय पर विफल हो जाता है, चुपचाप कुछ न करने के बजाय।
सामान्य कुंजियाँ: image, cpus, memory, net, ports, volumes, env, init, workdir, gpu, cuda, docker_socket, storage, overlay, और [network], [dev], [auth], [health], [restart], [service] टेबल।
पर्यावरण बनाए रखने के लिए आपको Dockerfile की आवश्यकता नहीं है। एक मशीन को अपनी पसंद के अनुसार सेट करें — हाथ से, या Smolfile से — फिर बंद मशीन को .smolmachine आर्टिफैक्ट में पैक करें और इसे किसी भी OCI रजिस्ट्री में पुश करें:
smolvm machine shell --name myvm # इंटरैक्टिव रूप से इंस्टॉल और कॉन्फ़िगर करें
smolvm machine stop --name myvm
smolvm pack create --from-vm myvm -o myvm
smolvm pack push --file myvm.smolmachine ghcr.io/you/myvm:v1
कोई भी इसे खींच सकता है और ठीक उसी मशीन को बूट कर सकता है:
smolvm pack pull ghcr.io/you/myvm:v1
काम करने वाले Smolfiles: python · node · docker-in-vm · local-llm · headless-browser · doom
अविश्वसनीय कोड को सैंडबॉक्स करें — अविश्वसनीय प्रोग्राम को हार्डवेयर-आइसोलेटेड VM में चलाएँ। होस्ट फ़ाइलसिस्टम, नेटवर्क, और क्रेडेंशियल हाइपरवाइज़र सीमा द्वारा अलग किए जाते हैं।
# नेटवर्क डिफ़ॉल्ट रूप से बंद है — अविश्वसनीय कोड बाहर संपर्क नहीं कर सकता
smolvm machine run --image alpine -- nslookup example.com
# विफल — कोई नेटवर्क एक्सेस नहीं
# ईग्रेस लॉक करें — केवल विशिष्ट होस्ट की अनुमति दें
smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -q -O /dev/null https://registry.npmjs.org
# काम करता है — अनुमत होस्ट
smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -q -O /dev/null https://google.com
# विफल — अनुमति सूची में नहीं
पोर्टेबल निष्पादन योग्य में पैक करें — किसी भी वर्कलोड को एक स्व-निहित बाइनरी में बदलें। सभी निर्भरताएँ पहले से बेक की जाती हैं — कोई इंस्टॉल चरण नहीं, कोई रनटाइम डाउनलोड नहीं, <200ms में बूट होता है।
smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
# Python 3.12.x — आइसोलेटेड, कोई pyenv/venv/conda आवश्यक नहीं
स्थानीय कंटेनर इमेज का उपयोग करें — CI, एयर-गैप्ड होस्ट, और तेज़ पुनरावृत्ति के लिए। --image को docker save / podman save आर्काइव दें, stdin पर पाइप करें, या अनपैक्ड rootfs निर्देशिका की ओर इंगित करें। इमेज कार्य आपके कंटेनर टूलिंग को सौंपा जाता है; smolvm केवल परिणाम बूट करता है।
# स्थानीय रूप से बनाएँ, बिना push/pull के VM में चलाएँ
docker build -t myapp .
docker save myapp | smolvm machine run --image - -- ./app
# आर्काइव फ़ाइल से (बिना नेटवर्क के बूट होता है)
smolvm machine run --image ./myapp.tar -- ./app
# पहले से अनपैक्ड rootfs निर्देशिका से
smolvm machine run --image ./rootfs/ -- ./app
विकास के लिए स्थायी मशीनें — बनाएँ, रोकें, प्रारंभ करें। इंस्टॉल किए गए पैकेज रीस्टार्ट के बाद बने रहते हैं।
smolvm machine create --net --name myvm
smolvm machine start --name myvm
smolvm machine exec --name myvm -- apk add sl
smolvm machine exec --name myvm -it -- /bin/sh
# अंदर: sl, ls, uname -a — बाहर निकलने के लिए 'exit' टाइप करें
smolvm machine stop --name myvm
निजी कुंजियों को गेस्ट में कॉपी किए बिना git और SSH का उपयोग करें। अपने होस्ट SSH एजेंट को VM में फॉरवर्ड करें। गेस्ट एजेंट से किसी भी फॉरवर्ड की गई कुंजी के साथ साइन करने के लिए कह सकता है जबकि सॉकेट उपलब्ध है, इसलिए इसे केवल उन वर्कलोड्स को फॉरवर्ड करें जिन पर आप भरोसा करते हैं। आपके होस्ट पर एक SSH एजेंट चल रहा होना आवश्यक है (ssh-add -l से जाँचें)।
smolvm machine run --ssh-agent --net --image alpine -- sh -c "apk add -q openssh-client && ssh-add -l"
# आपकी होस्ट कुंजियाँ सूचीबद्ध करता है; निजी कुंजी सामग्री होस्ट एजेंट में रहती है
smolvm machine exec --name myvm -- git clone [email protected]:org/private-repo.git
फ़ाइल में पर्यावरण घोषित करें — प्रतिलिपि योग्य मशीन कॉन्फ़िगरेशन के लिए ऊपर Smolfile देखें, और Dockerfile लिखे बिना कॉन्फ़िगर की गई मशीन को पुनः उपयोग योग्य .smolmachine इमेज में स्नैपशॉट करने के लिए।
प्रत्येक वर्कलोड एक हार्डवेयर-वर्चुअलाइज़्ड VM में अपने स्वयं के गेस्ट कर्नेल के साथ Hypervisor.framework (macOS), KVM (Linux), या Windows Hypervisor Platform (Windows) पर चलता है। libkrun VMM है और libkrunfw गेस्ट कर्नेल प्रदान करता है। इसे .smolmachine में पैक करें और यह कहीं भी चलता है जहाँ होस्ट आर्किटेक्चर मेल खाता है, शून्य निर्भरताओं के साथ।
इमेज OCI प्रारूप का उपयोग करती हैं — वही खुला मानक जो Docker उपयोग करता है। Docker Hub, ghcr.io, या अन्य OCI रजिस्ट्रियों पर कोई भी इमेज खींची और माइक्रोVM के रूप में बूट की जा सकती है। कोई Docker डेमन आवश्यक नहीं है।
डिफ़ॉल्ट: 4 vCPU, 8 GiB RAM। मेमोरी virtio balloon के माध्यम से लोचदार है — होस्ट केवल वही प्रतिबद्ध करता है जो गेस्ट वास्तव में उपयोग करता है और बाकी को स्वचालित रूप से पुनः प्राप्त करता है। vCPU थ्रेड निष्क्रिय होने पर हाइपरवाइज़र में सोते हैं, इसलिए ओवर-प्रोविज़निंग की लागत लगभग शून्य है। --cpus और --mem के साथ ओवरराइड करें।
smolvm प्रत्येक वर्कलोड को एक अलग VM और गेस्ट कर्नेल देकर गेस्ट/होस्ट सीमा को मजबूत करता है। यह अपने आप में एक कठोर मल्टी-यूज़र कंट्रोल प्लेन नहीं है:
smolvm CLI और VMM प्रक्रियाएँ आमंत्रित होस्ट उपयोगकर्ता की अनुमतियों के साथ चलती हैं। वह उपयोगकर्ता खाता, होस्ट OS, हाइपरवाइज़र बैकएंड, libkrun, और smolvm विश्वसनीय कंप्यूटिंग बेस में हैं।--volume के साथ पारित होस्ट निर्देशिकाएँ जानबूझकर अनुरोधित एक्सेस के साथ गेस्ट को उजागर की जाती हैं। अविश्वसनीय वर्कलोड में गोपनीय या संवेदनशील पथ माउंट न करें।--ssh-agent निजी कुंजी सामग्री को गेस्ट में कॉपी नहीं करता है, लेकिन यह गेस्ट को फॉरवर्ड किए गए एजेंट सॉकेट तक पहुँच प्रदान करता है और इसलिए VM चलने के दौरान हस्ताक्षर का अनुरोध करने की क्षमता प्रदान करता है।--net, पोर्ट फ़ॉरवर्डिंग, या होस्ट सेवाओं को सक्षम करना वर्कलोड की पहुँच योग्य सतह का विस्तार करता है।गेस्ट में रूट को अविश्वसनीय मानें। VM सीमा होस्ट तक इसकी सीधी पहुँच को सीमित करती है, जबकि हर स्पष्ट रूप से फॉरवर्ड की गई क्षमता, जिसमें माउंट, नेटवर्क एक्सेस, पोर्ट, और SSH एजेंट एक्सेस शामिल हैं, वर्कलोड के अधिकार का हिस्सा बन जाती है।
| smolvm | कंटेनर | Colima | QEMU | Firecracker | Kata | |
|---|---|---|---|---|---|---|
| वर्कलोड सीमा | VM + गेस्ट कर्नेल | नेमस्पेस + साझा कर्नेल | साझा VM के अंदर नेमस्पेस | VM + गेस्ट कर्नेल | VM + गेस्ट कर्नेल | प्रति कंटेनर VM |
| बूट समय | <200ms | ~100ms | ~सेकंड | ~15-30s | <125ms | ~500ms |
| आर्किटेक्चर | लाइब्रेरी (libkrun) | डेमन | डेमन (VM में) | प्रक्रिया | प्रक्रिया | रनटाइम स्टैक |
| प्रति-वर्कलोड VM | हाँ | नहीं | नहीं (साझा) | हाँ | हाँ | हाँ |
| macOS नेटिव | हाँ | Docker VM के माध्यम से | हाँ (krunkit) | हाँ | नहीं | नहीं |
| एम्बेडेबल SDK | हाँ | नहीं | नहीं | नहीं | नहीं | नहीं |
| पोर्टेबल आर्टिफैक्ट | .smolmachine | इमेज (डेमन आवश्यक) | नहीं | नहीं | नहीं | नहीं |
| होस्ट | गेस्ट | आवश्यकताएँ |
|---|---|---|
| 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) |
| Windows x86_64 | x86_64 Linux | Windows Hypervisor Platform (WHP) सक्षम |
machine create पर --net)। केवल TCP/UDP, कोई ICMP नहीं।/workspace पर माउंट करना (-v /host/dir:/workspace) डिफ़ॉल्ट स्टोरेज-डिस्क वर्कस्पेस पर प्राथमिकता लेता है — आपकी होस्ट निर्देशिका इसके बजाय उपयोग की जाती है।com.apple.security.hypervisor) के साथ हस्ताक्षरित होना चाहिए। शिप की गई रिलीज़ है; एक पुनः हस्ताक्षरित या नई बनाई गई बाइनरी चुपचाप इसे खो देती है और हर VM स्टार्ट तब krun_start_enter returned: -22 (EINVAL) के साथ विफल हो जाता है। इसे पुनः हस्ताक्षरित करें (एड-हॉक ठीक है): codesign --force --sign - --entitlements hv.entitlements <smolvm-bin> जहाँ hv.entitlements एक plist है जिसमें <key>com.apple.security.hypervisor</key><true/> होता है।--ssh-agent के लिए होस्ट पर एक SSH एजेंट चल रहा होना आवश्यक है (SSH_AUTH_SOCK सेट होना चाहिए)।GPU=1 के साथ बनाया जाना चाहिए और होस्ट पर virglrenderer + एक Vulkan ड्राइवर होना चाहिए (नीचे GPU त्वरण देखें)।--net अन्य प्लेटफ़ॉर्म की तरह ही काम करता है (इनबाउंड पोर्ट-फ़ॉरवर्डिंग के साथ virtio-net; आउटबाउंड-केवल VM के लिए TSI), साथ ही machine exec / इंटरैक्टिव सत्र और machine stats। Windows पर अभी उपलब्ध नहीं: GPU त्वरण और machine fork / स्नैपशॉट। Pack create को smolvm.exe के बगल में storage-template.ext4 / overlay-template.ext4 की आवश्यकता होती है (Windows में होस्ट mkfs.ext4 नहीं है)।smolvm होस्ट GPU को गेस्ट को virtio-gpu / Venus (Vulkan-over-virtio) के माध्यम से उजागर करता है। गेस्ट वर्कलोड एक वास्तविक Vulkan डिवाइस देखते हैं; Linux + Intel पर यह इस प्रकार प्रस्तुत होता है:
ANGLE (Intel, Vulkan 1.4 (Virtio-GPU Venus (Intel(R) UHD Graphics ...)), venus)
macOS — virglrenderer और MoltenVK smolvm वितरण में बंडल हैं। कोई अतिरिक्त इंस्टॉल आवश्यक नहीं है।
Linux — virglrenderer और एक होस्ट Vulkan ड्राइवर सिस्टम पैकेज मैनेजर से इंस्टॉल किया जाना चाहिए:
| डिस्ट्रो | पैकेज |
|---|---|
| Alpine | apk add virglrenderer mesa-vulkan-intel (या AMD के लिए mesa-vulkan-ati) |
| Debian/Ubuntu | apt install virglrenderer0 mesa-vulkan-drivers |
virglrenderer होस्ट GPU ड्राइवर स्टैक से libEGL और libdrm पर निर्भर करता है — ये हार्डवेयर-विशिष्ट हैं और बंडल नहीं किए जा सकते। कोई भी GPU-सक्षम Linux होस्ट उन्हें अपने GPU ड्राइवर के माध्यम से पहले से इंस्टॉल कर चुका होगा।
# CLI
smolvm machine run --gpu --image alpine -- vulkaninfo --summary
# Smolfile
# gpu = true
# gpu_vram = 2048 # MiB, डिफ़ॉल्ट 4096
गेस्ट Vulkan लोडर को virtio ICD की ओर इंगित किया जाना चाहिए:
export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/virtio_icd.x86_64.json
हेडलेस VM के अंदर हार्डवेयर-त्वरित WebGL के लिए ANGLE + Venus का उपयोग करने वाला एक काम करने वाला Chromium सेटअप देखने के लिए examples/headless-browser/ देखें।
--gpu और --cuda अलग-अलग इंटरफ़ेस प्रदान करते हैं। --gpu virtio-gpu / Venus के माध्यम से Vulkan उजागर करता है; यह CUDA प्रदान नहीं करता है। --cuda CUDA API रिमोटिंग सक्षम करता है: ड्राइवरलेस गेस्ट शिम vsock पर CUDA कॉल को होस्ट प्रक्रिया में फॉरवर्ड करते हैं, जो उन्हें होस्ट के NVIDIA ड्राइवर के माध्यम से निष्पादित करती है।
CUDA रिमोटिंग के लिए होस्ट पर एक NVIDIA GPU और एक काम करने वाला NVIDIA ड्राइवर आवश्यक है। यह GPU पासथ्रू नहीं है: गेस्ट को न तो भौतिक डिवाइस मिलता है और न ही NVIDIA ड्राइवर।
फोर्क-भारी Linux होस्ट को अपस्ट्रीम KVM फिक्स
916b7f4 युक्त कर्नेल का उपयोग करना चाहिए।
प्रभावित कर्नेल पर्याप्त होस्ट मेमोरी के बावजूद पहले KVM_RUN पर रुक-रुक कर ENOMEM रिपोर्ट कर सकते हैं;
smolvm एक्सपोज़र कम करता है और एक विफल वर्कर को बदल देता है, लेकिन कर्नेल अपडेट निश्चित फिक्स है।
VM सीमा अभी भी वर्कलोड के CPU, मेमोरी, और फ़ाइलसिस्टम को आइसोलेट करती है। GPU एक्सेस होस्ट प्रक्रियाओं और साझा होस्ट GPU द्वारा मध्यस्थ है, इसलिए GPU आइसोलेशन हार्डवेयर या VM सीमा के बजाय प्रक्रिया-स्तर पर रहता है। CUDA रिमोटिंग को कठोर मल्टी-टेनेंट GPU आइसोलेशन सीमा के रूप में न मानें।
डिज़ाइन, ट्रेड-ऑफ़, और पासथ्रू के साथ तुलना के लिए GPU access by API remoting: how a driverless microVM runs CUDA देखें।
docs/DEVELOPMENT.md देखें।
Apache-2.0 · @binsquare द्वारा निर्मित · twitter · github