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@xxxxxxxxxx> --- .../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 :|
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
