[Libosinfo] [osinfo-db PATCH 2/3] workload: Example of restricted high-perf

[Daniel P. Berrangé]

On Sat, Nov 17, 2018 at 01:06:12AM +0100, Martin Kletzander wrote:
> This example is taken from oVirt's high performance VM:
> 
>   https://www.ovirt.org/develop/release-management/features/virt/high-performance-vm/
> 
> The idea behind it is that all unnecessary devices are removed, here only usb
> controllers and video devices are removed, see URL above for more devices to be
> removed.
> 
> Ideally this should also require serial port, but that can be derived from a
> headless VM (similarly to oVirt).
> 
> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> ---
>  .../example.com/super-high-perf.xml.in        | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 data/workload/example.com/super-high-perf.xml.in
> 
> diff --git a/data/workload/example.com/super-high-perf.xml.in b/data/workload/example.com/super-high-perf.xml.in
> new file mode 100644
> index 000000000000..099d8b63d820
> --- /dev/null
> +++ b/data/workload/example.com/super-high-perf.xml.in
> @@ -0,0 +1,39 @@
> +<libosinfo version="0.0.1">
> +<!-- Licensed under the GNU General Public License version 2 or later.
> +     See http://www.gnu.org/licenses/ for a copy of the license text -->
> +  <workload id="http://example.com/high-perf">
> +    <short-id>super-high-perf</short-id>
> +    <_name>Super High Performance</_name>
> +    <derive-from id="http://example.com/high-perf"/>
> +  </workload>
> +
> +  <features>
> +    <remove>usb-controllers</remove> <!-- device class? -->
> +    <remove>video</remove>
> +  </features>

Yes, I think I'd express those explicitly as device classes:

     <devices>
         <class supported="false">video</class>
         <class supported="false">usb-controller</class>
         <class supported="true">disk</class>
     </devices>


> +    <!--
> +        or just
> +        <devices>
> +          <device id="http://usb.org/*" removed="true"/>
> +        </devices>
> +
> +        after which the application might be intelligent enough to just not put
> +        the controller there.  It's not going to work with video devices
> +        because.

Definitely not this - id URLs should be treated as completely opaque
strings. Nothing should try to parse or interpet sub-strings within
them.

> +    -->
> +
> +  <non-migratable>
> +    <features>
> +      <cache>passthrough</cache>
> +    </features>
> +    <cpu>
> +      <model>host-passthrough</model>
> +    </cpu>
> +  </non-migratable>

Not sure I understand the point of a "<non-migratable>" element here.

Why wouldn't you just have seperate workloads "super-high-perf-migratable"
and "super-high-perf-non-migratable"

> +  <!--
> +      this is an idea for having the information of "passthrough everything for
> +      high-perf, but you won't be able to migrate" put in the data.  But I don't
> +      really think this is needed.  But getting a feedback might prove me
> +      otherwise.
> +  -->
> +</libosinfo>

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 :|