Re: [RFC PATCH 1/1] qtest/migration: Support more than one QEMU binary

[Daniel P . Berrangé]

On Wed, Oct 04, 2023 at 12:59:49PM -0300, Fabiano Rosas wrote:
> Juan Quintela <quintela@redhat.com> writes:
> 
> > Fabiano Rosas <farosas@suse.de> wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >>
> >>> On Tue, Oct 03, 2023 at 05:24:50PM +0200, Philippe Mathieu-Daudé wrote:
> > [...]
> >
> >>> $ cat myqemu.dkr 
> >>> FROM fedora:38
> >>>
> >>> RUN dnf -y install qemu-kvm
> >>>
> >>> $ podman build -f myqemu.dkr --tag myqemu .
> >>>
> >>> $ cat > myqemu <<EOF
> >>> #!/bin/sh
> >>> exec podman run --volume /tmp=/tmp --security-opt label=disable myqemu 
> >>> qemu-system-x86_64 "$@"
> >>>
> >>> $ chmod +x myqemu
> >>>
> >>> $ QTEST_QEMU_BINARY=./myqemu.sh  ./build/tests/qtest/rtc-test
> >>
> >> I'm favor of this. I usually set that variable to something like 'gdb
> >> --args ...' and it works just fine.
> >>
> >>> Except we fail on the last step, because bind mounts don't make UNIX 
> >>> domain
> >>> sockets accessible. So we can see the /tmp/qtest-$PID.sock in the 
> >>> container,
> >>> but it can't be used.
> >>>
> >>> UNIX domain sockets in the filesystem are tied to the mount namespace, and
> >>> podman/docker inherantly creates a new mount namespace making the UNIX
> >>> domani socket inaccessible.
> >>>
> >>> UNIX domain sockets in the abstract namespace, however, are tied to the
> >>> network namespace, so if you used podman --network host, they should be
> >>> accessible.
> >>>
> >>> libqtest could be changed to use abstract UNIX domain sockets on Linux
> >>> only, and likely unlock the use of podman for QEMU.
> >
> > That is one idea, but why can't we convince a container to compile
> > _both_ qemus?
> >
> > I am not familiar with containers, but:
> > - We already know how to compile a qemu inside a container
> > - We can teach it to compile $HEAD and v8.0.0 (or whatever)
> >
> > And do the test inside, right?
> >
> > On the other hand, your approach has the advantage that one can test
> > opensuse qemu against fedora qemu, and similar.  Not sure how useful is
> > that, though.
> >
> > [lots of code to find common machine types]
> 
> I'm working on a cleanup of this patch to make it more integrated with
> libqtest. If we teach qtest_get_machines() to sometimes refresh the list
> of machines then it becomes way less code.
> 
> > I think that it is just easier to pass the machine type we want to test
> > to whatever script we have.  Specially where [sane] architectures like
> > arm don't have a default machine type (no, I haven't double checked if
> > that has changed lately).
> 
> We still need to enforce the same machine type for both binaries and a
> sane range of QEMU versions. I think our docs state that we only support
> migration from QEMU n->n+1 and vice versa? If the test will know what
> combinations are allowed, it could just go ahead and use those.

Query the 'pc' (or 'q35' as appropriate) alias on both QEMU versions,
to resolve them into versioned machines.

Then find which resolved machine version(s) exist in both QEMUs, and
prefer the src machine if multiple matches exist.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|