On Tue, Sep 04, 2018 at 02:42:47PM -0400, Cole Robinson wrote: > Though while we are considering extending the API I figure I'll mention the > other metadata bits that I think should end up in libosinfo, but it's not > clear yet if/how to expose them. Maybe it will shake out some other ideas > > Already tracked virt-manager: > * clock localtime vs utc Makes sense > * don't combine x2apic with solaris10/11: > https://bugs.launchpad.net/qemu/+bug/1395217 > * UEFI + hyperv clock can't be combined with certain windows OS: > https://bugs.launchpad.net/qemu/+bug/1593605 > https://bugzilla.redhat.com/show_bug.cgi?id=1185253 This gets a little difficult - how do we come up with osinfo XML to express arbitrary feature bugs in guest OS ? > Kinda tracked in virt-manager: > * Enabling hyper-v enlightenments for windows guests. Right now we just turn > them on if in the OS is windows family, but I believe it could be more fine > grained than that. Like maybe osinfo should advertise which enlightenment > features each windows version supports. Part of the weirdness here is that > linux infact supports these enlightenments as well, for better behavior when > linux runs on top of hyper-v, but we don't want to enable them for > linux+kvm. Not sure if/how that would be represented. Yeah, I wonder if this is a case for "simplified" feature representation just indicating a series of standardized feature names, whcih apps then turn into fully fledged XML. > Not presently tracked in virt-manager: > * Some windows versions limit the max number of CPU sockets: > https://bugzilla.redhat.com/show_bug.cgi?id=1335977 This definitely feels relevant The hardest thing in all of this is deciding how to represent this in the XML and API without an explosion in the number of APis we need to implement. 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
