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> > + <!-- > + 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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
