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@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