Project

General

Profile

Actions

action #164018

open

Enable additional options for the qemu device when creating a VM in openQA

Added by jlausuch 1 day ago. Updated 1 day ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2024-07-16
Due date:
% Done:

0%

Estimated time:

Description

Motivation

The new SL Micro 6.1 PowerPC images are created with 2 flavors: 512 and 4096 block sizes. The reason is to allow users pick one or the other depending on the physical storage to be used. In qemu, both can be used, but an additional flag needs to be specified in the device entry:
-device xyz,logical_block_size=4096,physical_block_size=4096

So, as an example, this is extracted from an openQA job directly:

> /usr/bin/qemu-img create -f qcow2 -F raw -b /var/lib/openqa/pool/1/SL-Micro.ppc64le-6.1-Base-ppc-4096-Build3.12.raw /var/lib/openqa/pool/1/raid/hd0-overlay0 32G`
> /usr/bin/qemu-img create -f qcow2 -F qcow2 -b /var/lib/openqa/pool/1/ignition.qcow2 /var/lib/openqa/pool/1/raid/hd1-overlay0 10485760`
> /usr/bin/qemu-system-ppc64 -device VGA,edid=on,xres=1024,yres=768 -g 1024x768 -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.fdtypeA=none -m 1024 -machine usb=off -cpu host -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -boot order=c -device nec-usb-xhci -device usb-tablet -device usb-kbd -smp 1,threads=1 -enable-kvm -no-shutdown -vnc :91,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev pipe,id=virtio_console_user,path=virtio_console_user,logfile=virtio_console_user.log,logappend=on -device virtconsole,chardev=virtio_console_user,name=org.openqa.console.virtio_console_user -chardev socket,path=qmp_socket,server=on,wait=off,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-overlay0-file,filename=/var/lib/openqa/pool/1/raid/hd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0-overlay0,file=hd0-overlay0-file,cache.no-flush=on,discard=unmap -device virtio-blk,id=hd0-device,drive=hd0-overlay0,bootindex=0,serial=hd0 -blockdev driver=file,node-name=hd1-overlay0-file,filename=/var/lib/openqa/pool/1/raid/hd1-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd1-overlay0,file=hd1-overlay0-file,cache.no-flush=on,discard=unmap -device virtio-blk,id=hd1-device,drive=hd1-overlay0,serial=hd1

So, the line that says
-device virtio-blk,id=hd0-device,drive=hd0-overlay0,bootindex=0,serial=hd0
would become
-device virtio-blk,id=hd0-device,drive=hd0-overlay0,bootindex=0,serial=hd0,logical_block_size=4096,physical_block_size=4096

For reference: https://bugzilla.suse.com/show_bug.cgi?id=1227707#c6

A possible solution, would be to create a new variable HDD_1_OPTIONS (or similar) which appends the value of this variable to -dev.

Acceptance criteria

  • TBD

Suggestions

  • Add an option in openQA using variables to append this configuration to the block device
Actions #5

Updated by okurz 1 day ago

  • Description updated (diff)
  • Category set to Feature requests
  • Target version set to future

Sorry, I don't see it possible to treat this request with high priority within the tools team right now given our current backlog https://progress.opensuse.org/issues?query_id=230 . But it looks like something that maybe is possible to be done easy enough by anyone outside the tools team as it seems to not rely too much on openQA internals and such

I changed the headers following our template https://progress.opensuse.org/projects/openqav3/wiki/#Feature-requests . I replaced what you called "Acceptance criteria" with "Suggestions" which I think better fits what you wrote. If you would like to learn more about acceptance criteria please see https://resources.scrumalliance.org/Article/need-know-acceptance-criteria

Actions #6

Updated by livdywan 1 day ago

okurz wrote in #note-5:

But it looks like something that maybe is possible to be done easy enough by anyone outside the tools team as it seems to not rely too much on openQA internals and such

Just having a brief look, I imagine one would probably add the options to get_cmdline in DriveDevice.pm. This is configured using variables like HDDMODEL_ and HDD_ in configure_blockdevs in Proc.pm, and probably where a new HDD_*_OPTIONS would be checked. DriveDevice.pm could have a new property like hdd_options.

Actions

Also available in: Atom PDF