Control: tags -1 - patch Hi Simon,
On Sun, Jun 25, 2023 at 12:00:21PM +0100, Simon McVittie wrote: > Control: forwarded -1 > https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/236 Thanks for the extensive review both here and on the MR. Please allow me to ignore all the pycodestyle and similar things until we have a solution that meets functional requirements. > The inability to reboot into an updated initrd or kernel is quite > significant for autopkgtest, and I'd be very tempted to call it a > blocker: I think many of the tests that specifically want a VM, and > are not satisfied with a lxc/podman container, are going to want that > *because* they are doing kernel/initrd things. On the merge request > (thanks for opening that!) I suggested a way to fix that limitation by > running `qemu-system-whatever -no-reboot` in a loop, so that the kernel > and initrd can be re-extracted after each shutdown (where reboot(8) > in the VM is turned into a shutdown as a result of -no-reboot). I think this together with the insight from your other mail that you want to reduce divergence of test environments is really helpful guidance. I was aware of the option of a -no-reboot loop (and that's even mentioned in the debvm-run manual page), but that comes with the complication of figuring out when to shut down (as you explained in detail already). I need deeper understanding of the context to reply in a useful way here. Let me also give a different view on this. You argued that the main reason to use the qemu backend is the ability to reboot. I do not agree with this. From my point of view, the main motivation is the better isolation (than lxc) and therefore lower risk of damage to my system. I also note that there is a particular test restriction "needs-reboot" and the new vmlinux boot mode could declare that it does not support this restriction. Do you thin that this would be an ok-ish alternative to properly implementing reboot? > You say "cloud image" here, but official Debian cloud images are > partitioned disks, and debvm uses a raw ext* filesystem filling the > entire disk (no partition table). Did you mean "cloud kernel"? Yes. > I'm already not very happy with -virt-qemu's use of screen-scraping > serial gettys, because screen-scraping an interactive shell isn't a > reliable thing to do, and the root shell on tty1/hvc1 means we end up > running the tests in a rather unrealistic environment that doesn't match > anyone's real Debian system: in practice real Debian systems are much > more likely to be server + ssh, or graphical console + display manager, > or graphical or serial console + getty, and they're certainly not what > we end up using with -virt-qemu (which is usually serial console + > passwordless root shell + su into user shell). Ok, that's news to me, but good to know. In a sense, debvm is in a similar spot here. Its main purpose is providing reproducing some kind of environment (e.g. for reproducing a bug). The realistic part is of lower importance though. So for debvm, I chose three main ways to interact with it: * qemu -nographic and a serial console is the default * Running qemu with a graphical interface (interactively) and this can use a regular tty login or a display manager * ssh > The way I'm hoping to resolve that is to introduce a -virt-ssh setup > script that shares code (the autopkgtest_qemu module) with -virt-qemu, > at which point we can use some sort of early-boot mechanism (perhaps > cloud-init, or the serial console, or debugfs, or a virtual CD-ROM > containing a script) to inject an authorized ssh key into the image and > (if necessary) install sshd, and then access it via ssh like an ordinary > server from then on. That'll make the test environment more realistic. I'm not sure how this is going to work for autopkgtest-virt-qemu. For debvm, ease of interactive use was a primary goal (as you basically can everything you can do with debvm directly with mmdebstrap + qemu). Therefore, I opted for adding the authorized_keys setup to the image construction and you can simply pass a key to debvm-create and it'll also install the ssh server then. This is a different approach than the one you describe here where the key is added retroactively. I think I can support the mechanisms you describe here in a debvm-create step at ease. So how do we proceed here? Quite evidently, our goals diverge here. While my goals are ease of unprivileged use, safe containment and broad architecture support, your goals are reduction of divergence of test beds and realistically reproducing regular environments if I capture things correctly. In any case, thanks for the extensive high quality feedback. Helmut
