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 :|