Expose in guests.yaml the provisioned HW setup to support <partitions> Beaker XML element

[thrix]

In some cases, it would be handy if the user would be able to read the hardware that was provisioned to do additional setup in the prepare phase.

For example, the user could ask for X block devices to be created and would be able to detect their

This could help to implement more generally part of the use cases for the <partitions> element in the Beaker XML format.

https://beaker-project.org/docs/user-guide/customizing-partitions.html

Note that this would not help with modifying the root partition, but for that we already have the kickstart field.

Kernel QE requirement: https://issues.redhat.com/browse/KQE-49
Testing Farm Jira: TBD

[thrix]

This seems a different approach as with #1835 proposal which would require tmt execution support.

[happz]

It probably makes no sense to describe every property of the guest, it could easily turn into some kind of Beaker inventory script.

• I'd like to follow the existing HW specification from https://tmt.readthedocs.io/en/stable/spec/hardware.html
• only fields for which we define extra "runtime manifest" fields would be added
• sometimes we could be able to re-use the HW specification key directly, for some properties we will need to add some, I guess:

# Requested:
hardware:
  disk:
    - size: "120 GiB"
    - size: "256 GiB"
    - size: "512 GiB"
  virtualization:
    hypervisor: != xen

# Something like this we could emit into a "manifest file":
hardware:
  disk:
    - block-device: /dev/vda
    - block-device: /dev/vdb
    - block-device: /dev/vdc
  virtualization:
    hypervisor: nitro

[happz]

And the link to guest topology describing what tmt knows about guests: https://tmt.readthedocs.io/en/stable/spec/plans.html#guest-topology-format

[happz]

One blocking issue for virtual aka testcloud, https://pagure.io/testcloud/issue/164