Re: [libvirt] [PATCH v4 2/5] libxl: add support for PVH
On 10/18/18 11:35 AM, Marek Marczykowski-Górecki 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?
I don't see a problem - each guest block represent set of possible
configurations. Given the current structure, you could also ask "is
the os_type for arch=x86_64 a xen or a hvm?". Both are valid, with
possibly different set of features available. And the same goes for
xenpv and xenpvh machines.
Right, it is not a problem. I've not been super confident in our modeling choice
and keep coming up with lame reasons while VIR_DOMAIN_OSTYPE_XENPVH might be a
better approach. But it is time for me to stop talking in circles and commit
this series. VIR_DOMAIN_OSTYPE_XENPV and machine xenpvh still feels like the
best approach and no one has flat out objected to that. We can always adjust the
capabilities reporting later if we feel there is a better way to do it.
Actually, I see qemu had similar problem as we have now with some
features
being specific to some machine value - maxCpus. And as solution, it was
put in machine's attributes. But I think this approach is short-sighted.
Agreed, we can't just keep adding attributes. Seems a better approach would be
<features> for each <machine>, but that is beyond the scope of this series.
Regards,
Jim