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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
