On Fri, Oct 19, 2018 at 05:10:30PM +0200, Marek Marczykowski-Górecki wrote: > On Fri, Oct 19, 2018 at 03:59:03PM +0100, Daniel P. Berrangé wrote: > > On Fri, Oct 19, 2018 at 08:53:15AM -0600, Jim Fehlig wrote: > > > own head) for either of the two modeling approaches > > > > > > https://www.redhat.com/archives/libvir-list/2018-October/msg00214.html > > > https://www.redhat.com/archives/libvir-list/2018-October/msg00891.html > > > > It has a bad name, but essentially you should consider "ostype" to > > refer to the Hypervisor <-> Guest hardware ABI. > > Oh, if that's the case, then indeed separate ostype makes sense. Maybe > it worth expanding ostype description somewhere in documentation? > > > Based on what I read, and your 2 links here, PV is clearly a different > > hardware ABI from PVH. Guest kernels needs different modifications for > > PV vs PVH. > > > > Sorry I didn't spot this sooner, and let this go off down the blind > > alley of switching based on machine type, when we should have used > > the ostype :-( > > What machine type should it use then? Still xenpvh, but make all the > decisions based on ostype? If Xen/QEMU calls the machine type 'xenpvh' then yeah we can still use it. By having a distinct ostype, when the XML says "xenpvh" for OS type, the XML parser can automatically find the correct machine type name from the capabilities data. So mgmt apps using libvirt won't need to set the machine type themselves, can just rely on the default, after they've set the ostype. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
