在 Collabora 公司，我们所做的许多工作之一就是为客户构建包括 32 位和 64 位 ARM 系统在内的各种架构的 Debian 衍生版。就像 Debian 做的那样，我们的 OBS 系统建立在原生系统而不是仿真器上。

幸运的是随着几年前 ARM 服务器系统的出现，为这些系统原生构建不再像以前那么痛苦了。对于 32 位的 ARM，我们一直依赖 Calxeda 刀片服务器，然而不幸的是 Calxeda 在不久前淘汰，硬件开始显露其年龄（尽管幸运的是 Debian Stretch 还支持它，因此至少软件还是新的）。

在 64 位 ARM 方面，我们运行在基于 Gigabyte MP30-AR1 的服务器上，该服务器可以运行 32 位的 ARM 代码（与之相反，比如基于 ThunderX 的服务器只能运行 64 位代码）。像这样在它们之上运行 armhf 虚拟机作为 从构建服务器 （ build slaves ） 似乎是一个很好的选择，但是设置起来可能会需要更多东西的介入。

第一个陷阱是 Debian 中没有标准的 bootloader 或者 boot 固件来启动 qemu 仿真的 “virt” 设备（我不想使用真实机器的仿真）。这也意味着在启动时客户机内没有任何东西会加载内核，也不会从客户机网络引导，这意味着需要直接的内核引导。

第二个陷阱是当前的 Debian Stretch 的 armhf 内核并不支持 qemu 虚拟机所提供的通用 PCI 主机控制器，这意味着客户机中不会出现存储器和网络。希望这会被尽快解决（Debian bug 864726），并出现在 Stretch 更新中，那在之前需要使用 bug 报告中附带的补丁的自定义内核，但在这篇文章中我不想进一步说。

高兴的假设我们有一个可用的内核，剩下的挑战是很好地管理直接内核加载。或者更具体地说，如何确保主机启动客户机通过标准 apt 工具安装的内核，而不必在客户机/主机之间复制内核，这本质上归结于客户机将 /boot 暴露给主机。我们选择的方案是使用 qemu 的 9pfs 支持来从主机共享一个文件夹，并将其用作客户机的 /boot。对于 9p 文件夹，似乎需要 “mapped” 安全模式，因为 “none” 模式对 dpkg 有问题（Debian bug 864718）。

由于我们使用 libvirt 作为我们的虚拟机管理器，剩下的事情就是如何将它们组合到一起。

第一步是安装系统，基本和平常一样。可以直接引导进入由普通的 Stretch armhf netboot 安装程序提供的 vmlinuz 和 initrd.gz（下载到如 /tmp 中）。 设置整体来说很直接，会有一些小的调整：

• /srv/armhf-vm-boot 设置为 9p 共享文件夹（这个应该存在，并且由 libvirt-qemu 拥有），这之后会被用于共享 /boot。
• 内核参数中在 root= 后面加上 VM 中的 root 分区，根据你的情况调整。
• 镜像文件使用 virtio 总线，这似乎不是默认的。

除了这些调整，最后的示例命令与 virt-install 手册页中的相似。

virt-install --name armhf-vm --arch armv7l --memory 512 \
  --disk /srv/armhf-vm.img,bus=virtio
  --filesystem /srv/armhf-vm-boot,virtio-boot,mode=mapped \
  --boot=kernel=/tmp/vmlinuz,initrd=/tmp/initrd.gz,kernel_args="console=ttyAMA0,root=/dev/vda1"

按照通常的方式运行安装。到最后安装程序可能会提示它不知道如何安装引导程序，这个没什么问题。只要在结束安装和重启之前，切换到 shell 并以某种方式将目标系统中的 /boot/vmlinuz 和 /boot/initrd.img 复制到主机中（比如 chroot 进入 /target 并在已安装的系统中使用 scp）。 这是必需的，因为安装程序不支持 9p，但是要启动系统，需要 initramfs 以及能够挂载根文件系统的模块，这由已安装的 initramfs 提供。这些完成后，安装就可以完成了。

接下来，引导已安装的系统。调整 libvirt 配置（比如使用 virsh 编辑并调整 xml）来使用从安装程序复制过来的内核以及 initramfs，而不只是使用它提供的。再次启动虚拟机，它应该就能愉快地进入安装的 Debian 系统中了。

要在客户机这一侧完成，/boot 应该移动到共享的 9pfs 中，/boot 的新 fstab 条目看上去应该这样：

virtio-boot /boot  9p trans=virtio,version=9p2000.L,x-systemd.automount 0 0

有了这一步，这只是将 /boot 中的文件混到新的文件系统里面，并且客户机完事了（确保 vmlinuz/initrd.img 保持符号链接）。内核可以如常升级，并对主机可见。

这时对于主机端，有另外一个问题需要跨过，由于客户机使用 9p 映射安全模式，客户机的符号链接对主机而言将是普通的包含链接目标的文件。为了解决这个问题，我们在客户机启动前使用 libvirt qemu 的 hook 支持来设置合适的符号链接。作为一个例子，下面是我们最终使用的脚本（/etc/libvirt/hooks/qemu）：

vm=$1
action=$2
bootdir=/srv/${vm}-boot

if [ ${action} != "prepare" ] ; then
  exit 0
fi

if [ ! -d ${bootdir} ] ; then
  exit 0
fi

ln -sf $(basename $(cat ${bootdir}/vmlinuz))  ${bootdir}/virtio-vmlinuz
ln -sf $(basename $(cat ${bootdir}/initrd.img))  ${bootdir}/virtio-initrd.img

有了这个，我们可以简单地定义 libvirt 使用 /srv/${vm}-boot/virtio-{vmlinuz,initrd.img} 作为机器的内核 / initramfs，并且当 VM 启动时，它会自动获取客户机安装的最新内核 / initramfs。

只有最后一个边缘情况了，当从 VM libvirt 重启会让 qemu 处理它而不是重启 qemu。如果这不幸发生的话，意味着重启不会加载新内核。所以现在我们通过配置 libvirt 来解决这个问题，从而在重启时停止虚拟机。由于我们通常只在升级内核（安装）时重启 VM，虽然这有点乏味，但这避免了重启加载的是旧内核 / initramfs 而不是预期的。