Re: [libvirt] [PATCH 10/10] xenconfig: add support for type="pvh"
On 9/14/18 5:41 PM, Marek Marczykowski-Górecki wrote:
On Fri, Sep 14, 2018 at 05:21:17PM -0600, Jim Fehlig wrote:
> On 8/5/18 3:48 PM, Marek Marczykowski-Górecki wrote:
>> Handle PVH domain type in both directions (xen-xl->xml, xml->xen-xl).
>> And add a test for it.
>>
>> Signed-off-by: Marek Marczykowski-Górecki
<marmarek(a)invisiblethingslab.com>
>> ---
>> Does domain_conf.c (virDomainDefFormatInternal) still need to silently
>> convert VIR_DOMAIN_OSTYPE_XEN to VIR_DOMAIN_OSTYPE_LINUX? In case of
>> PVH, VIR_DOMAIN_OSTYPE_LINUX was never reported as a valid option...
>
> I'd prefer that we switch to formatting type as VIR_DOMAIN_OSTYPE_XEN
See discussion on patch 1/10...
Opps, I thought I had already replied to this but apparently not. Let me try
again...
I guess it is possible to extend the hack in virDomainDefFormatInternal to also
check for def->os.machine == "xenpv" before converting to
VIR_DOMAIN_OSTYPE_LINUX.
> and
> indicating PV vs PVH with the machine attribute.
It's already here.
Yes, I know :-).
> For back compat we'd need
> to continue accepting <type>linux</type> when parsing XML. Other than a
lot
> of changes to test suite data files, am I overlooking compatibility problems
> with such a change?
Still accepting <type>linux</type> obviously must stay. But if we change
what is reported when formatting XML, it may cause:
- unexpected configuration change, confusing to the user (no manual
change, but XML is different)
And I think this is the reason for danpb's objection.
- that XML may not load on very old libvirt versions (I can't
find
exactly which one, but older than 0.7.2, which was almost 10 years
ago)
Personally I don't think either of this is a problem.
I agree that libvirt producing different guest XML after an update is not
appealing. But I do think we can extend the existing hack in
virDomainDefFormatInternal.
Regards,
Jim