Smol machines – máy ảo portable với cold start dưới 1 giây

 (github.com/smol-machines)
6 điểm bởi GN⁺ 4 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • smolvm là công cụ quản lý máy ảo dựa trên CLI hoạt động trên macOS và Linux, dùng để chạy phần mềm trong môi trường cô lập
  • Hỗ trợ cold start dưới 1 giây, quản lý bộ nhớ co giãn và tính di động dạng một tệp duy nhất, cho phép chạy VM nhanh và gọn nhẹ
  • VM chạy dưới dạng microVM dựa trên kernel Linux, có thể đóng gói thành tệp .smolmachine để chạy lại mà không cần phụ thuộc
  • Hỗ trợ tích hợp cho môi trường phát triển và bảo mật với cô lập qua ranh giới hypervisor, SSH agent forwarding, khai báo môi trường bằng Smolfile
  • Hỗ trợ khởi động image OCI mà không cần Docker daemon, đồng thời đưa ra một lựa chọn thay thế cho ảo hóa nhẹ với thời gian boot dưới 200ms và khả năng cô lập ở mức phần cứng

Tổng quan

  • smolvm là công cụ quản lý máy ảo dựa trên CLI để chạy phần mềm trong môi trường cô lập
  • Chạy trên macOS và Linux, hỗ trợ cold start dưới 1 giây, sử dụng bộ nhớ co giãn và đóng gói portable dưới dạng một tệp duy nhất
  • Mỗi workload chạy dưới dạng microVM dựa trên kernel Linux, cung cấp mức độ cô lập ở cấp phần cứng
  • VM được đóng gói thành tệp .smolmachine có thể chạy lại mà không cần phụ thuộc trên các nền tảng cùng kiến trúc

Tính năng chính

  • Quản lý và chạy máy ảo cục bộ

    • Chạy Linux VM tùy biến bằng lệnh smolvm machine run
    • Cold start dưới 1 giây, hỗ trợ cả macOS và Linux
    • Bộ nhớ được quản lý co giãn bằng virtio balloon, nên host chỉ được cấp phát đúng phần đang dùng thực tế

  • Đóng gói portable dạng một tệp duy nhất

    • Có thể gói thành tệp .smolmachine bao gồm cả trạng thái VM để tái tạo trên nền tảng khác
    • Tất cả phụ thuộc đều được nhúng sẵn nên có thể chạy ngay mà không cần cài đặt, thời gian boot dưới 200ms

  • Sandbox cho mã không đáng tin cậy

    • Filesystem, mạng và thông tin xác thực của host được tách biệt hoàn toàn thông qua ranh giới hypervisor
    • Mạng bị tắt theo mặc định, chỉ có thể cho phép một số host cụ thể bằng tùy chọn --allow-host

  • VM bền vững cho phát triển

    • Tạo và quản lý VM bằng các lệnh machine create, start, stop
    • Các gói đã cài vẫn được giữ lại sau khi khởi động lại, phù hợp để dùng làm môi trường phát triển

  • SSH agent forwarding

    • Chuyển tiếp SSH agent của host vào trong VM nhưng khóa riêng không bị sao chép sang guest
    • Có thể dùng an toàn thông tin xác thực SSH của host bằng tùy chọn --ssh-agent

  • Khai báo môi trường bằng Smolfile

    • Khai báo cấu hình VM bằng Smolfile định dạng TOML
    • Có thể chỉ định image, mạng, lệnh khởi tạo, volume, tùy chọn xác thực... để tạo môi trường có thể tái lập

Ví dụ sử dụng

  • Chạy VM tạm thời

    • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
    • Cách chạy một lần, VM sẽ tự động được dọn dẹp khi kết thúc

  • Tạo tệp thực thi đã đóng gói

    • smolvm pack create --image python:3.12-alpine -o ./python312
    • Có thể chạy một môi trường Python độc lập bằng tệp thực thi được tạo ra

  • Kiểm soát mạng

    • Mạng bị vô hiệu hóa theo mặc định
    • Có thể chỉ cho phép truy cập một số domain cụ thể bằng tùy chọn --allow-host

  • Dùng SSH và Git

    • smolvm machine run --ssh-agent --net --image alpine
    • Có thể truy cập kho Git bằng cách dùng an toàn khóa SSH của host

