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.
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. But then, it should probably reject PV features for PVH
machine somewhere - in post parse hook? Or maybe it should forcibly
remove them - for example I see PAE is forcibly enabled for 64bit HVM
guests.
--
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?