Conversation

Jarkko Sakkinen

It would be sometimes useful if #QEMU w/o libvirt could interpret domain XML to some level.

Like for instance if you want to CI kernel, that would be one use case for this.

For the sake of example, here’s the QEMU command-line that I use as starting point for any kernel testing/CI:

qemu-system-x86_64 \
  -M pc \
  -monitor unix:monitor.sock,server,nowait \
  -serial unix:serial.sock,server,wait \
  -drive file=disk.img,if=virtio,format=raw \
  -net nic,model=virtio \
  -net user,hostfwd=tcp::10022-:22 \
  -rtc base=localtime \
  -nographic \
  -chardev socket,id=chrtpm,path=${SWTPM_DIR}/swtpm-sock \
  -tpmdev emulator,id=tpm0,chardev=chrtpm \
  -device ${QEMU_TPM_DEVICE},tpmdev=tpm0 \
  -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
  "$@"
2
0
0

@jarkko I don't understand. How would XML improve your use case?

Also, why would you want to do it without libvirt? Interpreting domain XML and running QEMU is what using QEMU with libvirt does.

1
0
0
@janotomko It would be easier to have a few template configurations and XML can be more easily post-manipulated.
0
0
0

@jarkko what exactly do you need XML for? Is this just a carrier for the machine configuration.. in which case why not just use libvirt? You could always use to trigger an edit of the machine description if you want to change the kernel you boot in a particular domain.

1
0
0
@stsquad I generate the whole operating system for each kernel test build. I don't have a machine description when I start compiling it.

Essentially each test VM is also one shot, deleted after a single test run.

Basis is like https://codeberg.org/jarkko/linux-tpmdd-test
1
0
0
I even used to bootstrap qemu and swtpm for every single build at one point ;-) It is great when testing kernel features when you can always start from known state.
1
0
0
I guess I could create my own XML parser which then outputs run-qemu.sh.
0
0
0