Cấu trúc bên trong và cách hoạt động

  • Mỗi workload chạy kernel riêng trên Hypervisor.framework (macOS) hoặc KVM (Linux)
  • Sử dụng VMM dựa trên libkrun và kernel tùy biến (libkrunfw)
  • Hỗ trợ định dạng image OCI, có thể lấy trực tiếp image từ Docker Hub, ghcr.io... để chạy
  • Không cần Docker daemon, có thể boot trực tiếp image OCI tiêu chuẩn
  • Cấu hình mặc định là 4 vCPU, 8GiB RAM, có thể điều chỉnh bằng các tùy chọn --cpus, --mem
  • Luồng vCPU sẽ tự động chuyển sang chế độ tiết kiệm khi rảnh ở hypervisor nên gần như không có chi phí overcommit

So sánh

Hạng mục smolvm Containers Colima QEMU Firecracker Kata
Mức độ cô lập VM cho từng workload Namespace (kernel dùng chung) Namespace (một VM duy nhất) VM riêng lẻ VM riêng lẻ VM cho từng container
Thời gian boot <200ms khoảng 100ms vài giây 15~30 giây <125ms khoảng 500ms
Kiến trúc Thư viện (libkrun) Daemon Daemon trong VM Process Process Runtime stack
VM theo từng workload Hỗ trợ Không hỗ trợ Dùng chung Hỗ trợ Hỗ trợ Hỗ trợ
macOS native Hỗ trợ Thông qua Docker VM Dựa trên krunkit Hỗ trợ Không hỗ trợ Không hỗ trợ
SDK tích hợp Hỗ trợ Không hỗ trợ Không hỗ trợ Không hỗ trợ Không hỗ trợ Không hỗ trợ
Artifact portable .smolmachine Image cần daemon Không hỗ trợ Không hỗ trợ Không hỗ trợ Không hỗ trợ

Hỗ trợ nền tảng

Host Guest Yêu cầu
macOS Apple Silicon arm64 Linux macOS 11 trở lên
macOS Intel x86_64 Linux macOS 11 trở lên (chưa kiểm thử đầy đủ)
Linux x86_64 x86_64 Linux Cần KVM(/dev/kvm)
Linux aarch64 aarch64 Linux Cần KVM(/dev/kvm)

Các hạn chế đã biết

  • Mạng bị tắt theo mặc định, chỉ có thể bật bằng tùy chọn --net
  • Chỉ hỗ trợ TCP/UDP, không hỗ trợ ICMP
  • Volume mount chỉ hỗ trợ ở cấp thư mục, không hỗ trợ một tệp đơn lẻ
  • Trên macOS, chỉ có thể chạy binary được ký với quyền Hypervisor.framework
  • Khi dùng --ssh-agent, host phải đang chạy SSH agent (SSH_AUTH_SOCK cần được thiết lập)

Liên quan đến phát triển

  • Có thể xem hướng dẫn phát triển tại docs/DEVELOPMENT.md
  • Được phát hành theo giấy phép Apache-2.0 và do @binsquare tạo ra

Bài viết liên quan

