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

[Martin Kletzander]

On Tue, Nov 20, 2018 at 03:55:11PM +0000, Daniel P. Berrangé wrote:
>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>
>

I like that one better as well.  We just need to add the class data to the
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"
>

Sure, that could work as well.  Again this was just one of the ideas.

>> +  <!--
>> +      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 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20181123/a0347a59/attachment.sig>