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: > > On 10/19/18 8:14 AM, Daniel P. Berrangé wrote: > > > On Fri, Oct 19, 2018 at 08:06:18AM -0600, Jim Fehlig wrote: > > > > On 10/19/18 3:11 AM, Daniel P. Berrangé wrote: > > > > > On Thu, Oct 18, 2018 at 11:08:34AM -0600, Jim Fehlig wrote: > > > > > > On 10/17/18 12:59 PM, Marek Marczykowski-Górecki wrote: > > > > > > > On Sat, Oct 13, 2018 at 08:46:19AM -0600, Jim Fehlig wrote: > > > > > > > > I had some couch time at the start of the weekend and was > > > > > > > > finally able to > > > > > > > > try using this series with virt-install. As it turns out, > > > > > > > > reporting > > > > > > > > duplicate <guest> blocks for <os_type> 'xen' is not quite > > > > > > > > right. Instead we > > > > > > > > will want to report the additional <machine> under the existing > > > > > > > > 'xen' > > > > > > > > <guest> blocks. > > > > > > > > > > > > > > Is that virt-install limitation? In that case, IMO virt-install > > > > > > > should > > > > > > > be fixed, instead of changing capabilities xml to match its > > > > > > > limitations. > > > > > > > > > > > > Perhaps it is a virt-install limitation, but my suggestion was > > > > > > based more on > > > > > > how the qemu driver reports the different machines > > > > > > > > > > > > <guest> > > > > > > <os_type>hvm</os_type> > > > > > > <arch name='x86_64'> > > > > > > <wordsize>64</wordsize> > > > > > > <emulator>/usr/bin/qemu-system-x86_64</emulator> > > > > > > <machine maxCpus='255'>pc-i440fx-3.0</machine> > > > > > > <machine maxCpus='288'>pc-q35-3.0</machine> > > > > > > ... > > > > > > </arch> > > > > > > </guest> > > > > > > > > > > > > Compare that with reporting PV and PVH in different <guest> blocks, > > > > > > where > > > > > > the <os_type> and <arch> are the same. It seems confusing from a > > > > > > consumers > > > > > > POV > > > > > > > > > > > > <guest> > > > > > > <os_type>xen</os_type> > > > > > > <arch name='x86_64'> > > > > > > <wordsize>64</wordsize> > > > > > > <emulator>/usr/bin/qemu-system-x86_64</emulator> > > > > > > <machine>xenpv</machine> > > > > > > </arch> > > > > > > </guest> > > > > > > > > > > > > <guest> > > > > > > <os_type>xen</os_type> > > > > > > <arch name='x86_64'> > > > > > > <wordsize>64</wordsize> > > > > > > <emulator>/usr/bin/qemu-system-x86_64</emulator> > > > > > > <machine>xenpvh</machine> > > > > > > </arch> > > > > > > </guest> > > > > > > > > > > > > How should a consumer interpret that? Is the machine for > > > > > > os_type=xen, > > > > > > arch=x86_64 a xenpv or a xenpvh? > > > > > > > > > > Yes, you are right - any pair of (os_type, arch) should be unique > > > > > in the capabilities XML. So all machines should be reported in the > > > > > same block. > > > > > > > > Our difficulty with that is xenpv and xenpvh machines have different > > > > features. Marek pointed out that the qemu driver reports the "feature" > > > > maxCpus as an attribute on the machine element, but we're hesitant to > > > > keep > > > > adding attributes for each feature that is unique to a machine. > > > > > > > > Another option we discussed was reporting a superset of all features so > > > > that > > > > e.g. (xen, x86_64) block would contain features supported by both PV > > > > and PVH > > > > and then rejecting unsupported features when parsing domXML or starting > > > > the > > > > VM. This option is rather distasteful. > > > > > > > > And we also have the option of adding VIR_DOMAIN_OSTYPE_XENPVH, which > > > > I've > > > > shied away from but may be a better way to go in the end. Do you have > > > > any > > > > suggestions we may have overlooked? > > > > > > Oooh, it looks like i've been mis-understanding PVH in all my previous > > > reviews. > > > > > > I thought it was simply a "normal" Xen paravirtualized guest kernel. ie > > > any 'pv' guest is also a valid 'pvh' guest. Looking at the docs > > > > > > https://wiki.xen.org/wiki/Xen_Project_Software_Overview#Guest_Types > > > > > > It appears I was wrong. It says a pvh guest kernel relies on hardware > > > virt extensions for part of its work and paravirt for other parts. So > > > really is a hybrid between pv and hvm. > > > > Right. The Xen wiki also has a good writeup about the various guest types > > > > https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum > > > > > With that in mind, we should indeed have a distinct OS type constant > > > to express this. > > > > There have been some long threads in the various versions of this series > > with a lot of waffling :-). I made a few attempts at summarizing what we > > learned about PV vs PVH but could never build a strong case (at least in my > > 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? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list