1 bình luận

 
GN⁺ 4 ngày trước
Ý kiến trên Hacker News

  • Tôi đang làm một máy ảo có thể thay thế Docker container
    Mục tiêu là giữ nguyên tính tiện dụng của container (ergonomics) nhưng vẫn đạt thời gian khởi động dưới 1 giây
    Trong lúc làm việc liên quan đến Firecracker ở AWS, tôi nhận ra container là một lớp không cần thiết, còn Firecracker là công nghệ được thiết kế phù hợp với kiến trúc nội bộ của AWS
    Vì vậy tôi đã tự tạo ra một dạng hybrid kết hợp ưu điểm của container và Firecracker
    Tôi muốn nghe ý kiến của mọi người

    • Cái này thật sự rất ngầu. Tôi cũng từng nghiên cứu giải pháp sandboxing cho AI và đã tạo Locki bằng tổ hợp Lima+Incus
      Vấn đề là microVM thường không chạy được Docker hay Kubernetes
      Tôi muốn đưa cả cụm Kubernetes vào trong sandbox. Không biết có hỗ trợ chạy k3s không
    • Tôi muốn hỏi hiện trạng hỗ trợ live migration đang thế nào
      Đây luôn là tính năng bị thiếu trong các hệ thống tương tự, nhưng ngoài workload cloud-native thì vẫn còn nhiều môi trường cần tính năng này
      Nếu thêm được tính năng này thì đây sẽ thật sự là điểm khác biệt lớn
    • Tôi tò mò không biết có bao nhiêu phần trong code là được viết bằng LLM/AI
    • Tôi cũng đã làm một thứ tương tự — tên là shuru.run
      Vì Firecracker không chạy trên macOS, tôi muốn có cách dễ dàng để tạo sandbox microVM cho các ứng dụng AI
      Với người dùng phổ thông thì Firecracker quá nặng
    • Tôi muốn biết thách thức thiết kế khó nhất để đạt được thời gian boot dưới 1 giây là gì
      Và nếu muốn giảm thời gian đó hơn nữa thì hiện tại các điểm nghẽn nằm ở đâu

  • Dự án này nghe khá giống với nhiều triển khai unikernel — ví dụ như Unikraft

    • Tôi không rõ bên trong Unikraft thế nào vì nó không phải mã nguồn mở
      Nhưng Smol Machines không phải là triển khai unikernel mà là phiên bản Linux kernel được tinh gọn
      Vì vậy nó có độ tương thích cao với phần lớn phần mềm

  • Tính năng tạo binary tự chứa trông giống một cách để đóng gói ứng dụng JVM đơn giản hơn cả GraalVM Native
    Ví dụ lệnh:
    smolvm pack create --image python:3.12-alpine -o ./python312
    ./python312 run -- python3 --version
    → Python 3.12.x sẽ chạy trong trạng thái hoàn toàn cô lập, không cần pyenv/venv/conda

    • Đây là ý tưởng tương tự Electron
      Cũng như Electron phân phối web app kèm theo trình duyệt, Smol Machines đóng gói phần mềm cùng với Linux VM
      Có thể tránh được các vấn đề về quản lý phụ thuộc hay tương thích
      Cá nhân tôi nghĩ sẽ rất hay nếu các công cụ như Codex hay Claude Code cũng được phân phối theo cách này
    • Chắc ai cũng từng có ít nhất một lần “phá hỏng môi trường phát triển” của mình
      Đây là khái niệm ‘máy có thể phân phối’ để giải quyết vấn đề đó
      Chỉ cần thiết lập chuẩn một lần là có thể chia sẻ và chạy ngay cho bất kỳ ai

  • Tôi muốn biết liệu file .smolmachine có hỗ trợ chữ ký số và tự chứng thực hay không
    Tôi muốn biết nó có thể hoạt động tương tự tài liệu ký/xác minh của Sylabs không

  • Tôi tò mò liệu có thể làm nó nhanh hơn nữa bằng cách áp dụng ý tưởng từ zeroboot hay không

  • Bảng so sánh được làm rất tốt
    Ban đầu tôi nghĩ “trông giống Firecracker nhỉ”, nhưng sau khi xem bảng thì thấy sự khác biệt rất rõ
    Rất dễ xem, và nhìn chung đây là một công trình cực kỳ ấn tượng

    • Cảm ơn bạn

  • Tôi thấy các image alpine và python:3.12-alpine trong tài liệu CLI, nên muốn biết chúng đến từ đâu
    Chúng được lấy từ đâu đó như Docker registry, là image tích hợp sẵn, hay do tự tạo bằng smolfile?
    Tôi cũng muốn biết có image Ubuntu không
    Sẽ rất hay nếu có thêm tính năng hot resize bộ nhớ/CPU, và có vẻ cũng có thể dùng cho orchestration hạ tầng backend theo từng khách hàng

  • Phần lớn dự án mã nguồn mở đều khởi chạy container bằng Docker Compose, nhưng Smol Machines không hỗ trợ Docker bên trong microVM
    Ngoài ra cũng hơi tiếc vì nó không hỗ trợ nested VM như Vagrant

    • Docker đã nằm trong kế hoạch hỗ trợ. Chúng tôi dự định phát hành kernel tương thích có kèm các kernel flag cần thiết ở bản phát hành tiếp theo
    • Có vẻ Vagrant cần nesting vì nó khởi chạy VM ở máy cục bộ
      Thay vào đó, tôi đề xuất thử cách trampoline để chạy nó như một sibling VM của VM Vagrant

  • Tôi muốn nghe phần giải thích ngắn gọn về lý do cốt lõi khiến nên dùng Smol Machines thay vì Docker sandbox

  • Đây thật sự là một sản phẩm rất tuyệt. Chúc mừng