On Wed, 20 Nov 2019 at 17:36:39 +0100, Martin Pitt wrote:
> Francesco Poli (wintermute) [2019-11-08 23:59 +0100]:
> > Is there any hope to improve vmdb2 or to use another tool, in order
> > to create a KVM testbed without requiring superuser privileges?
>
> A much better approach to this would be what autopkgtest-buildvm-ubuntu-cloud
> does, and use a cloud image.
I think there's a place for both options. Starting from a cloud image
definitely seems better for a lowest-common-denominator, "I just want some
sort of testing" requirement set, and I would certainly prefer support
for new architectures to start from "first, make the cloud image work"
rather than always having to know how to build an autopkgtest-specific
bootable image from first principles.
One approach to this is to take a generic cloud image and modify it to
provide the serial ports that autopkgtest-virt-qemu currently needs,
like autopkgtest-buildvm-ubuntu-cloud does.
Another approach that I've been experimenting with is to make use of
the fact that cloud images already include cloud-init and a ssh server,
and use cloud-init to bring up the ssh server with a known public key
accepted. This seems less fragile than injecting commands on serial ports.
What building our own images *does* give us is total control. This is
partly bad, because we have to know all the tricks for making images
bootable on assorted architectures, but also partly good, because it lets
us test the different sorts of image that we want to support (EFI vs BIOS
boot, GPT vs MBR, systemd vs sysv-rc, merged-/usr vs unmerged-/usr).
This is particularly important when there are irreversible conversions
involved (you can go from unmerged /usr to merged /usr, but you can't
go from merged /usr to unmerged /usr).
I think the future I'd prefer to live in is that we *mostly* test on
cloud-derived images, but we also have the ability to build our own
autopkgtest-specific images for at least x86_64, and we can use those
to test the configurations that are not used on cloud images.
If that's how things work, then having autopkgtest-build-qemu be runnable
as non-root becomes a lot less important, because casual users with no
particularly special requirements will be using the cloud images anyway.
Another thing that has occurred to me when working on autopkgtest is
that it seems wasteful that we have so many wrappers around debootstrap,
which requires root (or playing with namespaces like mmdebstrap does,
or some other special action) and is not very fast. I would prefer to
be able to debootstrap a minbase tarball *once*, and then use that same
tarball as a basis for a bootable qemu image, lxc, lxd and Docker root
filesystems, and so on.
smcv
