Re: [libvirt] [PATCH v4 2/5] libxl: add support for PVH
On 10/16/18 7:23 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. E.g. instead of adding a duplicate
>
> <guest>
> <os_type>xen</os_type>
> <arch name='x86_64'>
> <wordsize>64</wordsize>
> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
> <machine>xenpvh</machine>
> <domain type='xen'/>
> </arch>
> ...
> </guest>
>
> we'll want to include the xenpvh machine in the existing <guest> config for
xen
>
> <guest>
> <os_type>xen</os_type>
> <arch name='x86_64'>
> <wordsize>64</wordsize>
> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
> <machine>xenpvh</machine>
> <machine>xenpv</machine>
> <domain type='xen'/>
> </arch>
> </guest>
>
> With this change to the capabilities reporting, virt-install works without
> modification using
>
> virt-install --paravirt --machine xenpv ...
>
> I didn't think too hard about the best way to handle this, but the attached
> diff is a POC hack that works with unmodified virt-install.
I can get it reported this way, but it will be wrong, because <features>
will be incorrectly reported. For example hap should be reported for
xenpvh, but not for xenpv, so bundling them together makes it
impossible. Similar for acpi and probably others too.
Yes, you are correct :-(. Modeling PVH has been more of a PITA than I expected.
If this really needs to be reported together, I'd go with reporting
superset of features, so os_type xen entry will have all features of PV
and PVH.
Reporting features that cannot possibly be supported doesn't see right. Let's
summarize what we've learned thus far and see if that helps with modeling PVH.
PVH is a new xen machine type that is a hybrid of PV and HVM. Like HVM, PVH
requires hardware virtualization support. Like PV, PVH requires a modified guest
kernel, and one that is modified differently than PV (e.g. CONFIG_XEN_PVH vs
CONFIG_XEN_PV in the linux kernel). PV and PVH have different feature sets. E.g.
PVH supports HAP, ACPI, etc., but PV does not. (Perhaps another useful data
point: the long term goal of the xen community is to remove CONFIG_XEN_PV,
essentially making PVH the new PV from xen perspective, but that is obviously a
long ways out.)
Currently in libvirt, PV is modeled as VIR_DOMAIN_OSTYPE_XEN and machine
"xenpv". HVM is modeled as VIR_DOMAIN_OSTYPE_HVM and machine "xenfv".
For PVH
we've considered VIR_DOMAIN_OSTYPE_XENPVH with machine "xenpvh", or simply
adding PVH as machine "xenpvh" under existing VIR_DOMAIN_OSTYPE_XEN.
I've pushed for adding a new machine "xenpvh" under existing
VIR_DOMAIN_OSTYPE_XEN with primary reason that both are OS types modified to run
on xen. Also existing tools like virt-{install,manager} know how to handle
OSTYPE_{HVM,XEN} and machines, allowing them to support PVH without (or with
minimal) modification.
Have I been narrow-minded with my "both are OS types modified to run on xen"
reasoning for using VIR_DOMAIN_OSTYPE_XEN? Should we really consider PVH a new
OSTYPE? Your reminder that PV and PVH have a different feature set hints to
modeling PVH as VIR_DOMAIN_OSTYPE_XENPVH. It is unfortunate that tools above
libvirt would have to be taught about this new OSTYPE, but that shouldn't
prevent using VIR_DOMAIN_OSTYPE_XENPVH if in fact it is the best way to model PVH.
Sadly I haven't strongly convinced myself one way or the other. I still like the
idea of reusing VIR_DOMAIN_OSTYPE_XEN and adding machine "xenpvh" since it seems
easier from an app perspective, but maybe I just need slapped and admit that PVH
is a new OSTYPE. (I'm sure you'd like to do the slapping at this point...)
Regards,
Jim