Re: "make check-acceptance" takes way too long

[Alex Bennée]

Stefano Brivio <sbrivio@redhat.com> writes:

> On Tue, 1 Feb 2022 09:06:25 +0000
> Daniel P. Berrangé <berrange@redhat.com> wrote:
>
>> On Tue, Feb 01, 2022 at 07:31:39AM +0100, Stefano Brivio wrote:
>> > Hi,
>> > 
>> > On Tue, 25 Jan 2022 10:20:11 +0100
>> > Gerd Hoffmann <kraxel@redhat.com> wrote:
>> >   
>> > >   Hi,
>> > >   
>> > > > IMHO the ideal scenario would be for us to have a kernel, initrd
>> > > > containing just busybox tools for the key arch targets we care
>> > > > about. Those could be used with direct kernel boot or stuffed
>> > > > into a disk iamge. Either way, they would boot in ~1 second,
>> > > > even with TCG, and would be able to execute simple shell scripts
>> > > > to test a decent amount of QEMU functionality.    
>> > > 
>> > > I have some test images based on buildroot which are essentially that.
>> > > https://gitlab.com/kraxel/br-kraxel/
>> > > 
>> > > Still a significant download, but much smaller than a full fedora or
>> > > ubuntu cloud image and it boots much faster too.  Not down to only one
>> > > second though.  
>> > 
>> > I'm not sure you can recycle something from it, but my (ugly) approach
>> > to make this fast (for a different purpose -- I'm using qemu to run
>> > tests in guests, not testing qemu) is to build an initramfs by copying
>> > the host binaries I need (a shell, ip, jq) and recursively sourcing
>> > libraries using ldd (I guess I mentioned it's ugly).
>> > 
>> > No downloads, systemd, dracut, etc., guest boots in half a second
>> > (x86_64 on x86_64, KVM -- no idea with TCG). Host kernel with a few
>> > modules packed and loaded by a custom init script.  
>> 
>> That is such a good idea, that it is exactly what I do too :-)
>> 
>>   https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py
>> 
>> it works incredibly well for the simple case of host-arch==guest-arch.
>
> Ah-ha, I feel better now. ;)
>
>> It could be made to work for foreign arch easily enough - just need
>> to have a foreign chroot lieing around somewhere you can point it
>> to.
>
> By the way, stage3 archives from:
>
>       https://www.gentoo.org/downloads/#other-arches
>
> get quite close to it ...no kernel binaries though.

We have up to now tried really hard as a project to avoid building and
hosting our own binaries to avoid theoretical* GPL compliance issues.
This is why we've ended up relying so much on distros to build and host
binaries we can use. Most QEMU developers have their own personal zoo of
kernels and userspaces which they use for testing. I use custom kernels
with a buildroot user space in initramfs for example. We even use the
qemu advent calendar for a number of our avocado tests but we basically
push responsibility for GPL compliance to the individual developers in
that case.

*theoretical in so far I suspect most people would be happy with a
reference to an upstream repo/commit and .config even if that is not to
the letter of the "offer of source code" required for true compliance.

-- 
Alex Bennée