メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/tomevault-io/skills-registry --skill lima-vm-operationsコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | lima-vm-operations |
| description | >- Use when this capability is needed. |
Guidance for installing, configuring, and running Lima — Linux VMs on macOS — on Apple Silicon Macs.
Scope: Lima 2.x on Apple Silicon (arm64) Macs running macOS 13 or later. Lima also runs on Intel Macs and Linux, but the defaults, performance, and feature set differ enough that those cases are out of scope here. Colima (a Docker-focused wrapper around Lima) is also out of scope.
Why a skill: Lima exposes a lot of knobs. The vz vs qemu choice, the four networking modes, and the mount-type selection each have consequences that aren't obvious from the help output. Choosing wrong gets you a VM that boots but can't reach the LAN, mounts your code read-only when you needed write, or runs at a fraction of the speed because it picked the wrong hypervisor. Defaults are right most of the time on Apple Silicon — this skill says when to deviate and why.
Before doing anything else, confirm the Mac is suitable and check what's already installed:
uname -m # must be arm64 for this skill's guidance
sw_vers # ProductVersion must be >= 13 for vz; >= 14 for full virtiofs
limactl --version 2>/dev/null || echo "lima not installed"
brew list --versions socket_vmnet 2>/dev/null || echo "socket_vmnet not installed"
If uname -m is x86_64, this skill's vmType: vz recommendations don't apply (vz is Apple-Silicon-only) — fall back to vmType: qemu.
For a one-call summary of host fitness, install state, and existing VMs, run /lima-doctor — it executes this Pre-Flight plus limactl list and recommends next actions. The unbounded /lima command is the menu/springboard for "what does this skill help with?"
Username gotcha: Lima derives the in-guest user from your macOS username, but Linux requires the username to match ^[a-z_][a-z0-9_-]*$. macOS names with dots, uppercase, or other characters (e.g. Jane.Doe, j.smith) get silently remapped to lima in the guest. That changes $HOME, the SSH user, and which path your ~ mount lands at. Check yours with id -un — if it doesn't match the regex, expect to use lima (not your Mac username) inside the VM, and write provisioning scripts accordingly. To opt out and keep a custom in-guest username, see references/lima-yaml.md (override.yaml section).
A related cosmetic side effect: limactl shell <name> tries to cd into the host's current working directory inside the guest. If that path isn't mounted, every shell invocation prints a harmless bash: line 1: cd: <path>: No such file or directory and lands you in $HOME instead. Quiet it with cd /tmp first, or pass --workdir=/ before the VM name (the flag must precede the VM name — limactl shell --workdir=/ <name> <cmd> works; limactl shell <name> --workdir / -- <cmd> fails confusingly).
vmType: vz on Apple Silicon. Apple's Virtualization.framework is faster and supports virtiofs mounts. Fall back to qemu only when vz can't satisfy a requirement (older macOS, certain device emulation).limactl edit <name> mutates the YAML of an existing VM; recreating to change one field loses VM state. The VM must be stopped to edit most fields.limactl validate ./my.yaml catches schema errors. It does not check arch matches between host and images: entries, that URLs resolve, or that mount paths exist — those are runtime concerns surfaced by limactl start. Use validate as a cheap typo gate, not a pre-flight green light.template:default, template:docker, template:k3s, etc.) encode the right vmType, image, and provisioning for common cases. Start from a template, then limactl edit to customize. (Lima 2.0+ uses template:<name>; older docs you'll find online still use template://<name> — that form is deprecated but still works.)writable: true if the guest needs to write — silent read-only mounts are a top source of "why is npm install failing inside the VM" confusion.127.0.0.1 automatically. You only need explicit portForwards: to remap ports or expose on 0.0.0.0.socket_vmnet.Pick a mode by what you need to reach:
networks:.socket_vmnet bridged.socket_vmnet shared or host.vzNAT: true (vz only).For the full mode table, decision rationale, host.lima.internal semantics, and the auto-port-forward deny-list, see references/networking.md.
Each reference file below is loaded on demand. Read the one that matches the current task — they don't duplicate content from this file or each other; they cross-link where needed.
references/installation.md — brew install steps, optional lima-additional-guestagents for cross-arch guests, and socket_vmnet sudoers setup.references/lifecycle.md — the limactl command surface: start, stop, list, shell, edit (including --set patches), delete, validate, factory-reset, plus where on disk Lima stores per-VM state.references/lima-yaml.md — annotated lima.yaml fields, the provision.mode table, the robust group-add pattern for adding the in-guest user to a group like docker, and the ~/.lima/_config/override.yaml workflow for opting out of the lima username remap.references/networking.md — full networking modes table, host.lima.internal resolver behavior, and auto-port-forward semantics + deny-list.references/mounts.md — virtiofs vs 9p vs reverse-sshfs, APFS case-insensitivity pitfalls, and mountInotify.references/workflows.md — common workflows: default Ubuntu VM, Docker host VM, running background processes from a single shell call, editing an existing VM's resources, x86_64 binaries via Rosetta, validating YAMLs.references/troubleshooting.md — log file locations, the read-stdout-first rule for startup failures, symptom→fix table, common gotchas, and the pre-mutation safety checklist.VM data lives at ~/.lima/<name>/ — lima.yaml (resolved config), diffdisk (qcow2 disk), serial.log (boot console), ha.stderr.log / ha.stdout.log (host agent logs). When troubleshooting, those logs are where the answers live (see references/troubleshooting.md).
Source: AeyeOps/aeo-skill-marketplace — distributed by TomeVault.