首次 vagrant up 慢主因是 box 下载、cloud-init 初始化和 apt update；后续启动快因省略这些步骤；国内用户需换镜像源，注意内核模块、DNS 干扰及 guest 工具安装。
不用“秒级”，实际首次 vagrant up 至少 3–5 分钟；但后续 vagrant reload 或 vagrant up（已下载 box）确实能控制在 10–20 秒内完成启动和网络就绪。
为什么 vagrant up 第一次这么慢？
真正耗时的不是 VirtualBox 启动，而是三件事：box 镜像下载（尤其用官方源时）、cloud-init 初始化（配置网络/用户/SSH 密钥）、以及 Ubuntu/Debian 系统首次 apt update。KVM（libvirt）虽比 VirtualBox 启动快几秒，但这些步骤一个不少。
- 别信“秒级拉起”的宣传——那是忽略首次下载和初始化的简化说法
- 国内用户务必换镜像源，否则
vagrant box add卡在 0% 是常态 - VirtualBox 在 Linux 上依赖
vboxdrv内核模块，lsmod | grep vbox无输出就别往下试 - KVM 用户注意：
vagrant plugin install vagrant-libvirt后必须用vagrant up --provider=libvirt，否则默认仍走 VirtualBox
vagrant init 选 box 时该看什么？
Box 不是越新越好，也不是名字带 ubuntu/jammy64 就一定适配你的 Vagrant 版本。关键看两点：是否预装 open-vm-tools（VirtualBox）或 qemu-guest-agent（KVM），以及是否禁用 systemd-resolved（避免 NFS 挂载失败）。
- 推荐直接用清华、USTC 镜像站的 box：
vagrant box add ubuntu/jammy64 https://mirrors.tuna.tsinghua.edu.cn/ubuntu-cloud-images/releases/jammy/release/ubuntu-22.04-server-cloudimg-amd64-vagrant.box - OpenReplay 官方
Vagrantfile显式指定hashicorp/bionic64，是因为其内核（4.15）与 k3s v1.21 兼容性更稳，而非“更新更好” - CentOS/RHEL 系 box 要小心：
centos/7已 EOL，almalinux/9或rockylinux/9更合适，但需确认 Vagrant 插件支持
共享目录挂载失败？先查 /etc/fstab 和 systemd-resolved
90% 的 vagrant reload 后共享目录消失，不是 Vagrantfile 写错，而是宿主机干扰了挂载流程。VirtualBox 用 vboxsf，KVM 用 9p，两者都怕 systemd-resolved 拦截 DNS 请求导致超时。
- 临时解决：
sudo systemctl stop systemd-resolved && sudo systemctl disable systemd-resolved（Ubuntu 22.04+ 必做） - 检查
/etc/fstab是否有残留vboxsf条目，有就删掉——Vagrant 自己管理挂载，手动写 fstab 会冲突 - KVM 下若报
mount: /vagrant: wrong fs type, bad option, bad superblock，大概率是没装qemu-guest-agent或未启用 9p 支持 - 改用 rsync 同步（
config.vm.synced_folder ".", "/vagrant", type: "rsync"）可绕过所有挂载问题，但不支持实时双向同步
真正卡住人的从来不是命令怎么敲，而是内核模块没加载、DNS 拦截了 NFS、或者你以为“box 下载完就万事大吉”，结果 cloud-init 卡在 Waiting for network to be configured...。把 vagrant up --debug | head -50 的前几十行日志看懂，比背十遍 vagrant 子命令有用得多。
